[00:00] <justdave> it was "current release" earlier this week, so I assume Hardy
[00:00] <pwnguin> yea
[00:01] <justdave> the thing did have Linux on it as shipped, but all binaries, and no dev toolkit on it
[00:01] <justdave> and a 2.2.18 kernel
[00:01] <justdave> so I'm assuming swiping the drivers off the original software probably won't be much use
[00:01] <justdave> the lack of a dev toolchain is the main reason I reloaded it
[00:02] <justdave> the software that shipped on it was all java and I hate java anyway (not to mention it was all compiled class files anyway, so not easily hackable)
[00:02] <pwnguin> im not sure there's a big ubuntu embedded community
[00:02] <pwnguin> you might seek out embeddian
[00:02] <justdave> Figured it'd be more fun to do touchscreen stuff in python ;)
[00:02] <pwnguin> or start an ubuntu embedded community if you like something in particular to ubuntu
[00:03] <pwnguin> err emdebian
[00:03] <pwnguin> if you're in germany, emdebian will be at fosdem in brussels
[00:04] <pwnguin> like tomorrow
[00:04] <pwnguin> er no
[00:04] <justdave> heh.  nope, USA.
[00:05] <pwnguin> thats right, its linuxtag thats in germany soon
[00:11] <guijemont> isn't there that moblin project ?
[00:11] <guijemont> based on ubuntu afaik
[00:11] <guijemont> moblin.org
[00:11] <pwnguin> there is
[00:11] <pwnguin> but
[00:12] <pwnguin> its basically a group for hire working on specific hardware and requirements
[00:12] <justdave> that looks like it's mostly for modern embedded hardware :)
[00:12] <justdave> this thing is like 7 years old
[00:12] <guijemont> yeah, I think they're mainly targetting intel Atom
[00:13] <guijemont> it's an intel sponsored project if I understand correctly
[00:13] <justdave> looks like the Geode stuff was manufactured by several folks...  AMD claims all the drivers got upstreamed into the mainline kernel
[00:14] <justdave> I found 4 kernel modules in Hardy that appear to deal with GPIO ports, but none of them seem to work on this thing
[00:14] <pwnguin> if you dont like emdebian, there's also the gumstix community
[00:15] <pwnguin> they also deal with gpio ports
[00:15] <justdave> emdebian might work, still reading. :)
[04:46] <justdave> haha, is this timing or what
[04:47] <justdave> just updated the package list and had a geode video driver show up
[04:47] <justdave> maybe I can do something better than VESA on this thing after all
[04:48] <justdave> although vesa isn't exactly working poorly on it, so I'm not too concerned :)
[11:30] <tseliot> can anyone of the kernel-team approve my subscription to the mailing list, please?
[11:59] <Swish> I was successful in compiling the kernel with make menuconfig followed by make-kpkg etc, but what's the right way to modify some .config options in the debian/config/i386/config file -then- build it the "ubuntu" way with the syntax:  AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules custom-binary-FLAVOUR  ?
[12:01] <Swish> i should say, what's "a" right way to do that, considering the config files are split up and later concatenated, and if I just overwrite a config file in debian/config/ARCH, that doesn't work at all and when I initiate a compile, i get asked a ton of questions
[12:10] <soren> tseliot: You don't need approval to subscribe to the mailing list.
[12:10] <soren> tseliot: I certainly didn't, so I can't imagine why you would.
[12:16] <tseliot> soren: is this the right link to the mailing list? https://lists.ubuntu.com/mailman/listinfo/kernel-team
[12:17] <soren> Looks like it.
[12:17] <tseliot> soren: I did it yesterday but I didn't receive the email to confirm my subscription
[12:17] <tseliot> I have just tried it now and it works
[12:18] <tseliot> o_O
[12:22] <emgent> morning
[12:24] <tseliot> ﻿emgent: moring
[12:35] <amitk> Swish: you can use the "debian/rules prepare-<flavour>' to do that
[12:35] <Swish> amitk, oooh, /me googles
[12:36] <amitk> Swish: e.g. debian/rules prepare-generic
[12:38] <Swish> okay, so that would create a .config file in debian/build/build-generic/ ... and then... I would edit that .config file in make menuconfig, then run some other script to re-split that new .config file into the multiple files in the debian/config/whatever dirs?
[12:38] <emgent> heya tseliot 
[12:43] <amitk> Swish: yes. We did talk about simplifying that a bit by directly allowing an interactive 'make menuconfig' and then split up the result..
[12:43] <amitk> splitconfig.pl in the scripts directory will help you split up the config now
[12:44] <Swish> ah ha.  so splitconfig uses as input the debian/build/* dirs, and outputs back into the debian/config/* dirs?
[12:44]  * Swish edits it
[12:45] <amitk> Swish: we'll accept patches to do this automagically ;)
[12:45] <Swish> hee hee ;)
[12:46] <Swish> this will have to wait until my kernel compile is done.
[12:47] <Swish> thanks for the info!  :)
[14:17] <alex_joni> BenC: short question. is 2.6.24-18 going to be pushed soon?
[14:21] <BenC> how do you mean pushed?
[14:21] <alex_joni> I mean released
[14:22] <alex_joni> I saw that git has that ABI number
[14:23] <BenC> it's still being prepared by the security team I guess
[14:37] <rtg> BenC: I think the security upload will happen today. or as soon as kees comes online.
[14:44] <BenC> rtg: sounds good
[14:44] <BenC> rtg: FYI, current intrepid locks up on my 1420 laptop (using 64-bit kernel) whenever I close the lid
[14:44] <BenC> getting ready to rebase to -rc4 to see if it fixes the problem
[14:45] <BenC> it's a strange lockup though.. the entire system locks up, except the screen is still on, and the mouse still moves...everything else is dead (no screen updates other than mouse)
[14:46] <rtg> BenC: I've been so busy with Hardy SRU's that I haven't even loaded Intrepid in several weeks.
[14:46] <BenC> rtg: Do you have any systems that duplicate the suspend/resume problem for testing ehci-hcd removal?
[14:46] <rtg> BenC: At least 2. Both of my XPS laptops
[14:47] <rtg> I've also fixed some Dell 640's using the same method, though I don't know if they were running -17
[14:48] <BenC> Do you have a way to test with a USB2.0 device attached to see if it causes some issues?
[14:50] <rtg> BenC: I think the case that we need to test is when your root device is USB. I have only one external USB drive, and I'm loath to trash it. Maybe I have a flash stick thats big enough.
[14:50] <rtg> I wonder if the classmate is USB?
[14:51] <BenC> it is
[14:51] <BenC> What does removing ehci-hcd do when you have a usb2.0 device connected?
[14:52] <rtg> BenC: thats what I'm trying to find out. It for sure dumps bluetooth devices correctly.
[14:52] <BenC> does it revert it to usb1.0 transparently, fail to be removed, or does it remove the devices completely?
[14:52] <rtg> BenC: I think it removes them, Looking at dmesg implies that for bluetooth.
[14:53] <BenC> And if the device is in use, I suspect it will fail to unload then (e.g. usb root fs)
[14:54] <rtg> BenC: right, that was the case I was asking mjg59 about.
[14:54] <BenC> rtg: shouldn't need to make it rootfs...should be able to test with it mounted, and open files on it
[14:55] <mjg59> No, there's no locking to prevent you from removing it
[14:55] <BenC> mjg59: then does it play nice and drop devices to usb1.0?
[14:55] <mjg59> Not as far as I know
[14:56] <mjg59> You'd need to trigger the 1.0 controller to power down the port and power it up again to get the handshaking redone
[14:56] <BenC> so in-use devices just get removed...that's pretty shitty...and makes it dangerous to add to pm-utils for removal
[14:56] <mjg59> There's no way you can drop from 2.0 to 1.0 without a simulated reconnection
[14:57] <mjg59> The protocol just doesn't allow it, AFAIK
[14:57] <rtg> BenC: correct. I think its the reason some file systems have gotten corrupted.
[14:57] <BenC> Can reconnections be done for in-use devices without loosing state?
[14:57] <BenC> in-kernel state I mean
[14:57] <BenC> *losing
[14:58] <mjg59> You could possibly abuse the USB persist stuff
[14:58] <mjg59> But I suspect it'd be unhappy about it being on a different controller
[14:58]  * BenC is totally into abusing things
[14:59] <amitk> BenC: you want to checkout the USB persist patch that I applied to get classmate suspend working? :)
[14:59] <rtg> amitk: how does persist work?
[15:03] <amitk> rtg: by working around the issue of the USB controller powering down on suspend. So the data structures are maintained on suspend. On resume, the kernel checks the persistence flag and prevents 'reset' of the device
[15:03] <rtg> amitk: does that work for the general case, e.g., for more then just the classmate?
[15:04] <amitk> or actually does just a port reset..
[15:04] <amitk> rtg: works across all devices, it is now default in 2.6.26, no kconfig option AFAIK
[15:05] <rtg> amitk: hmm.
[15:09] <amitk> rtg: ohh.. and each device has a persist file in sysfs where you tell whether it is persistent or not
[15:10] <BenC> rtg: I finally re-installed my laptop using 64-bit
[15:11] <BenC> netscape+flash seems to be working perfectly fine
[15:11] <BenC> s/netscape/firefox/
[15:11]  * BenC jumped back about 10 years for a moment there
[15:13] <amitk> BenC: wait till npviewer.bin starts crashing on you...
[15:15] <BenC> amitk: youtube+myspace+random-junk for 4 days and no crash yet
[15:15] <rtg> BenC: I've been running 64 bit for a couple months on both XPS's with no issues.
[15:16] <rtg> amitk: I think the noviwer stuff must have gotten fixed. I've not had any problems with it sine about alpha 4
[15:16] <rtg> *npviwer
[15:17] <BenC> forced push of rebase to -rc4 for intrepid
[15:17] <amitk> BenC: did you do a sync first?
[15:17] <BenC> hopefully no one committed anything in the last 20 minutes :)
[15:17] <amitk> we just cleaned up the tree..
[15:18] <amitk> BenC: did you pull after friday?
[15:19] <BenC> I pulled this morning
[15:20]  * amitk sighs with relief...
[15:23] <rtg> BenC: yeah, amitk cleaned up all of my Intrepid merge history. made it a lot nicer to look at with gitk. it might have also caught a couple of merge problems.
[15:23] <BenC> ubuntu-intrepid-ports is also being pushed
[15:23] <BenC> Hopefully I can get an upload of that today some time
[15:24] <BenC> and be done with it
[15:24] <rtg> BenC: I gotta get working on LRM and finish packaging the new broadcom driver.
[15:26] <BenC> Who's handling the dkms nvidia/fglrx packaging?
[15:27] <rtg> BenC: mario  and alberto milone.
[15:27] <rtg> the envy guy
[15:28] <amitk> rtg: did I tell you alberto volunteered to handle madwifi too..
[15:28] <rtg> amitk: handle it how?
[15:28] <amitk> rtg: DKMS'ify it
[15:29] <rtg> amitk: maybe we wanna get some experience with DKMS before we jump into the deep end.
[15:30] <rtg> we haven't exactly turned it loose on a million desktop users yet.
[15:30] <amitk> agreed...
[15:33] <BenC> When does he think he will have something in the archive?
[15:33] <rtg> BenC: I think they were shooting for sometime this week.
[15:33] <rtg> BenC: at least that was Mario's goal. I may distract him with Hardy issues, though.
[15:35] <soren> If a vendor/device ID combo is listed twice in modules.pcimap, which gets chosen? First match? Last match? Undefined?
[15:36] <rtg> soren: its sorted in modules.dep.
[15:36] <BenC> soren: undefined though
[15:36] <BenC> there's no guarantee which will get loaded
[15:37] <soren> So the list of modules that support the device is generated, and the one of those to appear first in modules.dep is chosen?
[15:37] <soren> Or something to the same effect?
[15:37] <rtg> unless the driver is blacklisted, its the first one in modules.dep that gets loaded.
[15:37] <BenC> that's generally what happens, but don't depend on it
[15:37] <rtg> BenC: well, LBM _does_ depend on it.
[15:37] <BenC> rtg: No, it doesn't
[15:38] <rtg> then I have an imperfect understanding.
[15:39] <BenC> rtg: modprobe will prefer things in updates/ before all others
[15:39] <BenC> modules.*map defines the module name, not the location it is loaded from
[15:39] <rtg> BenC: depmod  will prefer things in updates/ before all others
[15:42] <BenC> rtg: But that affects modules.dep, but modules.pcimap
[15:42] <BenC> *not
[15:43] <BenC> modules.pcimap is just a listing, modules.dep is where it gets the load location/dependencies from
[15:43] <rtg> BenC: modules.*map merely defines the module(s) name for a matching ID, right?
[15:43] <BenC> right
[15:44] <BenC> which means you cannot rely on the ordering in that file
[15:44] <BenC> modules.dep is a different story
[15:44] <rtg> BenC: right, order in modules.*map is unsorted.
[15:44] <rtg> but, moduels.dep is sorted according to depmod search rules.
[15:44] <BenC> right
[15:45] <BenC> but soren was asking about the ordering in modules.pcimap, which is unreliable :)
[15:45] <rtg> so, modprobe uses a straightforward algorithm to choose which module to load.
[15:45] <rtg> oh, maybe I misread sorens question.
[15:47] <rtg> soren: back to my original statement :) Unless blacklisted, the first module in modules.dep that is referenced in a modules.*map is the one to get loaded.
[16:04] <Xsss4hell> Is the 2.6.25.4 Kernel out jet?
[16:04] <Xsss4hell> for Ubuntu
[16:05] <Xsss4hell> I need it, because of ATI gfx cards and Catalys 8.5
[16:05] <rtg> Xsss4hell: Are you talking abut Intrepid?
[16:06] <Xsss4hell> no
[16:06] <Xsss4hell> I have Ubuntu Hardy..
[16:06] <Xsss4hell> Just wanted to update the kernel..
[16:07] <rtg> Xsss4hell: Hardy will continue to be based on a 2.6.24 kernel.
[16:07] <Xsss4hell> WLAN doesn't work either with the 2.6.17 Kernel.. Fritz!Wlan
[16:07] <Xsss4hell> 2.6.24.17 I mean
[16:08] <rtg> Xsss4hell: is there a bug report on it somewhere that I can read?
[16:11] <Xsss4hell> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/225353
[16:11] <rtg> Xsss4hell: ok, I'll look in a bit. on a conf call for awhile.
[16:12] <Xsss4hell> But I doesn work with 2.6.24.16-17 as far as I've tested it. WPA works on 2.6.24.16 but only with ndiswrapper and windows drivers.. Think about it, this type of wlan stick is the most common in Germany
[16:12] <Xsss4hell> WPA2 doesn't work on any of these kernels
[16:28] <Xsss4hell> rtg thank you ;)
[17:06] <BenC> rtg: -rc4 seems to have fixed the lockup I had when closing the laptop lid
[17:07] <rtg> BenC: you must have seen something on LKML that lead you in that direction?
[17:07] <BenC> rtg: my 1420 works out-of-the-box with stock kernel (no lum/lbm/lrm)
[17:07] <rtg> BenC: it ought to. I turned on all of ALSA. 
[17:08] <rtg> in the kernel, that is.
[17:08] <rtg> BenC: have you tried the microphone?
[17:09] <BenC> I did have to copy firmware
[17:10] <BenC> for iwl
[17:10] <BenC> rtg: Let me check...
[17:11] <BenC> Hmm, no built-in mic I guess...I'll need to find one to hook up
[17:11] <BenC> it seems to be working, just recording dead air tho
[17:12] <rtg> BenC: you should have iwl firmware in LUM. there is a LUM package on the kernel PPA. I'll start an upload with the -rc4 rebase.
[17:12] <johanbr> The 1420 I have does have a built-in mic.
[17:13] <johanbr> Maybe it's different depending on your options at purchase time.
[17:14] <rtg> johanbr: I have one as well, I just have to unearth it. Some are digital mics, some are analog.
[17:14] <johanbr> What do you mean by "unearth" ?
[17:15] <rtg> johanbr: I have a bunch of laptops from Dell. the 1420 is somewhere in the pile.
[17:15] <johanbr> Ahh, okay. I thought you were talking about the mic. :)
[17:16] <rtg> johanbr: the 1420 built-in mic was difficult to get working. I really hope there is no regression there.
[17:20] <BenC> johanbr: if you get the webcam option, it has built-in mic
[17:21] <BenC> I wonder if my other 1420 has the webcam
[17:23] <BenC> Ah, I have an E1420 that has built-in webcam+mic
[17:23] <BenC> I can swap my drive to it and test
[17:23] <rtg> BenC: what a PIA. wouldn't it be faster to just reinstall?
[17:24] <BenC> two screws vs. reinstall?
[17:24]  * BenC goes for the 2 screws
[17:24] <rtg> BenC: oh, much simpler then some I've dealt with.
[17:24] <BenC> it's too bad the 1420 doesn't have a wwan slot for my verizon card though :/
[17:25] <rtg> BenC: is that the laptop you're using since you wrecked your XPS1330?
[17:30] <BenC> yep...I was using the 1535, but that was too bulky
[17:30] <BenC> low battery life too
[17:39] <Xsss4hell> hi
[17:39] <Xsss4hell> To the kernel developers! Why don't you create a dynamic kernel tick rate, that automatically adjusts from 100Hz to >1000Hz if needed?
[17:41] <mjg59> Xsss4hell: The kernel already has a dynamic tick rate, so really what you're asking for is the default timeslice setting
[17:41] <Xsss4hell> yes, that what audio production system needs.. I think that's what you said
[17:42] <Xsss4hell> :)
[17:42] <Xsss4hell> so?
[17:42] <mjg59> Xsss4hell: So, the question you want to ask is "Can the default CONFIG_HZ be changed to 1000"
[17:42] <mjg59> :)
[17:42] <Xsss4hell> no, not really
[17:42] <Xsss4hell> my qustion then is
[17:43] <Xsss4hell> Can the default CONFIG_HZ be dynamically changed to 1000
[17:43] <mjg59> No
[17:43] <Xsss4hell> why not?
[17:43] <BenC> CONFIG_HZ is not a dynamic value
[17:43] <Xsss4hell> I know ^
[17:43] <BenC> so we can't dynamically change it
[17:43] <Xsss4hell> That's why I'm asking you, if you make it dynamic in the next kernel version
[17:44] <BenC> how do you propose we do that when it isn't a dynamic value?
[17:44] <Xsss4hell> modify the kernel's source
[17:44] <BenC> Do you have a patch to do this?
[17:45] <Xsss4hell> I wished I had one =)
[17:45] <BenC> You do realize it's not dynamic for a reason?
[17:45] <BenC> because it's hardcoded in a lot of fast path functions
[17:46] <Xsss4hell> I don't understand the reason why it is hardcoded.
[17:46] <BenC> dynticks is about as good as you are going to get
[17:46] <BenC> and we already have that
[17:46] <BenC> if you need something better, I would suggest the -rt kernel
[17:46] <BenC> which is there specifically for hardcore audio work
[17:47] <BenC> you could also try recompiling the kernel with CONFIG_HZ=1000 and let us know how that works for you
[17:47] <Xsss4hell> example audio production midi etc.. needs a very high tick. but these producers don't need the high tickrate 24/7 so why not set it dynamically down, to boost non-time cricital applications
[17:48] <BenC> it can't be done
[17:49] <BenC> you are saying it like it's a something simple we can just turn on in the kernel, when it would require tons of time to implement, even more time to regression test, and most likely impact performance to a point beyond acceptable limits
[17:49] <Xsss4hell> you mean, to much work. or technically not possible. because I don't understand the reasone why it doesn't work these way.
[17:50] <Xsss4hell> I did compile the 2.6.25.4 kernel with  CONFIG_HZ=1000  by the way. it's great but performance is not good a non time-critical apps and 3d somehow.
[17:50] <BenC> It would take way too long to explain why we can't just do this :)
[17:50] <Xsss4hell> hehe I see
[17:50] <Xsss4hell> but can you say if it is technically physically not possible, or it is just too much work?
[17:51] <BenC> CONFIG_HZ is hardcoded in the kernel, which means replacing it with a variable reference, which means overhead in time critical functions
[17:51] <BenC> it's possible, just not worth the effort because of the performance loss
[17:51] <BenC> IOW, you would lose performance by simply replacing CONFIG_HZ with a variable
[17:52] <Xsss4hell> then maybe running time-critically marked apps with CONFIG_HZ=1000 and all other with the CONFIG_HZ rate. Similar to QoS priority tagging
[17:52] <BenC> That makes no sense
[17:53] <BenC> HZ isn't a per process setting
[17:54] <Xsss4hell> It is just an idea. I know it isn't dynamic.
[17:54] <BenC> that's not even the point
[17:54] <BenC> HZ isn't a for applications...it's for the kernel
[17:54] <stgraber> you can't change the rate for a single app, it's for the whole system
[17:55] <stgraber> so if you implement something like that, it'd mean you change HZ to 1000 as soon as one of those "tagged" app is started
[17:55] <BenC> HZ is (basically) the number of times the kernel hits a timer interrupt, in which it can do things like scheduling processes
[17:57] <BenC> the more times you do a timer interrupt, the more changes per second the kernel can do context switching between processes, but it also means more time the kernel spends doing those things, instead of letting your processes run
[17:57] <BenC> s/changes/chances/
[17:57] <Xsss4hell> true
[17:57] <Xsss4hell> suboptimal
[17:58] <Xsss4hell> it isn't a generic solution, but a special: like generic user? take generic kernel | hardcore audio user? take rt kernel
[18:00] <Xsss4hell> like said it was a thought. I hoped that there is no need for a different CONFIG_HZ rate and things could work with one variable CONFIG_HZ rate..sadly it costs to much effort to create such a thing
[18:00] <BenC> There's lots of ways to adjust the scheduler though...perhaps there's some way to tune things to your liking
[18:13] <Xsss4hell> ty for your patience and this informative chat session
[18:13] <Xsss4hell> good bye
[19:11] <foka> rtg, Hi!  Just a follow-up to the seemingly corrupted dmesg output seen in RTL8102E bug reports:
[19:12] <foka> BenC, https://bugs.edge.launchpad.net/ubuntu/+source/klibc/+bug/235282
[19:12] <foka> rtg, It is not memory corruption, but rather a buggy dmesg  :-p
[19:19] <Tophat> wheee - hey mates ive read over the wiki and all the fun articles i can find.  but im still not quite sure how to get developing on the ubuntu kernel.....you know being a windows developer and all.
[19:19] <rtg> foka: right, it was the result of memory corruption in video ram because the network driver crashed.
[19:20] <laga> Tophat: well, what do you want to develop?
[19:20] <foka> rtg, Apparently not... In my case, it actually looked alright on the scrollback buffer, but not the "dmesg > dmesg.log" output.
[19:20] <foka> rtg, https://bugs.edge.launchpad.net/ubuntu/+source/klibc/+bug/235282
[19:20] <rtg> foka: anything after a crash is suspect.
[19:20] <foka> rtg, You see, we began seeing the same problem on machines that weren't crashed by a kernel oops...
[19:21] <foka> rtg, Actually, you may do an experiment to see if it is the case.
[19:21] <foka> rtg, Try /usr/lib/klibc/bin/dmesg
[19:21] <Tophat> laga - im not to sure, theres tons of things i would like to do.  but im not sure if you use git or cvs.  how you do your pushing (who decides whats good and whats not) and all that fun stuff
[19:21] <rtg> foka: hm, I didn't realize it occured even when the NIC driver was sane.
[19:22] <foka> rtg, And compare its output to /bin/dmesg (from util-linux)
[19:22] <foka> rtg, Let's just say we ran into yet another motherboard which refuses to boot due to SATA timeout, and then we saw the same weird dmesg output... (No kernel oops)
[19:23] <foka> rtg, I have yet to find time to report the bug about that motherboard though (a new ECS motherboard with nVidia MCP78 chipset)
[19:23] <rtg> foka: I'll assign the bug to myself so I don't forget it, but I've some other stuff thats gotta get done first.
[19:23] <laga> Tophat: you can clone the kernel source code for ubuntu using git
[19:23] <laga> Tophat: if you got patches, you can send them to the ubuntu kernel mailing list.
[19:24] <foka> rtg, No problem, it is no hurry, just so that you know /bin/dmesg currently included in initrd.gz is buggy.
[19:24] <laga> for big features, it's probably a good idea to use the vanilla kernel from kernel.org. but i'm not a kernel developer, so someone in here might know better :)
[19:24] <foka> rtg, I ended up copying a normal /bin/dmesg to a USB stick to get a correct dmesg output.
[19:27] <Tophat> thanks laga ill do that and play around for a while