public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Reuben Farrelly <reuben-lkml@reub.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Andrew Morton <akpm@osdl.org>,
	torvalds@osdl.org, gregkh@suse.de, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [GIT PATCH] PCI patches for 2.6.15 - retry
Date: Tue, 17 Jan 2006 02:11:32 +1300	[thread overview]
Message-ID: <43CB9B84.2060107@reub.net> (raw)
In-Reply-To: <43C6C331.1030602@pobox.com>



On 13/01/2006 9:59 a.m., Jeff Garzik wrote:
> Alan Cox wrote:
>> On Iau, 2006-01-12 at 16:55 +1300, Reuben Farrelly wrote:
>>
>>> ata1: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 0
>>> ata2: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x8 irq 0
>>> Unable to handle kernel NULL pointer dereference at virtual address 
>>> 00000000
>>
>>
>> That is the critical bit. The SATA ports have no PCI resources assigned
>> for bus mastering (BAR 4). libata should have driven the device PIO in
>> this case but the resource should have been assigned.
> 
> Agreed.  This appears to be BIOS assigning bad values to SATA hardware.
> 
> However, libata should recognize this and not attempt to iomap or drive 
> the hardware, in that case, rather than oops.
> 
>     Jeff

Some testing tonight has shown up a bit more about where this regression crept in.

Below the table reads release on left hand side, and the result of a given 
reboot on  the right hand side after the dash.  I had to do so many reboots to 
be sure that the bug was there or not - as you can see from the -mm1 test it 
doesn't always show up.

2.6.15 - OK OK OK OK OK
2.6.15-git1 - OK OK OK OK OK OK OK OK
2.6.15-git2 - OK
2.6.15-git6 - OK OK OK OK OK OK OK OK
2.6.15-git12 - OK OK OK OK OK OK OK

2.6.15-rc5-mm3 - OK OK OK(but oopsed in usb) OK OK(but oopsed in usb)
    Those oopses in USB were only seen in this release so looks likely whatever
    was causing them was fixed soon after.
2.6.15-mm1 - OK OK OOPSED OOPSED OOPSED all in ATA
2.6.15-mm2 + mm3 - [known to OOPS on this bug frequently but not tested in this 
round]
2.6.15-mm4 - OOPSED OK OOPSED TIMEOUT TIMEOUT OOPS OK
2.6.15-mm1 with no git-acpi.patch - TIMEOUT TIMEOUT OOPSED TIMEOUT OK

OK means the system booted up to single user mode without issue, TIMEOUT means 
that the controllers were assigned IRQ 50 and then failed to find any ATA disks 
and OOPSED means that he SATA ports were not assigned IRQs at all and hence the 
system oopsed out like this:

ahci: probe of 0000:00:1f.2 failed with error -12
ata1: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 0
ata2: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x8 irq 0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
  printing eip:
c023c873
*pde = 00000000
Oops: 0000 [#1]
<plus a trace and a whole lot more>

Full output on http://www.reub.net/files/kernel/outstanding-kernel-bugs.txt (as
usual)

In summary the good news is that 2.6.15-git12 (which is the latest linus tree)
is GOOD and does not seem to exhibit this problem.  Not a single -git release 
crapped out.  It seems some regression was introduced into 2.6.15-mm1 which has 
been carried forward through to -mm4 so far though but never pushed to Linus.
I guess it also suggests that it's not a hardware or bios issue given the sheer 
number of successful reboots in a row, and I think reverting the git-acpi.patch 
suggests that ACPI is not the cause of it, at least in this instance.  But 
that's about as far as I have gotten.

45 reboots later I'm finishing for tonight, but before I go back and hit it with
git bisect to narrow it down any further, Andrew/Jeff does this make it any 
easier to pinpoint, and/or do you have any preliminary patches to test or ideas 
as to what other subsystems could be involved?

Thanks,
Reuben




  reply	other threads:[~2006-01-16 13:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-09 20:37 [GIT PATCH] PCI patches for 2.6.15 - retry Greg KH
2006-01-10  0:00 ` Linus Torvalds
2006-01-10  0:44   ` Andrew Morton
2006-01-10  1:49     ` Alan Cox
2006-01-10  1:49       ` Andrew Morton
2006-01-10 10:03         ` Reuben Farrelly
2006-01-12  3:55         ` Reuben Farrelly
2006-01-12  4:29           ` Andrew Morton
2006-01-12  4:55             ` Reuben Farrelly
2006-01-12 11:42           ` Alan Cox
2006-01-12 20:59             ` Jeff Garzik
2006-01-16 13:11               ` Reuben Farrelly [this message]
2006-01-12 20:55       ` Jeff Garzik
2006-01-13  0:16         ` Alan Cox
2006-01-10  2:28     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43CB9B84.2060107@reub.net \
    --to=reuben-lkml@reub.net \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox