Re: sata_nv does not function in kernel > 2.6.20.21

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.