[00:10] <tupi> hello kernel experts
[00:11] <tupi> running debian on HP all-in-one omni 200 PC, had problem and it has been identified and apparently solved, but i can't find that the solution has been integrated in debian yet
[00:12] <tupi> here is the link i am refering to: https://bugs.freedesktop.org/attachment.cgi?id=56796
[00:13] <tupi> actually this link probably informs better: https://bugs.freedesktop.org/show_bug.cgi?id=43171
[00:13] <ubot2`> Freedesktop bug 43171 in DRM/Intel "[ILK] LVDS attached to !mobile left unlit" [Normal,Resolved: fixed]
[00:14] <tupi> well, i have just tried and downloaded the source of even the experimental 3.3 kernel [debian] and the solution is still not included
[00:14] <tupi> i have just tried and downloaded the source of even the experimental 3.3 kernel [debian] and the solution is still not included
[00:15] <tupi> the guy [Daniel Wolff] said he created debs packages, but i can't access the repository
[00:16] <tupi> probably was temporary ...: http://www.rapido.net.br/debs_hpomni200/
[00:18] <tupi> anyway, any one has an idea how I could try to solve my problem ? 
[00:34] <psusi> where does update-initramfs -u get its idea of what kernel version to update?  it keeps trying to update for 3.2.0-rc3+, which I no longer have installed
[00:34] <psusi> ( nor am currently running )
[00:43] <infinity> psusi: /var/lib/initramfs-tools/
=== JanC_ is now known as JanC
=== bladernr_afk is now known as bladernr_
[06:45] <dupondje> Weird, every time on startup my wifi is disabled by rfkill: [   26.182093] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio.
[06:45] <dupondje> is that a bug in Precise ? :s
[08:17] <apw> yay ... 140 updates
[08:19] <smb> apw, And it seems still working. :)
[08:20] <apw> they only just started installing so we shall see
[08:22] <smb> apw, Already booted into it
[08:28] <apw> smb ahh ok :)
[08:28] <apw> libreoffice is a huge pig
[08:38] <apw> smb, remind me to remove virtualbox too .. its rebuilding for every one of my 20 installed kerneles
[08:39] <apw> smb, and to remove all the 'spare' kernels i have
[08:39] <smb> apw, Maybe removing some of those 20 may be a good idea too
[08:39] <smb> apw, agree
[08:39] <smb> apw, You wanna my script
[08:39] <apw> smb, /me wanna your script
[08:40] <smb> apw, will be on chinstrap in a sec
[08:40] <apw> ta
[08:41] <smb> cleanup-kernels
[08:43] <smb> apw, Its written in a way to emmit command line to be piped into another shell
[08:43] <apw> smb, heh thats what i was about to change it to do, until i discovered thats what it did :)
[08:43] <smb> apw, I like to verify its sanity each time i run it
[08:44] <apw> Traceback (most recent call last):
[08:44] <apw>   File "/home/apw/brief/bin/cleanup-kernels", line 67, in <module>
[08:44] <apw>     kernel_list.sort(cmp=cmp_kver)
[08:44] <apw>   File "/home/apw/brief/bin/cleanup-kernels", line 52, in cmp_kver
[08:44] <apw>     if int(v1[n]) < int(v2[n]):
[08:44] <apw> IndexError: list index out of range
[08:44] <smb> apw, O dear, could be one version that worked for now... I think I had fixed that somewhere
[08:45]  * apw debugs
[08:45] <smb> apw, Think it was just some specail kernel 
[08:45] <smb> like -pae
[08:45] <smb> which tends to mess up the logic to decide which is version
[08:46] <apw> ['3', '0', '0']
[08:46] <apw> possibly that one
[08:46] <smb> would look ok for a version...
[08:46] <apw> smb, all the others are 4 digits
[08:47] <apw> ['3', '0', '0', '15']
[08:47] <smb> ah ok
[08:47] <smb> you have -pae there?
[08:47] <apw> smb, no, though i can also see that this would get that wrong too
[08:47] <apw> un  linux-image-3.0                                       <none>                                                (no description available)
[08:47] <apw> i think its that one
[08:48] <smb> apw, weird cause it starts by looking at vmlinux-* in /boot
[08:48] <apw> a test kernel way back when we were testing the different lengths for the name
[08:48] <apw> vmlinuz-3.0-0-generic
[08:48] <apw> an invalid package in the real scheme
[08:49] <smb> hm, hows a vmlinux file there when the package is un installed?
[08:49] <apw> who can say with dpkg
[08:49] <smb> ok, yeah and with the vmlinux file being different/wrong... bah
[08:50] <apw> smb, i can purge that one anyhow
[08:50] <smb> apw, Right, I bet dpkg -S will fail to find its source too
[08:51] <apw> smb, un is unpacked no errors ... and i can't purge it either
[08:51]  * smb tries to hide
[08:52] <apw> smb, actually no its, unknown not
[08:52] <apw> which is even less helpful
[08:52] <smb> ahm, yes
[08:52] <smb> dpkg --forget
[08:52] <smb> (not that that exyists)
[09:10] <apw> ok time to reboot and see if i make it
[10:31] <brendand> i've a system that has 8Gb of RAM installed (2x2GB + 1 4GB) and it's running -pae, but only 4GB are showing in MemTotal
[10:31] <brendand> this is on Oneiric
[10:35]  * cking --> on the phone with Lenovo :-/
[10:36] <cking> hoping his x220i will be fixed someday 
[10:37] <brendand> could this be a kernel issue or should i look for something else first? dmidecode shows all the memory
[10:37] <brendand> the CPU is an i5
[10:39] <cking> brendand, is this new kit, or has it just started failing?
[10:39] <brendand> cking - well, we've only just introduced a test to actually check this so it's hard to tell. the system is just over a year old
[10:40] <brendand> cking - is there something in dmidecode that could indicate a cell is 'unusable' or suchlike?
[10:45] <brendand> cking, i see what this is now. it's a test script deficiency (obviously)
[10:45] <brendand> cking, the 4GB 'Memory' device is a ROM chip
[10:46] <brendand> cking, i guess the script should only look for 'SIMM' and 'DIMM' form factor devices...
[10:46] <cking> brendand, you are trusting DMI data to be correct?!
[10:47] <brendand> cking, i wouldn't say 'trust'
[10:48] <brendand> cking, i am of course treating all these 'problems' with a large pinch of suspicion
[10:51] <cking> ;-)  Well, for memory layout maybe /sys/firmware/memmap is more helpful
[10:58] <brendand> cking, how to parse that though?
[11:00] <cking> brendand, http://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
[11:02] <brendand> cking, and that's more accurate than meminfo, or dmi? (i.e. which one would it replace?)
[11:02] <cking> what's meminfo?
[11:06] <cking> brendand, it depends on what you want to test, do you believe what the firmware is telling you (e.g. BIOS e820 memory info) or DMI tables (which could be lying) or both, or the kernel got it wrong
[11:06] <brendand> cking, i would believe that at the very least dmi is not fabricating non-existent memory chips 
[11:07]  * brendand please god let that assumption be true!
[11:07] <cking> brendand, cking's first rule of computing: assuming nothing
[11:07] <cking> oops, I meant: "assume nothing"
[11:08]  * brendand 's first rule of testing "trust but verify"
[11:10] <cking> brendand, that's where you're going wrong, trust nothing, it's always broken or lies to you
[11:11] <brendand> cking, we'd never get any testing done then :)
[11:13] <brendand> cking, what i'm saying is that i know there's a potential for false positives here , but we can try and iron out most of them and deal with the cases where we're being flat out lied to individually
[11:19] <brendand> it's no good to just say 'i refuse to test this because the data i have could be unreliable'
[11:22] <brendand> cking, on to another case. i also have a system which has a single 2GB DIMM and MemTotal is only mentioning about 1.5GB of that. I've heard graphics cards can take some of the RAM as video memory. is there a way to find out if this is the case?
[11:22] <brendand> and if so, how much has been taken
[11:22] <brendand> ?
[11:28] <lamont> Mar 20 05:28:21 wfg-gw kernel: [36992.811181] nf_ct_sip: dropping packetIN=eth0 OUT= MAC=00:0e:0c:5c:1c:78:00:0c:85:be:5a:85:08:00 SRC=192.168.133.192 DST=192.168.133.1 LEN=588 TOS=0x10 PREC=0x40 TTL=64 ID=27042 PROTO=UDP SPT=53122 DPT=5060 LEN=568 
[11:28] <lamont> make it stop screaming (3.2.0-19 still doesn't like cisco sip phones)
=== chrisccoulson_ is now known as chrisccoulson
[12:17] <dupondje> Weird, every time on startup my wifi is disabled by rfkill: [   26.182093] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio. Thats a bug or something known ?
=== bladernr_ is now known as bladernr_afk
[13:22]  * apw lunches
[13:45] <Teduardo> Howdy, any chance that we'll see support for Broadcom 5720 QP put into the 10.04 LTS?
=== bladernr_afk is now known as bladernr_
[13:57] <smb> lamont, Would that not be something that ufw needs to be teached? I believe that it is not the kernel as is but the firewall logging policy that produces those.
[14:21]  * apw is now tired
[14:24] <smb> Just now :)
[14:24] <smb> apw, From swimming after lunch or a lot of lunch?
[14:31]  * ogasawara back in 20
[14:34] <apw> smb, from swimming
[14:35] <smb> apw, Well done. At least something that feels like an achievement
[14:40] <smb> ogasawara, Looks like you are preparing to tie up another upload. Is it possible to delay that, still? Just got some feedback from cjwatson about the d-i change and he'd prefer some additional change
[14:56] <apw> smb, d-i change ?
[14:57] <smb> apw, I just submitted one this morning to include the dm-multipath module. But it would be more consistent with debian installer otehrwise to have that (and dm-round-robin) in a multipath udeb instead of the md
[14:58] <apw> smb, ahh ... yeah
[14:58] <apw> ogasawara, the good thing is the test builds likelly don't test those anyhow, so no need to redo them
[15:04] <apw>     Block: use a freezable workqueue for disk-event polling
[15:04] <apw>     
[15:04] <apw>     commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.
[15:04] <apw> smb, ^^ i wonder if that could be the sd_revalidate issue
[15:05] <apw>     block: fix __blkdev_get and add_disk race condition
[15:05] <apw> smb
[15:05] <apw> smb, actually that one ^^ claims to fix it explicitly
[15:05] <smb> apw, The description does not sound like the change I looked at before
[15:06] <apw> smb, and a second claiming to fix it :)
[15:06] <apw>     block: Fix NULL pointer dereference in sd_revalidate_disk
[15:07] <apw> one of 'em must fix it for P at least
[15:07] <smb> apw, I beleive that was the one
[15:07] <smb> And yes, I think those went into some stable
[15:11] <apw> all of them, thats where i am seeing them in the .12 rebase
[15:25] <jsalisbury> **
[15:25] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:25] <jsalisbury> **
[15:27] <infinity> apw: Before I go and change all the seeds and installer bits and such...
[15:28] <apw> infinity, yep ?
[15:28] <infinity> apw: Wouldn't it make more sense to just make the -powerpc package be the SMP kernel (and make linux-image-powerpc-smp depend on that), much as we've done for all the other arches that no longer have -smp flavours?
[15:28] <apw> erm i don't recall us dropping one before
[15:29] <apw> so that'd be before my time
[15:29] <infinity> It would be, yes.
[15:29] <apw> ogasawara, ??
[15:29] <apw> ^^
[15:29] <apw> bah
[15:29] <infinity> But -generic used to be a UP kernel.
[15:29] <infinity> Well, I'm not sure it used to be called generic.
[15:29] <infinity> Was probably -i386 or something.
[15:29] <infinity> But you get the idea.
[15:29] <ogasawara> I changed linux-meta such that linux-image-powerpc actually points to the powerpc-smp kernel
[15:29] <infinity> We don't explicitly mention -smp anywhere where SMP is the only option.
[15:30] <infinity> ogasawara: I know, I was arguing that maybe it should go the other way. :)
[15:30] <apw> i guess the installer doesn't use the meta at all
[15:30] <infinity> (And this is the same amount of work for me anyway, cause the argument would go further to say that -powerpc64-smp should just be -powerpc64)
[15:31] <infinity> apw: We sort of do and sort of don't.  It's complicated. :P
[15:32] <infinity> Anyhow, I'm prepared (and in fact, halfway done) to do the s/powerpc/powerpc-smp/ stuff all over, was just a point of note that we don't have "-smp" kernels on arches that are SMP by default.
[15:32] <infinity> Which is pretty much all of them now.
[15:34] <infinity> Anyhow, I don't want to create extra busy work for you guys.  If you're happy with the current state of things, I'll fix up the installer bits and call it done.
[15:34] <infinity> (And maybe propose a patch next cycle to rename the kernels :P)
[15:34] <ogasawara> infinity: I've no strong opinion either way, so lets just leave it as is for now and fix it up in Q
[15:35] <apw> ogasawara, yeah or cirtainly after B2 i recon
[15:36]  * infinity nods.
[15:36] <infinity> It's not a strong opinion here, just noting that it's inconsistent naming. :)
[15:36] <infinity> I'll worry about it later.
[15:36] <infinity> Oh, have you guys merged the patch from jk/benh?
[15:36] <ogasawara> infinity: so it's just your ocd kicking in
[15:36] <infinity> It fixes my G3. \o/
[15:37] <infinity> ogasawara: If I didn't have my OCD, I'd have nothing.
[15:37] <ogasawara> infinity: I've applied it, and plan to upload shortly
[15:37] <infinity> ogasawara: No rush on the uploading, I seem to be the only person complaining.  Just wanted to make sure it was merged.  Thanks. :)
[15:41] <Daviey> ogasawara: Sorry for not replying to your mail.. i will tackle tboot today.. it required some work, which i haven't had the capacity to do in the last week.
[15:42] <Daviey> smb: I'd like to raise bug 960311 in the meeting btw.
[15:42] <ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [Undecided,New] https://launchpad.net/bugs/960311
[15:42] <ogasawara> Daviey: no worries, thanks!
[15:43] <smb> Daviey, Ok, I may or may not have had time to look at it before
[15:43] <Daviey> smb: right.. thought i'd try and give you some heads up.. sorry it's not much
[15:46] <smb> Daviey, I don't think I'd expect much for something just filed 5 minutes ago
[15:48] <Daviey> smb: heh
[16:00] <jwi> smb: while you're playing with dm-multipath - there's also bug 598251
[16:00] <ubot2`> Launchpad bug 598251 in linux "kernel-image-$version-$flavor-di should provide 'multipath-modules'" [Low,Triaged] https://launchpad.net/bugs/598251
[16:01] <smb> jwi, If you just look at the kernel-team mailing list...
[16:02] <smb> ogasawara, Oh well, maybe you want to reference that bug number too in case you apply it
[16:02] <ogasawara> smb: I'll amend the commit message
[16:03] <jwi> smb: ah, great! :)
[16:06] <smb> jwi, It just happened to be brought to my attention by cjwatson a little earlier... Just not that there was another bug report already...
[16:06] <smb> coincidence... :)
[16:12] <lamont> smb: that particular message is a printk in the kernel where it looks a the packet a goes "tracking hard, let's just complain about it"
[16:13] <smb> lamont, Well, fw rules complain via messages looking like kernel ones... There did not seem to be something like that text in the kernel conntrack source...
[16:34] <apw> bug 922906
[16:34] <ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Medium,In progress] https://launchpad.net/bugs/922906
[16:41] <lamont> smb: in this case, it's from net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c line 120
[16:42] <lamont> the trick is to grep for nf_ct_%s
[16:44] <smb> Hm; I was looking for "dropping packet" but maybe I mistyped in a hurry or missed it in the output
[16:47] <lamont> smb: in other news, upgrading the firewall here to 3.2.0-19 seems to have fixed the occasional issue with not forwarding traffic for some sites
[16:51] <apw>  /b msm
[16:53] <smb> -EOMUCHSPACE
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Mar 27th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:15] <cking> jsalisbury, if it's not too much trouble, can you run that test shortly so I can examine the output and write an Email to my favour laptop provider... ;-)
[17:16] <jsalisbury> cking, I'll do it right now :-)
[17:16] <cking> ta! :-)
[17:22] <jsalisbury> cking, Do you want me to run another test to cause an overheat, or do you just need the output from intel-thermdump?
[17:25] <jsalisbury> cking, log on its way
[17:25] <smb> lamont, At least something. Hm, it looks like the place you found passes info to a function that uses a per protocol registered logger handler which somehow seems to be leading back to some ipt target called LOG. Not claiming to understand the whole concept here but I get the nagging feeling that this then comes back to be printed only if reaching a certain iptables rule...
[17:33] <cking> jsalisbury, sorry, i missed your comment. just the intel-thermdump output is fine - I want to see how the MSRs are configured
[17:33] <jsalisbury> cking, cool, you should have it in email.
[17:33] <smb> lamont, So maybe an addition in /etc/ufw/after.rules that jumps to ufw-skip-to-policy-input would help you to silence things...
[17:34] <cking> jsalisbury, thanks, yep, it's poorly configured. how lame is that?
[17:35] <jsalisbury> cking, That's with the latest BIOS update too.
[17:35] <lamont> smb: except that I want the traffic to be accepted, truth be told
[17:35] <cking> jsalisbury, doubly lame then
[17:35] <jsalisbury> cking, heh
[17:35] <lamont> 28283   17M ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060
[17:36] <jsalisbury> cking, can those settings be modified, or can it only be changed in the BIOS?
[17:36] <cking> jsalisbury, I'm sure there is some room for tweaking
[17:36]  * cking grabs some food, back later
[17:37] <lamont> smb: and interestingly, putting that rule at the head of the INPUT chain does nothing.
[17:37] <cking> jsalisbury, how old is that machine?
[17:37] <smb> lamont, Oh ok. Was not clear on that. IIRC, wasn't the some problem about some id and the port not being what the helper expected (and which is probably some standard)
[17:37] <lamont> also, ufw is not usable on this machine, unless it's managed to grow support for forwarding rules
[17:38] <jsalisbury> cking, About a year and a half old.
[17:38] <jsalisbury> cking, I purchased it in November/2010
[17:39] <lamont> smb: sorry about that.  this is a plain ol cisco 7940 phone talking to the asterisk server, which hasn't moved to its own machine yet, so it still lives on the box that does routing for the network as well
[17:39] <lamont> amusingly, the phone wokr
[17:39] <jdstrand> it does not have cli support. it continues to have the same support as is documented in ufw-framework (ie /etc/ufw/*rules)
[17:39] <lamont> works
[17:39] <lamont> smb: and I suspect that this is actually a case of the kernel saying "sip hard. lets go shopping"
[17:43] <smb> lamont, it could be that the rule to accept gets "overruled" by conntrack later. But I am far from understanding that whole stuff. And for what I said about the id and port. I just vaguely remember when you were talking about this and then thought at a later point in time you mention something like "doh <something< != port... Which led me to believe you found the reason why it gets dropped.
[17:45] <lamont> hrm
[17:45] <smb> Last time I scanned over that conntrack module it seemed like several places change the destination from accept to reject but that does not really help to differentiate between the things happening. 
[17:45] <lamont> the source port is incrementing, but that's just the phone having fits
[17:47] <lamont> 11:42:32.373739 IP 192.168.133.192.50815 > 192.168.133.1.5060: SIP, length: 561
[17:47] <lamont> 11:42:34.784066 IP 192.168.133.192.50816 > 192.168.133.1.5060: SIP, length: 561
[17:47] <lamont> 11:42:36.373627 IP 192.168.133.192.50817 > 192.168.133.1.5060: SIP, length: 561
[17:48] <lamont> 11:42:38.783707 IP 192.168.133.192.50818 > 192.168.133.1.5060: SIP, length: 561
[17:48] <lamont> and so on
[17:48] <lamont> should be completely valid traffic
[17:48] <lamont> OTOH, I can see where it would maybe not match ESTABLISHED,RELATED
[17:49] <lamont> smb: I suspect that it's conntrack remembering the packet for when the response comes through, only not.
[17:50] <lamont> 12 hours, 20000 lines of log, times 2 files
[17:51] <smb> lamont, It must be something in the SIP protocol part since it is the sip conntrack helper dropping the packet. Just not sure how to find out what the heck it does not like... :/
[17:55] <smb> lamont, Would that machine complaining be ok running a debug kernel that adds printk's to whatever place sets the destination to drop? Or rather try to get a wireshark log from some offending packages to try walking through the code. Any way I suppose there should be a bug report to handle any progress. Maybe there is already and I just forgot
[17:55] <lamont> smb: I would be happy to run such a kernekl
[17:55] <lamont> at least long enough to have it spew
[17:56] <lamont> I have a capture of phone traffic from thatphone if you want to walk the code while the kernel builds...
[17:56] <lamont> generic-pae/i386
[17:56] <lamont> ISTR filin a bug, let me go look
[17:58] <lamont> bug 960126
[17:58] <ubot2`> Launchpad bug 960126 in linux "kern.log full of nf_ct_sip complaints" [Medium,Incomplete] https://launchpad.net/bugs/960126
[17:59] <lamont> smb: and no, I don't really feel like collecting all the logs in the world for the bug
[18:00] <lamont> the tcpdump trace file is probably more relevant
[18:01] <smb> Ok, thanks, I will try to get some kernel. Though it will need a bit of time. Its not only to compile a kernel. I have to add printks in a way they are hopefully meaningful. Plus this side of the world reaches its late end of the day. If the plan works there should only be the syslog telling something
[18:02] <lamont> smb: cool
[18:02] <lamont> just holler whenever
[18:02] <smb> lamont, sure. will do
[18:05] <lamont> smb: and if you want a packet capture along with the syslog lines, just holler.  I have an unending supply
[18:08] <smb> lamont, Hm, if it is not too troublesome to get, something I can load into wireshark for inspection would maybe be even better... 
[18:08] <smb> I am looking at the code anyway to add the printks , so I can as well compare what is in the package while doing so
[18:09] <lamont> smb: sure.  let me get you a small file.
[18:12] <cking> jsalisbury, I'm not sure I've got the latest dmidecode output from your updated machine, do you mind sending it to me? Thanks
[18:12] <lamont> smb: bug updated with the syslog and pcapture
[18:12] <smb> lamont, Ok, great. Thanks
[18:13] <lamont> smb: fwiw, tcpdump -s 3000 -w ~/192.pcap host 192.168.133.192
[18:14] <lamont> afk lunch
[18:19] <jsalisbury> cking, will do
[18:19] <jsalisbury> cking, any particular options you want?
[18:20] <cking> jsalisbury, just "sudo dmidecode" 
[18:21] <jsalisbury> cking, on its way
[18:21] <cking> cheers
[19:06] <henrix> jsalisbury: ping
=== yofel_ is now known as yofel
[19:34] <jsalisbury> henrix, pong
[19:34] <henrix> jsalisbury: hi! i just found an old lkml thread that may finally solve bug #922906
[19:34] <ubot2`> Launchpad bug 922906 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Medium,In progress] https://launchpad.net/bugs/922906
[19:34] <henrix> jsalisbury: here's the link: http://marc.info/?t=130806561400010&r=1&w=2
[19:35] <henrix> jsalisbury: i ping'ed the thread, and eric replied stating that the patch has been stalled
[19:35] <henrix> jsalisbury: he'll try to push it asap
[19:35] <henrix> actually... it's not on lkml, but on fsdevel
[19:35] <jsalisbury> henrix, awesome, thanks for getting an update!
[19:36] <henrix> jsalisbury: no prob. i guess this issue has been around for *too* long :)
[19:36] <jsalisbury> henrix, I'll keep an eye out for the patch on lkml 
[19:36] <henrix> jsalisbury: cool
[19:36] <jsalisbury> henrix, thanks for finding that thread
[19:37] <henrix> jsalisbury: yeah, that was a though one... specially because lkml was not on CC
[19:38] <jsalisbury> henrix, yeah, that makes it tricky 
[19:38] <jsalisbury> henrix, I posted the link to that thread in the bug
[19:38] <henrix> following lkml is already difficult, following everything else around... is impossible!
[19:38] <henrix> thanks