[02:41] <pace_t_zulu> hey guys
[02:41] <pace_t_zulu> is it true there is a kernel freeze tomorrow?
[02:42] <crimsun> yes, but in effect it's already in place
[02:50] <pace_t_zulu> crimsun, are you aware of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/535297 ?
[02:50] <ubot3> Malone bug 535297 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000000000000028" [High,Confirmed] 
[02:51] <pace_t_zulu> Malone?
[03:48] <EruditeHermit> hello, can anyone help me with this error?
[03:48] <EruditeHermit> http://pastebin.com/Hnriax64
[04:09] <EruditeHermit> apparently its a bug with kernel package
[04:21] <netritious> Hi, is it possible to obtain the linux-headers packages for kernel version 2.6.32-15 ? They appear to be unavailable in the repository, but they are needed to workaround an issue a few are having with 2.6.32-16 and VBox.
[13:23] <apw> pace_t_zulu, Malone is the name of the launchpad software
[13:24] <apw> pace_t_zulu, ubot3 can translate other bug numbers scemes like CVE numbers and so prefixes its results with where it found things
[13:39] <pace_t_zulu> apw: thank you
[13:45] <smb> cking, So what other things. beside suspend resume can cause a tsc warp`
[13:45] <smb> ?
[13:45] <cking> smb, not sure what triggers it, but I've seen it on Atoms - you sometimes see TSC warp warnings.
[13:47]  * cking tries to think back 12+ months ago when he observed TSC issues on a N270.. hrm.. bit fuzzy
[13:47] <smb> Are those the that messages with -<huge number> marking tsc unstable?
[13:47] <cking> no - just small warping
[13:48] <cking> big warp only observed when coming out of S3
[13:48] <smb> Cause there is also the "Marking TSC unstable due to halts in idle", but probably thats the clocksource framework and not the things you looked at
[13:48] <apw> smb, the "two ack rule" things count as having two acks if they are sent by a core-committer and acked by one other ... right?
[13:49] <smb> apw, Usually not later. For now we could go with it
[13:49] <apw> rtg i've pushed qcm-msm branch into linux-meta ... you'll have to upload it the first time i guess
[13:50] <smb> apw, Thats why I usually pester two of you guys when I got a patch. :)
[13:50] <tgardner> apw, k
[13:50]  * apw pesters smb to look at tgardner's patch
[13:50] <apw> tgardner, i'll get the other one done now
[13:50] <cking> smb, if I recall, it's most probably an unstable TSC as reported by arch/x86/kernel/tsc.c
[13:50] <tgardner> apw, the patch for -virtual ?
[13:51] <smb> cking, Oh, so warp not only means warping around to 0 but also going faster forward or even back?
[13:51] <smb> apw, tgardner was busy which one
[13:51] <apw> tgardner, yeah am getting smb to review that
[13:52] <cking> warp to zero --> wrapping,  warping where TSC seems to jump back/forwards in a manner that's not expected
[13:53] <tgardner> cking, do you suppose that happens when ACPI is reefing on C states as well as S states?
[13:54] <cking> tgardner, can't say for sure, but it may be possible for C states too to affect it
[13:54] <tgardner> cking, that would make TSC well nigh unusable
[13:55]  * cking agrees
[13:55] <smb> It seems to be clear that tsc can halt in C states
[13:56] <cking> smb, have we any evidence of that - perhaps we need to get a script that tests for this
[13:56] <smb> cking, So that my problem. I havn't looked for some time but I thought that tsc is usually replaced by hpet for timer events
[13:57] <cking> smb, maybe so, but TSC does seem to be used for udelay by default if I understand the code correctly
[13:58] <smb> Right, probably we look/think of different usages
[13:59] <cking> ..hopefully not missing any out
[13:59] <smb> One thing is the clockevents framework for the monotonic and also the waking up/timer events (unfortunately its quite some time I looked at that code)
[14:01] <cking> if the only good reason for using the TSC is lower-latency in udelay then maybe an alternative mechanism in udelay can be used and we ditch the TSC
[14:11] <Q-FUNK> smb: it seems that AMD decided to get involved and contact the FIC engineering team themselves to solve bug #396286.  
[14:11] <ubot3> Malone bug 396286 in linux "[Geode LX] [ION603] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[14:11] <Q-FUNK> one thing I'm wondering:  what tools do we have to probe the BIOS and print the manufacturer and build date, etc.?
[14:12] <smb> Q-FUNK, sudo dmidecode
[14:12] <smb> It would be nice to have someone look at that with some low lever hw information
[14:12] <smb> Cause it looks like from a sw point of view I don't get farther
[14:15] <Q-FUNK> smb: I suspected as much. Thanks for trying.
[14:16] <smb> Q-FUNK, I hope at least the information we have can help there
[14:16] <Q-FUNK> at least, the good news is that AMD considers what's left of the Geode market to be wrothy of salvaging enough to contact FIC themselves.
[14:16] <Q-FUNK> hopefully, yes
[14:17] <Q-FUNK> and it indeed seems that otavio was correct when he said that none of his other Geode hardware showed the symptoms.
[14:19] <Q-FUNK> the program manager for AMD's embedded chips appologized on behalf of AMD, especially for the downfall of laying off Jordan Crouse, back then, and for having momentarily left Geode support in Linux and X.org in limbo.
[14:20] <Q-FUNK> they now have one guy in US and a whole team in Taiwan working on both issues.
[14:20] <smb> sweet
[14:20] <Q-FUNK> they're barely coming up to speed on the basics of e.g. using git, but I have a feeling that it's only a question of time before things fall back into place.
[14:21] <Q-FUNK> my only worry is whether any of those issues will be fixed on time for Lucid's release or not.
[14:21] <Q-FUNK> I'd rather avoid the situation we had with the X driver on Hardy having to be resucitated after Hardy was released, but well...
[14:23] <smb> It would have to be really fast to hit Lucid release. On the (maybe not  completely satisfying) side at least LTS gets a few point updates which rebuilds cd's
[14:24] <apw> smb, in the first bit of good news of the day ... i plugged and external monitor into my lucid box and it didn't GPU hang on me ... so we do have the fixes :)  you are on there now
[14:24] <smb> apw, \o/
[14:24] <Q-FUNK> \o/
[14:25] <apw> actually i've missed having IRC always visible
[14:25] <apw> amitk, in mutt-patched how often do the stats on the left update ?
[14:25] <Q-FUNK> apw: you position your IRC app in the second display?
[14:26] <apw> Q-FUNK, i have today ... its 'only' 1280x1024 so too small for working on
[14:26] <amitk> apw: you mean the unread count?
[14:26] <apw> amitk, yeah the numbers over there
[14:27] <amitk> apw: only when I move my 'cursor'
[14:27] <amitk> or open another mail folder
[14:27] <apw> as in C-n C-p in that left panel
[14:27] <amitk> right
[14:27] <apw> cool better than not seeing them
[14:27] <amitk> you don't see them?
[14:28] <Q-FUNK> apw: I wonder if I can do the same on this laptop running -intel.  when I'm at home, I'd love to slide specific apps on a separate display.
[14:28] <apw> no i do, i mean them updating only when i take action is better than not seeing them at all as i was without -patched
[14:28] <apw> Q-FUNK, works for me, this is a laptop.  added external, ran xrandr, and poop my desktop got wider
[14:29] <Q-FUNK> apw: interesting.  do you get separate desktops or just one large virtual desktop area?
[14:29] <apw> in the bad old days i used the 'tiny' laptop screen for irc et al and my 'huge' monitor for work ... but now my internal is bigger ...  
[14:29] <apw> all one desktop you can have windows spanning the break
[14:30] <Q-FUNK> hm.  ok. any way to have separate desktops, like in the old days?
[14:30] <Q-FUNK> IIRC with xineramara we had separate desktops.
[14:31] <apw> its not the default, i am sure its possible somehow, you'd have to ask on #u-x
[14:31] <apw> as this is what i wanted, i am not moaning
[14:33] <Q-FUNK> :)
[14:33] <Q-FUNK> hm.  due to the timezone difference, my e-mail exchanges with AMD Taiwan are pracically real-time.  pity their firewall prevents them from using IRC.
[14:42]  * apw reboots to test a kernle
[15:03] <tgardner> apw, strange install problem on Karmic when installing a Lucid kernel: 'linux-image-2.6.32-16-server depends on binutils (>= 2.20.1)'
[15:04]  * apw blinks
[15:04] <tgardner> its not like we're still doing dynamic linking
[15:05] <apw> tgardner, /me investigates
[15:06] <apw> tgardner, is that a binary from the archive or one you made
[15:06] <tgardner> apw, from my archive mirror
[15:06] <smb> apw, Could that be because of linux-tools?
[15:06] <tgardner> linux-image-2.6.32-16-server_2.6.32-16.25_amd64.deb
[15:07] <tgardner> smb, linux-tools is a 'suggests'
[15:07] <apw> smb, linux ... what he said
[15:07] <apw> tgardner, i don't have that dep on a local build
[15:08] <smb> apw, In one of my past attempts I was unable to install the kernel image without linux-tools
[15:08] <apw> tgardner, can you less the package and paste your Depends: line
[15:08] <apw> smb, yeah it changed
[15:08] <tgardner> apw, Depends: binutils (>= 2.20.1), binutils (<< 2.20.2), libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
[15:09] <tgardner> its gotta be from ${misc:Depends}, ${shlibs:Depends}
[15:09] <apw> wtf ? _two_ binutil depends
[15:09] <apw> tgardner, which is the problem one ?
[15:09] <tgardner> pretty tight constraints :)
[15:10]  * apw wonders why i have none on my local builds ... arrrg
[15:10] <tgardner> binutils (>= 2.20.1)
[15:11] <tgardner> we kind of have to figure this out lest it raise hell with the kernel backports
[15:11] <apw> well actually i suspect if you build it in a karmic chroot it'll be fine
[15:12] <tgardner> apw, ok I'll do that
[15:12] <tgardner> which is really the right solution anyway
[15:12] <apw> yeah we would be building them there .. but why do we have such tight contraints from that
[15:13] <tgardner> apw, I think its coming from the wildcard dependencies. I'll have to read up on them
[15:14] <tgardner> apw, while we're at it, we should reexamine the 'Provides:' boilerplate. most of that stuff is no longer accurate.
[15:16] <apw> tgardner, annoyingly for the linu-image package i put both those general defs together so we cannot tell by the position of the deps if some is from one or the other
[15:16] <apw> but i suspect it is cause of the perf binary in there, it is tying us to the current binutils version
[15:16] <apw> tgardner, i am starting to think it needs to come out into its own package
[15:17] <tgardner> apw, right, but as you've pointed out the backports will get build in a Karmic environment anyways
[15:17] <apw> into linux-tools flavour package
[15:17] <apw> yeah. makes testing kernels on the wrong series a lot harder though
[15:17] <tgardner> indeed
[15:17] <apw> to it might make sense to pull it out to its own package
[15:17] <apw> i will have a look how horrid that would be
[15:18] <tgardner> yeah, its not like there is any real binutils dependency, is there? initrams doesn't use it, right?
[15:18] <apw> nope ... its just cause of the binary i am sure ... perf
[15:19] <apw> i'll pull it out and see if the deps get better
[15:19] <apw> tgardner, what is a bit whack is my local builds have different deps:
[15:19] <apw>  Depends: libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
[15:20] <apw> they would preclude install on karmic too, but they arn't the same which is most wack
[15:20] <tgardner> why is the buildd different?
[15:20] <tgardner> apw, could be we're just tilting at a windmill here
[15:21] <apw> yeah i am not sure
[15:21] <apw> i guess i need to review that chroot and rebuild it
[15:22] <apw> i'll go split it out and we can see how it looks
[15:23] <apw> it didn't seem sensible to have a separate package for one bin kernel version locked, but these deps will hurt our testing and so its prolly worth the pain
[15:24] <tgardner> apw, yeah, but linux-tools doesn't have an ABI so how will you keep perf in sync?
[15:24] <apw> linux-tools is the binary independant bits
[15:24] <tgardner> oh, you mean a separate package just for perf?
[15:24] <apw> we'd ahve to have a kernel matches binary package for the tool  linnux-tools-15-generic, move linux-tools to linux-tools-common
[15:25] <apw> and have a linux-tools meta package
[15:25] <apw> yeah thats the proposal.  i thought i'd try it and see how vile it was
[15:25] <tgardner> what a pain in the ass
[15:25] <apw> yeah... it probabally would have been the 'right' way to do it, we were lazy and it bites us on the ass
[15:44] <manjo> apw, smb brb
[16:10] <tgardner> apw, so, a Lucid kernel installs better when built under Karmic
[16:10] <apw> good
[16:10] <tgardner> now lets see if it withstands a stress pass
[21:48] <cnd> apw: you remember anything that went in -16 that would cause bug 536858?
[21:48] <ubot3> Malone bug 536858 in linux "USB-Audio devices do not show up as input devices" [Low,Invalid] https://launchpad.net/bugs/536858
[21:51] <cnd> apw: nm, reporter invalidated the bug
[23:12] <Ng> are we aware of any virtio problems in lucid atm? I've been trying to install the alpha 3 iso image inside a virtio kvm on my lucid laptop and it gets to the package installation bit and ends up IO erroring itself read-only
[23:14] <daftykins> hi all, please excuse the newbie question... will Lucid be sticking with the 2.6.31 kernel through release and further?
[23:15] <RAOF> No; it will be sticking with the 2.6.32 kernel though.  There are plans to pull newer kernels in post-release, but I don't know details of that.
[23:16] <daftykins> ah yes my bad, typo/memory failure :) ah ok, thanks very much :)