[05:30]  * mozzwald is away: sleeping
[11:23] <lag_> Desperate times call for desperate measures!
[12:31] <OlivierN> berco: xem3 copies sur .../xem3. Y'en a un pour chaque core Ducati
[12:31] <OlivierN> oops
[12:41] <ndec> ogra: cool ! I just noticed you pushed the 10.10 images for OMAP!
[13:19] <ogra_cmpc> ndec, yeah, working on the omap4 ones now, hoping to have them ready by mid next week (there are some issues with the kernel package naming i need to have sorted first)
[13:20] <ndec> ogra_cmpc: ok. do you have instructions to use these new type of pre installed images?
[13:21] <ogra_cmpc> ndec, bunzip and dd, boot, be patient :)
[13:22] <ndec> ogra_cmpc: this looks quite complex ;-)
[13:22] <ogra_cmpc> hehe
[13:22] <ndec> ogra_cmpc: do you have the offsets if I want to mount loop to instpect the content?
[13:22] <lool> We should develop some GUI for ndec!
[13:22] <ndec> lool: yes, please
[13:23] <ndec> lool: that said I would love to be able to create my own images as well...
[13:23] <ogra_cmpc> ndec, not yet, noted on my todo now though, the rootfs starts at 72M
[13:23] <ndec> ogra_cmpc: thx
[13:24] <ogra_cmpc> livecd-rootfs is the tool we use for creating the rootfs, for the rest i can put a script online soon
[13:26] <ndec> ogra_cmpc: it creates preinstalled images? is that easy to use? how long does it take to create a UNE image?
[13:27] <ogra_cmpc> livecd-rootf creates ext2/3 rootfs images and spits out a kernel and initrd not the partitioned image
[13:28] <ogra_cmpc> for that we have additional wrapper scripts (the one i mentioned above)
[13:29] <ogra_cmpc> currently these scripts live in debian-cd but thats very complex to set up, i'll extract them and merge them into a single script yuo can feed the files from livecd-rootfs to
[13:30] <ogra_cmpc> creating the rootfs on a imx51 babbage board takes about 2-2.5h for netbook atm
[13:31] <ogra_cmpc> i suspect you will get that down to 1.5h on a panda :)
[13:34]  * lag_ has his internet-net in tow and it going to bag some cloud (going to buy an internet dongle)
[13:42] <ndec> ogra_cmpc: thanks for the details. that would be really nice to get this.
[15:23] <ogra> https://bugs.edge.launchpad.net/jockey/+bug/271288
[15:23] <ubot2> Launchpad bug 271288 in jockey (Ubuntu Intrepid) (and 2 other projects) "Require the user to confirm the license before downloading a driver if it is non-free or if it has patent issues (heat: 4)" [Wishlist,Won't fix]
[16:04] <lool> mpoirier: Oh hey there
[16:04] <mpoirier> lool; hello !
[16:05] <lool> mpoirier: Would you mind helping me out on the SDHC timing issue; I wanted to confirm whether there is a fix for it pending, candidate patch or anything
[16:05] <mpoirier> lool: completely in the dark still...
[16:05] <ogra> lool, turn off preemtion
[16:05] <lool> mpoirier: If not, I'd love confirming which exact CONFIGs I should turn off from the linux source package to workaround
[16:06] <mpoirier> lool: CONFIG_CPU_VOLUNTARY needs to be turned off.
[16:06] <lool> mpoirier: Ok; thanks
[16:06] <mpoirier> lool: CONFIG_CPU_PREEMPT turned on.
[16:06] <mpoirier> I think I'll send my buggy card to india.
[16:06] <mpoirier> TI folks that is.
[16:07] <mpoirier> they said they'd be willing to look at it.
[16:07] <mpoirier> lool: at this point an interrupt doesn't seem to be coming up after a transfer.
[16:08] <mpoirier> hence the call back function not called, leading to a time out on the transfer.
[16:08] <mpoirier> I have 2 exact same cards, one works, the other one doesn't.
[16:13] <lool> mpoirier: Thanks a lot
[16:13] <mpoirier> lool: by the way,
[16:13] <mpoirier> if you find instances where this work around doesn't work, please tell me.
[16:14] <lool> mpoirier: I have a relatively good card, SanDisk Extreme III; I dont know whether speed makes that more likley
[16:14] <mpoirier> lool: it's a wierd one...
[16:14] <lool> mpoirier: Ok; I'll try that out; right now my xcompiler is broken and I cant boot the board anymore, I'll rebuild a kernel as soon as I have a cross-compiler working
[16:14] <mpoirier> we haven't entirely narrowed down type of card and speed,
[16:14] <mpoirier> if that makes a difference at all...
[16:14] <lool> Ok
[16:15] <mpoirier> I've seen a lot of failures on a variety of cards...
[16:15] <mpoirier> again, if you still get a failure with PREEMPT_NONE, I need to know.
[16:16] <ogra> mpoirier, btw, another prob arose yesterday, seems the NAND driver got lost between lucid and maverick, i guess there is a config option missing
[16:17] <mpoirier> lool: by the way, I just looked in the config file.  It is CONFIG_PREEMPT_VOLUNTARY and CONFIG_PREEMPT_NONE
[16:17] <mpoirier> Yes, I noticed  that.
[16:17] <mpoirier> the NAND flash I mean...
[16:18] <ogra> can we get that back ? :)
[16:18] <mpoirier> we will need to yes.
[16:18] <mpoirier> I'll investigate and open a bug if need be.
[16:18] <ogra> else upgrades from lucid installs will break for C4 users
[16:18] <GrueMaster> in my testing, class 4 cards seem to work best, although I only have a handful of cards.  Class 2 fail consistently (2 SD 4G cards tested), class 6 fails 70% of the time (1 4G).  Both of my Kingston Class 4 cards work fine (8G &16G).
[16:18] <ogra> fresh maverick installs wont use NAND but for lucid users NAND is essential
[16:20] <lag_> ogra: nec was talking about generic udev rules
[16:20] <lag_> Are they in the filesystem?
[16:21] <ogra> lag_, yes, /lib/udev/rules.d/ ... they need somthign like /lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules for their device that allows access for all locally logged in users
[16:21] <lag_> ogra: I just found them *embarrassed smiley*
[16:22] <ogra> lag_, its all about access to the device
[16:23] <lag_> Do you know where this 'alias' is specified?
[16:30] <ogra> lag_, alias ?
[16:32] <lag_> ogra: nec mentioned that if I used MODULE_ALIAS macro there was a rule in udev that would pick up syslink's uevent
[16:32] <ogra> lag_, well, if you use the KERNEL parameter it will just apply ot the module
[16:33] <ogra> lag_, man udev btw
[16:33] <lool> lag_: Yes, I discussed this with mpoirier already
[16:34] <lool> lag_: It seems your re-doing this research
[16:34] <lool> lag_: /lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"
[16:34] <ogra> KERNEL=="syslink*", ENV{ACL_MANAGE}="1"
[16:34] <lool> Which means that if there's a DRIVER and a MODALIAS, that triggers a modprobe on the MODALIAS
[16:34] <ogra> lool, urgh
[16:34] <lool> ogra: "urgh"?
[16:34] <ogra> lool, you defiantely dont need the modprobe stuff
[16:35] <ogra> the driver gets already loaded by the platform uevent trigger
[16:35] <lool> ogra: That's what I'm speaking of
[16:35] <lool> loading the driver by the platform uevent trigger
[16:35] <lool> That's the only reason I can think of someone adding a MODULE_ALIAS
[16:36] <ogra> lool, i thought that doesnt need a rule since its done inside udevd if there is a paltform event
[16:37] <ogra> i.e. doesnt need to run scripts to speed up
[16:37] <lool> ogra: Really, which rule is that?
[16:38] <ogra> dunno, thats how Keybuk explained it to me once
[16:38] <lool> ogra: I'm pretty sure this is the rule used
[16:39] <ogra> well, i was convinced platfrom drivers dont need a rule at all and udevd has that bit builtin, but i might have understood that wrongly
[16:39] <lool> ogra: Are you sure of this, or could you look it up?
[16:40] <ogra> i'm not sure of it, thus my comment above :)
[16:40] <ogra> indeed the driver rule will match anyway even if i'm wrong
[16:41] <lool> ogra: grep-ing the udev source for modprobe and insmod, I see no direct loading; it's only done via rules, and the only place is from rules/rules.d/80-drivers.rules, so I'm pretty sure I pointed at the right spot
[16:41] <ogra> lool, ok
[16:41] <lool> Anyway, so much for trying to help out  :-)
[16:41]  * lool leaves for WE
[16:42] <ogra> lool, might be that i mixed it up with devtmpfs stuff
[16:42] <ogra> enjoy your WE :)
[16:54] <lag_> lool: Well the drivers aren't loading
[16:56] <lag_> lool: http://paste.ubuntu.com/458378/
[16:56] <lag_> ogra: See above paste - I am using KERNEL
[16:57] <ogra> you shouldnt add a rule for loading, as lool said, the 80-drivers.rules should just pick it up on booting
[16:57] <lag_> ogra: I had no intention
[16:58] <lag_> Did you see the above paste?
[16:58] <ogra> yes
[16:58] <lag_> It doesn't use DRIVER
[16:58] <lag_> It uses KERNEL and UDEV
[17:05] <ogra> it uses MODALIAS
[17:07] <lag_> They all use that though don't they?
[17:08] <lag_> The udev rule that I was pointed to uses DRIVER doesn't it?
[17:11] <lag_> Help me udev geeks :)
[17:11] <lag_> I've raised 2 uevents for you
[17:11] <hrw> you have modalias so udev should load it
[17:12] <lag_> But it doesn't
[17:12] <hrw> BB or panda?
[17:12] <lag_> So where do I start looking for a solution?
[17:12] <lag_> Panda
[17:14] <lag_> But the system is common throughout isn't it
[17:14] <lag_> I raised the two uevents seen in the paste above
[17:14] <lag_> But udev doesn't load the module(s)
[17:15] <lag_> What gives?
[19:28] <lool> lag_: hey
[19:28] <lag_> lool: Good evening
[19:29] <lool> lag_: So the rule only works when DRIVER and MODALIAS arent empty
[19:29] <lag_> I don't have a DRIVER variable
[19:29] <lag_> It has KERNEL instead
[19:30] <lool> lag_: So perhaps you need to extend the event to carry the relevant information
[19:30] <lag_> Yes, I think I know what I have to do
[19:30] <lool> lag_: If you prefer keeping the current event, you'll have to submit new rules to udev
[19:30] <lool> lag_: Ok cool
[19:31] <lag_> lool: Who controls the rules?
[19:31] <lag_> Where do they come from?
[19:31] <lool> lag_: Is there anything left open for discussion or where you were looking for input?  Sorry, I'm not sure I followed the status
[19:31] <lool> lag_: The rules are from udev upstream
[19:31] <lag_> Okay
[19:31] <lag_> So, I'm guessing I must conform to them
[19:32] <lool> lag_: It's a quite specific case that you have here, so it might make sense to handle them specially, but it might be more efficient or better to try to fit into the expected scheme
[19:36] <lag_> lool: Do we (Ubuntu) have any entries in udev? Or are they all standard?
[19:38] <lool> lag_: We add some, but ideally only upstreamable stuff, so you should check wiht upstream if in doubt
[19:40] <lag_> I don't think this project is upstreamable
[19:43] <lag_> Okay, I'm going to try and do it the hard way first
[19:43] <lag_> Thanks lool
[19:43] <lag_> Right, it's nearly 8 o'clock here - I'm offski