# IDE Interface Broken?

## Chiitoo

Not quite sure where to ask about this, but if this is not the best place, I know it will be moved.  ^^

Acer Aspire 1360 Laptop I looked into some ages ago had issues with the hard-drive, or apparently I had thought so when I looked into it back when, but now that I looked into it once more again, I found out a bit more.

It's not that the hard-drive is failing, as it doesn't detect a hard-drive of another Laptop, and what is more, it's not detecting the DvD-drive, either.

They're not shown in the BIOS even.

So what I'm asking is, do you think that part of the mother-board is simply toast, and beyond any reasonable fix?

I guess it is rather obvious looking at the data below, but I want a confirmation and there are two (2) side-questions, too!

I think I tried flashing the BIOS already when I first looked into it, but I did try it again to no effect.

That was a feat on itself since the flash-script has a fail-safe to prevent going on with it if the battery power is below 30%, and the battery is pretty much dead.

Luckily I had not forgot everything about how to edit .bat files in DOS and I managed to disable that part of it, or rather make it go on with it no matter what the battery-state is.  That was also the first time I created a DOS-bootable USB-stick under Linux!

As I am a lot more versed with Linux as I was when I first looked into it (in other words, couldn't really do anything about it before, other than stare at the BIOS that has almost no settings other than the clock, and taking the thing apart and check everything is properly in place), I figured I might be able to get some in-depth info via SystemRescueCd.

Since the Disc-drive is out of service, I used a 4 GiB USB-stick.

I had not used SystemRescueCd before, but as it is oft 'advertised' here, I wanted to take a look and I have to say it's quite impressive.

Side-question number one: Is there a way to have it not use the whole stick?

Reason being that I would like to use part of the stick for saving data, which obviously doesn't work when SRC takes it all up and mounts read-only when booted.

I tried to create it manually after I couldn't change the size of it via GParted, but it wouldn't boot (I was quite careful to do it right but I guess I still missed something, as I doubt the instructions being outdated).

Anyhooo, here's some info from that trip, and if there's anything else you would try, please, do tell!

```
[    0.071869] libata version 3.00 loaded.

[    2.934220] Write protecting the kernel read-only data: 2364k

[    3.507490] pata_via 0000:00:11.1: version 0.3.4

[    3.507547] pata_via 0000:00:11.1: power state changed by ACPI to D0

[    3.507553] pata_via 0000:00:11.1: power state changed by ACPI to D0

[    3.507560] pata_via 0000:00:11.1: can't derive routing for PCI INT A

[    3.528646] scsi0 : pata_via

[    3.530546] scsi1 : pata_via

[    3.531229] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x1c60 irq 14

[    3.531234] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1c68 irq 15

[    3.685399] ata1.00: ATA-6: RT▒vxq@`, nu, max UDMA/133

[    3.685404] ata1.00: 50092224 sectors, multi 0: LBA 

[    3.685411] ata1.00: limited to UDMA/33 due to 40-wire cable

[    3.840221] ata1.00: model number mismatch 'RT▒vxq@`' != 'STvxqA````````````````'

[    3.840227] ata1.00: revalidation failed (errno=-19)

[    3.840234] ata1.00: limiting speed to UDMA/33:PIO3

[    9.083223] ata1.00: model number mismatch 'RT▒vxq@`' != 'sT9v1x3qa`!`!`!`!`!`!`!`!`!`!`!`!`!`!`!`'

[    9.083229] ata1.00: revalidation failed (errno=-19)

[    9.083233] ata1.00: disabled
```

Uh-oh, something definitely isn't right, right?

The drive that was attached at the time, is from an Amilo Pro V2020, a Seagate, hence the model ST960821A but why is it all garbled up?

And what is this RT[...] it is being compared to (!=)?

Is it sending two different model-numbers which in addition get all messed up?

The output changes a little depending of where it is displayed at (terminal/encoding).

```
[    9.083223] ata1.00: model number mismatch 'RTvxq@`' != 'sT9v1x3qa`!`!`!`!`!`!`!`!`!`!`!`!`!`!`!`'
```

Side-question number two: One of the drives in my main-box says:

```
[    1.771829] ata2.00: n_sectors mismatch 1953516911 != 1953525168
```

What does this mean exactly?

Other than the number to the left does not equal to the number to the right.

Anything I should be concerned of?  :S

Other than crippled ATA, the Laptop seems to work OK as far as I can tell from driving it via the USB-SystemRescueCd, so I guess with USB-drives it's still perfectly usable.

Concluding (fer now) with 'lspci -k' for the heck of it (lshw says nothing about storage/cdrom except for the USB-stick).

```
00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: agpgart-amd64

00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/8251 PCI bridge [K8M890/K8T800/K8T890 South]

00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: yenta_cardbus

   Kernel modules: yenta_socket

00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: yenta_cardbus

   Kernel modules: yenta_socket

00:0b.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: firewire_ohci

   Kernel modules: firewire-ohci

00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: uhci_hcd

00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: uhci_hcd

00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: uhci_hcd

00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: ehci_hcd

00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge

   Subsystem: VIA Technologies, Inc. VT8235 ISA Bridge

   Kernel modules: i2c-viapro, via-ircc

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: pata_via

   Kernel modules: pata_via

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)

   Subsystem: Acer Incorporated [ALI] Device 0046

00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80)

   Subsystem: Acer Incorporated [ALI] Device 0046

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: via-rhine

   Kernel modules: via-rhine

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control

   Kernel driver in use: k8temp

   Kernel modules: k8temp

01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 64M] (rev a1)

   Subsystem: Acer Incorporated [ALI] Device 006e

   Kernel driver in use: nouveau

   Kernel modules: nouveau

```

Thankies for reading.  ^^

----------

## roarinelk

could be bad cable, loose connector, or dying ide chip.  if even the bios

can't reliably detect ide devices then a hardware failure is most likely

 (judging from the output, maybe one pin is loose. you can still see part of the ST signature).

sq2: after identifying the drive, libata attempts to tune a drive, then does identification again.

it reads the capacity reported by the drive. in your case, after tuning (most likely disabling the

host-protected area, HPA) it grows a few sectors in size (in your case a bit over 4kB).  

that's what the message says.

----------

## Chiitoo

 *roarinelk wrote:*   

> could be bad cable, loose connector, or dying ide chip.  if even the bios
> 
> can't reliably detect ide devices then a hardware failure is most likely
> 
>  (judging from the output, maybe one pin is loose. you can still see part of the ST signature).

 

Mmm, cables are out of the equation as both the hard-drive and DvD-drive are attached directly to the 'blocks' of pins.

I didn't really inspect those when it was open so that's something I will look into.  Will also check the soldering and such, but I'm also leaning to the chip simply dying, especially since it can't detect the DvD-drive either.

Thanks.

 *roarinelk wrote:*   

> sq2: after identifying the drive, libata attempts to tune a drive, then does identification again.
> 
> it reads the capacity reported by the drive. in your case, after tuning (most likely disabling the
> 
> host-protected area, HPA) it grows a few sectors in size (in your case a bit over 4kB).  
> ...

 

Aha, I see.

Thanks for that, too!

----------

