[00:31] <jjohansen> michaelh1: can you hook up a serial console?  sometimes a net console will work (though unlikely in your case), there is also always falling back to a camera if you have something on screen.
[00:33] <michaelh1> jjohansen: ah, a camera!  Good idea.  I've switched from wired ethernet to wireless and been working fine for two hours (fingers crossed)
[00:33] <jjohansen> michaelh1: also setting /proc/sys/kernel/printk_delay can some times make it so have a chance to read /catch output before it scrolls off the screen
[00:33] <michaelh1> jjohansen: ta.  I have a nice high-resolution screen so it holds quite a few lines.
[00:34] <jjohansen> michaelh1: ah, its nice when you can fit the oops on the screen, I was looking at a bug recently where it just didn't fit so I used printk display and took multiple pictures
[02:57] <bryceh_> JFo, bug #735126 has a kernel patch that looks ready to go (and already in linus' tree)
[06:11]  * apw yawns
[06:13] <jk-> hey apw 
[06:35] <apw> jk-, heya hows you
[08:35] <apw> morning all
[08:36] <smb> bonjour
[08:36] <apw> indeed, though getting up that early is never bon
[08:36] <smb> Hm are you not now in my tz?
[08:36]  * apw has been up for two and a half hours already
[08:37] <smb> Heh, ok. Probably a disadvantage being countryside. Rising with the chickens... :)
[08:37] <apw> the village bells don't help, clanging away at 7am
[08:39] <smb> Yeah, though one gets used to stuff like that
[09:25] <TeTeT> smb: I've talked to the customer on the xen guest problem with the high number of interrupts - they cannot really bring the system down and test as it is in production use
[09:27] <smb> TeTeT, Well and that may be the problem actually...
[09:29] <TeTeT> smb: the production use ? ;)
[09:30] <smb> TeTeT, Of course. Won't you think that a high number of eth0 interrupts may be somehow related to the network traffic taking place on the machine? ;)
[09:31] <TeTeT> smb: yeah, might be related - so you think it's just the usage and not a bug at all?
[09:33] <smb> TeTeT, It could very well be. The disk io did not seem to be exceptionally slow (for a fully virtualized guest on a busy host) and my experiments locally did not show something obvious
[09:33] <smb> Hence the question of trying to enable acpi to get slightly different interrupt routing and see whether that changes things
[09:34] <smb> Or compare to a different guest. The problem I can see is the syn package flood
[09:34] <smb> but that could be real traffic as well
[09:35] <smb> TeTeT, Maybe one thing to try would be to gather some wireshark or tcpdum log from within the guest to see what happens there
[09:36] <TeTeT> smb: hmm, what would it reveal beyond that network traffic is coming from and to the proxies?
[09:39] <smb> Beyond what kind, how much and whether that traffic is expected? :)
[09:41] <smb> The fact that the syn flood protection starts handing out cookies does not sound right. Though I am not sure I really have something to compare as it felt there was a lot of outbound traffic on that host
[09:46] <TeTeT> smb: it's their mirror of the archive and all updates are coming from that host, minus the proxies
[09:48] <smb> TeTeT, Basically all I can say from having tried CentOS5.5+Xen 3.0.3 (which should be quite close to what they got) is that I just did a quick install of 10.04 and did not see many net interrupts. However I did only have a simple one level failover bonding in place.
[09:49] <smb> Maybe it makes sense to check the switch configuration as well. I think one can twiddle something for bonding on that side as well.
[09:56] <TeTeT> smb: ok
[14:08] <JFo> bryceh_, got it
[14:37] <ogasawara> tgardner: bug 731878, looks like upstream is reverting the patch as well
[14:38] <tgardner> bug #731878
[14:39] <tgardner> no bot this morning?
[14:40] <JFo> been gone for a while
[14:40] <JFo> not really sure why
[14:48] <JFo> apw, or ogasawara whomever :) mind taking a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/737080?
[14:49] <JFo> it is the same hardware as akgraner and it is having similar overheating
[14:49] <JFo> this one owned by Stuart Langridge
[14:50] <apw> be good to ask him to see if the .38 mainline kernel has the issue, and if so, test .37, etc till it goes away
[14:50] <JFo> ok, will do
[14:56] <JFo> actually, should have done.
[14:56] <JFo> apw, there is a linus commit outlined by bryceh_ in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/735126
[14:56] <JFo> do you think it is possible to get it in?
[14:57] <tgardner> JFo, we love radeon patches.
[14:57] <JFo> :)
[14:59] <apw> JFo, will add it to my list for tommorrow ... looks pretty small
[14:59] <JFo> thank you sir
[14:59] <tgardner> JFo, this'll likely show up in stable pretty soon.
[14:59] <JFo> I suspect so, I just wanted to ask in case it didn't in time
[15:00]  * JFo is paranoid
[15:00]  * JFo goes back to the hotlist
[15:45]  * smb thinks sometimes he should wait longer before pushing the send button
[15:51] <JFo> heh
[15:51] <JFo> same here, but for me that should be every time
[15:52] <JFo> not sure what to do with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759503?comments=all
[15:52] <JFo> I think it needs csurbhi to look it over, but I can't find her
[15:56] <tgardner> JFo, that kinda looks like a kernel bug. 
[15:56] <smb> JFo, it seems to be a kernel bug triggered. Damn tgardner was faster
[15:56] <JFo> heh
[16:41] <hggdh> folks, pedro and I are going back to lucid SRU; I was doing the EC2, but I do not see an updated EC2 kernel
[16:42] <JFo> <- lunch
[16:44] <smb> hggdh, The last version I got in git is -315.28...
[16:45] <smb> That seems still to miss that one fix afaics
[16:46] <hggdh> smb: so you will be genning an update?
[16:47] <smb> I probably should do. Its only doing some sb600 fixup but one never knows...
[16:48] <hggdh> k. I will let pedro know
[16:48] <smb> hggdh, It will take a bit because I want to get my tree into a sane state first (working on something else)
[16:48] <hggdh> smb: no prob :-)
[16:48] <smb> But I hope I got it uploaded by tomorrow
[16:54] <ppisati> when does lucid expire?
[16:56] <ogasawara> ppisati: April 2013 for the desktop, April 2015 for the server
[16:57] <ogasawara> ppisati: https://wiki.ubuntu.com/Releases
[16:57] <ppisati> ogasawara: k
[16:59] <cooloney> ppisati: just got your email
[16:59] <cooloney> ppisati: let me try to recall this bug
[16:59] <ppisati> cooloney: it's the OTG thing/patch
[16:59] <ppisati> cooloney: basically, i can't get the a_idle state, so i'm doing something wrong
[17:01] <cooloney> ppisati: oh, i think you need a mini-A plug which is special for OTG
[17:01] <cooloney> ppisati: do you have such things?
[17:04] <ppisati> cooloney: what you mean special? i've a plug that i use to power that board
[17:04] <ppisati> cooloney: and what do i have to connect on the other end?
[17:05] <ppisati> cooloney: s/plug/cable with a mini-usb plug/
[17:09] <cooloney> ppisati: oh, OTG can work as USB host which named A mode
[17:09] <cooloney> so you need plug-in a mini-a connector to OTG port
[17:09] <cooloney> then the OTG will change to A mode
[17:10] <cooloney> at the other end of that cable, you can connect a USB flash disk 
[17:10] <cooloney> so the beagle board works as USB host to operate USB flash disk
[17:10] <ppisati> ok
[17:11] <ppisati> cooloney: but then i need a mini-usb plug <-> female usb cable
[17:13] <cooloney> ppisati: right, let me find one for you
[17:15] <ppisati> cooloney: no prob, i can chase one
[17:17] <cooloney> ppisati: great, man. i forget the name of my cable manufacture.
[17:17] <cooloney> ppisati: i'm in the conference, after I got home, i will check that for you
[17:17] <ppisati> cooloney: it's ok, i can handle it
[17:18] <ppisati> cooloney: is the panda board affected too? i mean, ti-omap4
[17:22] <cooloney> ppisati: i was told otg still has some issue on panda. but don't have much time to test that
[17:22] <cooloney> ppisati: i will try that later
[17:22] <ppisati> k
[17:33] <jjohansen> rebooting
[19:08]  * tgardner --> lunch
[20:18]  * jjohansen -> lunch
[20:31] <vanhoof> sforshee: you are a brave man :) (re: 561802)
[20:58] <sforshee> vanhoof, brave or stupid ? ;)
[21:01] <michaelh1> Hi there.  My machine is unreliable with the current Natty kernel - it dies with a kernel oops and backtrace sometimes, and sometimes halts with the numeric keylock led flashing
[21:01] <michaelh1> It seems to be more reliable on WiFi instead of ethernet, but dies ~4 times a day
[21:07] <sforshee> michaelh1, the blinking led means the kernel paniced
[21:07] <sforshee> if you can somehow capture the oops and open a bug it's probably your best bet
[21:08] <sforshee> even a photograph of the screen is better than nothing
[21:08] <michaelh1> Yeah, the camera trick is cool :)  Once I have a backtrace, how can I roll back my kernel?
[21:09] <sforshee> michaelh1, you mean roll back to a previous version ?
[21:09] <sforshee> if you have a known good kernel version that's important information for the bug report
[21:09] <michaelh1> sforshee: yeah, last weeks was more reliable on my machine.
[21:11] <jjohansen> michaelh1: you may have an older kernel already installed, what does ls /boot show
[21:12] <jjohansen> michaelh1: if there is multiple kernels in there you just need to hold down the left shift key on boot to get the grub menu, then you can select the one you want
[21:12] <jjohansen> to make it permanent you need to edit the grub.cfg
[21:13] <jjohansen> grub1 is /boot/grub/menu.lst
[21:13] <jjohansen> grub2 temporary is /boot/grub/grub.cfg
[21:14] <jjohansen> for permanent you need to update /etc/grub/<something>
[21:14] <michaelh1> grub always shows on my machine due to Maverick.  I have 2.6.38 -7 and -8 in /boot, so I can try -7 and see if it faults.
[21:14] <jjohansen> sorry can't remember what the actual file is atm
[21:14] <jjohansen> michaelh1: yeah that sounds good
[21:14] <jjohansen> you can also manually download kernels from packages.ubuntu.com
[21:15] <jjohansen> the maverick kernel works okay on natty
[21:17] <michaelh1> Not for me unfortunately.  The KMS in Maverick leads to red banding on my screen...  Non-KMS leads to draw errors :)
[21:18] <jjohansen> michaelh1: :(, the graphics stack is one of those areas that is problematic