**** BEGIN LOGGING AT Sat Feb 06 02:59:56 2010
Feb 06 03:31:14 <slaxxer> if opkg is so bad   why on earth   was it chosen????,,, because     somebody wanted to derail us???????
Feb 06 03:31:46 <ndnihil> because apt is too resource intensive for the GTA hardware
Feb 06 03:31:50 <ndnihil> is my guess
Feb 06 03:32:16 <slaxxer> ftp://ftp.armedslack.org/armedslack/armedslack-devtools/minirootfs/roots/
Feb 06 04:02:09 <slaxxer> ftp://ftp.armedslack.org/armedslack/armedslack-devtools/minirootfs/
Feb 06 04:34:16 <slaxxer> http://www.slackware.com/changelog/current.php?cpu=arm
Feb 06 04:35:10 <slaxxer> for those intrested
Feb 06 05:05:41 <slaxxer> cant set time on shr-u
Feb 06 11:18:53 <Rakhun> can someone tell me how to set or (preferably) disable the pin for bluetooth? :)
Feb 06 11:24:21 <PaulFertser> Rakhun: yes
Feb 06 11:24:37 <PaulFertser> Rakhun: there're two bluetooth agents in the test directory of bluez sources.
Feb 06 11:25:04 <PaulFertser> Rakhun: one is python, one is in C. Python agent is easily modifiable, the C one probably has an option to specify a constant pin, look it up.
Feb 06 11:25:34 <Rakhun> hm :/ ok
Feb 06 11:25:38 <Rakhun> thanks
Feb 06 11:26:27 <PaulFertser> Rakhun: what's wrong?
Feb 06 11:27:36 <jaacoppi> trying to emulate openmoko on qemu it gives "qemu: could not open disk image openmoko-flash.image: No such file or directory" - the files does exists, is 256K and reports as "Qemu Image, Format: Qcow , Version: 2" - any ideas what's wrong?
Feb 06 11:28:36 <jaacoppi> s/files does exists/file does exist/
Feb 06 11:28:37 <apt> jaacoppi meant: trying to emulate openmoko on qemu it gives "qemu: could not open disk image openmoko-flash.image: No such file or directory" - the file does exist, is 256K and reports as "Qemu Image, Format: Qcow , Version: 2" - any ideas what's wrong?
Feb 06 11:28:53 <Rakhun> PaulFertser: it just seems so cumbersome, I had hoped for something more like hciconfig hci0 pin off
Feb 06 11:31:27 <PaulFertser> jaacoppi: usually nobody tries to emulate openmoko nowadays since it's useless.
Feb 06 11:34:26 <jaacoppi> okay. I'm asking because I'd like to try some assembly hacking, my own primitive OS or something like that
Feb 06 12:09:55 <DocScrutinizer> you can't disable pin for NT, aiui
Feb 06 12:10:03 <DocScrutinizer> BT
Feb 06 12:10:51 <DocScrutinizer> just set default '0000'
Feb 06 12:12:49 <DocScrutinizer> at leasr winmoob has 0000 hardcoded, plus option for a user defined 2nd default
Feb 06 12:12:56 <DocScrutinizer> iirc
Feb 06 13:01:35 <ndnihil> any of you know anything about touchscreens under xorg?
Feb 06 13:03:36 <PaulFertser> ndnihil: they should work, autodetected with hal (on bleeding-edge systems hal got replaced by various other code). 
Feb 06 13:04:01 <ndnihil> the other couple I've tried worked out of the box just fine
Feb 06 13:04:08 <ndnihil> but this one is being a huge pain in the ass
Feb 06 13:04:15 <ndnihil> panasonic CF-U1
Feb 06 13:05:05 <Heinervdm> you need a kernel module that supports that TS
Feb 06 13:05:09 <PaulFertser> Oh, so probably it's not about xorg, rather about the kernel driver?
Feb 06 13:05:31 <ndnihil> I get data from the device if I cat /dev/usb/whateveritscalled
Feb 06 13:05:49 <ndnihil> but it's not playing nice with xorg
Feb 06 13:05:54 <Heinervdm> but is the the right format?
Feb 06 13:06:00 <ndnihil> Heinervdm: good question
Feb 06 13:06:44 <ndnihil> one of the things I found interesting was:
Feb 06 13:06:48 <Heinervdm> Gnutoo has rewritten the ts module for the htc-dream, so perhaps he knows sth about the format
Feb 06 13:06:49 <ndnihil> Bus 002 Device 002: ID 0430:0530 Sun Microsystems, Inc.
Feb 06 13:07:01 <PaulFertser> ndnihil: you want to have a kernel level input event device.
Feb 06 13:07:38 <ndnihil> I aliased in udev, but it looks like the same thing the hid device was dumping
Feb 06 13:08:06 <ndnihil> nothing in /dev/input/ is attached to it
Feb 06 13:09:02 <ndnihil> google has returned absolutely nothing
Feb 06 13:09:30 <ndnihil> just people bitching about the graphics chipset and emperorlinux selling the device with linux preinstalled
Feb 06 13:10:12 <ndnihil> they (emperor) of course havent posted anything in regards to the matter
Feb 06 13:16:42 <PaulFertser> ndnihil: is that some custom distro you're using?
Feb 06 13:18:43 <ndnihil> nope, debian stable
Feb 06 13:19:06 <ndnihil> it loaded just fine, no issues
Feb 06 13:19:53 <PaulFertser> ndnihil: let me look up the info in a more recent kernel...
Feb 06 13:20:03 <ndnihil> thanks I appreciate it
Feb 06 13:20:27 <ndnihil> 2.6.26 currently
Feb 06 13:27:26 <DocScrutinizer51> regarding Kroha has announced LTS for .32 and recommended users of older kernels to switch - .26 sounds a bit scary
Feb 06 13:29:38 <PaulFertser> ndnihil: looks like there's no driver that lists your vid:pid :( i suspect the TS is in fact of some other vendor and all you need is to understand what that is.
Feb 06 13:30:30 <ndnihil> figures
Feb 06 13:30:33 <ndnihil> oh well, it was free
Feb 06 13:30:43 <PaulFertser> ndnihil: i guess if you get any driver to work with it (including windows) and get some usb sniffing software, it'd not be that hard.
Feb 06 13:31:08 <ndnihil> I got it to respons using the generic 'mouse' driver and went through each and every protocol available
Feb 06 13:31:14 <ndnihil> but it was spastic
Feb 06 13:31:22 <ndnihil> s/respons/respond/
Feb 06 13:31:41 <ndnihil> when in doubt, brute force it eh?
Feb 06 13:31:42 <ndnihil> :)
Feb 06 13:31:49 <PaulFertser> ndnihil: it's not mouse, it's a touchscreen. The kernel has a dedicated driver for usb touchscreens.
Feb 06 13:32:17 <PaulFertser> ndnihil: with 15 different tyes
Feb 06 13:32:18 <ndnihil> it doesnt respond at all with evtouch or hidtouch
Feb 06 13:38:58 <DocScrutinizer> ~status
Feb 06 13:38:59 <apt> Since Tue Feb  2 02:10:03 2010, there have been 46 modifications, 240 questions, 0 dunnos, 0 morons and 115 commands.  I have been awake for 4d 11h 28m 55s this session, and currently reference 116809 factoids.  I'm using about 21480 kB of memory. With 0 active forks. Process time user/system 9676.94/310.4 child 0.37/0.12
Feb 06 13:39:59 <ndnihil> ~snack
Feb 06 13:40:00 * apt belches loudly. Oup, 'begpardon.
Feb 06 13:40:10 <ndnihil> silly bots
Feb 06 13:41:43 <DocScrutinizer> [maemo] [2010-02-06 14:24:36] *** ChanServ setzt Modus: +v infobot
Feb 06 13:41:52 * DocScrutinizer ??? o.O
Feb 06 13:42:15 <ndnihil> maybe a faq type script for the bot
Feb 06 13:43:14 <ndnihil> not the same one I tried
Feb 06 13:43:40 <DocScrutinizer> you think wondering why chanserv sets +v to infobot some 10min ago is a sort of FAQ?
Feb 06 13:43:56 <ndnihil> oh, thought you were questioning the bot itself
Feb 06 13:44:05 <ndnihil> chanserv can be set to autovoice particular users
Feb 06 13:44:10 <ndnihil> and autoop
Feb 06 13:44:21 <ndnihil> I use that feature on the server I oper on
Feb 06 13:44:54 <DocScrutinizer> nice. but that obviously means infobot joined maemo some 12min ago
Feb 06 13:45:05 <ndnihil> *shrug*
Feb 06 13:45:18 <ndnihil> perhaps someone manually told chanserv to voice it
Feb 06 13:45:44 <DocScrutinizer> as I have suppressed join/quit msgs here, I was wondering if the infobot server had a reboot
Feb 06 13:45:52 <ndnihil> ah
Feb 06 13:48:05 <DocScrutinizer> could've been netsplit
Feb 06 13:48:57 <ndnihil> didn't see one here
Feb 06 13:50:41 <DocScrutinizer> nevermind
Feb 06 13:50:54 <DocScrutinizer> ~botsnack
Feb 06 13:50:55 <apt> aw, gee, DocScrutinizer
Feb 06 13:51:49 <mmp> Hello; I have a problem with audio mixer settings -- is it normal that (just flashed latest SHR) when I mute right channel, I can hear audio from both earplugs (although quiet), when I enable right channel audio from right is much louder?
Feb 06 13:52:14 <mmp> basically, looks like left signal goes to both right and left earplug and right only to right 
Feb 06 13:52:24 <mmp> headphones should be OK, I just unpacked new set
Feb 06 13:53:07 <DocScrutinizer> sounds like wiring mismatch
Feb 06 13:53:19 <mmp> DocScrutinizer: yes, but on the same hardware it used to work
Feb 06 13:53:35 <mmp> (and earplugs are openmoko original, so I doubt this could be the problem)
Feb 06 13:53:56 <DocScrutinizer> same hw? didn't you unpack just a minute ago?
Feb 06 13:54:03 <DocScrutinizer> ooh
Feb 06 13:54:04 <mmp> earplugs yes
Feb 06 13:54:10 <mmp> but freerunner is the same
Feb 06 13:54:33 <DocScrutinizer> FR wiring is considered ok ;-P
Feb 06 13:54:49 <mmp> well... I used to have different earplugs, but those seems to not work anymore (I suspect they had shorted lines)
Feb 06 13:54:59 <mmp> so I'm a bit afraid of hardware damage
Feb 06 13:55:05 <DocScrutinizer> make sure you settled the jack tightly
Feb 06 13:55:50 <mmp> well, I did... seems to be OK
Feb 06 13:56:12 <PaulFertser> mmp: please tell exactly how do you connect your headphones to the FR
Feb 06 13:56:49 <mmp> PaulFertser: original FR headphones, not sure what you mean, I just plug them and leave all the framework running inside to load proper mixer settings
Feb 06 13:57:43 <PaulFertser> mmp: ah, ok. Be sure after you plugged in the headset the amp switch (in alsamixer) is toggled.
Feb 06 13:58:45 <mmp> well... which one?
Feb 06 13:58:47 <DocScrutinizer> or simply run alsactl restore -f stereoheadset
Feb 06 13:58:54 <mmp> speaker amp is disabled
Feb 06 13:59:10 <mmp> DocScrutinizer: there is either headset.state or stereoout.state
Feb 06 13:59:23 <DocScrutinizer> headset
Feb 06 13:59:53 <DocScrutinizer> I'd guess
Feb 06 13:59:56 <mmp> well.. that's the same state (both theoretically and empirically;-) as the state loaded when headset is plugged
Feb 06 14:00:11 <DocScrutinizer> exactly
Feb 06 14:00:29 <DocScrutinizer> that's why I say force loead it 
Feb 06 14:00:48 <mmp> DocScrutinizer: already did, but it did not help
Feb 06 14:01:41 <DocScrutinizer> no idea
Feb 06 14:01:48 <mmp> well... either is something pushing mono signal to both earplugs, or I really don't have idea either
Feb 06 14:02:22 <mmp> but I'm afraid it would be good to check the hardware
Feb 06 14:02:49 <mmp> maybe the older, shorted earplugs did some damage
Feb 06 14:02:54 <DocScrutinizer> mmp: believe me, the FR hw is quite scrutinized and all flaws wellknown
Feb 06 14:03:06 <DocScrutinizer> for audio at least
Feb 06 14:03:14 <mmp> DocScrutinizer: I'm saying my local damage :-(
Feb 06 14:03:19 <mmp> unfortunately
Feb 06 14:03:29 <mmp> I don't blame FR's hardware design
Feb 06 14:03:39 <mmp> but more my broken earplugs 
Feb 06 14:04:37 <DocScrutinizer> there were no older shorted headsets afaik. And thre's no way to do any damage done by any hypothetical short that I ever got to know of or could imagine
Feb 06 14:05:33 <mmp> DocScrutinizer: well.. that short might be caused by myself; just by using :)
Feb 06 14:05:43 <mmp> ok, but now I have one more idea of what could happen
Feb 06 14:06:35 <mmp> I had an audio rework done on my FR, so maybe something's broken there
Feb 06 14:06:58 <DocScrutinizer> that's quite possible
Feb 06 14:07:36 <mmp> like some capacitor with broken soldering
Feb 06 14:07:55 <mmp> looks like I know whom to contact :)
Feb 06 14:07:57 <mmp> DocScrutinizer, PaulFertser: thank you a lot :-)
Feb 06 14:08:12 <DocScrutinizer> yw
Feb 06 14:10:46 <PaulFertser> mmp: audio rework?
Feb 06 14:11:04 <PaulFertser> mmp: framework doesn't load an alternative state, it should be stereout with Amp switch toggled.
Feb 06 14:12:48 <DocScrutinizer> PaulFertser: ack
Feb 06 14:13:02 <DocScrutinizer> amp_mode, no?
Feb 06 14:13:35 * DocScrutinizer frowns and considers a second coffee
Feb 06 14:17:32 <DocScrutinizer> numid=94,name='Amp Spk Switch' 
Feb 06 14:17:59 <DocScrutinizer> Amp Mode probably is mere powerswitch
Feb 06 14:19:13 <PaulFertser> It's written in the rules file of oeventsd anyway
Feb 06 14:22:04 <mmp> PaulFertser: amp spk is disabled, afaik...
Feb 06 14:22:19 <PaulFertser> mmp: frameword toggles it whenever you plug in the headset.
Feb 06 14:24:12 <mmp> PaulFertser: yes, but it should disable it when headset is plugged, right?
Feb 06 14:27:07 <mmp> PaulFertser: btw, audio rework was changing the capacitors to not attenuate basses that much...
Feb 06 14:28:02 <DocScrutinizer> PaulFertser: which  btw is a quite botchy method to do this
Feb 06 14:29:52 * DocScrutinizer wonders where the crosstalk to *both* channels comes from, when one audiorail is proken, and the other one muted
Feb 06 14:30:05 <DocScrutinizer> broken, omg
Feb 06 14:31:01 <Rakhun> I got bluetooth file transfer working with pairing in emtooth :)
Feb 06 14:31:13 <PaulFertser> mmp: it's interesting, how exactly have you performed a rework?
Feb 06 14:31:31 <DocScrutinizer> PaulFertser: headset deserves a private dedicated statefile, in a sense of "that's my headset volume, that's my eq settings..."
Feb 06 14:31:37 <mmp> PaulFertser: my friend did, I'm not in EE field at all :-)
Feb 06 14:31:42 <PaulFertser> DocScrutinizer: of course
Feb 06 14:31:50 <PaulFertser> mmp: i wonder if he used "my" method or not :)
Feb 06 14:32:04 <mmp> PaulFertser: hmm... let me see :-)
Feb 06 14:33:24 * DocScrutinizer wonders and wonders where the crosstalk to *both* channels comes from, when one audiorail is broken, and the other one muted
Feb 06 14:34:12 <mmp> DocScrutinizer: me too, but basically I have no idea what happens inside; maybe just something has shorted, due to thermal changes :-)
Feb 06 14:36:09 <DocScrutinizer> see - if one chan has a loose contact, how on earth cna the signal skip to not only this chan output, but also to the other "good" chan - while signal of good chan can *not* jump to the broken one
Feb 06 14:38:04 <mmp> well... as I said, no idea; but having spent time debugging another project which in the end had a hardware problem, I believe anything can happen
Feb 06 14:38:20 <DocScrutinizer> well maybe I'm thinking too much in terms of ideal components. Muting simply might not be ideal
Feb 06 14:39:38 <DocScrutinizer> and the beoken chan shorted to ground - maybe can metal or sth
Feb 06 14:40:23 <DocScrutinizer> mmp: do you have access to a decent DVM?
Feb 06 14:40:31 <mmp> possibly :-) I'm into debugging software, not hardware; but having audio signal on the GND sounds like a possible reason
Feb 06 14:40:34 <DocScrutinizer> or any DVM?
Feb 06 14:40:41 <mmp> depends on what you mean by DVM
Feb 06 14:40:46 <mmp> digital volt meter? :)
Feb 06 14:40:54 <DocScrutinizer> digital voltmeter
Feb 06 14:41:02 <mmp> I think I have one
Feb 06 14:41:24 <mmp> ... in my hand now
Feb 06 14:41:34 <DocScrutinizer> could you test the resistence of broken audio out pin to GND please?
Feb 06 14:41:45 <mmp> hmm.. let me see
Feb 06 14:41:51 <DocScrutinizer> + on audio pin, - on GND
Feb 06 14:41:52 <mmp> (never disassembler FR before
Feb 06 14:41:55 <mmp> )
Feb 06 14:42:21 <DocScrutinizer> you just need a 2.5mm plug with wires cut off
Feb 06 14:42:58 <mmp> <joke>well, plenty of them im my under my bed :-P</joke>
Feb 06 14:43:13 <DocScrutinizer> hehe
Feb 06 14:43:17 <DocScrutinizer> I see
Feb 06 14:43:28 <mmp> but maybe one person could have some...
Feb 06 14:44:18 <DocScrutinizer> if you have a 2.5->3.5mm adapter you possibly can open one side to touch the solderpoints
Feb 06 14:44:39 <mmp> well, neither that one
Feb 06 14:44:49 <mmp> not mentioning, I'm screwed, literally
Feb 06 14:45:01 <mmp> my torx screwdriver is 200km away from me :-)
Feb 06 14:45:07 <DocScrutinizer> lol
Feb 06 14:45:11 <DocScrutinizer> nevermind then
Feb 06 14:46:08 <DocScrutinizer> just a dead simple test: slowly retract the plug, and listen if audio jumps from one chan to the other
Feb 06 14:47:30 <mmp> let me boot it again
Feb 06 14:52:53 <mmp> (DocScrunitizer: you are talking to a man studying teoretical computer science; an old joke tells that we are denied to use any EE equipment, because of the immitent danger of death these purely practical tools can have in our hands:-)
Feb 06 14:54:17 * DocScrutinizer hides scared
Feb 06 14:58:21 <mmp> ok, slowly plugging out the earplugs (from FR, of course): (left quiet, right loud) -> (distorted sound, right earplug significantly louder) -> (really quiet signal in left earplug) -> (left quiet, right loud) -> (speaker starts playing)
Feb 06 15:02:14 <DocScrutinizer> hmmm
Feb 06 15:02:16 <mmp> DocScrutinizer: have you ever seen CS student with a soldering iron in his (or even her hands?) :-)
Feb 06 15:02:29 <mmp> </joke>
Feb 06 15:02:50 <DocScrutinizer> I think I managed to never see any CS student ;-P
Feb 06 15:03:47 * DocScrutinizer runs for an emergency first aid coffee
Feb 06 15:17:44 <DocScrutinizer> mmp: you speaker/sounder output hasn't changed in quality or volume coincidentally with the breakage of left headphone channel?
Feb 06 15:18:12 <mmp> not, sure, I haven't used the speaker at all
Feb 06 15:19:18 <mmp> sounds... normally
Feb 06 15:19:58 <DocScrutinizer> hmm, I recommend you visit your friend who did the audio mod
Feb 06 15:21:29 <DocScrutinizer> tell him it seems to me like there's a short effectively making R4117 a 0R
Feb 06 15:22:33 <DocScrutinizer> possibly one of the wires used for connecting the big audio Cs has a contact to GND
Feb 06 15:53:46 <mmp> DocScrutinizer: ok, will do :-) thank you
Feb 06 16:54:43 <ndnihil> ooh, touchscreen vs. tablet mode in bios
Feb 06 16:54:51 * ndnihil hops
Feb 06 16:54:53 <ndnihil> hopes
Feb 06 16:55:56 <ndnihil> WOOT~
Feb 06 16:55:57 <ndnihil> !
Feb 06 16:56:32 <ndnihil> it needs calibration, but it's not epileptic now
Feb 06 17:12:47 <PaulFertser> ndnihil: what was the right setting? Were vid/pid changed?
Feb 06 17:15:43 <ndnihil> 0430:0501 now
Feb 06 17:15:52 <ndnihil> fujitsu chipset
Feb 06 17:16:50 <ndnihil> still labeled Sun, but it's Fujitsu
Feb 06 18:04:40 <PBeck> hi
Feb 06 18:29:15 <cosmos> hello
Feb 06 18:29:40 <cosmos> I cannot boot anymore from the nor
Feb 06 18:29:54 <cosmos> No more boot menus
Feb 06 18:29:57 <cosmos> only:
Feb 06 18:30:00 <cosmos> INFO: RCU detected CPU 0 stall
Feb 06 18:30:06 <cosmos> bla bla
Feb 06 18:30:35 <cosmos> I have no micro sd card
Feb 06 18:31:11 <cosmos> Is there any tricks with the debug board to repair my FR?
Feb 06 18:33:14 <cosmos> wait a minute....
Feb 06 18:33:30 <cosmos> I have my boot menus now
Feb 06 18:48:05 <DocScrutinizer51> o.O
Feb 06 19:30:13 <Weiss> cosmos: sounds like you just needed to switch it off for a little while to think about how naughty it's been
Feb 06 19:32:14 <MHazem> lol
Feb 06 19:35:13 <Weiss> (this is an established debugging technique in IT)
Feb 06 20:56:09 <cosmos> ok how to erase a kernel on FR, just flshing it?
Feb 06 20:56:19 <cosmos> *flashing
Feb 06 20:57:49 <PaulFertser> cosmos: yes
Feb 06 20:58:12 <cosmos> ok
Feb 06 21:00:12 <cosmos> same for the rootfs isn't it?
Feb 06 21:01:07 <PaulFertser> cosmos: sure. If you flash using u-boot.
Feb 06 21:01:21 <PaulFertser> cosmos: if you use nandwrite, you _must_ flasherase_all first!
Feb 06 21:04:08 <cosmos> using u-boot I have a "End of write exeeds partition end"
Feb 06 21:04:36 <cosmos> error -60 during downloading
Feb 06 21:05:30 <cosmos> so should I start installing the uImage and then the rootfs?
Feb 06 21:05:51 <cosmos> I do not know how to use nandwrite
Feb 06 21:06:53 <PaulFertser> cosmos: probably you use wrong nand partition with dfu-util
Feb 06 21:07:10 <PaulFertser> cosmos: the order of flashing doesn't matter
Feb 06 21:07:32 <cosmos> maybe...how to resolve that?
Feb 06 21:09:48 <cosmos> I'm just trying to install Qtmoko v19 avfer a try on SHR
Feb 06 21:09:58 <cosmos> *after
Feb 06 21:10:43 <PaulFertser> cosmos: use correct partition?
Feb 06 21:11:06 <cosmos> no idea
Feb 06 21:11:21 <PaulFertser> cosmos: it is a suggestion, not a question.
Feb 06 21:12:46 <radekp> cosmos: hi, use something like this:
Feb 06 21:12:50 <radekp> dfu-util -d 0x1d50:0x5119 -a kernel -R -D uImage-v19-nodebug.bin
Feb 06 21:12:51 <radekp> dfu-util -d 0x1d50:0x5119 -a rootfs -R -D qtmoko-debian-v19.jffs2
Feb 06 21:15:28 <cosmos> yes, step 1 ok, step 2 downloading
Feb 06 21:16:36 <cosmos> after that all trace of the old distribution will be erased and I'll get some free space on the fresh qtmoko install?
Feb 06 21:42:19 <radekp> cosmos: yes
Feb 06 21:45:06 <cosmos> nice job radek, thanks to you and to your team!
Feb 06 22:41:49 <cosmos> is it normal to find 2 Root branches ("Root <2>") with file manager
Feb 06 22:41:52 <cosmos> ?
Feb 06 22:53:20 <DocScrutinizer> errr what?
Feb 06 23:12:49 <slaxxer> maybe u have 2 partitions on your card an linux is installed on both
Feb 06 23:13:21 <slaxxer> what size are the partitions on the card?
Feb 06 23:58:27 <cosmos> slaaxer: I actually have no cards
Feb 07 00:02:03 <cosmos> but several howers ago I've put in the FR a microSD card (Integral 16 gb class 2) and I had kernel panics on boot. Then I put it out.
Feb 07 00:02:45 <cosmos> maybe a messy bootloader flash I've done
Feb 07 00:07:36 <cosmos> And if I type "reboot" on terminal I get:
Feb 07 00:11:54 <cosmos> "Unknown boot option 'g_ether_host_addr..."
Feb 07 00:12:04 <cosmos> maybe the usb connection
Feb 07 00:12:06 <cosmos> and
Feb 07 00:12:08 <cosmos> :
Feb 07 00:12:34 <cosmos> info: rcu detected cpu stall...
Feb 07 00:12:52 <cosmos> after that, boot is ok
Feb 07 00:58:26 <cosmos> who have try the Integral micro sd card on the FR?
Feb 07 01:57:45 <DocScrutinizer> never heard of "integral"
**** ENDING LOGGING AT Sun Feb 07 02:59:58 2010