PCMCIA mystery

Wary 5.0 testers have been reporting strange behaviour with USB sticks plugged in via a PCMCIA socket adaptor.

Testing on my laptop, yeah, it sure is weird. If I have a USB stick plugged in at power-on, after bootup the USB drive is not accessable. In my test it is /dev/sdc1, and 'probepart' recognizes the existence of /dev/sdc1, however it cannot be read from. Both "disktype /dev/sdc" and "guess_fstype /dev/sdc1" report failure.

However, and this is the mystery, in the initrd, before the switch_root, the USB drive is recognised, and identified as ext2 and able to be read from.

I put in a test near the beginning of rc.services, so just after the switch_root, and the USB drive can no longer be read.

I tested the same thing with an earlier Wary built with the 2.6.34.6 kernel, and no problem, the USB drive is correctly recognised after bootup.

Note, with Wary 5.0 (and 2.6.31.14 kernel), if I replug the USB drive after bootup, then it is recognised.

---

Comments

drive recognition
Username: shinobar
Sometimes /dev/sdc and/or /de/sdc1 may be missing. The LupQ-511 has a code for this issue in /etc/rc.sysinit. Try it if you are interested in. [code]# make all block device files, 3oct09 add drive device echo "Making all block device files" for ONELINE in $(probepart);do PART=$(echo "$ONELINE"|cut -d'|' -f1|cut -d'/' -f3) DRIVE=$(echo $PART|cut -b 1-3) if [ ! -b /dev/$DRIVE ] ;then UEVENT=/sys/block/$DRIVE/uevent echo $UEVENT [ -e $UEVENT ] && echo > $UEVENT sleep 0.2 fi [ -b /dev/$PART ] && continue UEVENT=/sys/block/$DRIVE/$PART/uevent echo $UEVENT [ -e $UEVENT ] && echo > $UEVENT done[/code]

Re missing device node
Username: BarryK
"Ah, that's it! Thanks shinobar. My mind was cloudy on the issue. It is not a kernel problem, it is a specific sequence of drive removal and plugging in. If I unplug my pen drive, the device node gets deleted. If I shutdown, plugin my pen drive, poweron, the device node exists in the initrd (or gets created) however it is missing after the switch-root. That's what Jemimah meant. She sent me a pm -- her solution is to remove all the whiteout files in /initrd/pup_rw/dev so that the device-nodes in the read-only Squashfs will appear on top. Ok, I have implemented a different solution in Woof. At line 1652 in the 'init' script in the initramfs, I have inserted: [i]#110114 if a drive unplugged in previous boot, but plugged in at bootup, device-nodes will be missing in main f.s... cp -a -u -f /dev/* /pup_new/dev/[/i] Shinobar, note that some memory cards are /dev/mmcblk* (ex: drive /dev/mmcblk0 partitition /dev/mmcblk0p1) which your code will not catch. Jemimah's solution also has a limitation, as if any required device-node does not exist in the squashfs layer, deleting the whiteout files won't help. When a memory drive is plugged in, device-nodes are created dynamically if they don't already exist, for example /dev/sdj1, which does not exist in the squashfs layer.

making device-node
Username: shinobar
"> cp -a -u -f /dev/* /pup_new/dev/ I tried the code in the inotrd, but no success or worse. Got 'input/ouput error' when i access to the device-node. Finally i implemented next code in /etc/rc.d/rc.sysinit at wary-500m06. [code]#19jan11 shinobar: make all block device files for ONELINE in $(probepart);do PART=$(echo "$ONELINE"|cut -d'|' -f1|cut -d'/' -f3) DRIVE=$(echo $PART|cut -b 1-3) if [ ! -b /dev/$DRIVE ] ;then UEVENT=/sys/block/$DRIVE/uevent [ -e $UEVENT ] && echo "add" > $UEVENT sleep 0.2 fi [ -b /dev/$PART ] && continue UEVENT=/sys/block/$DRIVE/$PART/uevent [ -e $UEVENT ] && echo "add" > $UEVENT done[/code] i don't know how we should treat /dev/mmcblk* files.

Tags: wary