[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SATA controller failure?

You're right in that the BIOS was flashed and used default settings (which apparently means disabling sata). I didn't take the initiative to the flashing though :-) so I still think it can be worthwhile to have someone take a look at the battery backup and powering of the motherboard. 
Thanks alot for your help

/Anders

Steven Jones wrote:


Flashed your bios? If so it might have picked fail safe defaults.

Anyway, check your bios to make sure the sata side has not been disabled
somehow.

On my sata setup you can see the sata being added to the systems bios
during post and the sata card polling for drives, if yours does'nt do
that then my only thought is a motherboard failure or a irq/mem
conflict.

Regards

thing

-----Original Message-----
From: Anders Rillbert [mailto:rillbert@chello.se] Sent: Friday, 18 November 2005 10:19 a.m. 
To: Steven Jones
Cc: debian-user@lists.debian.org
Subject: Re: SATA controller failure?

Hi,

Steven Jones wrote:

Any other changes? Patched the machine?

Nope.


Try running modprobe and see if you can manually install the driver.

Don't know what driver to try and install...



If not, reboot, does the sata card appear in the bios detection as the
machine posts?
The BIOS is unable to locate the sata drive. I don't have a separate sata card, it is integrated on the motherboard. I use GRUB as boot loader and when selecting my Windows distro (on the sata drive), GRUB fails with error 21 and a message that says something about not being able to find the disk. 

/Anders


-----Original Message-----
From: Anders Rillbert [mailto:rillbert@chello.se] Sent: Friday, 18 November 2005 9:35 a.m. 
To: debian-user@lists.debian.org
Subject: SATA controller failure?

Hi,
I have a dual boot system with a debian distro on an "ordinary" ide drive and a Windows distro on a SATA drive. Since yesterday morning my SATA drive can no longer be located by the BIOS but my other ide drive is not affected. 
I'm trying to figure out if it is the disk itself that has broke down

or
if it is something wrong on the motherboard (I don't have access to another machine with SATA connections to try the drive with). 
I have attached two snippets from my syslog, one before, and one after



the disk failure. To me it looks like linux can not even find the SATA
controller, implying that something has broke down on the motherboard (and the disk could hopefully still be ok). I'm not used to interpret these logs though, so I'd appreciate any comments on them: 

Syslog (outside the supplied snippets they are identical)

Before disk failure:
...
Nov 14 08:12:26 localhost kernel: eth0: Auto-negotiation Enabled.
Nov 14 08:12:26 localhost kernel: eth0: 100Mbps Full-duplex operation.
Nov 14 08:12:26 localhost kernel: libata version 1.02 loaded.
Nov 14 08:12:26 localhost kernel: ata_piix version 1.02
Nov 14 08:12:26 localhost kernel: ACPI: PCI interrupt 0000:00:1f.2[A]

->

GSI 18 (level, low) -> IRQ 185
Nov 14 08:12:26 localhost kernel: PCI: Setting latency timer of device



0000:00:1f.2 to 64
Nov 14 08:12:26 localhost kernel: ata1: SATA max UDMA/133 cmd 0xEC00

ctl

0xE802 bmdma 0xDC00 irq 185
Nov 14 08:12:26 localhost kernel: ata2: SATA max UDMA/133 cmd 0xE400

ctl

0xE002 bmdma 0xDC08 irq 185
Nov 14 08:12:26 localhost kernel: ata1: SATA port has no device.
Nov 14 08:12:26 localhost kernel: scsi0 : ata_piix
Nov 14 08:12:26 localhost kernel: ata2: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3c69 86:3c01 87:4003 88:20ff 
Nov 14 08:12:26 localhost kernel: ata2: dev 0 ATA, max UDMA7,
234493056 
sectors: lba48
Nov 14 08:12:26 localhost kernel: ata2: dev 0 configured for UDMA/133
Nov 14 08:12:26 localhost kernel: scsi1 : ata_piix
Nov 14 08:12:26 localhost kernel: Vendor: ATA Model: SAMSUNG SP1213C Rev: SV10 Nov 14 08:12:26 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05 Nov 14 08:12:26 localhost kernel: SCSI device sda: 234493056 512-byte hdwr sectors (120060 MB) 
Nov 14 08:12:26 localhost kernel: SCSI device sda: drive cache: write
back
Nov 14 08:12:26 localhost kernel:  /dev/scsi/host1/bus0/target0/lun0:

p1

p2 < p5 p6 p7 >
Nov 14 08:12:26 localhost kernel: Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 
Nov 14 08:12:26 localhost kernel: ACPI: PCI interrupt 0000:02:03.0[A]

->

GSI 19 (level, low) -> IRQ 177
Nov 14 08:12:26 localhost kernel: usbcore: registered new driver usbfs
Nov 14 08:12:26 localhost kernel: usbcore: registered new driver hub
Nov 14 08:12:26 localhost kernel: USB Universal Host Controller Interface driver v2.2 
Nov 14 08:12:26 localhost kernel: ACPI: PCI interrupt 0000:00:1d.0[A]

->

GSI 16 (level, low) -> IRQ 169
Nov 14 08:12:26 localhost kernel: uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 
Nov 14 08:12:26 localhost kernel: PCI: Setting latency timer of device



0000:00:1d.0 to 64
...

After disk failure:
...
Nov 16 07:07:55 localhost kernel: eth0: Auto-negotiation Enabled.
Nov 16 07:07:55 localhost kernel: eth0: 100Mbps Full-duplex operation.
Nov 16 07:07:55 localhost kernel: ACPI: PCI interrupt 0000:02:03.0[A]

->

GSI 19 (level, low) -> IRQ 177
Nov 16 07:07:55 localhost kernel: usbcore: registered new driver usbfs
Nov 16 07:07:55 localhost kernel: usbcore: registered new driver hub
Nov 16 07:07:55 localhost kernel: USB Universal Host Controller Interface driver v2.2 
Nov 16 07:07:55 localhost kernel: ACPI: PCI interrupt 0000:00:1d.0[A]

->

GSI 16 (level, low) -> IRQ 169
Nov 16 07:07:55 localhost kernel: uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 
Nov 16 07:07:55 localhost kernel: PCI: Setting latency timer of device



0000:00:1d.0 to 64
...

Regards
/Anders
Reply to: