[04:19] c === mdz_ is now known as mdz === Ng_ is now known as Ng [12:54] Hey folks [12:54] ov51x-jpeg (1.5.9-1) unstable; urgency=low [12:54] * New upstream release, fixes compilation on 2.6.27 kernels. [12:55] Does someone have the hardware or could review whether we can sync that over? [12:55] I'd think yes, but as I don't have such a webcam... [12:55] davidm has one though [12:56] I have a DKMS package of that one [12:56] in intrepid? [12:57] I saw Sergio's patch to fix compilation issues over the weekend, was intending pushing the DKMS to my PPA later [12:58] But, need to do some regression testing first [13:06] IntuitiveNipple: It might be easier to just sync over the old-style package for intrepid? [13:08] I maintain a bunch of DKMS web-cam driver packages, this is just one of them [14:41] amitk: so, how's aufs looking? ;) [15:50] um... [15:50] would it be possible to pull 8.2.7~rc1 version of drbd? [15:51] that would make it usable again in intrepid :) [16:54] munckfish, Didn't you have something you wanted in intrepid linux-ports. There has been more need for a re-spin. So if you are quick... ;-) [16:55] smb_tp: nah I'm still to identify the fix I need [16:55] smb_tp: thx for letting me know [16:55] What's the other "need for a re-spin"? === asac_ is now known as asac [16:56] smb_tp: is it the GFS stuff? I never did get to testing that stuff for that guy [16:57] munckfish, NP. Ok, then I just go forward with the current stuff. Yes, GFS and GNBD from fabbione [17:01] I appreciate some advice - I'm getting an intermittent hang on shutdown on PS3, and I'm not sure where to start finding a fix ... [17:01] I've tested various incarnations of out 2.6.25 based ports kernel in the last few weeks [17:01] and each time the problem has come back [17:01] but in a slightly different way:- [17:02] Basically it seems to carry out most of the shutdown procedure [17:02] but sometimes it just doesn't actually poweroff, or reboot [17:02] So I tried typing Alt+SysRq+o to poweroff [17:03] what I get is a oops/trace in the console [17:03] Unfortunately the top of the oops is off screen so I can't see it [17:03] but the stack traces seem to be fairly consistent [17:04] with some kernels the trace ends in snd_card_free_prepare [17:04] others in lpm_shutdown [17:05] each time I build a different kernel the trace consistently highlights a different function [17:05] which makes me think it's nothing wrong with the code in any of these places [17:05] could it be running out of memory? [17:05] anyway - any advice or suggestions would be gratefully received :) [17:14] munckfish, Hm, sorry, seems I stressed some of my network a bit too much. :-[ It is probably past using the logfile. OTherwise alt+sysrq+w might probably show something. But the output is usually long and if syslogd is already down it doesn't helpt much [17:16] smb: yep I think I tried alt+sysrq+w and yes it was off screen. I'll try again next time and take a closer look at it's output [17:19] munckfish, It might also be useful to know around which step of the shutdown/reboot this happens. Do you usually run without quiet and splash? [17:22] Ok I'll try to identify the last step more definitely. I'll switch off splash temporarily [17:23] heh, actually usplash doens't run anymore on boot for me PS3 in intrepid, I trying to work out why that is too. Seems something is missing from initramfs which was there in hardy. [17:23] (crickey my typing is rubbish today) [17:26] heh, mine is usually bad, so I won't notice... ;-) [17:32] if a box boots, then hibernates to disk and powers off, then boots, then wakes up the hibernate - there is no log from the 2nd boot is there ? [17:32] Correct [17:32] (trying to figure out why my dmesg dosn't look right) [17:33] good. I'll reboot and play closer attention :) [17:38] 3 [17:42] smb: not sure I pointed this out before: the "AC prevents/masks pauses" only occurs if I flip from battery to AC. if I have AC plugged in from the start, it pauses, and tapping a key just advances to the next pause. plugging in AC after it has booted = no more pauses [17:42] which seems odd. [17:44] CarlFK, Yes, it wasn't that clear until last time on irc. Unfortunately I had not much time to work on that since then. :( [18:19] smb: thx for the suggestions. I'll see if I can gather more info in the next couple of days. [19:19] console-kit-dae seems to be involved with a kernel panic on boot. [19:20] Something like that, it flashes by awfully fast. [20:05] Here are the panics: http://www.flickr.com/photos/7162611@N04/sets/72157607581668003/ [20:06] Any ideas? [20:06] Should I open a bug? [20:15] bronson, 2 of the 3 have apparmor. The other on fork might perhaps also fall there. Maybe check whether there are bugs open against that. Otherwise, open one. Those traces surely will be useful [20:22] bronson, Oh, and if there is already a bug, add your screenshots there. Anyways if you could mention the bug# here... [20:24] not sure how to find Intrepid kernel bugs in Launchpad... [20:24] ah, found it: https://bugs.launchpad.net/ubuntu/intrepid [20:26] https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.searchtext=apparmor&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch= [20:26] &field.has_no_package= [20:26] No results... does this mean that there are no bugs filed against apparmor? [20:30] bronson, seems like there currently is nothing. Ok, open a new one against the linux package. Title maybe "kernel panic in apparmor code"... [20:31] OK.