Hey!
On Wed, Sep 19, 2007 at 06:30:14PM +0300, Markus Törnqvist wrote:
Thank you for your excellent reply!
Glad you managed to read it all! :)
I've been reading dmesg and tested sda, I should have mentioned that, but that didn't help...
Please send us your dmesg output.
I actually have a mount now!! :)
Good.
I will explain details further below, but here's what I hope is relevant:
pcmcia: request for exclusive IRQ could not be fulfilled. pcmcia: the driver needs updating to supported shared IRQ lines. Probing IDE interface ide2... hde: ELITE PRO CF CARD 1GB, CFA DISK drive usbcore: registered new driver hiddev input: USB Multimedia Keyboard as /class/input/input0 input: USB HID v1.00 Keyboard [ USB Multimedia Keyboard ] on usb-0000:00:10.0-2 ide2 at 0x100-0x107,0x10e on irq 5 hde: max request size: 128KiB hde: 2031120 sectors (1039 MB) w/1KiB Cache, CHS=2015/16/63 hde: hde1 ide-cs: hde: Vpp = 0.0
The entirety is attached.
So the driver is broken wrt irq handling?
Yeah. It doesn't matter if the Ricoh controller has it's own interrupt and/or if you only ever have either CF or PCMCIA but not both. I don't remember if there's a shared IRQ on the MII.
The CF slot is PCMCIA slot #1 in the Ricoh RL5c476 controller, which by the way appears to be quite a crappy piece of hardware. (There are known, unfixed, hard-to-fix bugs with it specifically mentioned on the Linux PCMCIA page.)
http://pcmcia-cs.sf.net/%27s mail archives speak of irq problems at least.
I will definitely look into this further later.
http://www.kernel.org/pub/linux/utils/kernel/pcmcia/powerbugs.html
pcmcia-cs is deprecated. Only useful for old 2.4 kernels.
Then; are you using new PATA or old ATAPI/IDE drivers? Make sure you
I'm on the new one, CONFIG_IDE
No, that's the old one. Try moving over to pata_pcmcia instead, ide-cs is sort-of deprecated too. pata_pcmcia does shared IRQs.
Either way, the particular flash card you are using needs to be recognized by the kernel driver in order for things to work automagically. Run pccardctl info with the card inserted to get the PRODID_* strings you need - then calculate the CRC32 hash that needs to go into the kernel - see /usr/src/linux/Documentation/pcmcia/crc32hash.c and add the hashes to both drivers. Please send a patch to the linux-pcmcia mailing list with them as well.
I'm not sure I understand this part, at least completely, sorry.
This is not handleable by udev, to have the rules there for creating nodes? Or do I need to patch the drivers to have udev play along?
Where is your udev stored? If the answer is "on the CF" think about how it gets loaded. The kernel driver has to like the CF.
Documentation/pcmcia/devicetable.txt isn't really clear either on where I'm supposed to put those crc32 hashes...
They go into the drivers.
--8<-- drivers/ide/legacy/ide-cs.c PCMCIA_DEVICE_PROD_ID12("IBM", "microdrive", 0xb569a6e5, 0xa6d76178), PCMCIA_DEVICE_PROD_ID12("IO DATA", "PCIDE", 0x547e66dc, 0x5c5ab149), -->8-- etc..
- If FILO is to load the kernel from the Ricoh slot #1, the Ricoh
I'm actually thinking about skipping FILO if possible, so I have the kernel and and a small-enough initrd as the payload.
Not possible.
Have to admit I haven't really checked sizes yet, but the via spec said the bios is 2/4Mbit, so 4Mbit should fit pretty much...
Any thoughts on this?
4Mbit == 512kb
- Pluggable device events are handled in a separate kernel
thread,
This may turn out to be a severe problem.
Right.
Anyway, my roadmap is pretty much that next up I'll set up a local debian repository so I can install a kernel.
..
.. And then there will be linuxbios, finally :)
I like LB with Etherboot because it's so simple to throw different payloads at the system. Just change the dhcpd config and reset the board to try different payload.
Then once everything is working, build a new LB and flash the final version.
IBM has an article on this from early 2.4 kernel times. The suggested workaround was to add a few seconds delay to the kernel
Even if it were available I doubt it would patch in very cleanly,
No, certainly not. But it would at least show where exactly in the boot process the delay goes.
so something needs to be figured out.
I should ask linux-kernel about this some day.
It's also possible to configure the Ricoh slot #1 as a static IDE device - ie. not hot-pluggable and using the plain PATA/IDE drivers, not the PCMCIA ones. Then it works fine in FILO, and it almost worked with 2.6.18. A lot has happened in the kernel since so I think
What is "almost worked", please? :)
I don't remember so I tried to get away with being vague. :p
I think I posted all relevant dmesg logs to the list last September but I may have left the last experiments out - not sure.
There were issues when using ide-cs. pata_pcmcia wasn't ready yet. MANY changes especially for ATA/IDE went into 2.6.18 and it took some time to stabilize. I needed to get the board running and went for the IDE->CF adapter as a workaround. Since then my MII board caps blew so the board doesn't run anymore. If I can get hold of replacement caps of high quality it would be nice to get it working again. (Though I bought it really cheap and I also have a -CN board that I'd like to play with instead. :)
I do not want to be dumbing it down with a non-hotplug-aware driver. You may be fine with that.
That's almost the same type of defeat-admission as using a separate cf-ide adapter, which I'd rather pass up on.
These are the cards we are dealt as cutting edge early adopters and developers. We will always get screwed out of something. But we gain other things.
//Peter