sata_nv does not function in kernel > 2.6.20.21

sata_nv does not function in kernel > 2.6.20.21

[Matthew Hall]

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

Hello Storage Controller Experts,

I am writing this mail to you to request your assistance in resolving a 
functionality regression in my sata_nv controller driver in recent Linux 
kernels. I am hoping you can assist me in finding a solution to this 
because my TV tuner card is dependent on some fixes in the newer kernels 
but using the newer kernels causes some of my storage volumes to be 
unreadable, thereby putting me in a catch-22 situation. Please let me 
know if any other omitted information is required for diagnostics.

Sorry for the delay in contacting you promptly but:

1) I attempted to contact the maintainer listed directly in the driver 
source code and he never replied.

2) I was holding out the mistaken hope that the problem was transient 
and would be resolved without my intervention.

Disclaimer: I am sure one of you will notice I am using the nvidia 
binary video graphics driver on this system... I say this to provide 
full disclosure that I am aware of the implications and of course I am 
willing to disable the driver for diagnostic purposes. I have tried 
running the system without the driver loaded and did not find any change 
in behavior but if you think it is part of the problem please let me 
know.

I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA 
channels quit working due to some kind of resource conflict when I 
upgrade to any kernel above 2.6.20.xx series, in my case I am running 
2.6.20.21 SMP x86_64 presently.

The boot error which appears in dmesg for the missing SATA channels on 
2.6.23.12 is pasted below and a compressed copy of my configuration file 
for 2.6.23.12 is attached.

The dmesg for 2.6.20.21 is attached and note the configuration is the 
same except for being run through make oldconfig.

Best Regards,
Matthew Hall


ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 46
ACPI: PCI Interrupt 0000:80:07.0[A] -> Link [LT3D] -> GSI 46 (level,
low) -> IRQ 46
sata_nv 0000:80:07.0: Using ADMA mode
PCI: Unable to reserve mem region #6:1000@dfefe000 for device
0000:80:07.0
ACPI: PCI interrupt for device 0000:80:07.0 disabled
sata_nv: probe of 0000:80:07.0 failed with error -16
ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45
ACPI: PCI Interrupt 0000:80:08.0[A] -> Link [LT2E] -> GSI 45 (level,
low) -> IRQ 45
sata_nv 0000:80:08.0: Using ADMA mode
PCI: Unable to reserve mem region #6:1000@dfefd000 for device
0000:80:08.0
ACPI: PCI interrupt for device 0000:80:08.0 disabled
sata_nv: probe of 0000:80:08.0 failed with error -16

[-- Attachment #2: config-2.6.23.12.gz --]
[-- Type: application/octet-stream, Size: 9733 bytes --]

[-- Attachment #3: dmesg-2.6.20.21.gz --]
[-- Type: application/octet-stream, Size: 6329 bytes --]

Re: sata_nv does not function in kernel > 2.6.20.21

[Matthew Wilcox]

On Thu, Jan 10, 2008 at 02:47:33AM +0000, Matthew Hall wrote:
> I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA 
> channels quit working due to some kind of resource conflict when I 
> upgrade to any kernel above 2.6.20.xx series, in my case I am running 
> 2.6.20.21 SMP x86_64 presently.

Could you provide an 'lspci -v' and a 'cat /proc/iomem' for both kernels
please?  This doesn't seem to be a scsi problem per se, so I'm adding
linux-kernel and linux-ide -- can you drop linux-scsi from any reply
please.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: sata_nv does not function in kernel > 2.6.20.21

[Matthew Hall]

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

Matthew,

On Wed, Jan 09, 2008 at 08:39:45PM -0700, Matthew Wilcox wrote:
> On Thu, Jan 10, 2008 at 02:47:33AM +0000, Matthew Hall wrote:
> > I am using the Supermicro H8DCE motherboard. Some (not all) of the SATA 
> > channels quit working due to some kind of resource conflict when I 
> > upgrade to any kernel above 2.6.20.xx series, in my case I am running 
> > 2.6.20.21 SMP x86_64 presently.
> 
> Could you provide an 'lspci -v' and a 'cat /proc/iomem' for both kernels
> please?

I attached the requested materials to this mail.

> This doesn't seem to be a scsi problem per se, so I'm adding
> linux-kernel and linux-ide -- can you drop linux-scsi from any reply
> please.

Sorry, my mistake... since SATA was located under the SCSI section of 
the kernel and I have not posted previously I was not sure where to go 
with this one.

[-- Attachment #2: iomem-2.6.20.21.gz --]
[-- Type: application/octet-stream, Size: 575 bytes --]

[-- Attachment #3: iomem-2.6.23.12.gz --]
[-- Type: application/octet-stream, Size: 561 bytes --]

[-- Attachment #4: lspci-verbose-2.6.20.21.gz --]
[-- Type: application/octet-stream, Size: 1393 bytes --]

[-- Attachment #5: lspci-verbose-2.6.23.12.gz --]
[-- Type: application/octet-stream, Size: 1400 bytes --]

Re: sata_nv does not function in kernel > 2.6.20.21

[Jeff Garzik]

Matthew Hall wrote:
> ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 46
> ACPI: PCI Interrupt 0000:80:07.0[A] -> Link [LT3D] -> GSI 46 (level,
> low) -> IRQ 46
> sata_nv 0000:80:07.0: Using ADMA mode
> PCI: Unable to reserve mem region #6:1000@dfefe000 for device
> 0000:80:07.0
> ACPI: PCI interrupt for device 0000:80:07.0 disabled
> sata_nv: probe of 0000:80:07.0 failed with error -16
> ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45
> ACPI: PCI Interrupt 0000:80:08.0[A] -> Link [LT2E] -> GSI 45 (level,
> low) -> IRQ 45
> sata_nv 0000:80:08.0: Using ADMA mode
> PCI: Unable to reserve mem region #6:1000@dfefd000 for device
> 0000:80:08.0
> ACPI: PCI interrupt for device 0000:80:08.0 disabled
> sata_nv: probe of 0000:80:08.0 failed with error -16

Error -16 is EBUSY, which causes the driver load to fail due to the 
"Unable to reserve mem region" message.

This means that the sata_nv driver needed to use PCI BAR 6, but was 
unable to for some reason.  Given that sata_nv uses devres like other 
libata drivers, IMO the likely cause is outside the ATA subsystem (PCI? 
ACPI?).

One workaround to try is setting sata_nv module option 'adma' to zero 
(0), in the hopes that it ignores that final region and work anyway.

	Jeff

Re: sata_nv does not function in kernel > 2.6.20.21

[Matthew Hall]

On Wed, Jan 09, 2008 at 11:40:47PM -0500, Jeff Garzik wrote:
> Error -16 is EBUSY, which causes the driver load to fail due to the "Unable 
> to reserve mem region" message.
>
> This means that the sata_nv driver needed to use PCI BAR 6, but was unable 
> to for some reason.  Given that sata_nv uses devres like other libata 
> drivers, IMO the likely cause is outside the ATA subsystem (PCI? ACPI?).

I will follow up on this with the appropriate subsystem lists ASAP. 
Thanks for getting me redirected appropriately.

> One workaround to try is setting sata_nv module option 'adma' to zero (0), 
> in the hopes that it ignores that final region and work anyway.

I am not quite sure what to do about this part... my boot device for the 
system is on one of the sata_nv channels which remains functional and 
does not get disabled by the resource conflict.

How shall I best attempt the suggested workaround without having to 
delete the sata_nv driver from the kernel thus rendering the kernel 
unbootable on this machine? Is there some way to pass the appropriate 
option at boot instead of at module load time or some file I could 
modify to enable the specified option in the code?

> 	Jeff

Thanks for the fast reply!
Matthew Hall

Re: sata_nv does not function in kernel > 2.6.20.21

[Jeff Garzik]

Matthew Hall wrote:
> On Wed, Jan 09, 2008 at 11:40:47PM -0500, Jeff Garzik wrote:
>> Error -16 is EBUSY, which causes the driver load to fail due to the "Unable 
>> to reserve mem region" message.
>>
>> This means that the sata_nv driver needed to use PCI BAR 6, but was unable 
>> to for some reason.  Given that sata_nv uses devres like other libata 
>> drivers, IMO the likely cause is outside the ATA subsystem (PCI? ACPI?).
> 
> I will follow up on this with the appropriate subsystem lists ASAP. 
> Thanks for getting me redirected appropriately.
> 
>> One workaround to try is setting sata_nv module option 'adma' to zero (0), 
>> in the hopes that it ignores that final region and work anyway.
> 
> I am not quite sure what to do about this part... my boot device for the 
> system is on one of the sata_nv channels which remains functional and 
> does not get disabled by the resource conflict.
> 
> How shall I best attempt the suggested workaround without having to 
> delete the sata_nv driver from the kernel thus rendering the kernel 
> unbootable on this machine? Is there some way to pass the appropriate 
> option at boot instead of at module load time or some file I could 
> modify to enable the specified option in the code?

If you build the driver into the kernel, then pass "sata_nv.adma=0" on 
the kernel command line.

Otherwise, look into how your distro sets module options... probably 
editing /etc/modprobe.conf.  You may need to regenerate critical boot 
files such as initramfs (aka initrd) afterwards, again distro specific 
(try mkinitrd).  Set module option "adma=0" for the sata_nv module.

	Jeff

Re: sata_nv does not function in kernel > 2.6.20.21

[Alan Cox]

> Error -16 is EBUSY, which causes the driver load to fail due to the 
> "Unable to reserve mem region" message.
> 
> This means that the sata_nv driver needed to use PCI BAR 6, but was 
> unable to for some reason.  Given that sata_nv uses devres like other 
> libata drivers, IMO the likely cause is outside the ATA subsystem (PCI? 
> ACPI?).

Actually it looks to me like there is something very odd going on here.
The sata_nv code checks each of the 6 resources exists (wrongly - it does
it before pcim_enable_device so the check is probably not valid). That
would report -ENODEV.

EBUSY implies all 6 resources were assigned but one couldn't be mapped.