Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c

[Tejun Heo <htejun@gmail.com>]

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