sata_nv fails to detect drives

[Chris Osgood]

This issue is not really related to i386 alone as amd64 is also effected. This
effects any kernel using the libata SCSI sata_nv driver for SATA.

This may have something to do with nForce controllers and Seagate drives, I'm
not sure. I first saw this on my system which is using an Iwill DK8N nForce 250
Pro motherboard and Seagate 200GB hard drives (ST3200822AS). I had the drives
connected to the nForce controller while attempting to install Ubuntu. The
drives and/or SATA controller appeared to be detected by the sata_nv module but
I got this error message when the kernel attempts to boot:

ata1 is slow to respond
ata2 is slow to respond

Eventually the drives time-out and are not usable for installation.

Discussion threads:
http://lists.ubuntu.com/archives/ubuntu-users/2004-September/002521.html
http://www.amdzone.com/index.php?name=PNphpBB2&file=viewtopic&t=2300

This problem is described and a patch exists in the Linux kernel buzilla:
http://bugme.osdl.org/show_bug.cgi?id=3352

After applying that patch it appears to work normally. Although I have not
tested with a 2.6.8.1 kernel, it should work for that as well.

[Matt Zimmerman (mdz)]

Herbert, if you feel this is safe, I'm OK with this workaround going in for
Warty. We've had more than one report of this problem.

[Herbert Xu (herbert-gondor)]

It looks OK to me so I'll include it in the next upload.

[Chris Osgood (ubuntu-functionalfuture)]

As of kernel 2.6.10 and higher the workaround patch listed above is included in
the kernel.

[Matt Zimmerman (mdz)]

Are you able to confirm that the problem is fixed for you when using the Ubuntu
2.6.10 kernel in Hoary?

[Chris Osgood (ubuntu-functionalfuture)]

I tried the daily Hoary-install disc, both AMD64 and the i386 version. Neither
worked correctly.

It appears to load both the nv_sata and sata_nv drivers. I believe the nv_sata
driver is the deprecated IDE driver (?). That one should probably not be loaded.

One of my drives is detected but the other is not (slow to respond). It looks
like the one drive that was detected shows up as a SCSI device so I think the
right driver got it. My only guess is that the old IDE driver must reset the
drives which effects the SCSI driver when it tries to access the drive(s). I
believe the bug in the kernel may be related to the amount of time a reset
takes. The fix was to prevent the driver from reseting the drive.

[Chuck Short (zulcss)]

Is this with nforce 3 chipset? Can you add the demidecode to the bug report?

[Chris Osgood (ubuntu-functionalfuture)]

It is an Iwill DK8N - nForce3 Pro 250 chipset

# dmidecode 2.4
SMBIOS 2.3 present.
49 structures occupying 1933 bytes.
Table at 0x000FA0D0.
Handle 0x0000
 DMI type 0, 20 bytes.
 BIOS Information
  Vendor: American Megatrends Inc.
  Version: 080010
  Release Date: 10/14/2004
  Address: 0xF0000
  Runtime Size: 64 kB
  ROM Size: 512 kB
  Characteristics:
   ISA is supported
   PCI is supported
   PNP is supported
   APM is supported
   BIOS is upgradeable
   BIOS shadowing is allowed
   ESCD support is available
   Boot from CD is supported
   Selectable boot is supported
   BIOS ROM is socketed
   EDD is supported
   5.25"/1.2 MB floppy services are supported (int 13h)
   3.5"/720 KB floppy services are supported (int 13h)
   3.5"/2.88 MB floppy services are supported (int 13h)
   Print screen service is supported (int 5h)
   8042 keyboard services are supported (int 9h)
   Serial services are supported (int 14h)
   Printer services are supported (int 17h)
   CGA/mono video services are supported (int 10h)
   ACPI is supported
   USB legacy is supported
   AGP is supported
   LS-120 boot is supported
   ATAPI Zip drive boot is supported
   BIOS boot specification is supported
Handle 0x0001
 DMI type 1, 25 bytes.
 System Information
  Manufacturer: To Be Filled By O.E.M.
  Product Name: To Be Filled By O.E.M.
  Version: To Be Filled By O.E.M.
  Serial Number: To Be Filled By O.E.M.
  UUID: 00020003-0004-0005-0006-000700080009
  Wake-up Type: PCI PME#
Handle 0x0002
 DMI type 2, 15 bytes.
 Base Board Information
  Manufacturer: To be filled by O.E.M.
  Product Name: To be filled by O.E.M.
  Version: To be filled by O.E.M.
  Serial Number: To be filled by O.E.M.
  Asset Tag: To Be Filled By O.E.M.
  Features:
  Board is a hosting board
  Board is replaceable
  Location In Chassis: To Be Filled By O.E.M.
  Chassis Handle: 0x0003
  Type: Motherboard
  Contained Object Handlers: 0
Handle 0x0003
 DMI type 3, 21 bytes.
 Chassis Information
  Manufacturer: To Be Filled By O.E.M.
  Type: Desktop
  Lock: Not Present
  Version: To Be Filled By O.E.M.
  Serial Number: To Be Filled By O.E.M.
  Asset Tag: To Be Filled By O.E.M.
  Boot-up State: Safe
  Power Supply State: Safe
  Thermal State: Safe
  Security Status: None
  OEM Information: 0x00000000
Heigth: Unspecified
Number Of Power Cords: 1
  Contained Elements: 0
Handle 0x0004
 DMI type 4, 35 bytes.
 Processor Information
  Socket Designation: CPU 1
  Type: Central Processor
  Family: Opteron
  Manufacturer: AMD
  ID: 5A 0F 00 00 FF FB 8B 07
  Signature: Extended Family 0, Model 5, Stepping A
  Flags:
   FPU (Floating-point unit on-chip)
   VME (Virtual mode extension)
   DE (Debugging extension)
   PSE (Page size extension)
   TSC (Time stamp counter)
   MSR (Model specific registers)
   PAE (Physical address extension)
   MCE (Machine check exception)
   CX8 (CMPXCHG8 instruction supported)
   APIC (On-chip APIC hardware supported)
   SEP (Fast system call)
   MTRR (Memory type range registers)
   PGE (Page global enable)
   MCA (Machine check architecture)
   CMOV (Conditional move instruction supported)
   PAT (Page attribute table)
   PSE-36 (36-bit page size extension)
   CLFSH (CLFLU...

[Chris Osgood (ubuntu-functionalfuture)]

Recently this issue has gone away on my system. I upgraded to the latest DK8N
BIOS (v1.11) and added a PATA drive at the same time so I'm not sure which fixed
it but I can now boot the Ubuntu/Kubuntu Hoary release 5.04 and it finally
detects all my drives.

I have a suspicion that it was the BIOS upgrade as the changelog mentioned
something about failure to detect drives.

[Ben Collins (ben-collins)]

Closing on the basis of the last comment, reporting that it worked.