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

[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

[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.