[09:49] <abogani> rtg: Are you around?
[10:03] <amitk> abogani: rtg should come online in 2-3 hours
[10:10] <abogani> amitk: Thanks Amit. I have a problem on -rt. Can you help me, please?
[10:11] <amitk> abogani: sure, what is it
[10:12] <abogani> amitk: Thanks. After last (security) update of the kernel X don't want start at boot with nvidia X driver on 64bit (32bit works fine).... I suspect that the problem still live in Hardy.
[10:12] <abogani> Where should I look?
[10:12] <abogani> Do you have some suggestions?
[10:12] <abogani> Who could explain me why 32bit version works fine and 64bit not?
[10:13] <amitk> abogani: is the problem in Gutsy?
[10:14] <abogani> amitk: Yes.
[10:17] <amitk> abogani: I am checking the updates...
[10:18] <abogani> amitk: I suspect that isn't dependent from last update only...
[10:19] <abogani> I have only one 64bit system and i don't update/dist-upgrade often
[10:30] <amitk> abogani: could you post the /proc/version_signature of the working and non-working kernels?
[10:33] <abogani> Unofficial for both
[10:35] <amitk> abogani: do you know the last tag where it was working?
[10:38] <abogani> amitk: Sorry i don't remember. :-(
[10:39] <amitk> that makes it a bit hard to narrow down the problem :)
[10:40] <abogani> I know Amit ;-)
[10:40] <amitk> abogani: Do you have the problem with Hardy Alpha 4?
[10:42] <abogani> amitk: No Hardy (-rt) works very well but unfortunately my test system don't have a nvidia video card. Sorry but i don't enough computers :-)
[10:43] <amitk> abogani: Do we _ever_ have enoughc computers? ;-)
[10:44] <amitk> could you confirm with the Hardy live cd on the computer with the nvidia?
[10:45] <abogani> amitk:  I'll do this test!
[10:45] <abogani> amitk: Thank you for the moment! :)
[10:45] <amitk> np
[10:53] <tjaalton> abogani: reinstall the driver
[10:53] <tjaalton> abogani: unless you are using -nv
[10:56] <abogani> tjaalton: Ok i'll try that first! Thanks Timo.
[10:57] <amitk> tjaalton: why?
[11:02] <tjaalton> amitk: that's a valid question, but people have said that it helped..
[11:02] <tjaalton> abogani: do you use the official driver or envy?
[11:03] <tjaalton> abogani: also, the logfile would be nice
[11:03] <amitk> tjaalton: packaging problem?
[11:04] <tjaalton> amitk: with envy at least, our packages should be fine
[11:05] <tjaalton> if the package doesn't divert some files, upgrading the server will break it
[11:05] <tjaalton> I'm not sure if envy diverts libglx et al
[12:07] <ogra> hey ... i seem to have lots of oopses recently with the -5 kernel related to tick_notify and _spin_unlock_irqrestore is that known ?
[12:07] <ogra> it spills my logs and after some hours the system just hardlocks
[12:07] <thegodfather> ogra: what about collecting those OOPSes?
[12:08] <thegodfather> it's difficult to guess without
[12:08] <ogra> well, in fact its always the same it seems
[12:08] <thegodfather> well it doesn't help if you don't show us your OOPS ;)
[12:09] <ogra> http://paste.ubuntu-nl.org/54836/
[12:09] <ogra> there ist is :)
[12:10] <thegodfather> ogra: it's somewhere in RPC code. i guess you are running NFS of somekind
[12:10] <ogra> lets check, i'm not sure 
[12:10] <ogra> ogra@laptop:~$ ps ax|grep nfs
[12:10] <ogra>  6603 pts/0    R+     0:00 grep nfs
[12:10] <ogra> #
[12:10] <ogra> nop
[12:11] <thegodfather> rpc
[12:11] <ogra> ah, yeah
[12:11] <ogra> the client stuff
[12:11] <thegodfather> yeps
[12:11] <thegodfather> do you have some aggressive acpi features enabled?
[12:11] <thegodfather> well it's a laptop.. hmmm
[12:12] <thegodfather> try to disable acpid or whatever is used for power manager now
[12:12] <thegodfather> for what i can see something goes bad between the 2
[12:12] <ogra> i dont do it explicitly and i think there is an APIC message during boot ...
[12:12] <thegodfather> ACPI != APIC
[12:12] <ogra> ACPI not connected to local APIC or so ?
[12:12] <ogra> let me reboot i'll check
[12:13] <thegodfather> try to boot with the usual options.. noapic noacpi or whatever they are called now
[12:13] <thegodfather> because i run nfs/rpc stuff here but i don't see it
[12:13] <thegodfather> on the other side i don't run any power management stuff
[12:13] <ogra> (if booting wouldnt take 1h nowadays that would help :) )
[12:13] <thegodfather> just press the reset button :)
[12:13] <thegodfather> that's why we have journal FS'es
[12:13] <thegodfather> ;)
[12:14] <thegodfather> reboot -n -f will do
[12:14] <ogra> time not connected to IO-APIC ... no ACPI in that meassage, i was wrong
[12:14] <ogra> *timer
[12:14] <ogra> well, that speeds up shutdown ... booting is the painful thing here :)
[12:15] <ogra> to quote one of my favorite bugs: the worm on the screen is only 1cm long during boot and stops there for a minute or two *g*
[12:19] <thegodfather> it should be easy to figure the problem
[12:19] <thegodfather> there is only one call to spin_unlock_irq in the whole sunrpc driver
[12:19] <ogra> i wiped the nfs stuff for now ... nothing i  need anyway
[12:21] <thegodfather> and it might not even be a bug in sunrpc at the end
[12:21] <thegodfather> the code didn't change since Aug.
[12:21] <thegodfather> it's probably recalc_sigpending
[12:21] <ogra> did we switch to tickless recently ?
[12:21] <thegodfather> in .22
[12:21] <ogra> ah, well, no probs with .22 
[12:22] <ogra> might indeed as well be the new hal and its powermanagement 
[12:22] <thegodfather> no
[12:22] <thegodfather> this is a kernel bug... userland even if broken should not trigger this kind of OOPS'es
[12:22] <thegodfather> the thing is:
[12:22] <thegodfather> lock()
[12:23] <thegodfather> dononething()
[12:23] <thegodfather> unlock()
[12:23] <thegodfather> and you are getting an OOPS in the unlock
[12:23] <ogra> ah, right
[12:23] <thegodfather> so it might even be the unlock operation to be broken (very unlikely)
[12:23] <thegodfather> or the doonething that corrupts memory
[12:23] <thegodfather> (as an example)
[12:23] <thegodfather> anyway file a bug
[12:23] <thegodfather> the file is net/sunrpc/svc.c
[12:24] <thegodfather> there is only one call to that unlock thingy
[12:24] <ogra> will do
[12:32] <ogra> bug #89224
[12:32] <ubotu> Launchpad bug 89224 in ubiquity "GrubInstaller failed with code 1" [Undecided,Incomplete] https://launchpad.net/bugs/89224
[12:32] <ogra> ??
[12:33] <ogra> oh
[12:33] <ogra> bug #189224
[12:33] <ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [Undecided,New] https://launchpad.net/bugs/189224
[12:33] <ogra> :)
[12:56] <kraut> moin
[16:50] <Kano> hi BenC , lum is still -6 not -7
[16:50] <rtg> Kano: upload are in process. patience.
[16:50] <BenC> so?
[16:51] <Kano> rtg: ok
[16:51] <BenC> Kano: lum can't build until the kernel does
[16:51] <Kano> well it did here already ;)
[16:52] <rtg> BenC: he is pointing out that the git repo hasn't been updated, but I just have been busy this morning.
[16:52] <BenC> ah, gotcha
[16:55] <tseliot> BenC: did you have a look at my suggestions on the wiki?
[16:57] <BenC> tseliot: haven't had a chance yet
[17:00] <tseliot> BenC: I hope we can do this before February 14. Envy works great with my solutions
[17:01] <benje> hello
[17:02] <benje> we have found how to resolv disk detection under kernel 2.6.24 with the fujistu amilio laptop
[17:03] <benje> patko, give the link to the modificated .config please
[17:04] <benje> did we must open bug for this version of the kernel ?
[17:05] <amitk> benje: that would be appreciated, thank you
[17:06] <patko> benje, here is the working .config: http://paste.ubuntu-nl.org/54869/
[17:06] <BenC> Ok, in case people haven't seen: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:06] <BenC> The regular IRC kernel team meeting is in session
[17:06] <benje> amitk, it's need review to stay generic we take off the ide generic support for this is working 
[17:07] <amitk> benje: please attach the config to the launchpad bug
[17:07] <BenC> Agenda is at the URL above
[17:07] <benje> BenC, this is for me ? 
[17:07] <BenC> this is for the channel
[17:07] <benje> amitk, which else file must we post the original dmesg and this for now 
[17:08] <BenC> So a friendly request to hold off on general conversations until after the meeting
[17:08] <amitk> benje: yes. We can continue this after the IRC meeting
[17:08] <benje> ok
[17:09] <BenC> We are going to make this quick, since everyone is fairly busy
[17:09] <king_> ok
[17:09] <BenC> rtg: You've uploaded 7.11 today to fix the build failures in the 6.10 upload...guess we'll know soon if the builds process
[17:10] <rtg> indeed we will
[17:10] <BenC> rtg: since you've been closest with the kernel tree this release cycle...is there anything we should be concerned about with beta coming up?
[17:10] <rtg> some of the virtual features are new, virtio, kvm, etc. They are not part of 2.6.24.
[17:11] <rtg> iwlwifi remains at 1.2.0, but most of the other wireless cards are supported upstream.
[17:11] <rtg> there are some collision issues with legacy v.s. new drivers.
[17:11] <rtg> hopefully, blacklisting in modules-tools-init will help that.
[17:12] <BenC> I noticed the whole b43/legacy/bcm43xx issues...are they resolved now?
[17:12] <rtg> we'll see.
[17:12] <Kano> well it build the module
[17:12] <rtg> I'm sure Kano will let me know if they aren't.
[17:12] <Kano> the b43legacy
[17:12] <Kano> but i really prefer removing the pciids
[17:13] <BenC> Blacklisting is prefered, since it lets the user decide
[17:13] <rtg> black listing is effectively the same.
[17:13] <BenC> removing pci id's hard codes too much
[17:13] <Kano> echo bcm43xx >> /etc/modules
[17:13] <Kano> user decided
[17:13] <Kano> ;)
[17:13] <BenC> if the pci id's are removed, then the module wont bind to the device
[17:13] <Kano> not automatically
[17:13] <BenC> not at all, unless you echo the pci id's into newid in sysfs
[17:14] <BenC> unless you are just commenting out the MODULE_DEVICE_TABLE() in the driver, and that's the same as blacklisting anyway
[17:14] <BenC> but requires us to muck with the source
[17:14] <rtg> There are more issues with bcm then just PCI ids, it also depends on the SSB bus driver.
[17:14] <Kano> only the new one
[17:15] <Kano> well new 2
[17:15] <Kano> b43*
[17:15] <Kano> both depend on ssb
[17:15] <Kano> you could basically even disable bcm43xx
[17:15] <Kano> debian did that
[17:16] <rtg> We aren't gonna do that for now, so lets move on.
[17:16] <BenC> Right, let's hash this out on kernel-team@ where it needs to be
[17:16] <BenC> we know there is an issue, resolving it is beyond the context of the meeting
[17:16] <BenC> rtg: anything else?
[17:17] <rtg> I'm not as familiar with the current bug list as I should be.
[17:17] <rtg> so, there are probably other issues.
[17:17] <Kano> also has anybody else with the 64 bit no splash?
[17:17] <BenC> well, I was looking past the bug list
[17:17] <rtg> yep - I've seen it.
[17:17] <BenC> Kano: off topic...
[17:17] <Kano> thats a kernel issue
[17:17] <rtg> this -7.11 upload is against the 2.6.24 rebase
[17:18] <rtg> so, we'll have a stable code base against which to do our bug shooting.
[17:18] <BenC> rtg: excellent
[17:18] <rtg> thats it from me...
[17:18] <Kano> or kernel config
[17:18] <amitk> rtg: so we will go with upstream ALSA and iwlwifi for Hardy, correct?
[17:18] <BenC> amitk: mobile...you were at the sprint last week...anything we need to worry about with the kernel+beta for them?
[17:19] <rtg> amitk: correct.
[17:19] <amitk> BenC: not really
[17:20] <BenC> amitk: how important is 8.04 and 2.6.24 to UME right now?
[17:20] <amitk> all the mobile code is self-contained in it's flavour patchset and will probably go beyond Hardy
[17:20] <rtg> amitk squeaked in an lpia update this morning moments before I uploaded.
[17:21] <amitk> 8.04 is important to the customer, but schedules are tight and they _might_ not make it. So we will move them to a PPA after Hardy
[17:22] <amitk> rtg: yeah well.. I couldn't get back to sleep at 5am, so I pushed a patch instead ;)
[17:22] <rtg> sounds like jet lag.
[17:22] <BenC> insomnia goes hand-in-hand with last minute kernel patches, hehe
[17:22] <rtg> and FTBSs cause insomnia.
[17:23] <rtg> forgot to mention ndiswrapper updated to 1.52
[17:23] <amitk> rtg: is there anything else (major) that we will switch to LUM and upstream for Hardy?
[17:23] <rtg> nothing on the radar.
[17:25] <BenC> Ok, I think that covers us as far as status right now
[17:25] <BenC> Wanted to get some intros out of the way...joining us from a few weeks ago is Stefan Bader (sbader)...
[17:26] <BenC> stefanb I mean
[17:26] <stefanb> Hi :)
[17:26] <BenC> And just starting with Canonical on the kernel team yesterday is Colin King (king_)
[17:26] <king_> Hi too! :-)
[17:27] <BenC> Both are generalist on the kernel team, and will help handle our main workload for hardy 8.04 and beyond to following releases
[17:28] <BenC> And now some much needed, and usually avoided, discussion on our QA bug list
[17:28] <maks_> left freebsd king_ ?
[17:29] <king_> No.. I haven't touch FreeBsd for 10+ years now
[17:29] <BenC> So anyone who hasn't seen it, ogasawara (who is on the QA team, concentrating on the kernel) maintains this page: http://people.ubuntu.com/~ogasawara/hardy-buglist.html
[17:30] <BenC> It's an excellent starting place for community to work with the kernel team
[17:31] <rtg> It needs serious love for the next few weeks.
[17:31] <BenC> I'm sure ogasawara would appreciate feedback on this page as well (please, don't punish her inbox with requests to get your bug added :)
[17:32] <BenC> Yeah, since 2.6.24 is released, and uploaded, this list is primary focus
[17:32] <ogasawara> feedback would be great.  I suppose I should add a blurb to the top about what the list for anyone new
[17:32] <BenC> The churn is at a minimum now, so stable code base to work from
[17:33] <BenC> ogasawara: something like "Go away if you value your sanity"?
[17:33] <ogasawara> heh
[17:34] <maks_> have you already some nfs patches?
[17:34] <maks_> we have reports that nfs on 2.6.24 is quite buggy
[17:34] <maks_> aka does not sustain load
[17:34] <maks_> both nfs v3 and v4
[17:34] <BenC> ogasawara: One thing we discussed earlier was being more liberal with "Wont Fix" on some of these reports, and working harder to assign and respond to them more quickly
[17:35] <BenC> maks_: is there an open bug report?
[17:35] <maks_> http://marc.info/?l=linux-nfs&m=120220211505693&w=2
[17:35] <maks_> lots of informal reports on channel too
[17:36] <BenC> Ok, we'll investigate that
[17:36] <ogasawara> BenC: so one thing I haven't done in the past few weeks is assign to anyone as I wasn't sure how much work you guys already had on your plates
[17:36] <BenC> ogasawara: that's my fault...I've been slacking on initial processing of your list
[17:37] <stefanb> I normally go forward and self-assign me from that list
[17:38] <BenC> That's good
[17:38] <king_> I probably need some assigning to me to kick off with
[17:40] <BenC> king_: Oh, I can get you started off right :)
[17:41] <king_> BenC: the more the merrier
[17:41] <ogasawara> oh no, famous last words :)
[17:41] <BenC> Ok, let's wrap this up so we can get back to work...any out-of-band issues to bring up?
[17:42] <BenC> excellent...meeting adjourned then
[17:42] <BenC> ogasawara: thanks for joining us on short notice
[17:42] <ogasawara> np
[17:43] <BenC> Thanks everyone, have a great week
[17:44] <stefanb> see you
[17:44] <king_> bye for now
[17:45] <amitk> benje: so please attach the .config to the bug report and add an explanation if necessary
[17:46] <rtg> amitk: ' hardy lpia   Successfully built  (NEW)'
[17:47] <amitk> rtg: ofcourse! you thought I would commit a broken patch at 5am? ;-p
[17:47] <rtg> amitk: and did you think I _didn't_ do a test build just to make sure?
[17:47] <BenC> hehe
[17:47] <tseliot> BenC: when can I ping you again?
[17:49] <BenC> tseliot: let me get some lunch...in an hour?
[17:50] <benje> amitk, ok
[17:50] <tseliot> BenC: ok, thanks :-)
[17:50] <amitk> rtg: :)
[17:50]  * amitk -> groceries
[17:51] <benje> amitk, do you need the old dmesg and the new . we start explain what's happened with std kernel
[17:52] <amitk> benje: add everything that you feel is necessary.
[17:54] <Kano> rtg: when i change version+ rules clean i have got this problem: http://paste.debian.net/48499
[17:55] <rtg> Kano: use 'debuild -b' from devscripts to catch all of the package build deps.
[17:56] <Kano> rtg: all installed, just not the other headers
[17:56] <Kano> i only compile generic
[17:57] <Kano> you have one binary
[17:57] <Kano> utils/mod-dep
[17:59] <rtg> Kano: build problems are outside my area of interest. Its building on the archive, so its right for me.
[17:59] <Kano> rtg: you have too many binaries to build it on etch
[17:59] <Kano> you usually dont need em
[18:00] <rtg> Kano: The hardy release is built within the Hardy environment. That is all I really care about (or am responsible for).
[18:02] <Kano> rtg: call it like you want: this is bad
[18:03] <benje> amitk, there many problem :  boot with gutsy => kernel panic => soluce set noapic ; cd desktop gutsy noapic => no cdrom => must use netboot cdrom ;
[18:05] <Kano> rtg: and: you only need to delete the file
[18:06] <benje> do you think i must separate the post amitk 
[18:06] <Kano> rtg: ubuntu/sound/alsa-driver/utils/mod-deps
[18:06] <Kano> delete it and it will be created when needed
[18:07] <benje> between gutsy and the kernel 2.6.24 ?
[18:08] <rtg> Kano: you're right. How in the _fuck_ did a binary get checked in?
[18:08] <rtg> yhis was a clean checkout from the ALSA HG repo.
[18:09] <Kano> maybe add it in the clean rule extra
[18:10] <rtg> Kano: the original source directory is cloned into a build directory before building. there should not be any binaries to begin with.
[18:17] <Kano> LANG= grep ELF -Rs *|grep Binary
[18:17] <Kano> pretty simple check for binaries
[18:27] <rtg> Kano: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=summary
[18:27] <Kano> fine
[19:19] <tseliot> BenC: are you there?
[19:32] <tjaalton> maks_: client or server? (NFS instability)
[19:34] <amitk> benje: I would restrict the report to Hardy for now, since it is unlikely that this will be fixed for Gutsy
[19:38] <benje> amitk, ok this is quick description with .config http://paste.ubuntu-nl.org/54902/
[19:38] <tjaalton> maks_: seems to be server, so that's probably why I havent seen that
[19:40] <benje> amitk, i take off all about gutsy ;)
[19:41] <amitk> benje: looks good. Make sure to attach the .config as an attachment, not inline text
[19:41] <amitk> benje: and leave the gutsy parts in there, it might help in debugging
[19:41] <benje> ok amitk 
[19:59] <benje> amitk, i found this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/178843 the message is the same for the first boot of 2.6.24 about noapic but not for the same model and not all the same problem . do i post to it or open a new one?
[19:59] <ubotu> Launchpad bug 178843 in linux "kernel panic on boot in kubuntu 8.04 alpa 2 becouse of Apic" [Medium,Triaged] 
[20:00] <benje> must i 
[20:03] <amitk> benje: new bug with a comment listing the other bug number
[20:35] <benje> amitk, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/189368 
[20:35] <ubotu> Launchpad bug 189368 in linux "kernel panic with notebook Amilo Xa 2528 P5811 kernel 2.6.24" [Undecided,New] 
[23:33] <tormod> would be nice if someone could look at, and at least triage/milestone bug #186062. thanks
[23:33] <ubotu> Launchpad bug 186062 in linux-ubuntu-modules-2.6.24 "please update linux-wlan-ng (prism2_usb) to latest upstream version (>=1847)" [Undecided,New] https://launchpad.net/bugs/186062
[23:46] <rtg> tormod: from here? linux-wlan-ng-0.2.8/src/prism2/driver
[23:46] <tormod> rtg: no, from svn. Where do you document where the code comes from?
[23:47] <rtg> tormod: I didn't do this one. the previous guy didn't leave any tracks.
[23:47] <tormod> bad guy ;) svn://svn.shaftnet.org/linux-wlan-ng/trunk
[23:48] <rtg> tormod: put the svn URL in the LP report so we can remember it.
[23:48] <tormod> ok
[23:48] <tormod> what about Ubuntu changes, are they documented beside the commit comment?
[23:49] <rtg> tormod: I'll put a BOM file in the prism2_usb directory (Bill of Materials)
[23:51] <tormod> anyway, the only Ubuntu changes I could see by looking at the git history, are included upstream.
[23:51] <tormod> s/only//
[23:53] <rtg> tormod: does it need an updated p80211 ?
[23:53] <tormod> yes, they are hand in hand
[23:54] <tormod> p80211 was supposed to be something general for several drivers, it ended up in monogamy with prism2
[23:55] <tormod> I think l-u-m used to have p80211 as a subdir of prism2 or the other way around.
[23:59] <rtg> tormod: ok, test building.