**** BEGIN LOGGING AT Tue Mar 06 02:59:58 2012 Mar 06 04:35:22 hi Mar 06 04:35:42 klk Mar 06 10:19:24 Ugh, why does the touchpad hang for 2 minutes when I unplug the device while in drivemode? Mar 06 10:19:42 but if I run eject on it, it's instant Mar 06 10:21:35 rrix: it has to run filesystem checks Mar 06 10:21:55 ahh Mar 06 10:21:57 (or it thinks it does) Mar 06 10:21:58 makes sense Mar 06 10:22:01 That's silly Mar 06 10:22:35 it doesn't detect whether i did umount with linux or not - it always runs the check Mar 06 10:22:46 Yah Mar 06 10:23:13 I found that running eject /dev/sd$FOO keeps it from making those checks Mar 06 10:23:26 I'm tempted to figure out where it's making those checks and comment it out if it's editable code Mar 06 10:23:27 cool Mar 06 10:23:32 good to know Mar 06 10:51:54 rrix, stbuehler there is a difference between unmount and eject Mar 06 10:52:13 that is why it checks when you unmount and doesn't when you eject Mar 06 10:52:19 unmount purely unmounts it Mar 06 10:52:35 eject will lock the device for new writes, and sync pending writes Mar 06 10:53:11 when you unmount and unplug, you are doing a "dirty" unplug, the device does that and runs a file system check to try and fix anything that you just buggered up by disconencting it dirty Mar 06 10:53:22 and removes any files that were corrupted by it Mar 06 10:53:51 so... word to the wise... when removing any kind of removable media... eject, not just umount Mar 06 10:54:03 Right Mar 06 10:54:34 udisks isn't smart enough to unmount though, which sucks and means I have to open a terminal and run eject as root Mar 06 10:54:46 and rrix I would highly recommend against disabling those checks... it would be a much better option to remove the disk properly Mar 06 10:55:39 are you using udisks directly? or though a front-end such as nautilus? Mar 06 10:55:49 KDE's device manager Mar 06 10:56:02 that's a KDE problem then Mar 06 10:56:05 also, a sync && unmount would flush the file caches properly Mar 06 10:56:09 udisks definitely knows how to eject Mar 06 10:56:36 a sync && unmount would flush the file caches properly, but it doesn't disconnect the device in such a way that it knows that Mar 06 10:56:40 so it will still perform the checks Mar 06 10:56:45 Right Mar 06 10:57:20 cool, I think I might have derped my tablet's lvm... hmm Mar 06 10:57:21 so... just eject it... and if you can verify that KDE's device manager is not ejecting, but merely unmounting, then report it to KDE as a bug Mar 06 10:57:39 nautilus ejects properly, and AFAIK nautilus uses udisks Mar 06 10:57:49 ya Mar 06 10:58:11 ahh, actually it doesn't Mar 06 10:58:18 only usb-creator-common uses udisks Mar 06 11:03:28 rrix, I just checked, udisks definitely has an eject method... so if KDE's device manager is using udisks and it isn't ejecting removable media, then it should be reported Mar 06 11:03:35 http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html Mar 06 11:04:39 * rrix is digging through source code right now Mar 06 11:05:11 unrelated: What does pkill -SIGUSR1 cryptofs do? Mar 06 11:05:30 no clue Mar 06 11:29:54 if you saw that when you disconencted the drive, my guess is that the USR1 signal for cryptofs is probably the signal that takes it out of "lockdown" mode Mar 06 11:30:01 but that's just a guess, and may be incorrect Mar 06 11:30:20 cryptk: USR1 is from a different context altogether Mar 06 11:30:33 * rrix is playing with https://github.com/crimsonredmk/ArchLinuxARM-TouchPad Mar 06 11:30:53 To boot my own rootfs to play with Mar 06 11:31:34 moboot makes this a lot nicer than the Angstrom stuff of yore Mar 06 11:32:07 well, I can't think of too many things off the top of my head that cryptofs would need a signal for Mar 06 11:32:16 going into lockdown and coming out of lockdown are the main two Mar 06 11:32:40 Yeah Mar 06 11:33:29 hmmm, this kernel doesnt boot and moboot isn't making it a verbose kernel for some reason :\ Mar 06 11:54:03 cryptk: i just didn't knew eject can be used on "disks" too Mar 06 11:54:09 although imho it is wrong to depend on that Mar 06 11:54:26 umount shouldn't write the "unmounted" flag on a disk until the writes are synced Mar 06 11:54:55 and in that case you can just check the flag and know whether it was umounted in a clean way, no need for eject stuff Mar 06 19:44:23 stbuehler: writing the unmounted flag on the filesystem IS one of the writes that needs to be synced to the disk Mar 06 20:29:15 dwc-: and why again couldn't unmount do this? sync, write flag, sync... Mar 06 22:10:06 stbuehler: the same could be argued for all the other write calls... why not make sure that data makes it all the way through the fs cache, the controller cache, the disk cache, etc. Mar 06 22:36:49 dwc-: sry, that argument is just stupid. sure, you can assign all operations any semantics you want, and i'm not arguing further with you. Mar 06 22:51:43 you're right, you can, and unix and linux have long taken the stance that commands should do exactly what you ask it to do. calling unmount unmounts that filesystem, that's it Mar 06 23:00:02 you're more than welcome to patch the kernel on your linux machines to do that, but I don't think it's a wise decision that should be applied globally Mar 06 23:00:24 e.g. I have a small FS and a heavily used big FS on a RAID Mar 06 23:00:41 I don't want the big FS to blocked by writes forced by unmounting the small FS Mar 06 23:04:41 exactly Mar 06 23:05:21 the process that you are describing there stbuehler (sync, unmount, sync) but with the addition of a disconnect is colloquially known as "eject" Mar 06 23:05:33 and rather than turning unmount into eject... why not just use eject? Mar 06 23:55:07 any success getting palm pre plus on t-mobile in usa running 2.1.0? Mar 07 00:12:20 dwc-, cryptk: and why would you use a system wide sync in that case? you really don't want to think, and this really is my last comment. aaaargs. Mar 07 01:17:23 rwhitby: same question as before: any success getting palm pre plus on t-mobile in usa running 2.1.0? Mar 07 01:21:19 * DougReeder waves hello Mar 07 01:21:39 Anyone have a Veer running 2.2? I need a beta tester. Mar 07 01:22:34 acharis: sure, you'll get GSM/EDGE data. Mar 07 01:23:34 Veers running 2.2 can do touch-to-share, right? Mar 07 01:24:07 * rwhitby is not aware of a legal 2.2 release for veers Mar 07 01:24:40 I thought it had been hacked. Mar 07 01:24:58 hacked from illegally redistributed files Mar 07 01:25:06 Ah, bummer. Mar 07 01:26:04 folks Mar 07 01:26:41 rwhitby: that's fine...recommend the meta-att-preplus-2.1.0? meta-o2-preplus-2.1.0? i'm also willing to do debug on test att/wr 2.2.4 Mar 07 01:27:06 I recommend the one which matches the tokens on your device. Mar 07 01:27:40 hmm...thx...i'll return to rtfm Mar 07 01:28:23 use Show Properties or Impostah to determine your DMCARRIER token value, then use the appropriate script Mar 07 01:29:47 thx Mar 07 01:35:28 rwhitby: huh, it says att...guess i'll give it a whirl **** ENDING LOGGING AT Wed Mar 07 02:59:58 2012