I know this is 1.5 years later, but I seem to be running into the same issue and am having a hard time finding anything as to how to solve this: https://groups.google.com/d/msg/beagleboard/IeLSZ19NbMU/xeND-QH0AAAJ
Interestingly, hot plug for the uSD card works for me on a 3.8.13 kernel under Debian Wheezy (3.8.13-bone79 to be precise), so this must have been fixed in the meantime. However, it fails to work on a 4.1.15 kernel under Ubuntu 14.04.3 (4.1.15-ti-r40 to be precise). Would this be because it wasn't compiled into the kernel? On Monday, July 29, 2013 at 2:32:12 AM UTC-4, William Hermans wrote: > > By the by Patrick, this happened to me while booted off a USB hard drive. > However, the USB boot process in my case does require MLO, u-boot.img, and > uEnv.txt to be on the SD card. Of course this also means the SD card is > inserted at boot time as well. > > > On Sun, Jul 28, 2013 at 11:30 PM, William Hermans <yyr...@gmail.com > <javascript:>> wrote: > >> All things being equal, if the hotplug issues were not causing problems. >> Removing then re-inserting the drive in of its self should not cause any >> problems. >> >> At least I have demonstrated this to myself several times by restarting >> an NFS server ( which my beaglebone black has booted from in the past ). >> While the Beaglebone black kept running. Of course I did not issue any >> commands until the server was back up, and live again. >> >> Anyhow, perhaps I will attempt to dig into this deeper myself at some >> later point. But I am not sure if I would be able to find the exact problem. >> >> >> On Sun, Jul 28, 2013 at 10:01 PM, evilwulfie <evilw...@gmail.com >> <javascript:>> wrote: >> >>> no kidding >>> i use a SD card to boot from >>> >>> >>> On 7/28/2013 9:52 PM, Patrick wrote: >>> >>> Wulf Man, >>> What is this "boot device" to which you refer? >>> >>> If you're talking about the rootfs, then yes it would be bad to remove >>> that, but my rootfs is on the eMMC. >>> >>> If you think that having an SD card in at boot makes it automatically >>> the rootfs, then you're wrong. The default uboot config looks for an SD >>> card and if it finds one looks for a uEnv.txt file on it; after that, uboot >>> is done with the SD card, unless that uEnv.txt tells it to boot from SD. >>> >>> Patrick >>> >>> On Sunday, July 28, 2013 2:22:32 PM UTC-4, Wulf Man wrote: >>>> >>>> I cannot see how removing the SD card that is the boot device can be a >>>> good thing for a linux kernel >>>> If it was just SD card storage and you issue the unmount command sure >>>> or if the kernel has some kind of hot swap mechanism to allow that >>>> >>>> >>>> am i wrong that removing the boot device is a bad thing ? >>>> >>>> >>>> >>>> >>>> On 7/28/2013 11:03 AM, William Hermans wrote: >>>> >>>> Just repeated what I did earlier( twice ), that is removed sd card >>>> reinserted issued some disk utility commands, and nothing. BBB is still up >>>> and running. However, running blkid, and other disk utilities when the SD >>>> card is out did not change the output. Read: it seems the system still >>>> thinks it is plugged in, when it is in fact removed. >>>> >>>> >>>> On Sun, Jul 28, 2013 at 10:41 AM, William Hermans <yyr...@gmail.com> >>>> wrote: >>>> >>>>> I should have said earlier that /var/log/messages does not seem to >>>>> have any related messages either. Although I have not grepped yet for >>>>> exactness >>>>> >>>>> >>>>> On Sun, Jul 28, 2013 at 10:37 AM, William Hermans <yyr...@gmail.com> >>>>> wrote: >>>>> >>>>>> I stand corrected. It looks like now, I also have the same issue now. >>>>>> I do not exactly get a panic message. In fact I get no message at all. >>>>>> However the beaglebone black that has been runing fine for days straight >>>>>> suddenly started acting funny after i removed the SD card, and >>>>>> reinserted >>>>>> it. >>>>>> >>>>>> df -h would not function at all, but uname -a did. blkid would not >>>>>> work either, I guess I'll have to hook up my serial debug device again. >>>>>> ALthough I am not sure if that will help. THe problem seems to be silent >>>>>> for me. Perhaps using the $optargs debug parameter in uEnv.txt will help >>>>>> ? >>>>>> >>>>>> This is new however. This has not happened for me in the past, so it >>>>>> may be one of the latest kernel version I've built ? >>>>>> >>>>>> root@arm:~# uname -a >>>>>> Linux arm 3.8.13-bone21 #1 SMP Sat Jun 15 19:36:33 MST 2013 armv7l >>>>>> GNU/Linux >>>>>> >>>>>> This is debian wheezy by the way, and I boot from a USB hard drive. >>>>>> Using ethernet for LAN connection, and powered via USB 3.0. The USB hard >>>>>> drive is an external case + seagate baracuda ATA that is self powered. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jul 28, 2013 at 2:49 AM, Patrick <adapt...@gmail.com> wrote: >>>>>> >>>>>>> William, >>>>>>> The only hotplug problems I've had with USB have been due to it >>>>>>> taking too much current, or plugging in a hub that feeds power back to >>>>>>> the >>>>>>> host. Once I switched to a powered hub that does not feed anything >>>>>>> back, >>>>>>> everything was fine; the same issue affects the pi, and the same hub >>>>>>> solves >>>>>>> that problem on the pi. Now I can plug/unplug USB devices, including >>>>>>> storage, optical mice etc, without any problem. >>>>>>> >>>>>>> This is a completely separate issue. >>>>>>> >>>>>>> Are you saying that if you have a microSD card attached at boot, and >>>>>>> you remove it post-boot, you don't get a kernel panic 1 minute later? >>>>>>> What >>>>>>> happens for you when you run a blkid or partprobe? Does it still think >>>>>>> the >>>>>>> card is in there? >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> >>>>>>> On Sunday, July 28, 2013 3:11:16 AM UTC-4, William Hermans wrote: >>>>>>>> >>>>>>>> Well hotplug is a known issue, and afaik is a kernel related >>>>>>>> problem. This effects the SD slot, and USB. Never heard of or >>>>>>>> experienced a >>>>>>>> kernel panic though. Not saying I do not believe you, just saying that >>>>>>>> I >>>>>>>> have hot-plugged both USB and the SD card slot and have not personally >>>>>>>> experienced this. What happens for me, the device in question, may >>>>>>>> work for >>>>>>>> one more hot-plug, but will fail any further attempts. >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Jul 27, 2013 at 9:22 PM, Patrick <adapt...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Furthermore, your statement about mmcblk0 is incorrect. If the >>>>>>>>> microSD card is present, I don't have to boot from it. I can >>>>>>>>> interrupt >>>>>>>>> uboot, run a simple sequence of commands, and boot from eMMC without >>>>>>>>> ever >>>>>>>>> touching the microSD card, and the microSD card still shows up as >>>>>>>>> mmcblk0. >>>>>>>>> And I really don't care whether the microSD displaces eMMC and >>>>>>>>> causes device renaming (that is a lame problem, but solvable by UUIDs >>>>>>>>> and/or udev rules). But if I can't insert/remove microSD cards after >>>>>>>>> boot >>>>>>>>> time, I may as well give up on microSD altogether. >>>>>>>>> >>>>>>>>> >>>>>>>>> Patrick >>>>>>>>> >>>>>>>>> On Saturday, July 27, 2013 11:13:54 PM UTC-4, William Hermans >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> First, the media which is booted from shows up as mmcblk0 always >>>>>>>>>>> on the BBB. So it does not matter if it is an SD card or eMMC. Well >>>>>>>>>>> this >>>>>>>>>>> only applies to SD vs eMMC. If you boot from a network, or USB it >>>>>>>>>>> might be >>>>>>>>>>> different. >>>>>>>>>>> >>>>>>>>>>> As for the boot order, or what the BBB boots from this can be >>>>>>>>>>> and often is determined by uEnv.txt.. Although pressing and holding >>>>>>>>>>> the >>>>>>>>>>> boot button when booting cant change this. In order to boot from >>>>>>>>>>> eMMC while >>>>>>>>>>> an SD card is inserted, you need to have a properly configured >>>>>>>>>>> uEnv.txt >>>>>>>>>>> file variables. something such as this: >>>>>>>>>>> >>>>>>>>>>> mmcdev=1 >>>>>>>>>>> bootpart=1:2 >>>>>>>>>>> mmcroot=/dev/mmcblk1p2 ro >>>>>>>>>>> >>>>>>>>>>> In your uEnv.txt file should allow you to boot from the eMMC with >>>>>>>>>>> an SD card inserted into the SD card slot. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> -- >>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "BeagleBoard" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to beagleboard...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to beagleboard...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
