[PATCH 0/5] SATA/ACPI suspend/resume support

[PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

I've probably overlooked 1-2 small things, but this patchset
implements most of the changes that Jeff commented on about
2 weeks ago.  (Sorry for the delay.)

This is a series of 5 patches.  A rolled-up (combined) patch
is available at:
  http://www.xenotime.net/linux/SATA/2.6.15-rc7/libata-combine.patch

and all patches in the series (+ the quilt series file)
are available in:
  http://www.xenotime.net/linux/SATA/2.6.15-rc7/

patchset:
1.  libata_suspend.patch from Jens Axboe

2.  ata_acpi_make.patch
	Makefile, Kconfig, header, and kernel-doc changes

3.  libata-debugging.patch
	libata debugging infrastructure from Borislav Petkov
	(used in libata-acpi.patch)

4.  libata-acpi.patch
	The main SATA ACPI support functions

5.  libata-param.patch
	Add 'noacpi' and 'printk' module parameters.
	Update Documentation/kernel-parameters.txt

NOTES:
1.  not added (yet):  "platform" functions
2.  not yet using ata_exec_internal()

---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
While booting, it locks up after printing

    ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
    ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
    ata1(0): applying bridge limits
    ata1: dev 0 configured for UDMA/100

If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
panics during boot.

By the way, I found that kernel 2.6.15-rc7 with the following patches
work with or without the snd_intel8x0m module.

    git-libata-all.patch
    libata_resume_fix.patch
    libata_suspend-fix.patch
    libata_suspend.patch
    from http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/

Jae-hyeon

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 30 Dec 2005 17:36:44 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> While booting, it locks up after printing
> 
>     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
>     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
>     ata1(0): applying bridge limits
>     ata1: dev 0 configured for UDMA/100
> 
> If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> panics during boot.

Hi,

Can you capture the kernel oops & panic messages?

Please send me your .config also.

Is this on your Fujitsu notebook with some kind of hybrid
PATA/SATA?

> By the way, I found that kernel 2.6.15-rc7 with the following patches
> work with or without the snd_intel8x0m module.

I don't understand this part.  What does the intel sound
driver have to do with this?

>     git-libata-all.patch
>     libata_resume_fix.patch
>     libata_suspend-fix.patch
>     libata_suspend.patch
>     from http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

On Tue, Jan 03 2006, Randy Dunlap wrote:
> On 30 Dec 2005 17:36:44 +0900
> Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> 
> > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > While booting, it locks up after printing
> > 
> >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> >     ata1(0): applying bridge limits
> >     ata1: dev 0 configured for UDMA/100
> > 
> > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > panics during boot.
> 
> Hi,
> 
> Can you capture the kernel oops & panic messages?

I think I triggered the same oops on my T43, I'll try applying your sata
acpi patches and see if it reproduces.

> Please send me your .config also.
> 
> Is this on your Fujitsu notebook with some kind of hybrid
> PATA/SATA?

He notes it's an X41 - by the messages above, it is indeed a PATA drive
hidden behind a SATA bridge. The T43 uses the same kind of setup.

-- 
Jens Axboe

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

On Tue, Jan 03 2006, Jens Axboe wrote:
> On Tue, Jan 03 2006, Randy Dunlap wrote:
> > On 30 Dec 2005 17:36:44 +0900
> > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > 
> > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > While booting, it locks up after printing
> > > 
> > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > >     ata1(0): applying bridge limits
> > >     ata1: dev 0 configured for UDMA/100
> > > 
> > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > panics during boot.
> > 
> > Hi,
> > 
> > Can you capture the kernel oops & panic messages?
> 
> I think I triggered the same oops on my T43, I'll try applying your sata
> acpi patches and see if it reproduces.

It's crashing here:

                acpi_os_free((void *)gtf_address);

in ata_acpi_exec_tfs(), looks like it's trying to free an uninitialized
gtf_address. Setting to 0 and doing:

        if (gtf_address)
                acpi_os_free((void *)gtf_address);

fixes it. Probably due to a nasty warning that it spews on boot:

ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
88:203f
ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
ata_acpi_exec_tfs: call get_GTF, ix=0
ata_acpi_exec_tfs: call set_taskfiles, ix=0
do_drive_set_taskfiles: unexpected GTF length (-271707516)
scsi0 : ata_piix
  Vendor: ATA       Model: ST980825A         Rev: 3.04
  Type:   Direct-Access                      ANSI SCSI revision: 05

note the 'unexpected GTF length' message. Doing a suspend/resume cycle
doesn't trigger that error:

[...]
eth1: Coming out of suspend...
ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 21 (level, low) -> IRQ 23
ata1: dev 0 configured for UDMA/100
ata_acpi_exec_tfs: call get_GTF, ix=0
ata_acpi_exec_tfs: call set_taskfiles, ix=0
Restarting tasks... done
[...]

-- 
Jens Axboe

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On Tue, 3 Jan 2006 20:03:47 +0100
Jens Axboe <axboe@suse.de> wrote:

> On Tue, Jan 03 2006, Jens Axboe wrote:
> > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > On 30 Dec 2005 17:36:44 +0900
> > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > 
> > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > > While booting, it locks up after printing
> > > > 
> > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > >     ata1(0): applying bridge limits
> > > >     ata1: dev 0 configured for UDMA/100
> > > > 
> > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > panics during boot.
> > > 
> > > Hi,
> > > 
> > > Can you capture the kernel oops & panic messages?
> > 
> > I think I triggered the same oops on my T43, I'll try applying your sata
> > acpi patches and see if it reproduces.
> 
> It's crashing here:
> 
>                 acpi_os_free((void *)gtf_address);
> 
> in ata_acpi_exec_tfs(), looks like it's trying to free an uninitialized
> gtf_address. Setting to 0 and doing:
> 
>         if (gtf_address)
>                 acpi_os_free((void *)gtf_address);
> 
> fixes it. Probably due to a nasty warning that it spews on boot:
> 
> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
> ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
> 88:203f
> ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
> ata1(0): applying bridge limits
> ata1: dev 0 configured for UDMA/100
> ata_acpi_exec_tfs: call get_GTF, ix=0
> ata_acpi_exec_tfs: call set_taskfiles, ix=0
> do_drive_set_taskfiles: unexpected GTF length (-271707516)
> scsi0 : ata_piix
>   Vendor: ATA       Model: ST980825A         Rev: 3.04
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> 
> note the 'unexpected GTF length' message. Doing a suspend/resume cycle
> doesn't trigger that error:
> 
> [...]
> eth1: Coming out of suspend...
> ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 21 (level, low) -> IRQ 23
> ata1: dev 0 configured for UDMA/100
> ata_acpi_exec_tfs: call get_GTF, ix=0
> ata_acpi_exec_tfs: call set_taskfiles, ix=0
> Restarting tasks... done
> [...]

Thanks, I'll get right on it.
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On Tue, 3 Jan 2006 20:03:47 +0100
Jens Axboe <axboe@suse.de> wrote:

> On Tue, Jan 03 2006, Jens Axboe wrote:
> > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > On 30 Dec 2005 17:36:44 +0900
> > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > 
> > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > > While booting, it locks up after printing
> > > > 
> > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > >     ata1(0): applying bridge limits
> > > >     ata1: dev 0 configured for UDMA/100
> > > > 
> > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > panics during boot.
> > > 
> > > Hi,
> > > 
> > > Can you capture the kernel oops & panic messages?
> > 
> > I think I triggered the same oops on my T43, I'll try applying your sata
> > acpi patches and see if it reproduces.
> 
> It's crashing here:
> 
>                 acpi_os_free((void *)gtf_address);
> 
> in ata_acpi_exec_tfs(), looks like it's trying to free an uninitialized
> gtf_address. Setting to 0 and doing:
> 
>         if (gtf_address)
>                 acpi_os_free((void *)gtf_address);
> 
> fixes it. Probably due to a nasty warning that it spews on boot:
> 
> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
> ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
> 88:203f
> ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
> ata1(0): applying bridge limits
> ata1: dev 0 configured for UDMA/100
> ata_acpi_exec_tfs: call get_GTF, ix=0
> ata_acpi_exec_tfs: call set_taskfiles, ix=0
> do_drive_set_taskfiles: unexpected GTF length (-271707516)

Ugh.  So the ACPI taskfile data looks like crap??
I guess that I'll just invalidate gtf_address (set to NULL)
if gtf_length looks invalid.  Is there something better to do?

Jae-hyeon,

Please send me a dump of your ACPI tables (acpidump).
'acpidump' is at
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
Use the latest pmtools tarball.

BTW, to enable more debugging messages, boot the kernel with this
additional option:
  libata.printk=0xffff
(This is part of my patchset.)

Jens, could you see that <gtf_address> your system is
getting that is invalid?

> scsi0 : ata_piix
>   Vendor: ATA       Model: ST980825A         Rev: 3.04
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> 
> note the 'unexpected GTF length' message. Doing a suspend/resume cycle
> doesn't trigger that error:
> 
> [...]
> eth1: Coming out of suspend...
> ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 21 (level, low) -> IRQ 23
> ata1: dev 0 configured for UDMA/100
> ata_acpi_exec_tfs: call get_GTF, ix=0
> ata_acpi_exec_tfs: call set_taskfiles, ix=0
> Restarting tasks... done

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On Tue, Jan 03 2006, Randy Dunlap wrote:
> > ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
> > ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
> > 88:203f
> > ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
> > ata1(0): applying bridge limits
> > ata1: dev 0 configured for UDMA/100
> > ata_acpi_exec_tfs: call get_GTF, ix=0
> > ata_acpi_exec_tfs: call set_taskfiles, ix=0
> > do_drive_set_taskfiles: unexpected GTF length (-271707516)
> 
> Ugh.  So the ACPI taskfile data looks like crap??
> I guess that I'll just invalidate gtf_address (set to NULL)
> if gtf_length looks invalid.  Is there something better to do?

Bugger me, I'm totally acpi ignorant. But did you see my note that if I
clear gtf_address before calling into the function (where you pass it by
reference), the problem goes away? That smells more like return-on-error
without setting it at all, hence kfree() blows up when passed a bogus
stack filled variable.

> Jae-hyeon,
> 
> Please send me a dump of your ACPI tables (acpidump).
> 'acpidump' is at
> http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> Use the latest pmtools tarball.

I've attached mine as well, in case they are useful.

> Jens, could you see that <gtf_address> your system is
> getting that is invalid?

Sure, will reboot it after posting this message.

-- 
Jens Axboe


[-- Attachment #2: acpi.tables.bz2 --]
[-- Type: application/x-bunzip2, Size: 58667 bytes --]

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On Tue, 3 Jan 2006 21:06:03 +0100
Jens Axboe <axboe@suse.de> wrote:

> On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
> > > ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
> > > 88:203f
> > > ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
> > > ata1(0): applying bridge limits
> > > ata1: dev 0 configured for UDMA/100
> > > ata_acpi_exec_tfs: call get_GTF, ix=0
> > > ata_acpi_exec_tfs: call set_taskfiles, ix=0
> > > do_drive_set_taskfiles: unexpected GTF length (-271707516)
> > 
> > Ugh.  So the ACPI taskfile data looks like crap??
> > I guess that I'll just invalidate gtf_address (set to NULL)
> > if gtf_length looks invalid.  Is there something better to do?
> 
> Bugger me, I'm totally acpi ignorant. But did you see my note that if I
> clear gtf_address before calling into the function (where you pass it by
> reference), the problem goes away? That smells more like return-on-error
> without setting it at all, hence kfree() blows up when passed a bogus
> stack filled variable.

Yes, I'll fix that part also.

> > Jae-hyeon,
> > 
> > Please send me a dump of your ACPI tables (acpidump).
> > 'acpidump' is at
> > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> > Use the latest pmtools tarball.
> 
> I've attached mine as well, in case they are useful.
> 
> > Jens, could you see that <gtf_address> your system is
> > getting that is invalid?
> 
> Sure, will reboot it after posting this message.
> 
> -- 
> Jens Axboe


---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

On Tue, Jan 03 2006, Jens Axboe wrote:
> On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
> > > ata1: dev 0 cfg 49:2f00 82:346b 83:7d09 84:6003 85:3469 86:3c09 87:6003
> > > 88:203f
> > > ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48
> > > ata1(0): applying bridge limits
> > > ata1: dev 0 configured for UDMA/100
> > > ata_acpi_exec_tfs: call get_GTF, ix=0
> > > ata_acpi_exec_tfs: call set_taskfiles, ix=0
> > > do_drive_set_taskfiles: unexpected GTF length (-271707516)
> > 
> > Ugh.  So the ACPI taskfile data looks like crap??
> > I guess that I'll just invalidate gtf_address (set to NULL)
> > if gtf_length looks invalid.  Is there something better to do?
> 
> Bugger me, I'm totally acpi ignorant. But did you see my note that if I
> clear gtf_address before calling into the function (where you pass it by
> reference), the problem goes away? That smells more like return-on-error
> without setting it at all, hence kfree() blows up when passed a bogus
> stack filled variable.
> 
> > Jae-hyeon,
> > 
> > Please send me a dump of your ACPI tables (acpidump).
> > 'acpidump' is at
> > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> > Use the latest pmtools tarball.
> 
> I've attached mine as well, in case they are useful.
> 
> > Jens, could you see that <gtf_address> your system is
> > getting that is invalid?
> 
> Sure, will reboot it after posting this message.

It's just 0 (because I fill it as such). do_drive_get_GTF() looks
suspicious, at least with noacpi != 0 it will return success without
filling gtf_address. Perhaps you want to treat that as an error, or
check for it earlier?

Anyways, I'm pretty sure do_drive_get_GTF() needs some fixing. I'll
leave that to you, let me know if you want me to test anything.

-- 
Jens Axboe

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On Tue, 3 Jan 2006 21:13:12 +0100
Jens Axboe <axboe@suse.de> wrote:

> On Tue, Jan 03 2006, Jens Axboe wrote:
> > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > 
> > > Ugh.  So the ACPI taskfile data looks like crap??
> > > I guess that I'll just invalidate gtf_address (set to NULL)
> > > if gtf_length looks invalid.  Is there something better to do?
> > 
> > Bugger me, I'm totally acpi ignorant. But did you see my note that if I
> > clear gtf_address before calling into the function (where you pass it by
> > reference), the problem goes away? That smells more like return-on-error
> > without setting it at all, hence kfree() blows up when passed a bogus
> > stack filled variable.

Yes, I'll just init gtf_length and gtf_address to 0
in do_drive_get_GTF().

> > > Jae-hyeon,
> > > 
> > > Please send me a dump of your ACPI tables (acpidump).
> > > 'acpidump' is at
> > > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> > > Use the latest pmtools tarball.
> > 
> > I've attached mine as well, in case they are useful.

At least it shows that there is no _GTF at all for SATA devices,
only for PATA (which my patch does not address).

> > > Jens, could you see that <gtf_address> your system is
> > > getting that is invalid?
> > 
> > Sure, will reboot it after posting this message.
> 
> It's just 0 (because I fill it as such). do_drive_get_GTF() looks
> suspicious, at least with noacpi != 0 it will return success without
> filling gtf_address. Perhaps you want to treat that as an error, or
> check for it earlier?
> 
> Anyways, I'm pretty sure do_drive_get_GTF() needs some fixing. I'll
> leave that to you, let me know if you want me to test anything.

Yes, basic error on my part.  I've updated the patch series
and rediffed it against 2.6.15.  If one of you could test it,
that would be great (Jae-hyeon or Jens).

New patch series is at
  http://www.xenotime.net/linux/SATA/2.6.15/
with a combined patch at
  http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch

If you don't want to revert the old patchset and apply the new
one, you can just do this:

	*gtf_length = 0;
	*gtf_address = 0UL;
at the top of do_drive_get_GTF().


Thanks for your help.
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

On Tue, Jan 03 2006, Randy Dunlap wrote:
> On Tue, 3 Jan 2006 21:13:12 +0100
> Jens Axboe <axboe@suse.de> wrote:
> 
> > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > 
> > > > Ugh.  So the ACPI taskfile data looks like crap??
> > > > I guess that I'll just invalidate gtf_address (set to NULL)
> > > > if gtf_length looks invalid.  Is there something better to do?
> > > 
> > > Bugger me, I'm totally acpi ignorant. But did you see my note that if I
> > > clear gtf_address before calling into the function (where you pass it by
> > > reference), the problem goes away? That smells more like return-on-error
> > > without setting it at all, hence kfree() blows up when passed a bogus
> > > stack filled variable.
> 
> Yes, I'll just init gtf_length and gtf_address to 0
> in do_drive_get_GTF().

Sounds good.

> > > > Jae-hyeon,
> > > > 
> > > > Please send me a dump of your ACPI tables (acpidump).
> > > > 'acpidump' is at
> > > > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> > > > Use the latest pmtools tarball.
> > > 
> > > I've attached mine as well, in case they are useful.
> 
> At least it shows that there is no _GTF at all for SATA devices,
> only for PATA (which my patch does not address).

Aren't they the same thing? Any plans on checking that as well, I think
there's a fair share of pata-on-sata laptops out there.

> > > > Jens, could you see that <gtf_address> your system is
> > > > getting that is invalid?
> > > 
> > > Sure, will reboot it after posting this message.
> > 
> > It's just 0 (because I fill it as such). do_drive_get_GTF() looks
> > suspicious, at least with noacpi != 0 it will return success without
> > filling gtf_address. Perhaps you want to treat that as an error, or
> > check for it earlier?
> > 
> > Anyways, I'm pretty sure do_drive_get_GTF() needs some fixing. I'll
> > leave that to you, let me know if you want me to test anything.
> 
> Yes, basic error on my part.  I've updated the patch series
> and rediffed it against 2.6.15.  If one of you could test it,
> that would be great (Jae-hyeon or Jens).
> 
> New patch series is at
>   http://www.xenotime.net/linux/SATA/2.6.15/
> with a combined patch at
>   http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch
> 
> If you don't want to revert the old patchset and apply the new
> one, you can just do this:
> 
> 	*gtf_length = 0;
> 	*gtf_address = 0UL;
> at the top of do_drive_get_GTF().

Works for me (well I have my version, which logically does the same
thing).

-- 
Jens Axboe

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On Tue, 3 Jan 2006 22:16:11 +0100
Jens Axboe <axboe@suse.de> wrote:

> > At least it shows that there is no _GTF at all for SATA devices,
> > only for PATA (which my patch does not address).
> 
> Aren't they the same thing? Any plans on checking that as well, I think
> there's a fair share of pata-on-sata laptops out there.

It certainly would be Good to have that supported.
I'll take a look at the ACPI (3.0) spec to see what (more)
is needed.

BTW, there's a different IDE-ACPI patch from
Shaohua Li <shaohua.li@intel.com>.  Have you seen it?
Has anyone here tested it?
http://marc.theaimsgroup.com/?l=linux-kernel&m=113390716128790&w=2

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jens Axboe]

On Tue, Jan 03 2006, Randy Dunlap wrote:
> On Tue, 3 Jan 2006 22:16:11 +0100
> Jens Axboe <axboe@suse.de> wrote:
> 
> > > At least it shows that there is no _GTF at all for SATA devices,
> > > only for PATA (which my patch does not address).
> > 
> > Aren't they the same thing? Any plans on checking that as well, I think
> > there's a fair share of pata-on-sata laptops out there.
> 
> It certainly would be Good to have that supported.
> I'll take a look at the ACPI (3.0) spec to see what (more)
> is needed.

It's all very confusing. Is it just a questions of checking which _GTF's
to query? You can use ata_dev_knobble() to check whether this is an SATA
or PATA drive. The rest of the code should be the same.

> BTW, there's a different IDE-ACPI patch from
> Shaohua Li <shaohua.li@intel.com>.  Have you seen it?
> Has anyone here tested it?
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113390716128790&w=2

I hadn't seen it before. I have no real pata + acpi suspending machines,
though.

-- 
Jens Axboe

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> On Tue, 3 Jan 2006 20:03:47 +0100
> Jens Axboe <axboe@suse.de> wrote:
> > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > On 30 Dec 2005 17:36:44 +0900
> > > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > > 
> > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.

My laptop is ThinkPad X41 Tablet, which has the same SATA controller
as X41.

> > > > > While booting, it locks up after printing
> > > > > 
> > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > >     ata1(0): applying bridge limits
> > > > >     ata1: dev 0 configured for UDMA/100
> > > > > 
> > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > panics during boot.
> > > > 
> > > > Hi,
> > > > 
> > > > Can you capture the kernel oops & panic messages?
> > > > Please send me your .config also.

I tried to copy them here:

 sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172
 printing eip:
c0118fc5
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c0118fc5>] Not tainted VLI
EFLAGS: 00010006   (2.6.15-rc7-randyahci)
EIP is at complete+0x15/0x60
eax: 00000172   ebx: c0352000   ecx: 00000000   edx: c1fe5760
esi: 00000092   edi: 00000001   ebp: c0353f08   esp: c0353eec
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c0352000 task=c030fb00)
Stack: c1fe5760 c1fe5760 00000000 c1fe5760 c0253f9a 00000000 c1fe5284 c1fd6500
       c0253ebd c1fe5284 00000000 c1fe5760 c02545bc c1fe5760 00000000 c0353f50
       c0353f28 c0352000 c0353fa4 00000282 00000000 c1fd64a0 00000000 c0353fa4
Call Trace:
 [<c0253f9a>] ata_qc_complete+0x3a/0xc0
 [<c0253ebd>] __ata_qc_complete+0x6d/0x80
 [<c02545bc>] ata_interrupt+0x11c/0x140
 [<c013f5e9>] handle_IRQ_event+0x39/0x70
 [<c013f69e>] __do_IRQ+0x7e/0x120
 [<c01219a1>] __do_softirq+0x41/0xa0
 [<c0105739>] do_IRQ+0x19/0x30
 [<c0103b82>] common_interrupt+0x1a/0x20
 [<c010105d>] default_idle+0x42/0x60
 [<c01010e2>] cpu_idle+0x42/0x60
 [<c035487f>] start_kernel+0x15f/0x180
 [<c03543b0>] unknown_bootoption+0x0/0x1f0
Code: 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d e9 45 e9 1a 00 90 8d 74 26 00 55 89 e5 56 53 83 ec 14 9c 5e fa bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 00 31 c9 31 d2 89 4c 24 10 83 c0 04 b9 01 00 00 00 89 54 24
 <0>Kernel panic - not syncing: Fatal exception in interrupt

> Jae-hyeon,
> 
> Please send me a dump of your ACPI tables (acpidump).
> 'acpidump' is at
> http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ .
> Use the latest pmtools tarball.

I attached the acpi dump and my .config.  I used the acpidump debian
package version 20050926-1.

> BTW, to enable more debugging messages, boot the kernel with this
> additional option:
>   libata.printk=0xffff
> (This is part of my patchset.)

This does not seem to be telling me more about kernel panic, which is
gone anyway.

> Yes, basic error on my part.  I've updated the patch series
> and rediffed it against 2.6.15.  If one of you could test it,
> that would be great (Jae-hyeon or Jens).
> 
> New patch series is at
>   http://www.xenotime.net/linux/SATA/2.6.15/
> with a combined patch at
>   http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch

With this patch series, resume still fails with snd_intel8x0m
rmmod-ed.  Resume works if the snd_intel8x0m module has been inserted.
I am curious about this, too.

Jae-hyeon


[-- Attachment #2: acpidump.out.bz2 --]
[-- Type: application/octet-stream, Size: 63034 bytes --]

[-- Attachment #3: config-2.6.15-rc7.bz2 --]
[-- Type: application/octet-stream, Size: 6337 bytes --]

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 04 Jan 2006 07:40:00 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > On Tue, 3 Jan 2006 20:03:47 +0100
> > Jens Axboe <axboe@suse.de> wrote:
> > > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > > On 30 Dec 2005 17:36:44 +0900
> > > > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > > > 
> > > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> 
> My laptop is ThinkPad X41 Tablet, which has the same SATA controller
> as X41.
> 
> > > > > > While booting, it locks up after printing
> > > > > > 
> > > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > > >     ata1(0): applying bridge limits
> > > > > >     ata1: dev 0 configured for UDMA/100
> > > > > > 
> > > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > > panics during boot.
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Can you capture the kernel oops & panic messages?
> > > > > Please send me your .config also.

This certainly isn't the same failure that Jens saw.

Could there be any informative & helpful messages missing
before these messages, e.g., an assert() failure?

I don't quite understand what CONFIG_SCSI_SATA_AHCI has to do
with this.  I see ata_interrupt() [from libata-core.c],
but ahci.c contains ahci_interrupt(), which isn't in this
stack dump.  Nevertheless, it looks like complete() is
being passed a NULL struct completion...  Maybe I'm misusing
the completion API and don't know it (?).

BTW, .config file, please.

> I tried to copy them here:
> 
>  sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172
>  printing eip:
> c0118fc5
> *pde = 00000000
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c0118fc5>] Not tainted VLI
> EFLAGS: 00010006   (2.6.15-rc7-randyahci)
> EIP is at complete+0x15/0x60
> eax: 00000172   ebx: c0352000   ecx: 00000000   edx: c1fe5760
> esi: 00000092   edi: 00000001   ebp: c0353f08   esp: c0353eec
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, threadinfo=c0352000 task=c030fb00)
> Stack: c1fe5760 c1fe5760 00000000 c1fe5760 c0253f9a 00000000 c1fe5284 c1fd6500
>        c0253ebd c1fe5284 00000000 c1fe5760 c02545bc c1fe5760 00000000 c0353f50
>        c0353f28 c0352000 c0353fa4 00000282 00000000 c1fd64a0 00000000 c0353fa4
> Call Trace:
>  [<c0253f9a>] ata_qc_complete+0x3a/0xc0
>  [<c0253ebd>] __ata_qc_complete+0x6d/0x80
>  [<c02545bc>] ata_interrupt+0x11c/0x140
>  [<c013f5e9>] handle_IRQ_event+0x39/0x70
>  [<c013f69e>] __do_IRQ+0x7e/0x120
>  [<c01219a1>] __do_softirq+0x41/0xa0
>  [<c0105739>] do_IRQ+0x19/0x30
>  [<c0103b82>] common_interrupt+0x1a/0x20
>  [<c010105d>] default_idle+0x42/0x60
>  [<c01010e2>] cpu_idle+0x42/0x60
>  [<c035487f>] start_kernel+0x15f/0x180
>  [<c03543b0>] unknown_bootoption+0x0/0x1f0
> Code: 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d e9 45 e9 1a 00 90 8d 74 26 00 55 89 e5 56 53 83 ec 14 9c 5e fa bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 00 31 c9 31 d2 89 4c 24 10 83 c0 04 b9 01 00 00 00 89 54 24
>  <0>Kernel panic - not syncing: Fatal exception in interrupt


> > New patch series is at
> >   http://www.xenotime.net/linux/SATA/2.6.15/
> > with a combined patch at
> >   http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch
> 
> With this patch series, resume still fails with snd_intel8x0m
> rmmod-ed.  Resume works if the snd_intel8x0m module has been inserted.
> I am curious about this, too.

Wow, interesting, but I have no idea about that.

---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:

> On 04 Jan 2006 07:40:00 +0900
> Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > > On Tue, 3 Jan 2006 20:03:47 +0100
> > > Jens Axboe <axboe@suse.de> wrote:
> > > > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > > > On 30 Dec 2005 17:36:44 +0900
> > > > > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > > > > 
> > > > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > 
> > My laptop is ThinkPad X41 Tablet, which has the same SATA controller
> > as X41.
> > 
> > > > > > > While booting, it locks up after printing
> > > > > > > 
> > > > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > > > >     ata1(0): applying bridge limits
> > > > > > >     ata1: dev 0 configured for UDMA/100
> > > > > > > 
> > > > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > > > panics during boot.
> 
> This certainly isn't the same failure that Jens saw.
> 
> Could there be any informative & helpful messages missing
> before these messages, e.g., an assert() failure?

Let me copy as far as I can setting the video mode to 80x60.
Scrolling back does not work after kernel panic.

highmem bounce pool size: 64 pages
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ahci: probe of 0000:00:1f.2 failed with error -12
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
do_drive_set_taskfiles: unexpected GTF length (-1040297340)
scsi0: ata_piix
  Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
  Type:   Direct-Access                      ANSI SCSI revision: 05
ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata2: disabling port
scsi1 : ata_piix
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
SCSI device sda: drive cache: write back
 sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172
 ...

> I don't quite understand what CONFIG_SCSI_SATA_AHCI has to do
> with this.  I see ata_interrupt() [from libata-core.c],
> but ahci.c contains ahci_interrupt(), which isn't in this
> stack dump.  Nevertheless, it looks like complete() is
> being passed a NULL struct completion...  Maybe I'm misusing
> the completion API and don't know it (?).
> 
> BTW, .config file, please.

.config was already included in my previous posting, with the name
config-2.6.15-rc7.bz2.

> > > New patch series is at
> > >   http://www.xenotime.net/linux/SATA/2.6.15/
> > > with a combined patch at
> > >   http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch
> > 
> > With this patch series, resume still fails with snd_intel8x0m
> > rmmod-ed.  Resume works if the snd_intel8x0m module has been inserted.
> > I am curious about this, too.
> 
> Wow, interesting, but I have no idea about that.

As I said in a previous posting, 2.6.15-rc7 + git-libata-all.patch +
libata_resume_fix.patch + libata_suspend-fix.patch +
libata_suspend.patch, solved the problem, irrespective of the presence
of snd_intel8x0m.  Among these four, libata_suspend.patch is Jens'
patch.  So probably snd_intel8x0m issue is not related to your
(modification of Jens') code.  Looks like one of the above four
patches has the fix.

Another point that I observed is that your patch against 2.6.15-rc7,
did not work together with suspend2 patch, even if snd_intel8x0m was
inserted.  Again, the above combination works with suspend2.

Jae-hyeon

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 04 Jan 2006 10:31:23 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> 
> > On 04 Jan 2006 07:40:00 +0900
> > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > > > On Tue, 3 Jan 2006 20:03:47 +0100
> > > > Jens Axboe <axboe@suse.de> wrote:
> > > > > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > > > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > > > > On 30 Dec 2005 17:36:44 +0900
> > > > > > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > > > > > 
> > > > > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > 
> > > My laptop is ThinkPad X41 Tablet, which has the same SATA controller
> > > as X41.
> > > 
> > > > > > > > While booting, it locks up after printing
> > > > > > > > 
> > > > > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > > > > >     ata1(0): applying bridge limits
> > > > > > > >     ata1: dev 0 configured for UDMA/100
> > > > > > > > 
> > > > > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > > > > panics during boot.
> > 
> > This certainly isn't the same failure that Jens saw.
> > 
> > Could there be any informative & helpful messages missing
> > before these messages, e.g., an assert() failure?
> 
> Let me copy as far as I can setting the video mode to 80x60.
> Scrolling back does not work after kernel panic.

Thanks.

> highmem bounce pool size: 64 pages
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
> ahci: probe of 0000:00:1f.2 failed with error -12

-12 is -ENOMEM.  ahci can fail with -ENOMEM in 5 places.
3 of them are due to kmalloc() failures (real NOMEM).
1 is due to failure of dma_alloc_coherent() and
1 is due to failure of pci_iomap().

Have you seen any other shortage-of-memory conditions?


> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> ata1(0): applying bridge limits
> ata1: dev 0 configured for UDMA/100
> do_drive_set_taskfiles: unexpected GTF length (-1040297340)
> scsi0: ata_piix
>   Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
> ata2: disabling port
> scsi1 : ata_piix
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
>  sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172
>  ...
> 
> > I don't quite understand what CONFIG_SCSI_SATA_AHCI has to do
> > with this.  I see ata_interrupt() [from libata-core.c],
> > but ahci.c contains ahci_interrupt(), which isn't in this
> > stack dump.  Nevertheless, it looks like complete() is
> > being passed a NULL struct completion...  Maybe I'm misusing
> > the completion API and don't know it (?).
> > 
> > BTW, .config file, please.
> 
> .config was already included in my previous posting, with the name
> config-2.6.15-rc7.bz2.

Yes, thanks, I saw the acpidump but missed the config file.

> > > > New patch series is at
> > > >   http://www.xenotime.net/linux/SATA/2.6.15/
> > > > with a combined patch at
> > > >   http://www.xenotime.net/linux/SATA/2.6.15/libata-combine-2615.patch
> > > 
> > > With this patch series, resume still fails with snd_intel8x0m
> > > rmmod-ed.  Resume works if the snd_intel8x0m module has been inserted.
> > > I am curious about this, too.
> > 
> > Wow, interesting, but I have no idea about that.
> 
> As I said in a previous posting, 2.6.15-rc7 + git-libata-all.patch +
> libata_resume_fix.patch + libata_suspend-fix.patch +
> libata_suspend.patch, solved the problem, irrespective of the presence
> of snd_intel8x0m.  Among these four, libata_suspend.patch is Jens'
> patch.  So probably snd_intel8x0m issue is not related to your
> (modification of Jens') code.  Looks like one of the above four
> patches has the fix.
> 
> Another point that I observed is that your patch against 2.6.15-rc7,
> did not work together with suspend2 patch, even if snd_intel8x0m was
> inserted.  Again, the above combination works with suspend2.

---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 04 Jan 2006 10:31:23 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> 
> > On 04 Jan 2006 07:40:00 +0900
> > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > > > On Tue, 3 Jan 2006 20:03:47 +0100
> > > > Jens Axboe <axboe@suse.de> wrote:
> > > > > On Tue, Jan 03 2006, Jens Axboe wrote:
> > > > > > On Tue, Jan 03 2006, Randy Dunlap wrote:
> > > > > > > On 30 Dec 2005 17:36:44 +0900
> > > > > > > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > > > > > > 
> > > > > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > 
> > > My laptop is ThinkPad X41 Tablet, which has the same SATA controller
> > > as X41.
> > > 
> > > > > > > > While booting, it locks up after printing
> > > > > > > > 
> > > > > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > > > > >     ata1(0): applying bridge limits
> > > > > > > >     ata1: dev 0 configured for UDMA/100
> > > > > > > > 
> > > > > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > > > > panics during boot.
> > 
> > This certainly isn't the same failure that Jens saw.
> > 
> > Could there be any informative & helpful messages missing
> > before these messages, e.g., an assert() failure?
> 
> Let me copy as far as I can setting the video mode to 80x60.
> Scrolling back does not work after kernel panic.
> 
> highmem bounce pool size: 64 pages
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
> ahci: probe of 0000:00:1f.2 failed with error -12
> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> ata1(0): applying bridge limits
> ata1: dev 0 configured for UDMA/100
> do_drive_set_taskfiles: unexpected GTF length (-1040297340)
> scsi0: ata_piix
>   Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
> ata2: disabling port
> scsi1 : ata_piix
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
>  sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172
>  ...
> 
> > I don't quite understand what CONFIG_SCSI_SATA_AHCI has to do
> > with this.  I see ata_interrupt() [from libata-core.c],
> > but ahci.c contains ahci_interrupt(), which isn't in this
> > stack dump.  Nevertheless, it looks like complete() is
> > being passed a NULL struct completion...  Maybe I'm misusing
> > the completion API and don't know it (?).

Jae-hyeon,

Does your system work without using the AHCI driver?
or is it required?
Of course, even if the AHCI driver is not needed,
it shouldn't be oopsing like this.

It looks like the ata_piix driver is the one that is
actually being used, from what I can see here.

Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
and 'lspci -v'.

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

> > > > > > > > I tested kernel 2.6.15-rc7 with your patch applied on my ThinkPad X41.
> > > 
> > > My laptop is ThinkPad X41 Tablet, which has the same SATA controller
> > > as X41.
> > > 
> > > > > > > > While booting, it locks up after printing
> > > > > > > > 
> > > > > > > >     ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> > > > > > > >     ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> > > > > > > >     ata1(0): applying bridge limits
> > > > > > > >     ata1: dev 0 configured for UDMA/100
> > > > > > > > 
> > > > > > > > If I select CONFIG_SCSI_SATA_AHCI, then the kernel emits an oops and
> > > > > > > > panics during boot.
> > 
> > This certainly isn't the same failure that Jens saw.
> > 
> > Could there be any informative & helpful messages missing
> > before these messages, e.g., an assert() failure?
> 
> Let me copy as far as I can setting the video mode to 80x60.
> Scrolling back does not work after kernel panic.
> 
> highmem bounce pool size: 64 pages
> Initializing Cryptographic API
> io scheduler noop registered
> io scheduler anticipatory registered
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
> ahci: probe of 0000:00:1f.2 failed with error -12
> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
> ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
> ata1(0): applying bridge limits
> ata1: dev 0 configured for UDMA/100
> do_drive_set_taskfiles: unexpected GTF length (-1040297340)
> scsi0: ata_piix
>   Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
> ata2: disabling port
> scsi1 : ata_piix
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
> SCSI device sda: drive cache: write back
>  sda:<1>Unable to handle kernel NULL pointer dereference at virtual address 00000172

Jae-Hyeon,

If you are up to it, please enable libata verbose debugging
and then boot & cause this bug again and send me as much
output as you can collect.
Patch is below.

Thanks,
---
~Randy


From: Randy Dunlap <randy_d_dunlap@linux.intel.com>

Enable libata verbose debugging output.

Signed-off-by: Randy Dunlap <randy_d_dunlap@linux.intel.com>
---

 include/linux/libata.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp linux-2615-work/include/linux/libata.h~debugs linux-2615-work/include/linux/libata.h
--- linux-2615-work/include/linux/libata.h~debugs	2006-01-02 19:21:10.000000000 -0800
+++ linux-2615-work/include/linux/libata.h	2006-01-04 11:40:05.000000000 -0800
@@ -37,8 +37,8 @@
 /*
  * compile-time options
  */
-#undef ATA_DEBUG		/* debugging output */
-#undef ATA_VERBOSE_DEBUG	/* yet more debugging output */
+#define ATA_DEBUG		/* debugging output */
+#define ATA_VERBOSE_DEBUG	/* yet more debugging output */
 #undef ATA_IRQ_TRAP		/* define to ack screaming irqs */
 #undef ATA_NDEBUG		/* define to disable quick runtime checks */
 #undef ATA_ENABLE_PATA		/* define to enable PATA support in some

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
>
> Does your system work without using the AHCI driver?
> or is it required?

I tested turning off AHCI with 2.6.15-rc7 + git-libata-all.patch +
libata_resume_fix.patch + libata_suspend-fix.patch +
libata_suspend.patch.  The system runs okay, and ACPI suspend/resume
and suspend2 work, without AHCI.

> Of course, even if the AHCI driver is not needed,
> it shouldn't be oopsing like this.
> 
> It looks like the ata_piix driver is the one that is
> actually being used, from what I can see here.
> 
> Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
> and 'lspci -v'.

They are enclosed below.

> If you are up to it, please enable libata verbose debugging
> and then boot & cause this bug again and send me as much
> output as you can collect.
> Patch is below.

Let me remind you that I used kernel 2.6.15-rc7 +
http://www.xenotime.net/linux/SATA/2.6.15-rc7/libata-combine.patch +
libata verbose debug patch.  libata-combine-2615.patch does not cause
kernel panic.

I copied boot up messages below for cases with CONFIG_SCSI_SATA_AHCI
turned off and on.  After turning on verbose debugging messages, the
call trace has changed, and the kernel panics for
CONFIG_SCSI_SATA_AHCI=n as well.

Jae-hyeon




Kernel output when CONFIG_SCSI_SATA_AHCI=n:


  PREFETCH window: d0000000-d1ffffff
  MEM window: a2000000-a3ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-6fff
  MEM window: a0200000-afffffff
  PREFETCH window: d0000000-d7ffffff
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 17
Simple Boot Flag at 0x35 set to 0x1
audit: initializing netlink socket (disabled)
audit(1136496723.633:1): initialized
highmem bounce pool size: 64 pages
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
vesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 6144k, total 7872k
vesafb: mode is 1024x768x32, linelength=4096, pages=1
vesafb: protected mode interface info at 00ff:44f0
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 128x96
fb0: VESA VGA frame buffer device
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
piix_init: pci_module_init
ata_pci_init_one: ENTER
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt c1ff0000, dma 1ff0000
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata_bus_reset: ENTER, host 1, port 0
ata_bus_softreset: ata1: bus reset via SRST
ata_dev_classify: found ATA device by sig
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 1, dev 0
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_dev_identfy: do ATA identify
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_exec_command_pio: ata1: cmd 0xEC
ata_pio_sector: data read
ata_qc_complete: EXIT
ata_dump_id: 49==0x0b00  53==0x0007  63==0x0007  64==0x0003  75==0x0000
ata_dump_id: 80==0x0078  81==0x0019  82==0x746b  83==0x5988  84==0x6003
ata_dump_id: 88==0x203f  93==0x600b
ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
ata_dev_identify: EXIT, drv_stat = 0x50
ata1(0): applying bridge limits
ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev
ata_host_set_pio: base 0x8 xfer_mode 0xc mask 0x1f x 4
ata_dev_set_xfermode: set features - xfer mode
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_tf_load_pio: feat 0x3 nsect 0x45 lba 0x0 0x0 0x0
ata_tf_load_pio: device 0xA0
ata_exec_command_pio: ata1: cmd 0xEF
ata_host_intr: ata1: protocol 1 (dev_stat 0x50)
ata_qc_complete: EXIT
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=5 xfer_shift=0, xfer_mode=0x45, base=0x40, offset=5
ata1: dev 0 configured for UDMA/100
do_drive_set_taskfiles: unexpected GTF length (-1040260476)
ata_device_add: ata1: probe end
scsi0 : ata_piix
ata_device_add: probe_begin
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 24 00 32 c0 00
ata_scsiop_inq_std: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 60 00 32 c0 00
ata_scsiop_inq_std: ENTER
  Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
  Type:   Direct-Access                      ANSI SCSI revision: 05
ata_device_add: EXIT, returning 1
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt c1ff9000, dma 1ff9000
ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata_device_add: probe begin
ata_device_add: ata2: probe begin
ata_bus_reset: ENTER, host 2, port 0
ata_bus_softreset: ata2: bus reset via SRST
ata2: disabling port
ata_bus_reset: EXIT
ata_device_add: ata2: probe end
scsi1 : ata_piix
ata_device_add: probe begin
ata_device_add: EXIT, returning 1
piix_init: done
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 32 c0 00
ata_scsiop_noop: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
ata_scsiop_read_cap: ENTER
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsiop_mode_sense: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
ata_scsiop_mode_sense: ENTER
SCSI device sda: drive cache: write back
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsiop_noop: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
ata_scsiop_read_cap: ENTER
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsiop_mode_sense: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
ata_scsiop_mode_sense: ENTER
SCSI device sda: drive cache: write back
 sda:<3>ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 00 00 00 00 08
ata_scsi_translate: ENTER
scsi_10_lba_len: ten-byte command
ata_sg_setup: ENTER, ata1
ata_sg_setup: 1 sg elements mapped
ata_fill_sg: PRD[0] = (0x37C0B000, 0x1000)
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x0 0x0 0x0
ata_tf_load_pio: device 0xE0
ata_exec_command_pio: ata1: cmd 0xC8
ata_scsi_translate: EXIT
ata_host_intr: ata1: host_stat 0x24
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
ata_sg_clean: unmapping 1 sg elements
Unable to handle kernel NULL pointer dereference at virtual address 00000172
 printing eip:
c0118fc5
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c0118fc5>]    Not tainted VLI
EFLAGS: 00010006   (2.6.15-rc7-debugnoahci)
EIP is at complete+0x15/0x60
eax: 00000172   ebx: c036a000   ecx: 00000000   edx: c1fee760
esi: 00000082   edi: 00000001   ebp: c036bee4   esp: c036bec8
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c036a000 task=c0327b00)
Stack: c0255933 c1fefb58 c1fefb00 c0252800 00000046 00000000 c1fee284 00000000
       c026242d c1fee760 00000000 c1fee760 c0262520 c1fee760 00000000 c1fee760
       00000000 c011cb87 c1fd0260 c1fee284 c0262bf8 c1fee760 00000000 00000001
Call Trace:
 [<c0255933>] scsi_delete_timer+0x13/0x30
 [<c0252800>] scsi_done+0x10/0x30
 [<c026242d>] __ata_qc_complete+0x6d/0x80
 [<c0262520>] ata_qc_complete+0x50/0xe0
 [<c011cb87>] printk+0x17/0x20
 [<c0262bf8>] ata_interrupt+0x178/0x190
 [<c013f5e9>] handle_IRQ_event+0x39/0x70
 [<c013f69e>] __do_IRQ+0x7e/0x120
 [<c01219a1>] __do_softirq+0x41/0xa0
 [<c0105739>] do_IRQ+0x19/0x30
 [<c0103b82>] common_interrupt+0x1a/0x20
 [<c010105d>] default_idle+0x2d/0x50
 [<c01010e2>] cpu_idle+0x42/0x60
 [<c036c87f>] start_kernel+0x15f/0x180
 [<c036c3b0>] unknown_bootoption+0x0/0x1f0
Code: 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d e9 c5 bf 1b 00 90 8d 74 26 00 55 89 e5 56 53 83 ec 14 9c 5e fa bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 00 31 c9 31 d2 89 4c 24 10 83 c0 04 b9 01 00 00 00 89 54 24
 <0>Kernel panic - not syncing: Fatal exception in interrupt




Kernel output when CONFIG_SCSI_SATA_AHCI=y:


  PREFETCH window: d0000000-d1ffffff
  MEM window: a2000000-a3ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-6fff
  MEM window: a0200000-afffffff
  PREFETCH window: d0000000-d7ffffff
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 17
Simple Boot Flag at 0x35 set to 0x1
audit: initializing netlink socket (disabled)
audit(1136491631.351:1): initialized
highmem bounce pool size: 64 pages
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
vesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 6144k, total 7872k
vesafb: mode is 1024x768x32, linelength=4096, pages=1
vesafb: protected mode interface info at 00ff:44f0
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 128x96
fb0: VESA VGA frame buffer device
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
ahci_init_one: ENTER
acpi_bus-0201 [27] bus_set_power         : Device is not power manageable
ahci: probe of 0000:00:1f.2 failed with error -12
piix_init: pci_module_init
ata_pci_init_one: ENTER
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt c1ff0000, dma 1ff0000
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata_bus_reset: ENTER, host 1, port 0
ata_bus_softreset: ata1: bus reset via SRST
ata_dev_classify: found ATA device by sig
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 1, dev 0
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_dev_identfy: do ATA identify
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_exec_command_pio: ata1: cmd 0xEC
ata_pio_sector: data read
ata_qc_complete: EXIT
ata_dump_id: 49==0x0b00  53==0x0007  63==0x0007  64==0x0003  75==0x0000
ata_dump_id: 80==0x0078  81==0x0019  82==0x746b  83==0x5988  84==0x6003
ata_dump_id: 88==0x203f  93==0x600b
ata1: dev 0 ATA-6, max UDMA/100, 117210240 sectors: LBA
ata_dev_identify: EXIT, drv_stat = 0x50
ata1(0): applying bridge limits
ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev
ata_host_set_pio: base 0x8 xfer_mode 0xc mask 0x1f x 4
ata_dev_set_xfermode: set features - xfer mode
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_tf_load_pio: feat 0x3 nsect 0x45 lba 0x0 0x0 0x0
ata_tf_load_pio: device 0xA0
ata_exec_command_pio: ata1: cmd 0xEF
ata_host_intr: ata1: protocol 1 (dev_stat 0x50)
ata_qc_complete: EXIT
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=5 xfer_shift=0, xfer_mode=0x45, base=0x40, offset=5
ata1: dev 0 configured for UDMA/100
do_drive_set_taskfiles: unexpected GTF length (-1040260476)
ata_device_add: ata1: probe end
scsi0 : ata_piix
ata_device_add: probe_begin
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 24 00 ff c1 50
ata_scsiop_inq_std: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 60 00 ff c1 50
ata_scsiop_inq_std: ENTER
  Vendor: ATA       Model: HTC426060G9AT00   Rev: 00P3
  Type:   Direct-Access                      ANSI SCSI revision: 05
ata_device_add: EXIT, returning 1
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt c1ff9000, dma 1ff9000
ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
ata_device_add: probe begin
ata_device_add: ata2: probe begin
ata_bus_reset: ENTER, host 2, port 0
ata_bus_softreset: ata2: bus reset via SRST
ata2: disabling port
ata_bus_reset: EXIT
ata_device_add: ata2: probe end
scsi1 : ata_piix
ata_device_add: probe begin
ata_device_add: EXIT, returning 1
piix_init: done
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 ff c1 50
ata_scsiop_noop: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
ata_scsiop_read_cap: ENTER
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsiop_mode_sense: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
ata_scsiop_mode_sense: ENTER
SCSI device sda: drive cache: write back
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsiop_noop: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
ata_scsiop_read_cap: ENTER
SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsiop_mode_sense: ENTER
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
ata_scsiop_mode_sense: ENTER
SCSI device sda: drive cache: write back
 sda:<3>ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 00 00 00 00 08
ata_scsi_translate: ENTER
scsi_10_lba_len: ten-byte command
ata_sg_setup: ENTER, ata1
ata_sg_setup: 1 sg elements mapped
ata_fill_sg: PRD[0] = (0x37C0B000, 0x1000)
ata_dev_select: ENTER, ata1: device 0, wait 1
ata_tf_load_pio: feat 0x0 nsect 0x8 lba 0x0 0x0 0x0
ata_tf_load_pio: device 0xE0
ata_exec_command_pio: ata1: cmd 0xC8
ata_scsi_translate: EXIT
ata_host_intr: ata1: host_stat 0x24
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
ata_sg_clean: unmapping 1 sg elements
Unable to handle kernel NULL pointer dereference at virtual address 00000172
 printing eip:
c0118fc5
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c0118fc5>]    Not tainted VLI
EFLAGS: 00010006   (2.6.15-rc7-debugahci)
EIP is at complete+0x15/0x60
eax: 00000172   ebx: c036c000   ecx: 00000000   edx: c1fee760
esi: 00000082   edi: 00000001   ebp: c036dee4   esp: c036dec8
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c036c000 task=c0329b00)
Stack: c0255933 c1fefb58 c1fefb00 c0252800 00000046 00000000 c1fee284 00000000
       c026242d c1fee760 00000000 c1fee760 c0262520 c1fee760 00000000 c1fee760
       00000000 c011cb87 c1fd0260 c1fee284 c0262bf8 c1fee760 00000000 00000001
Call Trace:
 [<c0255933>] scsi_delete_timer+0x13/0x30
 [<c0252800>] scsi_done+0x10/0x30
 [<c026242d>] __ata_qc_complete+0x6d/0x80
 [<c0262520>] ata_qc_complete+0x50/0xe0
 [<c011cb87>] printk+0x17/0x20
 [<c0262bf8>] ata_interrupt+0x178/0x190
 [<c013f5e9>] handle_IRQ_event+0x39/0x70
 [<c013f69e>] __do_IRQ+0x7e/0x120
 [<c01219a1>] __do_softirq+0x41/0xa0
 [<c0105739>] do_IRQ+0x19/0x30
 [<c0103b82>] common_interrupt+0x1a/0x20
 [<c010105d>] default_idle+0x2d/0x50
 [<c01010e2>] cpu_idle+0x42/0x60
 [<c036e87f>] start_kernel+0x15f/0x180
 [<c036e3b0>] unknown_bootoption+0x0/0x1f0
Code: 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d e9 05 d6 1b 00 90 8d 74 26 00 55 89 e5 56 53 83 ec 14 9c 5e fa bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 00 31 c9 31 d2 89 4c 24 10 83 c0 04 b9 01 00 00 00 89 54 24
 <0>Kernel panic - not syncing: Fatal exception in interrupt




The following information was collected with the working kernel
mentioned above because I cannot boot otherwise.


/proc/interrupts:

           CPU0       
  0:     118963    IO-APIC-edge  timer
  1:        131    IO-APIC-edge  i8042
  5:         10    IO-APIC-edge  serial
  8:          4    IO-APIC-edge  rtc
  9:       2982   IO-APIC-level  acpi
 12:        707    IO-APIC-edge  i8042
 14:       6517    IO-APIC-edge  libata
 15:          1    IO-APIC-edge  libata
 17:          0   IO-APIC-level  uhci_hcd:usb1, eth0, i915@pci:0000:00:02.0
 18:          0   IO-APIC-level  Intel ICH6 Modem
 19:          0   IO-APIC-level  uhci_hcd:usb2
 20:         21   IO-APIC-level  uhci_hcd:usb3
 21:          2   IO-APIC-level  uhci_hcd:usb4, ehci_hcd:usb5
 22:          0   IO-APIC-level  Intel ICH6
 23:       6650   IO-APIC-level  ipw2200
NMI:          0 
LOC:      22882 
ERR:          0
MIS:          0


/proc/iomem:

00000000-0009efff : System RAM
0009f000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000ce800-000cfdff : Adapter ROM
000d0000-000d0fff : Adapter ROM
000e0000-000effff : Extension ROM
000f0000-000fffff : System ROM
00100000-5f6dffff : System RAM
  00100000-002cec28 : Kernel code
  002cec29-0035db1f : Kernel data
5f6e0000-5f6f4fff : ACPI Tables
5f6f5000-5f6fffff : ACPI Non-volatile Storage
5f700000-5fffffff : reserved
68000000-6807ffff : 0000:00:02.1
a0000000-a003ffff : 0000:00:02.0
a0040000-a00403ff : 0000:00:1d.7
  a0040000-a00403ff : ehci_hcd
a0040400-a00404ff : 0000:00:1e.2
  a0040400-a00404ff : Intel ICH6
a0040800-a00409ff : 0000:00:1e.2
  a0040800-a00409ff : Intel ICH6
a0080000-a00fffff : 0000:00:02.0
a0100000-a01fffff : PCI Bus #02
  a0100000-a010ffff : 0000:02:00.0
    a0100000-a010ffff : tg3
a0200000-afffffff : PCI Bus #04
  a0200000-a0200fff : 0000:04:00.0
  a0201000-a02010ff : 0000:04:00.1
  a0202000-a0202fff : 0000:04:02.0
    a0202000-a0202fff : ipw2200
  a2000000-a3ffffff : PCI CardBus #05
c0000000-cfffffff : 0000:00:02.0
  c0000000-c07affff : vesafb
d0000000-d7ffffff : PCI Bus #04
  d0000000-d1ffffff : PCI CardBus #05
e0000000-efffffff : reserved
f0008000-f000bfff : reserved
fec00000-fec0ffff : reserved
fed14000-fed19fff : reserved
fed20000-fed8ffff : reserved
fee00000-fee00fff : reserved
ff000000-ffffffff : reserved


/proc/ioports:

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : libata
01f0-01f7 : libata
0200-0207 : serial
03c0-03df : vesafb
1000-107f : 0000:00:1f.0
  1000-107f : motherboard
    1000-1003 : PM1a_EVT_BLK
    1004-1005 : PM1a_CNT_BLK
    1008-100b : PM_TMR
    1010-1015 : ACPI CPU throttle
    1020-1020 : PM2_CNT_BLK
    1028-102f : GPE0_BLK
1180-11bf : 0000:00:1f.0
  1180-11bf : motherboard
15c0-15df : motherboard
15e0-15ef : motherboard
1600-162f : motherboard
1632-167f : motherboard
1800-1807 : 0000:00:02.0
1810-181f : 0000:00:1f.2
  1810-181f : libata
1820-183f : 0000:00:1d.0
  1820-183f : uhci_hcd
1840-185f : 0000:00:1d.1
  1840-185f : uhci_hcd
1860-187f : 0000:00:1d.2
  1860-187f : uhci_hcd
1880-189f : 0000:00:1d.3
  1880-189f : uhci_hcd
18a0-18bf : 0000:00:1f.3
18c0-18ff : 0000:00:1e.2
  18c0-18ff : Intel ICH6
1c00-1cff : 0000:00:1e.2
  1c00-1cff : Intel ICH6
2000-207f : 0000:00:1e.3
  2000-207f : Intel ICH6 Modem
2400-24ff : 0000:00:1e.3
  2400-24ff : Intel ICH6 Modem
3000-6fff : PCI Bus #04
  3000-30ff : PCI CardBus #05
  3400-34ff : PCI CardBus #05


lspci -v:

0000:00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
	Subsystem: IBM: Unknown device 0575
	Flags: bus master, fast devsel, latency 0
	Capabilities: <available only to root>

0000:00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA])
	Subsystem: IBM: Unknown device 0582
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at a0080000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 1800 [size=8]
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Memory at a0000000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: <available only to root>

0000:00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
	Subsystem: IBM: Unknown device 0582
	Flags: fast devsel
	Memory at 68000000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: <available only to root>

0000:00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Memory behind bridge: a0100000-a01fffff
	Capabilities: <available only to root>

0000:00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) (prog-if 00 [UHCI])
	Subsystem: IBM: Unknown device 0565
	Flags: bus master, medium devsel, latency 0, IRQ 17
	I/O ports at 1820 [size=32]

0000:00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) (prog-if 00 [UHCI])
	Subsystem: IBM: Unknown device 0565
	Flags: bus master, medium devsel, latency 0, IRQ 19
	I/O ports at 1840 [size=32]

0000:00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI])
	Subsystem: IBM: Unknown device 0565
	Flags: bus master, medium devsel, latency 0, IRQ 20
	I/O ports at 1860 [size=32]

0000:00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) (prog-if 00 [UHCI])
	Subsystem: IBM: Unknown device 0565
	Flags: bus master, medium devsel, latency 0, IRQ 21
	I/O ports at 1880 [size=32]

0000:00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI])
	Subsystem: IBM: Unknown device 0566
	Flags: bus master, medium devsel, latency 0, IRQ 21
	Memory at a0040000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <available only to root>

0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) (prog-if 01 [Subtractive decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=04, subordinate=07, sec-latency=64
	I/O behind bridge: 00003000-00006fff
	Memory behind bridge: a0200000-afffffff
	Prefetchable memory behind bridge: 00000000d0000000-00000000d7f00000
	Capabilities: <available only to root>

0000:00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
	Subsystem: IBM: Unknown device 0581
	Flags: bus master, medium devsel, latency 0, IRQ 22
	I/O ports at 1c00 [size=256]
	I/O ports at 18c0 [size=64]
	Memory at a0040800 (32-bit, non-prefetchable) [size=512]
	Memory at a0040400 (32-bit, non-prefetchable) [size=256]
	Capabilities: <available only to root>

0000:00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) (prog-if 00 [Generic])
	Subsystem: IBM: Unknown device 0576
	Flags: bus master, medium devsel, latency 0, IRQ 18
	I/O ports at 2400 [size=256]
	I/O ports at 2000 [size=128]
	Capabilities: <available only to root>

0000:00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
	Subsystem: IBM: Unknown device 0568
	Flags: bus master, medium devsel, latency 0

0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master])
	Subsystem: IBM: Unknown device 056a
	Flags: bus master, 66MHz, medium devsel, latency 0
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at 1810 [size=16]
	Capabilities: <available only to root>

0000:00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)
	Subsystem: IBM: Unknown device 056b
	Flags: medium devsel, IRQ 11
	I/O ports at 18a0 [size=32]

0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)
	Subsystem: IBM: Unknown device 0577
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at a0100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <available only to root>

0000:04:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8d)
	Subsystem: IBM: Unknown device 0555
	Flags: bus master, medium devsel, latency 64, IRQ 17
	Memory at a0200000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=04, secondary=05, subordinate=08, sec-latency=176
	Memory window 0: d0000000-d1fff000 (prefetchable)
	Memory window 1: a2000000-a3fff000 (prefetchable)
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
	16-bit legacy interface ports at 0001

0000:04:00.1 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 13)
	Subsystem: IBM: Unknown device 0556
	Flags: bus master, medium devsel, latency 64, IRQ 11
	Memory at a0201000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <available only to root>

0000:04:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
	Subsystem: Intel Corporation: Unknown device 2712
	Flags: bus master, medium devsel, latency 64, IRQ 23
	Memory at a0202000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 05 Jan 2006 23:08:12 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> >
> > Does your system work without using the AHCI driver?
> > or is it required?
> 
> I tested turning off AHCI with 2.6.15-rc7 + git-libata-all.patch +
> libata_resume_fix.patch + libata_suspend-fix.patch +
> libata_suspend.patch.  The system runs okay, and ACPI suspend/resume
> and suspend2 work, without AHCI.
> 
> > Of course, even if the AHCI driver is not needed,
> > it shouldn't be oopsing like this.
> > 
> > It looks like the ata_piix driver is the one that is
> > actually being used, from what I can see here.
> > 
> > Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
> > and 'lspci -v'.
> 
> They are enclosed below.

Hi,
While I'm looking over this, do you have a mode in which
the AHCI driver loads successfully?  If so, look for a
kernel message similar to this one:

ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x5 impl SATA mode

and post it, please.  (I think that it won't say "SATA mode".)
The "prog-if" value of 80 from your lspci output is interesting to me:
0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master])

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:

> On 05 Jan 2006 23:08:12 +0900
> Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> 
> > Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > >
> > > Does your system work without using the AHCI driver?
> > > or is it required?
> > 
> > I tested turning off AHCI with 2.6.15-rc7 + git-libata-all.patch +
> > libata_resume_fix.patch + libata_suspend-fix.patch +
> > libata_suspend.patch.  The system runs okay, and ACPI suspend/resume
> > and suspend2 work, without AHCI.
> > 
> > > Of course, even if the AHCI driver is not needed,
> > > it shouldn't be oopsing like this.
> > > 
> > > It looks like the ata_piix driver is the one that is
> > > actually being used, from what I can see here.
> > > 
> > > Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
> > > and 'lspci -v'.
> > 
> > They are enclosed below.
> 
> Hi,
> While I'm looking over this, do you have a mode in which
> the AHCI driver loads successfully?  If so, look for a
> kernel message similar to this one:
> 
> ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x5 impl SATA mode
> 
> and post it, please.  (I think that it won't say "SATA mode".)
> The "prog-if" value of 80 from your lspci output is interesting to me:
> 0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master])
> 

I couldn't find a line like that from a working kernel with AHCI
option on.  The only ahci-related lines look like

    ahci 0000:00:1f.2: version 1.2
    ahci: probe of 0000:00:1f.2 failed with error -12

I selected AHCI because the lines in ata_piix.c

	{ 0x8086, 0x2653, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_rm },

and

	/* ich6_sata_rm */
	{
		.sht		= &piix_sht,
		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_SRST |
				  PIIX_FLAG_COMBINED | PIIX_FLAG_CHECKINTR |
				  ATA_FLAG_SLAVE_POSS | PIIX_FLAG_AHCI,
		.pio_mask	= 0x1f,	/* pio0-4 */
		.mwdma_mask	= 0x07, /* mwdma0-2 */
		.udma_mask	= 0x7f,	/* udma0-6 */
		.port_ops	= &piix_sata_ops,
	},

seemed to indicate that my controller was ahci-capable.
But according to
http://marc.theaimsgroup.com/?l=linux-ide&m=111828214909335&w=2,
my system does not support AHCI.  I don't see Region 5 in the output
of lspci -vv -s 00:1f.2.

Jae-hyeon

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 06 Jan 2006 10:02:14 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> 
> > On 05 Jan 2006 23:08:12 +0900
> > Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:
> > 
> > > Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> > > >
> > > > Does your system work without using the AHCI driver?
> > > > or is it required?
> > > 
> > > I tested turning off AHCI with 2.6.15-rc7 + git-libata-all.patch +
> > > libata_resume_fix.patch + libata_suspend-fix.patch +
> > > libata_suspend.patch.  The system runs okay, and ACPI suspend/resume
> > > and suspend2 work, without AHCI.
> > > 
> > > > Of course, even if the AHCI driver is not needed,
> > > > it shouldn't be oopsing like this.
> > > > 
> > > > It looks like the ata_piix driver is the one that is
> > > > actually being used, from what I can see here.
> > > > 
> > > > Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
> > > > and 'lspci -v'.
> > > 
> > > They are enclosed below.
> > 
> > Hi,
> > While I'm looking over this, do you have a mode in which
> > the AHCI driver loads successfully?  If so, look for a
> > kernel message similar to this one:
> > 
> > ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x5 impl SATA mode
> > 
> > and post it, please.  (I think that it won't say "SATA mode".)
> > The "prog-if" value of 80 from your lspci output is interesting to me:
> > 0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master])
> > 
> 
> I couldn't find a line like that from a working kernel with AHCI
> option on.  The only ahci-related lines look like
> 
>     ahci 0000:00:1f.2: version 1.2
>     ahci: probe of 0000:00:1f.2 failed with error -12
> 
> I selected AHCI because the lines in ata_piix.c
> 
> 	{ 0x8086, 0x2653, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_rm },
> 
> and
> 
> 	/* ich6_sata_rm */
> 	{
> 		.sht		= &piix_sht,
> 		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_SRST |
> 				  PIIX_FLAG_COMBINED | PIIX_FLAG_CHECKINTR |
> 				  ATA_FLAG_SLAVE_POSS | PIIX_FLAG_AHCI,
> 		.pio_mask	= 0x1f,	/* pio0-4 */
> 		.mwdma_mask	= 0x07, /* mwdma0-2 */
> 		.udma_mask	= 0x7f,	/* udma0-6 */
> 		.port_ops	= &piix_sata_ops,
> 	},
> 
> seemed to indicate that my controller was ahci-capable.
> But according to
> http://marc.theaimsgroup.com/?l=linux-ide&m=111828214909335&w=2,
> my system does not support AHCI.  I don't see Region 5 in the output
> of lspci -vv -s 00:1f.2.

Yes, I don't think that it's AHCI-capable, but I still must
keep the Oops from happening, so I'm going thru your kernel
message log output (still).

Thanks for your help.
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy Dunlap]

On 05 Jan 2006 23:08:12 +0900
Jae-hyeon Park <jhpark@tuhep.phys.tohoku.ac.jp> wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> >
> > Does your system work without using the AHCI driver?
> > or is it required?
> 
> I tested turning off AHCI with 2.6.15-rc7 + git-libata-all.patch +
> libata_resume_fix.patch + libata_suspend-fix.patch +
> libata_suspend.patch.  The system runs okay, and ACPI suspend/resume
> and suspend2 work, without AHCI.
> 
> > Of course, even if the AHCI driver is not needed,
> > it shouldn't be oopsing like this.
> > 
> > It looks like the ata_piix driver is the one that is
> > actually being used, from what I can see here.
> > 
> > Please send your /proc/interrupts, /proc/iomem, /proc/ioports,
> > and 'lspci -v'.
> 
> They are enclosed below.
> 
> > If you are up to it, please enable libata verbose debugging
> > and then boot & cause this bug again and send me as much
> > output as you can collect.
> > Patch is below.
> 
> Let me remind you that I used kernel 2.6.15-rc7 +
> http://www.xenotime.net/linux/SATA/2.6.15-rc7/libata-combine.patch +
> libata verbose debug patch.  libata-combine-2615.patch does not cause
> kernel panic.

Thanks for that clarification.
So enabling ATA debugging via:
-#undef ATA_VERBOSE_DEBUG	/* yet more debugging output */
+#define ATA_DEBUG		/* debugging output */
+#define ATA_VERBOSE_DEBUG	/* yet more debugging output */

is causing this particular Oops.  Hmph.


> I copied boot up messages below for cases with CONFIG_SCSI_SATA_AHCI
> turned off and on.  After turning on verbose debugging messages, the
> call trace has changed, and the kernel panics for
> CONFIG_SCSI_SATA_AHCI=n as well.

To clarify more (for me):
Without the libata verbose debugging patch, do you (still)
have a problem with the AHCI driver causing an Oops?

Thanks,
---
~Randy

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Jae-hyeon Park]

Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:

> To clarify more (for me):
> Without the libata verbose debugging patch, do you (still)
> have a problem with the AHCI driver causing an Oops?

I compiled six versions of kernels anew and tested again.
The results are as follows:

    2.6.15-rc7 + libata-combine.patch AHCI=n
        Kernel panics.  Symbols in call trace are as in
        http://marc.theaimsgroup.com/?l=linux-ide&m=113632815321896&w=2
    
    2.6.15-rc7 + libata-combine.patch AHCI=y
        Kernel panics.  Symbols in call trace are as in
        http://marc.theaimsgroup.com/?l=linux-ide&m=113632815321896&w=2
    
    2.6.15-rc7 + libata-combine.patch + verbose patch AHCI=n
        Kernel panics.  Symbols in call trace are as in
        http://marc.theaimsgroup.com/?l=linux-ide&m=113647020707839&w=2
    
    2.6.15-rc7 + libata-combine.patch + verbose patch AHCI=y
        Kernel panics.  Symbols in call trace are as in
        http://marc.theaimsgroup.com/?l=linux-ide&m=113647020707839&w=2
    
    2.6.15 + libata-combine-2615.patch AHCI=n
        Resume works if snd_intel8x0m has been loaded.
    
    2.6.15 + libata-combine-2615.patch AHCI=y
        Resume works if snd_intel8x0m has been loaded.

It turned out that kernel panic is independent of AHCI option.  I made
a wrong statement in the bug report perhaps because I was compiling
too many kernels.  I am sorry for the confusion.

Jae-hyeon

Re: [PATCH 0/5] SATA/ACPI suspend/resume support

[Randy.Dunlap]

On 07 Jan 2006 22:11:00 +0900 Jae-hyeon Park wrote:

> Randy Dunlap <randy_d_dunlap@linux.intel.com> writes:
> 
> > To clarify more (for me):
> > Without the libata verbose debugging patch, do you (still)
> > have a problem with the AHCI driver causing an Oops?
> 
> I compiled six versions of kernels anew and tested again.
> The results are as follows:
> 
>     2.6.15-rc7 + libata-combine.patch AHCI=n
>         Kernel panics.  Symbols in call trace are as in
>         http://marc.theaimsgroup.com/?l=linux-ide&m=113632815321896&w=2
>     
>     2.6.15-rc7 + libata-combine.patch AHCI=y
>         Kernel panics.  Symbols in call trace are as in
>         http://marc.theaimsgroup.com/?l=linux-ide&m=113632815321896&w=2
>     
>     2.6.15-rc7 + libata-combine.patch + verbose patch AHCI=n
>         Kernel panics.  Symbols in call trace are as in
>         http://marc.theaimsgroup.com/?l=linux-ide&m=113647020707839&w=2
>     
>     2.6.15-rc7 + libata-combine.patch + verbose patch AHCI=y
>         Kernel panics.  Symbols in call trace are as in
>         http://marc.theaimsgroup.com/?l=linux-ide&m=113647020707839&w=2
>     
>     2.6.15 + libata-combine-2615.patch AHCI=n
>         Resume works if snd_intel8x0m has been loaded.
>     
>     2.6.15 + libata-combine-2615.patch AHCI=y
>         Resume works if snd_intel8x0m has been loaded.
> 
> It turned out that kernel panic is independent of AHCI option.  I made
> a wrong statement in the bug report perhaps because I was compiling
> too many kernels.  I am sorry for the confusion.

No problem.  I'll take a look at those panics again.

---
~Randy