=== asac_ is now known as asac
[01:47] <matjan> hi, over the past couple of days i have been experiencing system crashes... but but no messages were left in the logs... i am using hardy with the 2.6.24-19 kernel
[01:47] <matjan> however, yesterday, something was logged
[01:47] <matjan> let me post quickly one line here: 
[01:47] <matjan> Aug 12 11:32:30 quadpc kernel: [101268.517063] Pid: 11524, comm: hadam3_um_5.03_ Tainted: P    B D (2.6.24-19-generic #1)
[01:48] <matjan> this is followed by 40 (or so) more messages and then it stops with: ==================
[01:49] <matjan> not sure if i can ask about this problem here...
=== rikai_ is now known as rikai
=== foka_ is now known as foka
[04:27] <RAOF> It seems the interactive performance has dropped a lot under heavy IO, certainly from Hardy's kernel.  In particular, reading the dpkg database can interrupt Banshee/gstreamer/pulseaudio's music for multiple seconds, and make the UI unusable for the duration of the read.  What's the best way of debugging this?
[04:28] <RAOF> I could build the kernel from Ubuntu git and try to bisect, but it'll take quite some time to actually test each build, so it'd be good if someone had a guess as to where to start :)
[05:03] <pwnguin> scheduling policy
[05:15] <pwnguin> RAOF: in hardy, you might notice from time to time that high disk i/o messes with input
[05:16] <pwnguin> apt operations seem to trigger key repeats
[05:17] <pwnguin> something about group scheduling polcy
[05:17] <RAOF> I didn't so much notice that.
[05:17] <pwnguin> a friend of mine got rather angry at Ubuntu over it, up until debian had similar problems
[05:21] <lifeless> lol
[05:21] <pwnguin> same with firefox
[05:22] <pwnguin> those Ubuntu developers! always breaking my stuff. thats it, i have to go back to debian if I want a working computer
[05:22] <pwnguin> *24 hours later*
=== thegodfather is now known as fabbione
[11:46] <Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-pv_lock_ops-fix.patch
[11:47] <Kano> could somebody push that upstream? it is a needed fix for 3d drivers + paravirt
[11:56] <amitk> Kano: BenC already told you we would not do anything to work around GPL symbols
[11:56] <Kano> but thats a newly introduced error
[11:56] <Kano> it was not there in 2.6.26
[11:56] <Kano> if you ignore that ship 8.10 without nvidia+fglrx drivers
[11:57] <Kano> i am pretty sure nobody will use it then
[11:58] <amitk> Kano: besides, why don't you email it to lkml? :)
[11:58] <Kano> dont like mailinglists, never liked that
[11:59] <amitk> Kano: i think you can post to LKML through a web interface, no subscription necessary.
[11:59] <Kano> you can read it
[12:03] <amitk> Kano: http://www.kernel.org/pub/linux/docs/lkml/#s3-3
[12:03] <amitk> There, now you can post to the list directly.
[12:31] <mjg59> Kano: The only people who will apply that patch are upstream, so.
[12:47] <Kano> well i will not write mail, just do it
[12:47] <Kano> bye
[13:03] <laga> Kano rocks.
[13:05] <amitk> laga: he does indeed
[13:10] <laga> so, how do i submit patches against the ubuntu kernel?
[13:10] <laga> assuming i've got them in my git tree
[13:10] <benje> hi is ther is planed to set memory to 64 in generic kernel to handle all memory and swap of recent conmputer .
[13:11] <mjg59> benje: Use a 64-bit kernel or the server kernel
[13:11] <mjg59> benje: Supporting PAE results in a performance hit
[13:11] <benje> mjg59, oki thanks 
[13:12] <laga> ooh, i found some documentation in the wiki
[13:23] <laga> i guess it's a bit too late now to use the commit templates :(
[13:25] <laga> is it absolutely necessary to have the signed-off-by line in all commits?
[13:32] <laga> ooh, git-gui.
[13:47] <amitk> laga: Signed-off is mandatory to establish provenance of the code
[13:48] <laga> ok. i've found out how to add it to existing commits
[13:48] <amitk> laga: sending each commit as an attachment to a separate email is good. If you have lots of patches, you can point to your git tree.
[13:49] <laga> hum. i don't have lots of patches, but i'm lazy so i'll just upload my tree.
[13:50] <amitk> laga: if they are patches to various drivers , it would be nice to have detailed explanations in the patches themselves
[13:50] <laga> no, it's just a proper aufs tree
[14:26] <soren> BenC: Do you think you can explain what needs to happen for virtio-net to be available in the installer (without having to install additional udebs)?
[16:37] <BenC> soren: I can split up the modules into the general udeb's...otherwise, you would need to ask cjwatson how things work in the installer
[16:37] <BenC> soren: maybe it can detect that it is running in a vm and automatically request the right udeb
[16:38] <BenC> amitk, rtg, smb_tp: Preparing an intrepid upload...anything you guys working on right now that I should hold off for?
[16:38] <soren> BenC: I think we ship much, much more esotric modules in the general udeb's as it is.
[16:38] <soren> BenC: I have a patch for Intrepid, actually.
[16:39] <smb_tp> BenC, nope
[16:39] <BenC> soren: patches are good :)
[16:39] <rtg> BenC: Mario pointed out that Broadom ain't working in LRM, so I need to look at that.
[16:39] <soren> BenC: Indeed they are. :) Gimme a minute.
[16:39] <rtg> Intrepid LRM (that is)
[16:40] <BenC> rtg: I'd say that's an incorrect statement, since I was just using it last week :)
[16:40] <rtg> BenC: I'm good with that :)
[16:41] <BenC> rtg: which reminds me, that I and some one else confirmed that the wl driver has a bug which prevents it from allowing wan connections behind a NAT AP
[16:41] <rtg> BenC: I remember seeing that. How can a MAC layer driver mess up a NAT connection?
[16:41] <BenC> rtg: b43 works fine, so it's definitely the wl driver's fault
[16:42] <BenC> rtg: does wl have it's own IP stack too?  :)
[16:42] <rtg> BenC: I wonder if ti's truncating the MTU. (It is a full MAC driver)
[16:43] <BenC> rtg: I didn't get far enough with testing it to see where the packets were being dropped...maybe I'll have some time another day to run ethereal on it
[16:43] <BenC> rtg: MTU was some one else's guess too
[16:44] <BenC> I'd have to see the packet to know what's going on, and I really hate spending time on it considering I can't fix it
[16:44] <BenC> rtg: Can you email me the broadcom contacts?
[16:44] <rtg> BenC: NAT packets aren't wrappered, they just get the return IP and port number swizzled after trhe routing decision.
[16:45] <BenC> rtg: right...I'm kind of thinking that either the AP is ignoring the packets from some odd reason, or the swizzling is causing wl to ignore the return packets
[16:46] <rtg> BenC: all that happens in IP. The AP is a layer 2 MAC bridge.
[16:46] <BenC> rtg: the fact that it works to LAN machines _AND_ that it only affects some applications is making it even more weird
[16:46] <BenC> rtg: e.g. mozilla works fine, elinks works fine, but telnet to port 80 doesn't
[16:47] <BenC> rtg: and ssh doesn't work
[16:47] <BenC> so it seems to have something to do with packet size
[16:47] <BenC> I think ssh and telnet limit to 512 bytes
[16:47]  * amitk looks up yet another Tim'ism - swizzle. And it surprised to find it in the Jargon File!
[16:47] <BenC> amitk: swizzle sticks dude
[16:47] <rtg> amitk: what? You think I invented it? huh.
[16:48] <amitk> heh
[16:48] <BenC> wget doesn't work either, IIRC
[16:48] <rtg> BenC: Broadcom POC info emailed.
[16:48] <BenC> rtg: thanks
[16:49] <BenC> I wonder if it may have something to do with tcp windows...I can at least swizzle that in sysctl ;)
[16:49]  * BenC honors the new word-of-the-day
[16:49] <soren> sysctl? :)
[16:49] <amitk> BenC: the wl driver should not know anything about the NATing.. that would happen at the gateway
[16:49] <rtg> BenC: as you said, no use spending time on something we can't fix.
[16:49] <BenC> amitk: it shouldn't...but it doesn't happen across a straight route...only over NAT
[16:50] <BenC> amitk: and confirmed with two different b43 cards, and two different AP's
[16:50] <BenC> so we can't even blame the NAT stack on the AP
[16:50] <rtg> BenC: are the APs simple bridges, or do they have routing built in?
[16:50] <amitk> BenC: played with 'iwconfig frag' ?
[16:51] <BenC> rtg: mine is routing...I don't know about the other
[16:51] <BenC> mine is a wrt54g with dd-wrt firmware
[16:51] <BenC> the other was a stock cisco AP
[17:00] <BenC> rtg: email sent, CC'd you
[17:01] <soren> BenC: Patch sent to kernel-team@l.u.c
[17:02] <soren> BenC: Ok, as I was saying: I don't think keeping virtio modules in a udeb by themselves is justified (if that requires people to do more stuff in the installer to make it work).
[17:04] <BenC> soren: But is it possible to have that udeb automatically selected based on the environment?
[17:04] <soren> For KVM, yes.
[17:04] <soren> (other virtualisation things will be offering virtio devices soon, too)
[17:05] <soren> BenC: Oh, er..
[17:05] <soren> WEll, yes, we can look at the presence of certain PCI id's.
[17:05] <soren> That should always work.
[17:06] <soren> Just to reiterate: You removed them from nic-modules to keep netboot images smaller. Right?
[17:07] <BenC> soren: right
[17:07] <soren> So how am I supposed to netboot kvm guests?
[17:07]  * soren might be missing something here..
[17:08] <BenC> soren: well, it can netboot...just might not be able to do the install :)
[17:08] <BenC> soren: this probably should include someone who works on d-i
[17:08] <BenC> soren: since I only know a trivial amount about this
[17:08] <BenC> soren: does kvm/qemu even support PXE boot?
[17:09] <soren> I'm just desperately trying to work out why specifically virtio was removed from nic-modules and not one of the many other ones.
[17:09] <soren> BenC: Sure. It has done so for ages.
[17:11] <BenC> soren: I'm personally at a disadvantage to defend that decision, I just know that for netboot, things need to be kept small
[17:12] <soren> BenC: Oh, I thought you were the one who decided it should be that way. The commit had your name on it, I believe :)
[17:13] <BenC> soren: I did decide it, but soley based on what udebs/netboot was meant for :)
[17:16] <soren> So I should talk to cjwatson, I presume?
[17:17] <BenC> soren: clflush commit pulled into intrepid
[17:17] <soren> Thanks very much.
[17:17] <BenC> soren: cjwatson is probably best
[17:17] <BenC> soren: if I can get a clear definition of what should and shouldn't go into udeb's, it would make life remarkably easier for all of us
[17:18]  * soren makes a note
[17:18] <soren> Ok, thanks
[17:26] <mkrufky> is there a command that i can ask a user to do that will tell me if he is running hardy32 or hardy64 ?
[17:26] <laga> uname -a?
[17:26] <mkrufky> obviously i can have him look at /proc/cpu , but i am not sure if that is definitive to determine that running flavor, versus cpu capability
[17:26]  * smb_tp damn, too late ;-)
[17:27] <rtg> uname -m
[17:27]  * smb_tp curses tiny laptop fonts. 
[17:27] <smb_tp> mkrufky, right uname -m ist the one
[17:29] <amitk> uname only tells about kernel, dpkg-architecture will tell about userspace too
[17:29] <smb_tp> mkrufky, dpkg-architecture will show which ... ok
[17:30] <rtg> BenC: pushed Intrepid patch
[17:30] <mkrufky> awesome ... thanks to both of you
[17:30] <mkrufky> looks like dpkg-architecture is what i needed
[18:36] <cody-somerville> Hey
[18:36] <cody-somerville> Did we ever get compcache spec done?
[20:36] <mkrufky>  is anybody here going to the Linux Plumbers conference?
[20:36] <mkrufky> http://www.linuxplumbersconf.org
[20:44] <rtg> mkrufky: all of the Canonical/Ubuntu kernel dev team will be there.
[20:45] <mkrufky> ah, great!
[21:44] <Ampelbein> Could someone please have a look at bug #163236? The ipw3945-driver is deprecated and all development has gone to the iwlwifi-project. So I think this bug can be set to "Won't fix"? Can somebody with the correct rights check that out, please?
=== rikai_ is now known as rikai