Re: 2.6.14-rc5-mm1 - ide-cs broken!

Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Greg KH]

<apologies for the broken threading>

> [17194333.620000] cs: memory probe 0xf0000000-0xf80fffff: excluding 
> 0xf0000000-0xf87fffff
> [17194333.644000] pcmcia: Detected deprecated PCMCIA ioctl usage.
> [17194333.644000] pcmcia: This interface will soon be removed from the 
> kernel; please expect breakage unless you upgrade to new tools.
> [17194333.644000] pcmcia: see 
> http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for 
> details.
> [17194334.032000] Probing IDE interface ide2...
> [17194334.320000] hde: 1024MB Flash Card, CFA DISK drive
> [17194334.992000] ide2 at 0x4100-0x4107,0x410e on irq 3
> [17194334.992000] hde: max request size: 128KiB
> [17194334.992000] hde: 2001888 sectors (1024 MB) w/1KiB Cache, 
> CHS=1986/16/63
> [17194334.992000] hde: cache flushes not supported
> [17194334.992000]  hde: hde1
> [17194335.004000] ide-cs: hde: Vcc = 3.3, Vpp = 0.0
> [17194335.224000]  hde: hde1
> [17194335.632000]  hde: hde1
> [17194335.736000]  hde: hde1
> [17194335.744000]  hde: hde1
> ... ("hde: hde1" repeating)...
> 
> ok, now the situation is less lethal, but still no proper ide-cs working. 
> there are no unknown symbols now, but the other output in dmesg is the 
> same. especially, the loop to output "hde: hde1" is here, but if i remove 
> the card, it stops and the system is still responsible. 
> 
> i checked something i forgot to check before... is the hde device seen 
> in /sys somewhere, when the card is plugged in. the answer is yes!:
> 
> /sys/block/hde/hde1/
> 
> presents itself fully normal like other ide drives. in 
> /sys/block/hde/hde1/sample.sh 
> i found "mknod /dev/hde1 b 33 1" and tried to run it. successfully!
> the result is: in dmesg, the "hde: hde1" output loop stopped and my card 
> is working again!!! 

Heh, the poor-man's udev worked for someone :)

> so the trouble seems not only (or not at all) related to the kernel but 
> (also) to udev (i use 071), hotplug (mine is 2004_09_23), pcmciautils 
> (010) or something else.
> 
> can somebody tell me, what state of this process (discovering device, 
> loading needed modules, udev creating node under /dev) is the output 
> "hde: hde1" to dmesg and how can it be possible that it loops? 

The problem is in your udev rules.  You are running something in them
that is opening up your ide-cs device, which causes another hotplug
event to happen, which causes udev to run again, and so on.

I suggest you take this up with your distro, they are the ones
responsible for this problem.

Hint, gentoo, debian, and suse don't have this problem, so you might
want to look at their rules files for how to work around this.  Look for
this line:

# skip accessing removable ide devices, cause the ide drivers are horrible broken

and add the rules after it.

> it seems that this chain of processing is stuck somewhere and needs a 
> execution of the command to create the node under /dev by hand to finish.

I think the presence of the node causes udev to not generate another
one, which keeps the rule from being run and another hotplug event from
being generated.

Hope this helps,

greg k-h

Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Alan Cox]

On Iau, 2005-11-03 at 23:19 -0800, Greg KH wrote:
> Hint, gentoo, debian, and suse don't have this problem, so you might
> want to look at their rules files for how to work around this.  Look for
> this line:
> 
> # skip accessing removable ide devices, cause the ide drivers are horrible broken


I was under the impression people had eventually decided the media
change patch someone was proposed was ok after investigating one or two
cases I knew of that turned out to be borked hardware ?

Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Greg KH]

On Fri, Nov 04, 2005 at 03:14:53PM +0000, Alan Cox wrote:
> On Iau, 2005-11-03 at 23:19 -0800, Greg KH wrote:
> > Hint, gentoo, debian, and suse don't have this problem, so you might
> > want to look at their rules files for how to work around this.  Look for
> > this line:
> > 
> > # skip accessing removable ide devices, cause the ide drivers are horrible broken
> 
> 
> I was under the impression people had eventually decided the media
> change patch someone was proposed was ok after investigating one or two
> cases I knew of that turned out to be borked hardware ?

I was not aware of that, I'd be glad to see that patch go into the tree
to help others who have run into this over the years.

Hm, have a pointer to the latest proposed patch for this anywhere?

thanks,

greg k-h

ide-cs broken / udev magic

[Damir Perisa]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

Le Friday 04 November 2005 08:19, Greg KH a écrit :
 | <apologies for the broken threading>

no problem

@Judd + Tobias: this is a ide-cs trouble thing that exists in arch with 
default udev rules as of 071-1

 | > [17194333.620000] cs: memory probe 0xf0000000-0xf80fffff: excluding
 | > 0xf0000000-0xf87fffff
 | > [17194333.644000] pcmcia: Detected deprecated PCMCIA ioctl usage.
 | > [17194333.644000] pcmcia: This interface will soon be removed from
 | > the kernel; please expect breakage unless you upgrade to new tools.
 | > [17194333.644000] pcmcia: see
 | > http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for
 | > details.
 | > [17194334.032000] Probing IDE interface ide2...
 | > [17194334.320000] hde: 1024MB Flash Card, CFA DISK drive
 | > [17194334.992000] ide2 at 0x4100-0x4107,0x410e on irq 3
 | > [17194334.992000] hde: max request size: 128KiB
 | > [17194334.992000] hde: 2001888 sectors (1024 MB) w/1KiB Cache,
 | > CHS=1986/16/63
 | > [17194334.992000] hde: cache flushes not supported
 | > [17194334.992000]  hde: hde1
 | > [17194335.004000] ide-cs: hde: Vcc = 3.3, Vpp = 0.0
 | > [17194335.224000]  hde: hde1
 | > [17194335.632000]  hde: hde1
 | > [17194335.736000]  hde: hde1
 | > [17194335.744000]  hde: hde1
 | > ... ("hde: hde1" repeating)...
 | >
 | > ok, now the situation is less lethal, but still no proper ide-cs
 | > working. there are no unknown symbols now, but the other output in
 | > dmesg is the same. especially, the loop to output "hde: hde1" is
 | > here, but if i remove the card, it stops and the system is still
 | > responsible.
 | >
 | > /sys/block/hde/hde1/
 | > presents itself fully normal like other ide drives. in
 | > /sys/block/hde/hde1/sample.sh
 | > i found "mknod /dev/hde1 b 33 1" and tried to run it. successfully!
 | > the result is: in dmesg, the "hde: hde1" output loop stopped and my
 | > card is working again!!!
 |
 | Heh, the poor-man's udev worked for someone :)

:D ... true, sometimes one has to do things manually to have it done.

 | The problem is in your udev rules. You are running something in them 
 | that is opening up your ide-cs device, which causes another hotplug
 | event to happen, which causes udev to run again, and so on.

thanx for the explaination. i'm using archlinux and it seems that i'm the 
only one who uses ide-cs and therefore ran into this trouble. i just 
added

BUS=="ide", SYSFS{removable}="1", GOTO="no_volume_id"
BUS=="ide", SYSFS{../removable}="1", GOTO="no_volume_id"

to /etc/udev/rules.d/udev.rules

as other distros use to ignore removable ide's. now i need to load the 
ide-cs module by hand (bad thing, as module should be loaded 
automagically with udev/hotplug) but on the other hand, no more 
dmesg-spamming, no freezes and also the node is created successfully 
after module is loaded. 

is there some other rules that may be usefull adding in this case? 

is there planed action to change ide-cs to work without making it being 
ignored ... without this exception that needs to be specified in udev 
rules? 

thank you for the analysis and the workaround that i'm now using to have 
ide-cs working again. making it behave like any other ide would be cool, 
but is only aesthetical for me, as things work now :)

greetings,
Damir

-- 
Build a system that even a fool can use and only a fool will want to use 
it.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ide-cs broken / udev magic

[Greg KH]

On Sat, Nov 05, 2005 at 12:22:36AM +0100, Damir Perisa wrote:
> as other distros use to ignore removable ide's. now i need to load the 
> ide-cs module by hand (bad thing, as module should be loaded 
> automagically with udev/hotplug) but on the other hand, no more 
> dmesg-spamming, no freezes and also the node is created successfully 
> after module is loaded. 

This shouldn't have changed the "autoload" capability of the module at
all.  It should still being loaded with whatever means it was being
loaded before.  But that's a distro specific question, not a
linux-kernel issue.

> is there planed action to change ide-cs to work without making it being 
> ignored ... without this exception that needs to be specified in udev 
> rules? 

Yes, there are patches somewhere to fix this up, I'm trying to track
them down.

thanks,

greg k-h

Re: ide-cs broken / udev magic

[Richard Purdie]

On Fri, 2005-11-04 at 15:28 -0800, Greg KH wrote:
> On Sat, Nov 05, 2005 at 12:22:36AM +0100, Damir Perisa wrote:
> > as other distros use to ignore removable ide's. now i need to load the 
> > ide-cs module by hand (bad thing, as module should be loaded 
> > automagically with udev/hotplug) but on the other hand, no more 
> > dmesg-spamming, no freezes and also the node is created successfully 
> > after module is loaded. 
> 
> This shouldn't have changed the "autoload" capability of the module at
> all.  It should still being loaded with whatever means it was being
> loaded before.  But that's a distro specific question, not a
> linux-kernel issue.
> 
> > is there planed action to change ide-cs to work without making it being 
> > ignored ... without this exception that needs to be specified in udev 
> > rules? 
> 
> Yes, there are patches somewhere to fix this up, I'm trying to track
> them down.

This is a bug in the ide layer as CF pcmcia devices are marked as
removable but the devices (and the behaviour of ide-cs) does not fit the
Linux definition of such devices.

See this thread: http://lkml.org/lkml/2005/9/21/118

I'm hoping to work out a patch to change this in a manner acceptable to
everyone but haven't found time yet. I've not forgotten though.

Richard

Re: ide-cs broken / udev magic

[Damir Perisa]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

Le Saturday 05 November 2005 03:06, Richard Purdie a écrit :
 | > > is there planed action to change ide-cs to work without making it
 | > > being ignored ... without this exception that needs to be
 | > > specified in udev rules?
 | >
 | > Yes, there are patches somewhere to fix this up, I'm trying to track
 | > them down.
 
thanx for info + your work

 | This is a bug in the ide layer as CF pcmcia devices are marked as
 | removable but the devices (and the behaviour of ide-cs) does not fit
 | the Linux definition of such devices.
 |
 | See this thread: http://lkml.org/lkml/2005/9/21/118
 
ah!... ok, now i understand more about that. what your patch is doing is 
removing the "removable" status from them, right? what were the bad sides 
of this patch? (why didn't it made to the linus or at least mm-tree?)

 | I'm hoping to work out a patch to change this in a manner acceptable
 | to everyone but haven't found time yet. I've not forgotten though.

if you need, i can test possible solutions. i have Apacer, Kodak and PQI 
CF cards; SanDisk SD cards, a panasonic SD-to-CF convertor and a 
CF-PCMCIA card. 

greetings,
Damir

-- 
The sum of the Universe is zero.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Richard Purdie]

On Fri, 2005-11-04 at 08:37 -0800, Greg KH wrote:
> On Fri, Nov 04, 2005 at 03:14:53PM +0000, Alan Cox wrote:
> > On Iau, 2005-11-03 at 23:19 -0800, Greg KH wrote:
> > > Hint, gentoo, debian, and suse don't have this problem, so you might
> > > want to look at their rules files for how to work around this.  Look for
> > > this line:
> > > 
> > > # skip accessing removable ide devices, cause the ide drivers are horrible broken
> > 
> > 
> > I was under the impression people had eventually decided the media
> > change patch someone was proposed was ok after investigating one or two
> > cases I knew of that turned out to be borked hardware ?
> 
> I was not aware of that, I'd be glad to see that patch go into the tree
> to help others who have run into this over the years.
> 
> Hm, have a pointer to the latest proposed patch for this anywhere?

This was discussed in the thread: http://lkml.org/lkml/2005/9/21/118

Alan Cox:
> On Iau, 2005-09-22 at 15:21 +0100, Richard Purdie wrote:
> > 1. Are ide-cs devices removable or not. See above.
>
> Having done testing on the cards I have based on RMK's suggestion I
> agree they are not removable except for specific cases (IDE PCMCIA cable
> adapter plugged into a Syquest). That case is already handled in the
> core code.

Alan: Can you confirm the patch below continues to handle the case
you're talking about?

> The fact cache flushing is all odd now is I guess bug 4. on the list but
> easy to fix while fixing 1

I don't know the ide code well enough to understand what needs fixing
here. Can you elaborate further?

I'll resend this patch as it still applies and we seem to be in general
agreement about what needs doing. There was also the issue of media
change serial number checking but that really needs tackling separately.


This patch stops CompactFlash devices being marked as removable. They
are not removable (as defined by Linux) as the media and device are 
inseparable. When a card is removed, the whole device is removed from 
the system and never sits in a media-less state.

This stops some nasty udev device creation/destruction loops.

Further, once this change is made, there is no need for ide to
differentiate between flash and other devices so the is_flash variable
can be removed from ide_drive_t.

Signed-off-by: Richard Purdie <rpurdie@rpsys.net> 


Index: linux-2.6.13/drivers/ide/ide-probe.c
===================================================================
--- linux-2.6.13.orig/drivers/ide/ide-probe.c	2005-08-29 00:41:01.000000000 +0100
+++ linux-2.6.13/drivers/ide/ide-probe.c	2005-09-21 20:57:34.000000000 +0100
@@ -125,45 +125,6 @@
 }
 
 /**
- *	drive_is_flashcard	-	check for compact flash
- *	@drive: drive to check
- *
- *	CompactFlash cards and their brethern pretend to be removable
- *	hard disks, except:
- * 		(1) they never have a slave unit, and
- *		(2) they don't have doorlock mechanisms.
- *	This test catches them, and is invoked elsewhere when setting
- *	appropriate config bits.
- *
- *	FIXME: This treatment is probably applicable for *all* PCMCIA (PC CARD)
- *	devices, so in linux 2.3.x we should change this to just treat all
- *	PCMCIA  drives this way, and get rid of the model-name tests below
- *	(too big of an interface change for 2.4.x).
- *	At that time, we might also consider parameterizing the timeouts and
- *	retries, since these are MUCH faster than mechanical drives. -M.Lord
- */
- 
-static inline int drive_is_flashcard (ide_drive_t *drive)
-{
-	struct hd_driveid *id = drive->id;
-
-	if (drive->removable) {
-		if (id->config == 0x848a) return 1;	/* CompactFlash */
-		if (!strncmp(id->model, "KODAK ATA_FLASH", 15)	/* Kodak */
-		 || !strncmp(id->model, "Hitachi CV", 10)	/* Hitachi */
-		 || !strncmp(id->model, "SunDisk SDCFB", 13)	/* old SanDisk */
-		 || !strncmp(id->model, "SanDisk SDCFB", 13)	/* SanDisk */
-		 || !strncmp(id->model, "HAGIWARA HPC", 12)	/* Hagiwara */
-		 || !strncmp(id->model, "LEXAR ATA_FLASH", 15)	/* Lexar */
-		 || !strncmp(id->model, "ATA_FLASH", 9))	/* Simple Tech */
-		{
-			return 1;	/* yes, it is a flash memory card */
-		}
-	}
-	return 0;	/* no, it is not a flash memory card */
-}
-
-/**
  *	do_identify	-	identify a drive
  *	@drive: drive to identify 
  *	@cmd: command used
@@ -278,13 +239,17 @@
 	/*
 	 * Not an ATAPI device: looks like a "regular" hard disk
 	 */
-	if (id->config & (1<<7))
-		drive->removable = 1;
 
-	if (drive_is_flashcard(drive))
-		drive->is_flash = 1;
+	/* 
+	 * 0x848a = CompactFlash device 
+	 * These are *not* removable in Linux definition of the term
+	 */
+
+	if ((id->config != 0x848a) && (id->config & (1<<7)))
+		drive->removable = 1;
+	
 	drive->media = ide_disk;
-	printk("%s DISK drive\n", (drive->is_flash) ? "CFA" : "ATA" );
+	printk("%s DISK drive\n", (id->config == 0x848a) ? "CFA" : "ATA" );
 	QUIRK_LIST(drive);
 	return;
 
Index: linux-2.6.13/drivers/ide/ide.c
===================================================================
--- linux-2.6.13.orig/drivers/ide/ide.c	2005-09-19 10:53:59.000000000 +0100
+++ linux-2.6.13/drivers/ide/ide.c	2005-09-21 20:52:53.000000000 +0100
@@ -242,7 +242,6 @@
 		drive->name[2]			= 'a' + (index * MAX_DRIVES) + unit;
 		drive->max_failures		= IDE_DEFAULT_MAX_FAILURES;
 		drive->using_dma		= 0;
-		drive->is_flash			= 0;
 		drive->vdma			= 0;
 		INIT_LIST_HEAD(&drive->list);
 		sema_init(&drive->gendev_rel_sem, 0);
Index: linux-2.6.13/drivers/ide/ide-disk.c
===================================================================
--- linux-2.6.13.orig/drivers/ide/ide-disk.c	2005-09-19 10:53:59.000000000 +0100
+++ linux-2.6.13/drivers/ide/ide-disk.c	2005-09-21 20:51:31.000000000 +0100
@@ -895,11 +895,7 @@
 	if (drive->id_read == 0)
 		return;
 
-	/*
-	 * CompactFlash cards and their brethern look just like hard drives
-	 * to us, but they are removable and don't have a doorlock mechanism.
-	 */
-	if (drive->removable && !(drive->is_flash)) {
+	if (drive->removable) {
 		/*
 		 * Removable disks (eg. SYQUEST); ignore 'WD' drives 
 		 */
Index: linux-2.6.13/include/linux/ide.h
===================================================================
--- linux-2.6.13.orig/include/linux/ide.h	2005-08-29 00:41:01.000000000 +0100
+++ linux-2.6.13/include/linux/ide.h	2005-09-21 20:56:29.000000000 +0100
@@ -697,7 +697,6 @@
 	unsigned noprobe 	: 1;	/* from:  hdx=noprobe */
 	unsigned removable	: 1;	/* 1 if need to do check_media_change */
 	unsigned attach		: 1;	/* needed for removable devices */
-	unsigned is_flash	: 1;	/* 1 if probed as flash */
 	unsigned forced_geom	: 1;	/* 1 if hdx=c,h,s was given at boot */
 	unsigned no_unmask	: 1;	/* disallow setting unmask bit */
 	unsigned no_io_32bit	: 1;	/* disallow enabling 32bit I/O */

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Alan Cox]

On Mer, 2005-11-09 at 10:17 +0000, Richard Purdie wrote:
> > Having done testing on the cards I have based on RMK's suggestion I
> > agree they are not removable except for specific cases (IDE PCMCIA cable
> > adapter plugged into a Syquest). That case is already handled in the
> > core code.
> 
> Alan: Can you confirm the patch below continues to handle the case
> you're talking about?

It does. The Syquest is picked up later on in the driver itself.

Alan

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Bill Davidsen]

Richard Purdie wrote:
> On Fri, 2005-11-04 at 08:37 -0800, Greg KH wrote:
> 
>>On Fri, Nov 04, 2005 at 03:14:53PM +0000, Alan Cox wrote:
>>
>>>On Iau, 2005-11-03 at 23:19 -0800, Greg KH wrote:
>>>
>>>>Hint, gentoo, debian, and suse don't have this problem, so you might
>>>>want to look at their rules files for how to work around this.  Look for
>>>>this line:
>>>>
>>>># skip accessing removable ide devices, cause the ide drivers are horrible broken
>>>
>>>
>>>I was under the impression people had eventually decided the media
>>>change patch someone was proposed was ok after investigating one or two
>>>cases I knew of that turned out to be borked hardware ?
>>
>>I was not aware of that, I'd be glad to see that patch go into the tree
>>to help others who have run into this over the years.
>>
>>Hm, have a pointer to the latest proposed patch for this anywhere?
> 
> 
> This was discussed in the thread: http://lkml.org/lkml/2005/9/21/118
> 
> Alan Cox:
> 
>>On Iau, 2005-09-22 at 15:21 +0100, Richard Purdie wrote:
>>
>>>1. Are ide-cs devices removable or not. See above.
>>
>>Having done testing on the cards I have based on RMK's suggestion I
>>agree they are not removable except for specific cases (IDE PCMCIA cable
>>adapter plugged into a Syquest). That case is already handled in the
>>core code.
> 
> 
> Alan: Can you confirm the patch below continues to handle the case
> you're talking about?
> 
> 
>>The fact cache flushing is all odd now is I guess bug 4. on the list but
>>easy to fix while fixing 1
> 
> 
> I don't know the ide code well enough to understand what needs fixing
> here. Can you elaborate further?
> 
> I'll resend this patch as it still applies and we seem to be in general
> agreement about what needs doing. There was also the issue of media
> change serial number checking but that really needs tackling separately.
> 
> 
> This patch stops CompactFlash devices being marked as removable. They
> are not removable (as defined by Linux) as the media and device are 
> inseparable. When a card is removed, the whole device is removed from 
> the system and never sits in a media-less state.

Having used CF devices for some years (since RH 8.0) I'm not sure what 
problem you're addressing here. Could you describe what problem you're 
having, and also note what current functionality this will change?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Richard Purdie]

On Wed, 2005-11-09 at 11:41 -0500, Bill Davidsen wrote:
> Richard Purdie wrote:
> > This patch stops CompactFlash devices being marked as removable. They
> > are not removable (as defined by Linux) as the media and device are 
> > inseparable. When a card is removed, the whole device is removed from 
> > the system and never sits in a media-less state.
> 
> Having used CF devices for some years (since RH 8.0) I'm not sure what 
> problem you're addressing here. Could you describe what problem you're 
> having, and also note what current functionality this will change?

I'll try the explanation once more assuming you failed to understand the
previous messages in this thread and those linked to in the link I
provided to a thread about this.

Block devices have a "removable" flag. This flag is defined to indicate
devices where the media can change. A property of these devices is that
the device node and device stay around and media may or may not be
present at any one time. Examples of such devices are floppy and ide cd
drives.

When you remove a CF card, the controller is removed with the card and
nothing to do with the CF card or the device exists anymore. They are
therefore not removable devices in the linux definition of the term.

Currently the removable flag is set for CF cards. This is incorrect as a
CF device and interface either exists or doesn't. There is no media-less
state.

This incorrect setting causes loops with udev scripts requiring
userspace hacks to stop things looping. 

The patch therefore correctly sets the removable flag and removes some
unneeded code. 

This shouldn't break anything in userspace apart from anything that
incorrectly interprets the removable flag as being something its not.

Richard

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Bill Davidsen]

Richard Purdie wrote:
> On Wed, 2005-11-09 at 11:41 -0500, Bill Davidsen wrote:
> 
>>Richard Purdie wrote:
>>
>>>This patch stops CompactFlash devices being marked as removable. They
>>>are not removable (as defined by Linux) as the media and device are 
>>>inseparable. When a card is removed, the whole device is removed from 
>>>the system and never sits in a media-less state.
>>
>>Having used CF devices for some years (since RH 8.0) I'm not sure what 
>>problem you're addressing here. Could you describe what problem you're 
>>having, and also note what current functionality this will change?
> 
> 
> I'll try the explanation once more assuming you failed to understand the
> previous messages in this thread and those linked to in the link I
> provided to a thread about this.

Given the large number of possible valid configurations, I'm trying to 
determine which you are trying to fix and if that will break the others.
> 
> Block devices have a "removable" flag. This flag is defined to indicate
> devices where the media can change. A property of these devices is that
> the device node and device stay around and media may or may not be
> present at any one time. Examples of such devices are floppy and ide cd
> drives.
> 
> When you remove a CF card, the controller is removed with the card and
> nothing to do with the CF card or the device exists anymore. They are
> therefore not removable devices in the linux definition of the term.
> 
> Currently the removable flag is set for CF cards. This is incorrect as a
> CF device and interface either exists or doesn't. There is no media-less
> state.
> 
> This incorrect setting causes loops with udev scripts requiring
> userspace hacks to stop things looping. 
> 
> The patch therefore correctly sets the removable flag and removes some
> unneeded code. 
> 
> This shouldn't break anything in userspace apart from anything that
> incorrectly interprets the removable flag as being something its not.
> 
There are, at minimum, three possible hardware attach cases, each of 
which may be on a distribution which uses udev or not. I'm assuming that 
if this is a udev problem is would be fixed at the udev level, but your 
comment on "userspace hacks" does sound like fixes to userspace bugs.

The three attach methods are pcmcia, direct plugin slots (laptops only 
AFAIK), and USB devices.

It seems that the pcmcia cases for laptops and desktops are the same, 
and the whole media and device go away as a unit with the card. But for 
USB and direct plug-in, the "device" seems to be present even without 
media. I can't easily check that for laptop before tonight, but attached 
USB devices show up as sdX currently, with or without media. That's on 
an older kernel, I'll check 2.6.13 tonight.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Richard Purdie]

On Wed, 2005-11-09 at 15:56 -0500, Bill Davidsen wrote: 
> Given the large number of possible valid configurations, I'm trying to 
> determine which you are trying to fix and if that will break the others.

I'm primarily fixing ide-cs but the same fix equally applies to any
CompactFlash interface directly accessed as an ide device. 

> There are, at minimum, three possible hardware attach cases, each of 
> which may be on a distribution which uses udev or not. I'm assuming that 
> if this is a udev problem is would be fixed at the udev level, but your 
> comment on "userspace hacks" does sound like fixes to userspace bugs.

Initially I'd have blamed udev but its actually doing exactly the right
thing in this case and is definitely not at fault. (I've described this
in detail in the past if you want more information.)

> The three attach methods are pcmcia, direct plugin slots (laptops only 
> AFAIK)

These both generally use ide-cs and the patch was written with this in
mind. 

There are a small number of broken adaptors which have been discussed
and the known ones are already worked around. 

> , and USB devices.
> 
> It seems that the pcmcia cases for laptops and desktops are the same, 
> and the whole media and device go away as a unit with the card. But for 
> USB and direct plug-in, the "device" seems to be present even without 
> media. I can't easily check that for laptop before tonight, but attached 
> USB devices show up as sdX currently, with or without media.

USB devices have secondary controllers between the card and the USB bus.
The ide interface is not exposed to the system and they're handled by a
totally different interface and driver (sd = scsidisk). This patch
doesn't change anything to do with that and their behaviour is correct.

Richard

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Damir Perisa]

[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]

Le Wednesday 09 November 2005 21:56, Bill Davidsen a écrit :
 | There are, at minimum, three possible hardware attach cases, each of
 | which may be on a distribution which uses udev or not. I'm assuming
 | that if this is a udev problem is would be fixed at the udev level,
 | but your comment on "userspace hacks" does sound like fixes to
 | userspace bugs.
 
udev+hotplug interaction causing loops is only a bug, because the CF 
(ide-cs) is detected as removable, but it is not. (at least that's how i 
understand it) of course, one can start arguing, that such looping should 
be somehow inhibited by udev or hotplug and i'm not very much used to the 
procedures there that may have possibilities for such an inhibition for 
looping, but it sounds to me like fighting symptoms. curing the patient 
(sorry for this analogy) is in almost all cases better and this means 
here --- as long i understand it --- to have a proper handling of CF in 
the kernel, so that the userspace tools do not get the chance to mess 
with procedures. :P

redhat and a lot of other distributions have udev workaround lines in 
their udev.rules to hinder it looping, but in the end, this are only 
workarounds and not solid solutions. (assigning "no_volume_id" to 
something is not a really nice way)

 | The three attach methods are pcmcia, direct plugin slots (laptops only
 | AFAIK), and USB devices.
 
on the macroscopic scale, you are right. but as far i know (i'm no kernel 
coder), a USB-CF reader is identified as usb-storage device and the 
controler in the CF itself is not used by the kernel but by the reader 
itself. the kernel does not communicate with the CF card but with the 
reader and thinks of it as a removable device (where the CF is the 
medium). firewire-CF readers work in the same way using sbp2 driver 
instead of usb-storage. the kernel thinks, it addresses just another 
usb-storage or sbp2 device. 

i think that's also the reason, why my girlfriend's fw-CF reader is 
echo'ing this lines, if connected to the computer:
	sda: asking for cache data failed
	sda: assuming drive cache: write through
but that's another story...

the pcmcia attach method is different to the usb/fw-reader one. the CF is 
directly accessed by the kernel and its controler directly communicating 
with ide-cs. how this happens in detail, i don't know in detail, but the 
difference is that the controler is directly addressed by the kernel and 
is therefore the device. the media is in fact just the chips in the CF 
inside in this case. (whereas in usb/fw-reader, the "media" is the whole 
CF card) so in this case, you cannot remove the media if the CF is 
plugged into your pcmcia slot. (except if you are very good at hardware 
surgery and have money for new CF's ;)

so as summary:
there are at least four methods (usb reader, fw reader, direct slot, 
pcmcia-cf) -- or 2 basically different ones (indirect (reader=device 
cf=media) and direct (cf=device with media inside))

now i hope that i didn't make a mistake here, because i'm no expert; only 
longterm linux user with experience from 2.0-2.6 kernels. i try to use as 
little workarounds as possible, because cure is always better than 
fighting symptoms. :D

greetings,
Damir

-- 
Youth is when you blame all your troubles on your parents; maturity is
when you learn that everything is the fault of the younger generation.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Bill Davidsen]

Thank you Rickard and Damir for reassuring me that this change is highly 
unlikely to impact any of the connection methods I use. Since PCMCIA on 
desktops and non-udev systems are uncommon, I felt the question was 
better mentioned before the patch went in. Occasionally my confiurations 
do result in a "nobody would do that" reaction.

I hope it solves your problems as well.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Damir Perisa]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

Le Wednesday 09 November 2005 23:55, Bill Davidsen a écrit :
 | Thank you Rickard and Damir for reassuring me that this change is
 | highly unlikely to impact any of the connection methods I use. 

you're welcome

comparing our two emails, you can see that Rickard is much better used to 
this matter than myself, as his email is more condense but has the same 
information as mine. (see also my signature in this email)

 | Since PCMCIA on desktops and non-udev systems are uncommon, I felt the
 | question was better mentioned before the patch went in. Occasionally 
 | my confiurations do result in a "nobody would do that" reaction.
 
well placed questions never hurt (some answers may, but that's another 
story :P )... and often other people find that they also wanted to know 
the answer but didn't dare to ask. 

greetings,
Damir

-- 
If it takes a lot of words to say what you have in mind,
give it more thought.

	-- Dennis Roch

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Mark Lord]

Richard Purdie wrote:
>
> - *	FIXME: This treatment is probably applicable for *all* PCMCIA (PC CARD)
> - *	devices, so in linux 2.3.x we should change this to just treat all
> - *	PCMCIA  drives this way, and get rid of the model-name tests below
> - *	(too big of an interface change for 2.4.x).
> - *	At that time, we might also consider parameterizing the timeouts and
> - *	retries, since these are MUCH faster than mechanical drives. -M.Lord
> - */

I believe the latter half of those comments (timeouts) should
be left in the IDE layer (somewhere), as a note to current/future
maintainers about something that does need fixing eventually.

Something like this:

/*
  * FIXME:  Someday we ought to parameterize IDE timeouts to use
  * much smaller values when dealing with flash memory cards.
  * For example, these devices never require more than a second
  * (much less, actually) for "spin-up", compared with a limit
  * of 31 seconds for mechanical ATA drives.  This would speed up
  * error recovery for these popular devices, especially in embedded work
  */

Cheers
-M.Lord

Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Richard Purdie]

On Thu, 2005-11-10 at 09:57 -0500, Mark Lord wrote: 
> Richard Purdie wrote:
> >
> > - *	FIXME: This treatment is probably applicable for *all* PCMCIA (PC CARD)
> > - *	devices, so in linux 2.3.x we should change this to just treat all
> > - *	PCMCIA  drives this way, and get rid of the model-name tests below
> > - *	(too big of an interface change for 2.4.x).
> > - *	At that time, we might also consider parameterizing the timeouts and
> > - *	retries, since these are MUCH faster than mechanical drives. -M.Lord
> > - */
> 
> I believe the latter half of those comments (timeouts) should
> be left in the IDE layer (somewhere), as a note to current/future
> maintainers about something that does need fixing eventually.
> 
> Something like this:
> 
> /*
>   * FIXME:  Someday we ought to parameterize IDE timeouts to use
>   * much smaller values when dealing with flash memory cards.
>   * For example, these devices never require more than a second
>   * (much less, actually) for "spin-up", compared with a limit
>   * of 31 seconds for mechanical ATA drives.  This would speed up
>   * error recovery for these popular devices, especially in embedded work
>   */

Does this still apply given the existence of devices like microdrives?
My microdrive certainly sounds like it could take a second or two to
spin up...

Richard