Hello, On Mon, Jan 10, 2011 at 09:10:12AM +0100, Hannes Reinecke wrote: > > First, sorry for not posting something about this sooner - I'd > > pinged Kay on IRC about it, and I *promise* I had planned to > > forward it to the scsi/ati guys, but work has been hell this > > week. Anyway, here's the initial report we got about it, along > > with a lot of debugging by other folks (including the OP, who > > I think is 'resonance' in that thread): > > http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/ > > > It's all Tejun's fault. Gees, Hannes. That's very kind of you. :-P > kernel crashing in ata_sff_data_xfer / ioread32 ... > Looks like we're trying a read to a page which wasn't > mapped/allocated properly. > > And yes, it definitely should be fixed in the kernel first. Yeah, definitely. It isn't clear from the thread. * Is it a regression? * Can this be triggered by simply running ata_id or does it need any other condition to trigger? I don't recall any related change in the area, at least in libata, so it's a bit surprising. If it's a regression, I think it's more likely to be something between userland and libata. The user buffer mapping code for sg commands is quite scary after all. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
