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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
