* Can this be triggered by simply running ata_id or does it need any
other condition to trigger?
Yes, once the system has booted, issuing
lib/udev/ata_id-unpatched /dev/dvd
produces the same kernel panic nearly every time. Also, as I mentioned
earlier, the sg__sat_identify utility from sg3-utils-1.30 does the same
on 1-3 attempts out of 10; i.e., issuing
sg__sat_identify -vv -p /dev/dvd
On 01/11/2011 08:25 AM, Tejun Heo wrote:
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.
--
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
