[01:12] <ohsix> was 2.6.38.10.24 -> 2.6.38.10.25 a no change rebuild?
[07:55]  * apw yawns
[08:00] <jk-> hey apw
[08:00] <apw> jk-, yo ... 
[08:16]  * smb grumbles at udev net rules...
[08:23] <apw> smb, heh what did they do to you today
[08:23] <apw> (and moin)
[08:23] <jk-> do you have an eth4511 device?
[08:24] <jk-> eth5*10^2
[08:24] <smb> apw, moin :) Well leaving one of my nics named eth0-eth1 which does not help if your interfaces setup wants eth1 or eth0
[08:24]  * smb is sadistic and uses bonding
[08:24] <smb> probably more masochistic
[08:24] <apw> smb, you are mad
[08:25] <smb> apw, It is that dogfood kind of madness
[08:26] <smb> jk-, So not that bad, but still. How do you get that mad numbers?
[08:26] <apw> yay lts backports natty hit -proposed
[08:26] <smb> apw, and real proposed this time?
[08:26] <smb> (as in main)
[08:26] <jk-> smb: keep changing the MAC, I guess :) 50-persistent-net should take care of the rest
[08:27]  * jk- wonders how 'random MAC address' ethernet devices are handled by udev
[08:27] <smb> In theory everyone will get a new name right....
[08:27] <apw> ohsix, i am supprised to see a bump like that in what i assume is the linux-meta package
[08:27] <ohsix> apw: apparently it was to include something in the backports, the changelog showed up a few hours later
[08:27] <smb> Though that seems to be the purpose as the mac is not really supposed to be different that often
[08:29] <apw> ohsix, actually no its not, its a backport ...
[08:29] <apw>   * Added compat-wireless packages to Natty LBM
[08:29] <apw> ohsix, ahh you found it
[08:30] <smb> \o/ I was able to change a lp status
[08:38] <apw> smb, i wonder if that is cause it still got a high timeout or if they fixed it
[08:39] <smb> apw, Sadly it could be either (everybody else not trying to atm or it being fixed)
[08:39] <jk-> smb: yeah; but some devices don't have an EEPROM for the MAC, so the driver generates one at probe time
[08:40] <smb> jk-, though probably that one should be in the privately usable range, which is ignored for the persistent rules
[08:41] <jk-> ahh
[08:41] <jk-> thinking++
[08:41] <smb> Just saw some skips in there for xen and kvm/quemu driver ids as well
[08:41]  * jk- should read the code rather than making assumptions about it
[08:42] <smb> :) As long as it is findable. I seem to fail finding the piece that would actually trigger the renaming...
[08:45] <jk-> smb: /etc/udev/rules.d/70-persistent-net.rules
[08:45] <jk-> sets NAME=
[08:46] <smb> jk-, Well yes, as well as /lib/udev/rules.d/75-persistent-net-generator.rules would set it
[08:46] <jk-> but that might not be the issue in your case
[08:46] <jk-> yah
[08:47] <jk-> smb: it's not something in /etc/network/ ?
[08:47] <smb> But that is setting a shell var. The driver will remain unimpressed unless something tells it a new name...
[08:48] <jk-> smb: I thought udev would see that as a new device name, and do the rename?
[08:48] <jk-> again, making assumptions here...
[08:49] <smb> jk-, Would make the same assumptions that something, somewhere will detect that the name set and the name used are not the same and start the rename
[08:49] <smb> The big question is "where is that hidden"
[08:50] <smb> At least the names of scripts in /etc/network and /lib/udev are not obviously sticking out...
[08:57] <apw> # rename interface if needed
[08:57] <apw> ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"
[08:58] <apw> smb, ^^ i think those two lines cause the rename, and i suspect the actual change may occur in the udev binary
[08:59] <smb> apw, Yeah, that sounds like the only possible explanation, cause I could not find anything that remotely looks like doing the job externally.
[09:00] <smb> Which would hint a breakage there when I am left with a ethx-ethy device while the persistent rule section only has either. Sounds like it is forgetting to make a final move
[09:09] <apw> smb thats a bugger and no mistake
[09:23] <lucazade> Hi!  I'd like to know if in kernel 3.0 for OO it is included/enabled the support for Gma500 framebuffer
[09:51] <apw> lucazade, erm no idea off the top of my head
[09:52] <lucazade> apw, thanks.. I'll give a look :)
[10:28] <ppisati> apw: about our CVE tracker
[10:29] <ppisati> apw: one of the patch i applied in maverick/ti-omap4 had no buglink
[10:29] <ppisati> apw: and i opened one
[10:29] <ppisati> apw: but i don't understand why the CVE page says it affects only the omap4 branch
[10:29] <ppisati> apw: anyway, CVE-2010-3296
[10:30] <ubot2> ppisati: The cxgb_extension_ioctl function in drivers/net/cxgb3/cxgb3_main.c in the Linux kernel before 2.6.36-rc5 does not properly initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via a CHELSIO_GET_QSET_NUM ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3296)
[10:30] <ppisati> apw: and here is the LP bug i create: 795436
[10:30] <ppisati> apw: and, while there, can you accpet the maverick nomination? thanks :)
[10:38] <apw> bug #795436
[10:38] <ubot2> Launchpad bug 795436 in linux-ti-omap4 "CVE 2010-3296" [Undecided,New] https://launchpad.net/bugs/795436
[10:38] <apw> ppisati, approved
[10:38] <apw> ppisati, do you mean on the ALL-linux.html page ?
[10:38] <ppisati> yep
[10:39] <ppisati> the cve says "linux before 2.6.36"
[10:39] <apw> ppisati, if the page is _white_ in that area it means that there is no information to collect, normally that means that the
[10:39] <apw> CVE doesn't affect _or_ is already released for that cve on the other branches
[10:40] <apw> its a limitation on how that page is generated, and on my list to fix 
[10:40] <ppisati> ok
[10:40] <apw> maverick_linux: released (2.6.35-23.36)
[10:41] <apw> yeah in the tracker its all 'released' across the board ... so it is missing in the page i scrape to make that combiined one
[10:41] <apw> i have a different way to make the page planned, but its not written yet
[10:41] <ppisati> ok, no prob
[10:42] <apw> take white to mean "very likely can be ignored" for nwo
[10:44] <apw> ppisati, ti-omap4 is manually maintained right?
[10:44] <apw> (for cves_
[11:13] <tkamppeter> I have a problem with USB, seems that my Lenovo laptop is not compatible with the Oneiric kernel. Even directly after reboot "sudo lsusb -vvv" hangs and on the system console I get several message "usb 7-1: device descriptor read/64, error -110" and after some minutes I get "hup 7-0:1.0: unable to enumerate USB device on port 1". Anyone has an idea what happens?
[11:15] <apw> tkamppeter, that is possible with the .39 kernel there are a lot of very bad USB fookages about at the moemnt, a lot of them being introduced and fixed by stable updates on all releases
[11:15] <apw> tkamppeter, i think they are gone in the 3.0 kernels, but they have install problems cause of the stupid version number so i'd hold off on those as well
[11:16] <tkamppeter> apw, I need a working USB quickly to do testing for CUPS development, what should I do?
[11:17] <apw> well you can instlal the just built 3.0 kernel and see if it helps but you may find other problems like ps not being happy when you do
[11:17] <apw> i've just had a libc6 upgrade issue due to the version number ... and i have no idea if that machine can even reboot
[11:17] <apw> cirtainly reboot into a .39 kernel to do updates
[11:18] <apw> tkamppeter, those kernels are in the NEW queue, see the version page for links
[11:23] <tkamppeter> apw, perhaps I better boot into .38 first before installing a 3.0.x kernel. But thanks anyway.
[11:47] <Kano> hi, is the daily cronjob disabled?
[11:50] <tkamppeter> apw, now I have booted into 2.6.38-9 and I have still the same USB problem. Do I have to return to a from-scratch install of Natty to get a dev platform for the printing stack?
[11:50] <apw> tkamppeter, i have no idea what the issue if is you have reverted your kernel and its not working.  maybe udev is borked
[11:51] <apw> wow Kano is persistant, 40s to get an answer in
[11:51] <tkamppeter> apw, is "lsusb" using UDEV?
[11:52] <apw> tkamppeter, nope, hmm, oh lsusb is hanging, ... do you have th 38-8 kernle on there ?
[11:52] <apw> -9 might have had the stable update which caused all our grief with usb
[11:53] <tkamppeter> apw, yes, so will go to that.
[11:58] <tkamppeter> apw, booted 2.6.38-8-generic #42-Ubuntu and still the same problem.
[11:59] <apw> hrm
[11:59] <apw> tkamppeter, when did this last work for you
[12:01] <smb> apw, tkamppeter If that helps I am at 2.6.38-10.44 from proposed and lsusb does work. But maybe it could also be of help to try completly power off the machine in question before booting anything...
[12:01] <apw> smb, oh not one of those EC issues ... GAH
[12:01] <smb> Hm, and this is Natty user-space...
[12:02] <smb> probably not that helpful then
[12:02] <apw> i guess lsusb might be foobar
[12:02] <apw> nope works here on a half installed OO bog
[12:02] <apw> box
[12:04] <tkamppeter> laptop is Oneiric, the kernel which I am now running must be of Natty times.
[12:04] <tkamppeter> What are "EC" issues?
[12:05] <smb> embedded controller. some piece of hardware controlling/driving a lot of internal things (through acpi)
[12:06] <tkamppeter> The laptop is a Lenovo Thinkpad T400.
[12:06] <smb> So lsusb also seems to work on my server box...
[12:06] <tkamppeter> The USB problem I observed only today.
[12:06] <apw> tkamppeter, the embedded controller on some machines have crashed and mad things occur.  the 'fix' has been power off remove battery wait 20 mins and put it back together ... i was scepticle but it worked for me
[12:06] <smb> (which is oneiric kernel and user-space)
[12:07] <tkamppeter> apw, so I will try. I will restart xchat from another box now.
[12:10] <tkamppeter> So this controller has some memory constantly supplied with power from the battery and also having large backup capacitors to hold data during system reset and battery change?
[12:13] <tkamppeter> apw, I am still here, the laptop is running an eternal process.
[12:14] <apw> tkamppeter, cirtainly it draws so little that the capacitors in the mchine are enough to keep it alive for some minutes it seems, cking is the expert
[13:33] <tkamppeter> apw, smb, I tired the shutdown of my notebook and leaving it without battery for more than 30 minutes, but to no avail, the USB is still broken.
[13:35] <tkamppeter> apw, smb, I got a fast "sudo lsusb -vvv" once, then I connected the USB hubs with 10 printers again and it broke again. Seems that connecting many devices is messing up this mysterious memory, but it was never that way before. I am still on kernel 38-8.
[13:35] <tkamppeter> apw, smb, I hope I do not need a new laptop.
[13:36] <smb> tkamppeter, So does anything change when you connect the hub but for test remove some of the printers?
[13:37] <tkamppeter> smb, only first hub, no printers, same problem.
[13:38] <smb> Hm, so without the hub it works but with it, it does not?
[13:39] <smb> like a single printer directly to the usb port works or not?
[13:39] <tkamppeter> also the hub removed, same problem.
[13:39] <smb> Though you said it was working once without?
[13:41] <cking> best to boot back to a known working kernel, and try with one device plugged in to sanity check it
[13:42] <smb> cking, Right, though he says that 2.6.38-8 used to work and does not seem to anymore
[13:42] <cking> so sounds like a H/W issue to me
[13:42] <tkamppeter> Yes, before connecting the hub OK, hub+printers broken, hub broken, hub removed, broken.
[13:42] <smb> tkamppeter, I would try then rebooting and trying no hub, but one printer
[13:43] <smb> Would you have a different usb hub to try?
[13:43] <cking> and if you have another machine sanity check the printer, then the hub with it.
[13:44] <smb> Also, depending on whether the hub is active can sometimes help to disconnect that from everything
[13:44] <cking> good point
[14:47] <apw> ogasawara, i am holding off on uploading linux-meta becuase my machine here is having trouble installing libc with the 2 digit kernel installed
[14:47] <ogasawara> apw: ack
[14:48] <apw> right now i am not at all sure how to get out of my hole
[14:49] <ogasawara> apw: is that a warning that I shouldn't try testing
[14:49] <apw> i wouldn't upgrade to oneiric with that kernel as the runnig one
[14:49] <apw> i have a mahcine half upgraded with libc6 half installed
[14:50] <apw> i suspect rebooting will not be a winning plan
[14:50] <apw> as to how to get out of it with a half installed package which won't install ... erm
[15:09] <tkamppeter> smb, apw, now I have rebooted without any hub or printer connected and the problem persists. 
[15:11] <tkamppeter> smb, apw, if this is really from a broken piece of hardware this would mean that this piece of hardware is messing up the memory of the USB subsystem, breaking it down until the system gets neutralized again (30 min without battery).
[15:13] <apw> cking, that sounds like you magic EC loses its mind fix ... scarey
[15:13] <smb> tkamppeter, Unfortunately that can happen. I got one older desktop that sometimes gets into that state. Removing all power is simpler there, though. 
[15:13] <smb> Not sure whether 30mins without battery are really needed
[15:13] <apw> cking, can you rmember what the rules are if you over current a USB port.  i seem to remember they can stay disabled forever
[15:14] <apw> "forever" meaning until power is removed ...
[15:15] <cking> apw, I'm not sure - I don't know much about USB.
[15:15] <tkamppeter> apw, smb, the USB port seems not to be disabled. lsusb -vvv finishes after a timeout of some minutes and all printers are visible after that.
[15:18] <cking> This is what I googled: "On a laptop, a "power bug" chip is used. That is an 8 pin DIP
[15:18] <cking> chip. It has a precision current sense inside. If the current
[15:18] <cking> exceeds 500mA, some FET transistors inside turn off the power
[15:18] <cking> feeding the USB port. At the same time, a logic signal from the
[15:18] <cking> power bug, is sent to one of the OC# pins on the Southbridge.
[15:18] <cking> As a result, the laptop doesn't need a fuse."
[15:19] <cking> so it should only last until one powers the box off
[15:19] <apw> cking, thanks :)
[15:20] <tkamppeter> cking, thanks.
[15:21] <cking> on a desktop, a polyfuse is used, which may need a long while to cool off before being re-usable
[15:22] <tkamppeter> strange is that the USB plug in which always have the hubs with the printers I is on bus #1. the internal hub which makes lsusb -vvv hanging for several minutes is bus #7, device #1.
[15:22] <cking> http://www.pcreview.co.uk/forums/usb-overcurrent-status-detected-t4032559.html
[15:23] <apw> tkamppeter, and what is that device when it finally tells you
[15:23] <tkamppeter> Also the plug is still working after once having obtained the hanging "lsusb -vvv".
[15:24] <apw> perhaps something else is broke, on that bus
[15:24] <tkamppeter> apw: "sudo lsusb -vvv" tells
[15:24] <apw> tkamppeter, you know it worked on maverick yes ?
[15:24] <tkamppeter> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[15:24] <apw> so perhaps boot a maverick livecd and see if it still does work there
[15:25] <tkamppeter> as the start of the new entry, then it hangs for several minutes and continues afterwards.
[15:26] <apw> so that sounds like there is something on that bus, but its not working hmmm
[15:27] <tkamppeter> apw, I am running now another "sudo lsusb -vvv" capturing the output, to see what happens after the timeout.
[15:27] <apw> if you have a place you really know it worked, i think a livecd at that level to confirm if its bug or h/w
[15:28] <cking> or both perhaps?
[15:29] <tkamppeter> apw, after the timeout, the broken device's properties are shown normally and no error message is shown. After that the entries of the remaining devices is shown with normal speed.
[15:36] <smb> apw, cking Could it "think" that something is connected but there is not anything for real? Or something broken indeed. Hard to tell.
[15:36] <cking> smb, it's hard to tell at this point
[16:25] <tkamppeter> apw, smb, cking, now I am on Oneiric with the default kernel, all hubs and printers disconnected, shut down the system, taken out the battery for some seconds, booted into said OS. Added back the hubs and printers one by one, tested after each device. Everything perfect as long as the HP LaserJet 1020 is not connected. System even recovers after having connected and removed the LaserJet 1020 (LJ 1020 directly on computer, all the other
[16:25] <tkamppeter>  printers on hubs as before).
[16:40] <jdstrand> ogasawara: hey, I wonder if 760131 and 751689 are related in any way...
[16:40] <jdstrand> ogasawara: nothing to do there, just a thought
[16:52] <apw> bug 760131 bug 
[16:52] <ubot2> Launchpad bug 760131 in ubuntu-release-notes "Power consumption raised significantly in natty" [Undecided,Fix released] https://launchpad.net/bugs/760131
[16:52] <apw> bug 751689
[16:52] <ubot2> Launchpad bug 751689 in linux "Thinkpad x201* overheats due to slow fans when on 'auto'" [Critical,Confirmed] https://launchpad.net/bugs/751689
[16:52] <apw> jdstrand, maybe the issue is made visible by the clear heating we see with out the fix for the former, but clearly its still a bug somewhere in the latter case, likely bios
[16:54] <jdstrand> make sense
[17:47] <tkamppeter> apw, smb, cking, all is working now for me as long as the LaserJet 1020 is not connected and even returns when disconnecting the LaserJet 1020. On two Natty boxes the LaserJet 1020 works without any problem.
[17:48] <tkamppeter> apw, smb, cking, thank you very much for your help.
[17:48] <tkamppeter> apw, smb, cking, and it seems that taking out the battery for some seconds is enough to reset the EC.
[17:57] <cking> cool
[19:06] <vish> hi, i'm trying to kernel bisect and i'm following instructions from https://wiki.ubuntu.com/Kernel/KernelBisection , but after i did a $ git checkout -b mybisect origin/master , i dont have a debian.master/changelog file to add the changelog entry
[19:07] <vish> (there is no debian folder too)
[19:07] <vish> how do i get to build the bisected kernel?
[19:11] <jjohansen> vish: what kernel did you clone?
[19:11] <vish> maverick
[19:12] <jjohansen> vish: if you do
[19:12] <jjohansen> git checkout master
[19:12] <jjohansen> do have a debian folder then?
[19:12] <vish> oh! , /me tries
[19:15] <vish> jjohansen: woot! yea, now i have the debian folders,  so would that give me the bisected kernel or the master..  or do i just have to continue as in the wiki?
[19:16] <jjohansen> vish: making the branch just makes it so you don't mess up the master branch, if you don't care, you can do it on master.  If you need to fix master you can always do
[19:16] <jjohansen> git checkout -f
[19:16] <jjohansen> git reset --hard origin/master
[19:18] <vish> jjohansen: nah, i dont care about the master.. i'm just trying to bisect to find the commit, and i need to build the deb.. so, i can just skip the " $ git checkout -b mybisect origin/master " part of the wiki and work on the master right?
[19:19] <jjohansen> yes
[19:19] <vish> jjohansen: thanks.. :)
[19:20]  * bjf -> lunch
[19:39] <Kano> hi, why way module-init-tools raised to 3.13-1-u? i had no problems using 3.12-1
[19:40] <Kano> and even the lenny version was enough in my tests
[19:40] <Kano> which is 3.4...
[19:41] <Kano> a bit stupid to use those depends on mainline
[19:43] <Kano> you compile the kernel in hardy chroot but depend on a oneric package....
[19:58] <Kano> i can patch that on the fly but it is a stupid thing...