[00:18] <jewsucanuse> ogasawara, will ndiswrapper (with the 2 patches it needs) be included in the alpha 1 kernel or are the bkl calls to prohibitive?
[00:18] <ogasawara> jewsucanuse: not sure, have been tracking ndiswrapper for natty very closely
[00:19] <jewsucanuse> there are patches that allow clean compilation on 2.6.37, but there were concerns about how ioctl was being used.
[00:20] <ogasawara> s/have been/haven't been/
=== lifeless_ is now known as lifeless
=== amitk is now known as amitk-afk
=== lifeless_ is now known as lifeless
=== amitk-afk is now known as amitk
=== smb` is now known as smb
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
=== diwic is now known as diwic_afk
=== ogra_ac_ is now known as ogra_ac
=== amitk is now known as amitk-afk
=== diwic_afk is now known as diwic
[11:58] <apw> bug #600453
[11:58] <ubot2> Launchpad bug 600453 in linux (openSUSE) (and 3 other projects) "[arrandale] [i915] DELL E6510: blank screen on boot (Intel GPU) (affects: 31) (dups: 1) (heat: 206)" [Medium,Confirmed] https://launchpad.net/bugs/600453
=== yofel_ is now known as yofel
[14:08] <JFo> morning apw
[14:09] <apw> JFo, morning
=== bjf[afk] is now known as bjf
[14:45] <vish> apw: hi, so what should i ask on the older bug, that they test your kernel and check if there are no problems?
[14:46] <apw> vish i have done so, and not had time today to see if they have taken notice yet
[14:46] <vish> cool!
[14:46]  * vish checks as well..
=== tgardner is now known as tgardner-afk
[15:23] <vish> apw: they dont seem to mention any problems with the kernel [old in Bug #507148 ], but i get those messages as well.. and have not found any noticeable side-effects due to those messages..
[15:23] <ubot2> Launchpad bug 507148 in xserver-xorg-video-ati (Ubuntu Lucid) (and 4 other projects) "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500 (affects: 8) (heat: 60)" [High,Invalid] https://launchpad.net/bugs/507148
[15:29] <apw> vish tnakns
[15:39] <avinashhm> vinashhm> hi, is any one familiar with lockdep asserting bugs .. I am stuck with a deadlock bug ..i wanted to know if a single task can hold multiple mutexes ???.. error @  @ http://paste.ubuntu.com/539017/ ... any help ???
[15:52] <apw> avinashhm, yes a process can hold any number of mutexes, obviously if you hold more than one you had really really better know what you are doing, ordering is key
[15:54] <avinashhm> apw, i am making sure it is in proper order .. last acquired first released .. but still i am having this lockdep error, of "recursive locking" .. i made sure with prints that i amn't acquiring same mutext without releasing .. but still it is cribbing ... :-(
[15:54] <apw> it seems likely lockdep is right, and its saying you have a lock you are re-taking
[15:57] <apw> that sort of thing is common when you have the lock but interrupts are enabled and the interrupt handler takes the lock too on the same cpu
[16:00] <avinashhm> apw, but with prints above here are prints just b4 my mutex_lock and mutex_unlock api's .. so i amn't relocking a mutex which is already locked ... [ end number is the address of the mutext ] ... so i amn't re-taking.. 
[16:01] <avinashhm> so you mean here .. two processes are holding that lock .. one mine and the other interrupt handler ??
[16:01] <apw> the protections are based on a cpu
[16:02] <avinashhm> apw, so what i can do to improve or get unlocked from here ??
[16:06] <avinashhm> apw, so how is it usually interrupts are disabled when we have the lock ?? please pardon me if my questions are childish .. but i amn't familiar with these ...first bug of this type :-)
[16:07] <apw> avinashhm, no interrupt handling is manual and separate
[16:07] <avinashhm> apw, so how are these type of problems solved usually ?? 
[16:08] <apw> avinashhm, debugging as you have indicated in combination with the lockdep output and reading the code
[16:08] <apw> its a very hard problem
[16:10] <avinashhm> apw, to be frank i still didn't understand the problem , is there any place i can look for to understand this lockdep description??? 
[16:10] <avinashhm> actually the problem is easily reproducible , during bootup .. need to trace ..
[16:14] <avinashhm> apw, seems like i am too tired of this problem from morning .. i ll debug further and see you tomorrow ..thanks for the help buddy ... 
[16:16] <JFo> skaet_, do you have bugs for me? :)
[16:17] <skaet_> have you gone through the ones from the status last week.  :)
[16:17] <skaet_> other than that,  I won't be taking a pass through the bugs until after alpha 1 goes out today.   Some last minute issues are going to keep me busy today.
=== tgardner-afk is now known as tgardner
[17:47] <JFo> smb, bug 684304 looks like it may be of interest to you
[17:47] <ubot2> Launchpad bug 684304 in linux (Ubuntu) "cciss module does not identify resources (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/684304
[17:47] <JFo> hggdh just pinged me about it
[17:47] <JFo> failing install so it seems
[17:48] <smb> JFo, Hm. Yeah, sounds like it needs to interest me. 
[17:48] <JFo> well, I shall return. I am off to lunch then to a (hopefully warm) coffee shop
[17:48] <JFo> smb, :)
[17:48] <JFo> bbiab
[17:58] <tgardner> sconklin, any interesting status from the SRU test review meeting?
[18:06] <smb> tgardner, Wasn't there a bug report or some issue with Broadcom NetXtreme of some sort recently?
[18:51] <apw> tgardner, ok ... this is confirmed a grub graphics mode handoff issue 
[18:51] <tgardner> apw, is there a known fix yet?
[18:52] <apw> tgardner, there is a work around, turnign off graphics handoff.  am working on whats wrong now
[18:52] <apw> i think its an unhandled pipe underrun, but am trying to confirm that
[18:52] <tgardner> apw, I would have thought removing splash would have corrected it
[18:53] <apw> tgardner, nope doesn't change how grub hands off the screen
[20:01] <ogasawara> bjf, sconklin: lucid fsl-imx51 rebased and pushed to my repo for review - git://kernel.ubuntu.com/ogasawara/ubuntu-lucid.git fsl-imx51
[20:02] <bjf> ogasawara, cool, will look at it in a bit, not to worried about it though
[20:02] <ogasawara> bjf, sconklin: assuming that looks good, package for review/signing is on zinc in my home dir under proposed-pkgs/lucid/linux-fsl-imx51_2.6.31-608.21_source.changes
[20:03] <sconklin> ogasawara: both on a call, be with you in a sec
[20:23] <JFo> skaet_, I am assuming that, due to the alpha 1 release, that there will be no new bugs on the release team radar for kernel. :)
[20:23] <JFo> for this week, I mean
[20:23] <skaet_> JFo, don't make assumptions...  ;)   all sorts of interesting results coming up from the alpha.  ;)
[20:23] <JFo> :-/
[20:23]  * JFo was only assuming for one day ;-)
[20:23] <tgardner> skaet_, "interesting" == bad ?
[20:24] <skaet_> weather I'll be able to summarize or not by the end of the day, is a different matter.
[20:24] <skaet_> whether, even.
[20:24] <JFo> heh, ok
[20:24] <ogra_ac> skaet_, how about we auto-assign them all to JFo then his assumption is true for the rest of us ;)
[20:24] <skaet_> ogra_ac, lol
[20:24] <JFo> ogra_ac, :-P
[20:25]  * JFo closes bugs with extreme prejudice ;)
[20:25] <ogra_ac> no, with scripts 
[20:25] <ogra_ac> mind you, i have seen them ;)
[20:25] <skaet_> tgardner, not sure yet...
[20:25] <JFo> ogra_ac, :-D
[20:30]  * ogasawara lunch
[20:55]  * jjohansen lunch
[21:14] <manjo> tgardner, Checksum doesn't match for /home/manjo/linux_2.6.35-24.42.dsc
[21:14] <manjo> tgardner, I did a remote debsign 
[21:14] <manjo> and dput tells me checksum does not match
[21:14] <manjo> tgardner, I signed the .changes and .dsc file 
[21:16] <tgardner> manjo, you only need to sign the changes file, e.g., 'debsign -r tangerine.buildd:*.changes'
[21:16] <manjo> tgardner, ack ... when I signed .changes I get No signature on /home/manjo/linux_2.6.35-24.42.dsc. so I signed the .dsc as well
[21:17] <tgardner> how are you packaging? Use the '-us -uc' options so that 'dpkg-buildpackage -S' doen't complain.
[21:20] <manjo> tgardner, I did dpkg-buildpackage -S -sa  -rfakeroot -I.git -I.gitignore -i'\.git.*'
[21:20] <tgardner> so, whats changed? You've done this before.
[21:55] <bjf> sconklin, we've had a lucid linux-mvl-dove in -proposed for a while now, any idea what the plans are w.r.t it? I have a rebased lucid linux-mvl-dove locked and loaded
[21:56] <sconklin> bjf: I have no idea - I thought that Ike or Eric or someone else was going to handle those
[21:57] <bjf> sconklin, i went ahead and handled it, all our branches should be very up-to-date at this point (ogasawara did fsl-imx51 earlier)
[21:58] <sconklin> bjf: great! You and ogasawara have blown this release out (in a good way)
[22:00] <bjf> sconklin, now i've got an upload and nowhere to go :-)
[22:21] <manjo> tgardner, VirtFS is a 9P based passthrough filesystem for virtualized guests.
[22:22] <tgardner> manjo, incidentally, I remembered that you should be using 'dput -u' when remote signing and uploading from a machine that doesn't have your GPG key
[22:23] <manjo> tgardner, lp dos not allow me to use -u, -u I think says ignore signature  
[22:58] <lifeless> a friend of mine is seeing this: "Suggestion: Enable the CONFIG_PM_ADVANCED_DEBUG kernel configuration option. This option will allow PowerTOP to collect runtime power management statistics."
[22:58] <lifeless> from powertop
[22:58] <RAOF> There's an open bug for that, let me hunt it.
[22:59] <RAOF> lifeless: bug #632327
[22:59] <lifeless> RAOF: thanks
[22:59] <AfC> powertop just told me "Suggestion: Enable the CONFIG_PM_ADVANCED_DEBUG kernel configuration option. This option will allow PowerTOP to collect runtime power management statistics."
[22:59] <ubot2> Launchpad bug 632327 in linux (Ubuntu) "Powertop suggests CONFIG_PM_ADVANCED_DEBUG kernel option (affects: 18) (heat: 123)" [Wishlist,Triaged] https://launchpad.net/bugs/632327
[22:59] <AfC> which is a new one on me.
[22:59] <AfC> ah, you're already on it
[23:00] <AfC> (was a new on on me. Thanks Robert, Christopher)
=== bjf is now known as bjf[afk]
[23:55] <joshhunt> not sure if this is the correct forum, but i've got a question about initrd packaging. does ubuntu put the firmware for bnx2 driver in the initrd or do you wait until root is mounted?