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.

Attachments:

(No filename) (3.26 kB)
(No filename) (189.00 B)
Download all attachments

2005-11-04 23:29:34

by Greg KH

[permalink] [raw]

Subject: Re: ide-cs broken / udev magic

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

2005-11-05 02:07:22

by Richard Purdie

[permalink] [raw]

Subject: Re: ide-cs broken / udev magic

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

2005-11-05 12:36:55

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.

Attachments:

(No filename) (3.29 kB)
(No filename) (189.00 B)
Download all attachments

2005-11-09 22:53:34

by Bill Davidsen

[permalink] [raw]

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

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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2005-11-09 23:05:26

On Tue, Feb 14, 2006 at 05:43:09PM +0000, Christoph Hellwig wrote:
> On Tue, Feb 14, 2006 at 01:14:09AM +0100, Adrian Bunk wrote:
> > As usual, there isn't much feedback regarding problems with one driver
> > from people using an obsolete driver for the same hardware.
> >
> > So schedule the SCSI qlogicfc driver for removal and let the
> > flames^Wfeedback begin...
>
> The driver has been deprecatedd since long before the official deprecation
> mechanisms existed. It'll go away for 2.6.17.

Is this patch pending somewhere or should I send a patch?

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed