Bug 4460

Summary:	PCMCIA hard disk not started correctly
Product:	Drivers	Reporter:	Owen Savill (osavill)
Component:	PCMCIA	Assignee:	linux-pcmcia
Status:	REJECTED INSUFFICIENT_DATA
Severity:	normal	CC:	bunk
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.11	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	PCMCIA mass storage diagnostic output PCMCIA mass storage diagnostic output PCMCIA mass storage diagnostic output PCMCIA mass storage diagnostic output

Description Owen Savill 2005-04-08 14:47:48 UTC

Distribution: Mandrake 10.1
Hardware Environment: Dell Inspiron 7500
Software Environment: kernel 2.6.11
Problem Description:

When the PCMCIA hard disk is inserted the LEDs light up and the disk spins, then 
everything stops, then the LEDs come back on and the disk spins up again then it 
 all stops again. The stop is very sudden and complete. By doing cardctl insert 
the system will do the double beep and hde1 .. hdeN appear in /dev, but none of 
them can be mounted. The disk has 2 FAT32, 1 swap and 5 ext3 partitions The /
var/log/messages output is simply:
Apr  8 22:03:29 opc kernel: cs: pcmcia_socket1: time out after reset.

This disk works fine under 2.4 and Windoze.

Steps to reproduce: Plugin a PCMCIA hard disk

Comment 1 Dominik Brodowski 2005-04-09 13:04:03 UTC

Please create a new attachment with complete "dmesg" output.

Comment 2 Andrew Morton 2005-05-25 22:07:32 UTC

What happened to that dmesg output?

Is this bug still present in 2.6.12-rc5?

Comment 3 Owen Savill 2005-05-26 13:24:35 UTC

Sorry about the inactivity, we've been in turmoil just recently. I will get  
back to it now. Thanks, for you patience.

Comment 4 Owen Savill 2005-05-27 14:41:49 UTC

Yes, it is still present. 
 
The dmesg output is: 
May 27 22:26:50 localhost kernel: cs: pcmcia_socket0: time out after reset. 
May 27 22:27:11 localhost kernel: PCMCIA: socket dfc0642c: *** DANGER *** 
unable to remove socket power 
May 27 22:27:20 localhost kernel: PCI: Enabling device 0000:06:00.0 (0000 -> 
0002) 
May 27 22:27:20 localhost kernel: PCI: No IRQ known for interrupt pin A of 
device 0000:06:00.0. Please try using pci=biosirq. 
May 27 22:27:20 localhost kernel: ohci_hcd 0000:06:00.0: Found HC with no IRQ.  
Check BIOS/PCI 0000:06:00.0 setup! 
May 27 22:27:20 localhost kernel: PCI: Enabling device 0000:06:00.3 (0000 -> 
0002) 
May 27 22:27:20 localhost kernel: PCI: No IRQ known for interrupt pin A of 
device 0000:06:00.3. Please try using pci=biosirq. 
May 27 22:27:20 localhost kernel: ehci_hcd 0000:06:00.3: Found HC with no IRQ.  
Check BIOS/PCI 0000:06:00.3 setup! 
May 27 22:27:36 localhost kernel: PCMCIA: socket dfc0642c: *** DANGER *** 
unable to remove socket power 
May 27 22:27:48 localhost kernel: cs: pcmcia_socket0: time out after reset.

Comment 5 Dominik Brodowski 2005-05-31 11:49:15 UTC

Have you tried pci=biosirq as the dmesg output suggests? Can you attach a
_complete_ dmesg here, please?
Sidenote to akpm: this should not hold up 2.6.12 --- the reason for the
mysterious "unable to remove socket power" is not tracked down, and present in
many kernel releases

Comment 6 Owen Savill 2005-06-01 13:27:18 UTC

4 kernel output files attached...

Comment 7 Owen Savill 2005-06-01 13:27:56 UTC

Created attachment 5109 [details]
PCMCIA mass storage diagnostic output

Comment 8 Owen Savill 2005-06-01 13:28:38 UTC

Created attachment 5110 [details]
PCMCIA mass storage diagnostic output

Comment 9 Owen Savill 2005-06-01 13:29:14 UTC

Created attachment 5111 [details]
PCMCIA mass storage diagnostic output

Comment 10 Owen Savill 2005-06-01 13:30:02 UTC

Created attachment 5112 [details]
PCMCIA mass storage diagnostic output

Comment 11 Owen Savill 2005-06-01 13:30:40 UTC

These files were collected at boot up with an attached USB disk. The results
are the same with or without the USB disk and if the test is repeated after
boot. They are done with "pci=biosirq", but the results are the same without this.

Comment 12 Dominik Brodowski 2005-06-30 14:25:33 UTC

Please re-try with a very recent kernel, build the yenta socket driver into the
kernel and boot with "yenta_socket.bios_override=1".

Comment 13 Dominik Brodowski 2005-07-25 11:14:59 UTC

any update on this with recent kernels, and also the module parameter I
suggested last time?

Comment 14 Owen Savill 2005-07-26 14:09:55 UTC

Sorry for the delay. Should be able to turn my attention back to these over the
next few days. Thanks for the patience.

Comment 15 Owen Savill 2005-08-08 14:33:31 UTC

Sorry about the delay.   
   
Tried 2.6.12.4 tonight and still no go. Looking in the logs the only output I   
can see is "Aug  8 22:04:43 localhost kernel: cs: pcmcia_socket1: time out   
after reset." 
   
That's still all I can find ! Nothing id dmesg this time, will recheck the 
kernel config to ensure I've enabled all debug.   
 
It looks like the device will work if it is presents during boot up. I'll 
recheck this as well to ensure I wasn't seeing things !

Comment 16 Owen Savill 2005-08-08 14:35:42 UTC

Rats - sorry missed Comment #12 From Dominik Brodowski. 
 
It's getting late so I'll try the suggestion tomorrow.

Comment 17 Owen Savill 2005-08-09 12:17:07 UTC

Tried "yenta_socket.bios_override=1" and it made no difference. And I was 
mistaken, booting with the device inserted does not make it work. 
 
Have also tried a Toshiba 5Gb drive. Although this is recognised it is not 
read / writable and df reports about 340K free even though the disk is 
completely empty. 
 
Now the strange bit. A Toshiba 2Gb and an unbadged 340Mb disk both work fine. 
The disk in the caddy is a 20Gb. So is it a size issue ?  
 
The 5Gb, 2Gb and 340Mb disk and "propper" PCMCIA disks in that they are 
complete units, whereas mine is a 2.5" disk in a caddy. But then the 5Gb 
doesn't work either, but then again it fails in a different way to mine in the 
caddy !!!

Comment 18 Dominik Brodowski 2005-11-15 08:54:59 UTC

Can you check the status of this in 2.6.14.2 or 2.6.15-rc1, please?

Comment 19 Owen Savill 2005-11-15 15:14:02 UTC

Will do...

Comment 20 Dominik Brodowski 2006-01-10 09:16:59 UTC

Can you check the status of this in 2.6.15 or later, please?

Comment 21 Dominik Brodowski 2006-03-27 13:18:42 UTC

Could you verify whether this problem still exists in 2.6.16, please?

Comment 22 Adrian Bunk 2006-08-01 06:39:55 UTC

Please reopen this bug if it's still present in kernel 2.6.17.