Date: Fri, 15 Jun 2012 11:17:53 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Boot hangs on v9 system at CD device probe Message-ID: <20120615091753.GR46065@alchemy.franken.de> In-Reply-To: <201206150716.q5F7GGCD053882@lurza.secnetix.de> References: <20120614222851.GQ46065@alchemy.franken.de> <201206150716.q5F7GGCD053882@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 15, 2012 at 09:16:16AM +0200, Oliver Fromme wrote: > Marius Strobl wrote: > > [...] > > > > > > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > > [...] > > > > I've committed it to head in r237107 as a band-aid for now as it's a > > sufficiently severe problem. Obviously, fixing ATA_CAM to not break > > ATAPI CAM instead is the right thing to do. I've already spent quite > > some time trying to find the underlying but didn't get anywhere with > > that so far though (granted, most of that wasted time was because of > > me thinking that this would be due to an endian bug only seen on big > > endian machines, which turned out to not be the case). AFAICT, mav@ > > also has ALI hardware affected by this issue, maybe he'll have a > > look at it eventually ... > > I'm not sure if it's the same or a different issue, but ATA_CAM > also breaks for me with a legacy P-ATA controller (UDMA-133) on > RELENG_9. Removing ATA_CAM and adding "atapicam" fixes it. > > I've described the problem in more detail here: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068175.html > > This is the controller in question: > > pciconf: > atapci0@pci0:3:6:0: class=0x018085 card=0x4d68105a chip=0x4d69105a rev=0x02 hdr=0x00 > vendor = 'Promise Technology, Inc.' > device = '20269' > class = mass storage > > dmesg: > atapci0: <Promise PDC20269 UDMA133 controller> port 0xdc00-0xdc07, > 0xd880-0xd883,0xd800-0xd807,0xcc00-0xcc03,0xc880-0xc88f mem > 0xfeaf8000-0xfeafbfff irq 21 at device 6.0 on pci3 This likely is a different issue as atapromise(4) already disables ATAPI DMA by default since before ATA_CAM hit the tree. > > Shall I open a PR with this? > It probably won't hurt to file one and assign it to mav@. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120615091753.GR46065>