[03:18] <lamont> rtg: does the -j16 make it go faster?
=== asac_ is now known as asac
=== \sh_away is now known as \sh
=== \sh is now known as \sh_away
[08:09] <kraut> amitk: thanks for the info
[08:10] <kraut> did anyone of you verified http://www.linux.it/~md/software/novmsplice.tgz?
[08:10] <kraut> it's an workaround against this vmsplice issue. that's a c-code where you could compile your own kernel-module.
[08:10] <kraut> it should disable vmsplice
=== \sh_away is now known as \sh
[08:20] <kraut> moin
[08:20] <alex_joni> kraut: I thought there's a fix in 2.6.24.2 ?
=== abogani changed the topic of #ubuntu-kernel to: Topic for #ubuntu-kernel is: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 12, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
=== abogani changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 12, 17:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
[11:29] <abogani> rtg, amitk: Hi Tim, Hi Amit! Please don't forget to enable ati closed driver (fglrx) in -rt l-r-m. Thanks.
[11:30] <tjaalton> abogani: does it build?
[11:30] <amitk> abogani: why was it disabled?
[11:30] <abogani> tjaalton: When i submit the patch it compile fine.
[11:31] <amitk> abogani: also the meeting is at 1700 UTC, wiki has been corrected...
[11:31] <tjaalton> abogani: ok, cool
[11:33] <abogani> amitk: Thank you! I have corrected the topic in this room.
[11:34] <amitk> great
[11:34] <abogani> tjaalton: Let me re-check build of l-r-m...
[11:35] <abogani> amitk: Could i add a topic for today meeting (as Open Discussion)?
[11:35] <amitk> abogani: go ahead
[11:35] <abogani> amitk: Should i add it to wiki page?
[11:35] <amitk> abogani: yes
[11:36] <abogani> amitk: Ok, Thanks.
[11:39] <abogani> Done
[11:40] <abogani> tjaalton: Compilation test in progress...
[11:43] <tjaalton> there's also a request to enable nvidia/fglrx for -server
[12:05] <abogani> for server?
[12:10] <abogani> server + GUI? shudder...
[12:12] <tjaalton> the server kernel is useful in some situations
[12:12] <tjaalton> in a workstation
[12:14] <tjaalton> bug 153011
[12:15] <ubotu> Launchpad bug 153011 in linux-restricted-modules-2.6.24 "no nvidia-glx or fglrx for server kernels" [Medium,Triaged] https://launchpad.net/bugs/153011
[12:24] <abogani> tjaalton: Compilation test successfully. Patch still good.
[12:26] <abogani> amitk: Could you enable in debian/rules the fglrx driver for l-r-m, please?
[12:27] <amitk> abogani: was your patch already integrated?
[12:27] <abogani> Yes!
[12:28] <amitk> ok, I'll see that it is done
[12:28] <abogani> You can find it at ati/patches/1-rt-compat-symbols.diff in source package.
[12:28] <abogani> Ok, Thanks!
[12:37] <jdahlin_> It seems that hardy kernels takes a lot longer to startup than gutsy ones
[12:37] <jdahlin_> the part 'looking for new hardware', took 1-2 seconds on gutsy but on hardy it's easily 20 seconds
=== LifeHacker is now known as tuxmaniac
[13:58] <amitk> jdahlin_: is there a bug about this?
[14:02] <jdahlin_> amitk, I tried to search on hardy/linux without finding anything
[14:02] <jdahlin_> what's the right product/source package to search on?
[14:02] <amitk> product=ubuntu, package=linux
[14:03] <amitk> jdahlin_: file a bug please
[14:03] <amitk> tjaalton: have you verified that fglrx and nvidia compiles for server flavour?
[14:04] <tjaalton> amitk: no I haven't
[14:05] <amitk> tjaalton: rtg says it wouldn't compile due to some dependencies. He'll take a stab at it today
[14:05] <tjaalton> amitk: oh cool
[15:42] <Kano> hi rtg , are you interested in a webcam driver patch for lum?
[15:43] <rtg> Kano: email it to the kernel team mailling list.
[15:46] <alejalej> hello kernel people
[15:46] <alejalej> am running Hardy
[15:47] <alejalej> very happy with the kernel change
[15:47] <Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/lum-stk11xx.patch
[15:47] <alejalej> no need to noapic no more, etc
[15:47] <Kano> if you like to look
[15:47] <alejalej> but I have some problems with suspend/hibernate... and specially resume
[15:47] <alejalej> do I need to file a bug first=
[15:47] <alejalej> or could you guys point me to some interesting alternative....
[15:51] <alejalej> did someone flood me out?
=== jdahlin_ is now known as jdahlin
[16:26] <Kano> rtg: for amd64: error in debian control line 78: duplicate Conflicts
[16:27] <Kano> when compiling generic
[16:27] <rtg> Kano: hmm, I saw that on my PPA build this morning, but haven't been able to get back to it.
[16:28] <Kano> for the linux-libc-dev 
[16:29] <rtg> I wonder why that just started showing up.
[16:29] <Kano> well i tried to compile it on amd64 siiiiiiiiiiiiiiiiid
[16:38] <rtg> looks like dpkg was upgraded and caught a long standing syntax error.
[16:40] <amitk> rtg: did unifying 75 and 78 fix it?
[16:40] <rtg> amitk: don't know yet. it takes a bit.
=== \sh is now known as \sh_away
[16:48] <Kano> ubuntu/media/stk11xx/stk11xx.ko
[16:49] <Kano> at least my patches compiles the module ;)
[16:50] <amitk> Kano: you have to send an email to kernel-team@lists.ubuntu.com explaining _what_ the patch does.
[16:52] <Kano> it adds just this
[16:52] <Kano> svn co http://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/trunk/driver stk11xx
[16:54] <rtg> Kano: the purpose of the email list is 1) wider distribution for comments, and 2) time elasticity. Not everyone has the time to camp on IRC to find out what is going on.
[16:55] <Kano> well you are online and you have acess to git ;)
[16:56] <Kano> it is a very easy module, em8300 i still have to do...
[16:57] <Kano> or you if you like ;)
[17:03] <amitk> BenC just postponed the IRC meeting by 15mins...
[17:12] <rtg> ogasawara: when you regen your hardy-buglist page, could you put a date in the title?
[17:12] <ogasawara> rtg: sure, np
[17:13] <rtg> 'tanks
[17:14] <king_> ogasawara: how often is it updated? Is it a manual update?
[17:14] <ogasawara> king_:  updated every hour via cron job on rookery
[17:15] <BenC> I see everyone else is alive
[17:15] <BenC> smb: ping
[17:15] <ogasawara> king_: and the list is maintained in a bzr tree which gets pulled on rookery
[17:15] <smb> Ben: yup
[17:15] <BenC> good deal
[17:16] <BenC> Ok, The weekly Kernel Team meeting is now in session...agenda, as usual, is at: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:17] <BenC> Let's run down the team, see what's going on
[17:17] <BenC> amitk: You're up first, how's things?
[17:17] <amitk> doing ok
[17:18] <amitk> A bunch of mobile updates for graphics drivers, dma, etc. coming up next week
[17:18] <BenC> amitk: going into hardy kernel?
[17:18] <amitk> I won't have a lot of time to do bug fixing this week
[17:19] <amitk> BenC: yes
[17:19] <BenC> Ok
[17:19] <BenC> amitk: This is all for lpia, I assume
[17:20] <amitk> yes. Everything going in is restricted to LPIA
[17:20] <amitk> it won't affect other flavours
[17:20] <BenC> good, so no need to worry much about code freezes for the rest of the dist
[17:20] <maks_> BenC: can i please remind you on an initramfs-tools sync
[17:21] <BenC> maks_: best thing is to email me, if you could please
[17:21] <BenC> my inbox acts as a todo list :)
[17:21] <rtg> also copy kernel-team mailing list.
[17:21] <maks_> which email BenC ?
[17:21] <BenC> bcollins@ubuntu.com, kernel-team@lists.ubuntu.com
[17:21] <maks_> cool
[17:22] <BenC> amitk: Thanks
[17:22] <BenC> rtg: How's the kernel looking right now for next milestone?
[17:22] <rtg> amitk is packaging the -8 ABI, which is based on 2.6.24.2
[17:22] <rtg> there are a couple pof critical crashes that I need to look at as soon as its uploaded.
[17:23] <rtg> would also like to review some of the wireless issues.
[17:23] <rtg> otherwise, I think its looking OK
[17:23] <amitk> -8 will include the fixes for the vmsplice CVEs
[17:23] <rtg> yep
[17:24] <BenC> This will be the Alpha 5 kernel, right?
[17:24] <rtg> oh, and there are some possible IDE issues.
[17:24] <BenC> what happened there?
[17:24] <rtg> yes - it should be the A5 kernel.
[17:24] <rtg> Ng complained that his laptop wnet fropm sda back to hda.
[17:25] <BenC> you mean issues like regressions caused by the -8 kernel, or things that were already there?
[17:25] <rtg> someting in the -7 kernel.
[17:25] <BenC> Did someone dork around with the via IDE/PATA driver?
[17:25] <rtg> there is one commit that enables more IDE devices. perhaps that one?
[17:25] <BenC> yeah, sounds like it
[17:25] <rtg> I'll get you to reveiew it with me later.
[17:25] <BenC> we don't want to enable IDE drivers where we already have a libata-pata one
[17:26] <rtg> you are the expert there.
[17:26] <amitk> BenC: can initramfs enforce an order in which modules are tried?
[17:26] <BenC> Need to watch out when we mess with that sort of config change...could really screw up someone's system
[17:26] <amitk> ata_piix before ide_disk, for example?
[17:26] <BenC> amitk: only by blacklisting
[17:27] <amitk> BenC: unfortunate
[17:28]  * BenC pimps the udev device/driver binding paradigm, and moves on
[17:29] <BenC> rtg: Ok, thanks
[17:29] <BenC> smb: how's things coming along for you?
[17:30] <smb> So far, I work on several bugs. Most of them currently require more input or looking into them
[17:30] <smb> Did the tp_smapi addittion to lum last week
[17:31] <BenC> smb: Since you are a few weeks into things now, how are you finding the work flow and documentation?
[17:31] <smb> Generally, there are a few bugs in the crried forward section that have fixes either only in the -mm tree or not ready yet. Is it ok to leave them triaged there or can we park them
[17:32] <smb> Well, as most of us, I find Leann's buglist most usefult. 
[17:32] <BenC> smb: if there's no chance of us fixing them, then marking them WontFix is proper
[17:32] <BenC> smb: it will get it out of limbo so we can move on to more important things
[17:33] <ogasawara> smb:  if you want to keep an eye on them, feel free to reassign to canonical-qa and I'll track them
[17:33] <rtg> smb: if there isn't an upstream fix by now, then its unlikely to happen in timew.
[17:34] <smb> ogasawara: Yes, I guess we did that for one and I keep an eye on the upstream report
[17:34] <BenC> The only time that isn't the case is where it's a critical bug/regression that we should put some effort into
[17:34] <rtg> like an oops.
[17:35] <BenC> well, and oops that isn't in something like netatalk :)
[17:35] <rtg> right. an oops in something interesting.
[17:35] <BenC> smb: Alright, thanks
[17:36] <BenC> king_: And fresh from your first week with us, how are things coming along?
[17:37] <king_> Ok thanks - I believe I'm up to speed .. with help I've got some code now into the repository!
[17:37] <king_> I've been looking at several bugs...
[17:37] <king_> Some look a bit more open ended than others.
[17:38] <king_> I've put a patch in for the macbook 3.1 track pad
[17:38] <king_> And I've been trying to understand why  the /proc/acpi/alarm is missing for the x86_64 
[17:39] <BenC> That reminds me, we should probably revert back to sending patches to kernel-team for double-ack before commit like we used to
[17:39] <king_> I need to know how to this then.
[17:40] <BenC> This predates both you and smb, so I'll give it a quick once over
[17:40] <king_> Ok.
[17:40] <maks_> baah kernel-team is a subscriber list
[17:40] <smb> ok
[17:40] <king_> ok.
[17:40] <BenC> Any patches that we commit (this pertains mostly to the kernel), would be sent to kernel-team@lists.ubuntu.com
[17:41] <BenC> before they are committed
[17:41] <BenC> at least two people on the team have to ACK the patch before it can be committed...assuming a kernel team person submits the patch, that means one ACK from a team member
[17:41] <smb> or pushed. we could commit locally to get a git-format-patch version
[17:42] <king_> This would be a good way of catching any dubious commits by newbies :-)
[17:42] <BenC> yeah, it's all about checks and balances :)
[17:43] <rtg> except its not a democracy.
[17:43]  * BenC puts on the iron fist
[17:43] <BenC> seriously, I'm more inclined to just put in my 2 cents where needed and let you guys make the final decision
[17:44] <king_> I'd appreciate it.. if it does not slow down workflow..
[17:44] <BenC> it seemed to work well before, but we stopped doing it since we only had 3 of us on the team, which did slow things down
[17:45] <BenC> with 5 of us, the ACK turn around should be quick, especially if you ping everyone when it's important
[17:45] <rtg> I try to stay on top of kernel-team submissions.
[17:46] <BenC> king_: ok, thanks
[17:46] <BenC> Moving on to QA bug list
[17:46] <BenC> I haven't had a chance to look at it today...is there anything serious going on there?
[17:47] <rtg> Bug #189224 is interesting
[17:47] <ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [High,Triaged] https://launchpad.net/bugs/189224
[17:47] <BenC> The carried forward section is still growing
[17:47] <smb> Which might be  cpuidle
[17:47] <ogasawara> also mathiaz reported Bug #185303
[17:47] <ubotu> Launchpad bug 185303 in linux "Kernel Oops - unable to handle kernel paging request - Hardy server i386 alpha3/alpha4 install on HP Proliant ML350 fails" [High,Triaged] https://launchpad.net/bugs/185303
[17:47] <BenC> And there's still a lot unassigned bugs
[17:48] <Kano> rtg: btw. sent a mail...
[17:49] <smb> For example https://bugs.launchpad.net/ubuntu/+bug/152187 is something  that is assigned to qa and the fix wont happen too soon
[17:49] <ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] 
[17:49] <rtg> I should have a bit more time to work on bugs. The CVE flurry seems to have settled.
[17:50] <ogasawara> smb: I can move the qa assigned bugs off the list and track them separately
[17:50] <BenC> 189224 looks pretty damn serious
[17:50] <rtg> Benyup
[17:51] <smb> ogasawara: I think that would be good. Since this issue has to wait for the upstream fix
[17:51] <rtg> BenC: yup, even.
[17:51] <BenC> rtg: 185303 appears very similar to a vendor issue we had
[17:52] <rtg> its got some interesting wrinkles. amd64 works, i386 doesn't
[17:52] <BenC> bios related
[17:52] <BenC> although that one was fixed by a bios update...so maybe we need to track the actual problem
[17:52] <BenC> it's a regression either way
[17:53] <rtg> I think Mathiaz has checked for BIOS updates. I'll confirm.
[17:53] <rtg> He showed me this one at sprint.
[17:53] <BenC> Let's make a point to get this carried over list knocked out some how
[17:54] <BenC> those two bugs mentioned should get some priority (especially the cpuidle one)
[17:54] <smb> Ok, I try to dig further there
[17:54] <rtg> smb: get him a 2.6.24.2 based kernel.
[17:55] <BenC> the pci bios seems like it should be easy to debug
[17:55] <rtg> except for the fact that it chunders inside the BIOS.
[17:55] <smb> rtg: right. I read something related that vanished later
[17:58] <BenC> Alright...
[17:58] <BenC> abogani: ping
[17:58] <abogani> BenC: pong
[17:58] <abogani> Ok the thing is off-topic in this moment but I prefer clarify this point in time for next release.
[17:58] <abogani> Is it possibility to ship -rt kernel flavour in main in hardy+1?
[17:58] <abogani> There isn't CVE or Secunia advisory. It have the same local exploit of the -generic one.
[17:58] <abogani> Obviously i don't want merge -rt code into main git tree but is sufficient maintain it to a separate patchset (as usual) and release it through main repos.
[17:59] <abogani> Noteworthy is that 2.6.25 will merge other fundamental pieces from -rt patchset via Molnar's git tree (http://kerneltrap.org/node/15345).
[17:59] <abogani> Thus why we can't raise -rt to main? what i can do to achieve this goal (for hardy+1)?
[17:59] <BenC> abogani: this is something we'll need to discuss in detail at UDS
[18:00] <BenC> abogani: are you on the sponsored list?
[18:01] <abogani> Mhhh sponsored list? I don't know nothing about it... Thus I suppose no. 
[18:01] <BenC> abogani: email me some notes and I'll see if we can work some way for you to be at either FOSSCamp or UDS to plead your case in person :)
[18:01] <abogani> BenC: Ok. Thanks a lot.
[18:01] <BenC> at the very least, creating a blueprint on launchpad targetted for hardy+1 is a great start
[18:02] <abogani> specifically for main inclusion?
[18:02] <BenC> yeah
[18:02] <abogani> Ok. 
[18:03] <BenC> Ok, that ends the actual agenda
[18:03] <BenC> Any open items for discussion?
[18:04] <BenC> I'll take that as a no, and call the meeting to a close
[18:04] <BenC> Thanks every one!
[18:08] <tjaalton> well, there are some DRM changes in 2.6.25-rc1 that would be nice to have, like ba8bbcf6ff4650712f64c0ef61139c73898e2165
[18:08] <tjaalton> it might fix bug 189260
[18:08] <ubotu> Launchpad bug 189260 in xserver-xorg-video-intel "Backlight doesn't turn on after resume" [Medium,Confirmed] https://launchpad.net/bugs/189260
[18:08] <tjaalton> at least upstream thinks so :)
[18:23] <tjaalton> amitk: if you are doing l-r-m as well, let me know before you upload.. I'll toss you with a diff to fix bug 190347
[18:23] <ubotu> Launchpad bug 190347 in linux-restricted-modules-2.6.24 "Bad entry in menu" [Low,In progress] https://launchpad.net/bugs/190347
[18:26] <rtg> tjaalton: email it to kernel-team. I'll probably be doing the upload later today.
=== \sh_away is now known as \sh
[18:26] <tjaalton> rtg: oh today already.. ok
=== smb is now known as smb_away
[18:27] <rtg> tjaalton: actually, lrm probably won't get uploaded until tomorrow given the ABI bump.
[18:28] <tjaalton> rtg: cool, more time for me ;)
[18:29] <tseliot> tjaalton: maybe your diff can include my patch as well ;)
[18:29] <tseliot> shameless plug
[18:30] <tseliot> :-P
[18:30] <tjaalton> tseliot: hehe
[18:30] <tjaalton> actually, I'm having second thoughts about including the desktop file for nvidia-settings, since it's not a tool for a casual user, and could do more damage than good
[18:33] <tjaalton> or at least don't show it by default
=== smb_away is now known as smb
[20:33] <Kano> hi, ist ubuntu.com down?
[20:36] <Kano> hmm now it seems to work again
[20:37] <Kano> rtg: did you see the mail in the ml?
[20:37] <rtg> yes
[20:37] <Kano> and where is your commit
[20:37] <rtg> busy
[20:38] <Kano> when there is a more complicated makefile with serveal flags, how to convert these?
=== Keybuk_ is now known as Keybuk
=== \sh is now known as \sh_away
[21:45] <Kano> rtg: do you test the kernel on amd64?
=== smb is now known as smb_away
=== smb_away is now known as smb
=== smb is now known as smb_away
=== doko_ is now known as doko
[22:38] <Kano> rtg: do you know that standard debian kernels have FB_VESA=y and FRAMEBUFFER_CONSOLE=y?
[22:40] <mjg59> Kano: That doesn't make it a sensible thing to do
[22:40] <Kano> sure without i dont get a framebuffer on amd64
[22:41] <Kano> never with a ubuntu live cd
[22:41] <mjg59> Sure you do
[22:41] <mjg59> But you'll never get one by default
[22:41] <Kano> dont know whats differnet with i386, but that problem is mainly amd64 there
[22:43] <Kano> also usplash only works with 32 bit
[22:44] <mjg59> usplash works fine with most 64 bit hardware
[22:44] <Kano> well my destiny is to have the none working examples
[22:44] <mjg59> I'm working on it, but it's not a kernel issue
[22:46] <Kano> do you own a system where it does not work
[22:46] <mjg59> No, but I know what needs to be done before it can be fixed
[22:47] <Kano> so what
[22:47] <mjg59> ?
[22:47] <Kano> tell me what you think the problem is
[22:47] <mjg59> The x86 emulation is bugged in some way
[22:48] <Kano> in usplash?
[22:49] <mjg59> Yes
[22:49] <mjg59> Well, in libx86
[22:49] <Kano> interesting that it works on some systems...
[22:50] <mjg59> Depends on the video BIOS
[22:51] <Kano> usually static vesafb is working everywhere...
[22:52] <mjg59> We can't use vesafb by default
[22:52] <Kano> vga=0 would disable it
[22:53] <mjg59> The default would have to be disabled
[22:53] <Kano> at least enabling is then easy
[22:54] <mjg59> It will already be handled properly
[22:54] <Kano> i really doubt that
[22:55] <tjaalton> mjg59: the buglist for xserver-xorg-video-nv has many potential testers for you ;)
[22:56] <mjg59> Kano: Check /usr/share/initramfs-tools/scripts/init-top/framebuffer
[22:56] <mjg59> tjaalton: Why on earth are they filed against the X driver?
[22:58] <Kano> mjg59: why dont you make fbcon static, it is modprobed anyway?
[22:58] <mjg59> Kano: So it's not loaded if the user doesn't ask for it
[22:59] <Kano> also the splash check is suboptimal
[22:59] <mjg59> ?
[23:00] <tjaalton> mjg59: lack of better knowledge perhaps
[23:00] <Kano> when you use splashy you have a splash option,but you need vesafb
[23:00] <Kano>         splash*)
[23:00] <Kano>                 FB="vga16fb";
[23:00] <mjg59> Which version are you looking at?
[23:00] <mjg59> That's not in the current code
[23:00] <Kano> etch
[23:00] <mjg59> Well, blame Debian
[23:01] <Kano> well will fetch u initramfs
[23:03] <Kano> the modprobe does not work
[23:04] <Kano> on my system
[23:04] <Kano> definitely not
[23:04] <mjg59> Working out why would be helpful
[23:04] <mjg59> Since it works here
[23:04] <Kano> well i can not send you my gfx card
[23:04] <mjg59> If the modprobe is failing, the graphics card is irrelevant
[23:06] <Kano> well sid + ubuntu are similar in that file btw
[23:06]  * mjg59 shrugs
[23:07] <Kano> just that u does not check for while read fbno desc; do if [ $(($fbno < 32)) ]; then before mknod /dev/fb${fbno} c 29 ${fbno}
[23:08] <Kano> and u uses -Qb
[23:08] <Kano> option to modprobe
[23:12] <Kano> interestingly i can use onboard vga too and get the same problem...
[23:13] <Kano> http://www.gigabyte.co.nz/Products/Motherboard/Products_Overview.aspx?ProductID=2535
[23:13] <Kano> this board
[23:57] <Kano> mjg59: the thing is: after boot vesafb is never loaded, only fbcon