=== emma_ is now known as emma === asac_ is now known as asac [14:22] apw: did you read my mail about the blacklight patch? [14:22] you have asked for a revert yes? [14:22] yes, because it is impossible do disable that patch [14:23] for those which do not need it [14:23] .28 is out of sync with what is in .27 and we need to resolve that as part of a sensible fix for the whole thing [14:24] also i wrote a 2nd mail about rt2860+rt2870, which works fine as backport from 2.6.29 [14:26] i've sent a patch for drbd 8.3.0 on mailing list, but it's too big; could that one get included, so that we could merge newer drbd? [14:26] i got the same error, then i just added a link to my server [14:26] but basically it is just from 2.6.29... [14:27] will do that next time :) [14:27] apw: could you revert it until you find a better solution [16:31] hey, is there anyone from the kernel team here? [16:32] i have a bug i would like to discuss with someone [16:39] bcurtiswx, which bug? [16:39] bug #277924 [16:39] Malone bug 277924 in linux "kernel cannot find map file" [Undecided,Confirmed] https://launchpad.net/bugs/277924 [16:39] I don't know what else the kernel team would want in there, plus theres a "fix" mentioned at the end of the comments... [16:40] i can't push an importance on it, and i won't triage it until i get confirmation that the kernel team has enough information to fix it [16:42] bcurtiswx, let me just scan trhough that [16:42] smb_tp_: ty [16:47] Hm, there seem to be two possible faults or solutions in there. One that claims the path is wrong and another saying rootdelay would change things. Can you tell me which is the case in your case? [16:49] smb_tp_: well i haven't tested the rootdelay fix, i can if u would like. All the rootdelay fix would suggest is that the kernel tries to find the system map too early. I don't beleive the path is incorrect [16:51] I might have an influence if /boot is another partition than /, just by changing timings a bit. How is yor setup there? [16:52] Disk /dev/sda: 500.1 GB, 500107862016 bytes [16:52] 255 heads, 63 sectors/track, 60801 cylinders [16:52] Units = cylinders of 16065 * 512 = 8225280 bytes [16:52] Disk identifier: 0x9fee4f19 [16:52] Device Boot Start End Blocks Id System [16:52] /dev/sda1 * 1 59681 479387601 83 Linux [16:52] /dev/sda2 59682 60801 8996400 5 Extended [16:52] /dev/sda5 59682 60801 8996368+ 82 Linux swap / Solaris [16:53] that was an fdisk -l [16:53] the following is my df [16:53] Filesystem 1K-blocks Used Available Use% Mounted on [16:53] /dev/sda1 471864592 32801912 415093300 8% / [16:53] tmpfs 1535548 0 1535548 0% /lib/init/rw [16:53] varrun 1535548 124 1535424 1% /var/run [16:53] varlock 1535548 0 1535548 0% /var/lock [16:53] udev 1535548 2892 1532656 1% /dev [16:53] tmpfs 1535548 296 1535252 1% /dev/shm [16:53] lrm 1535548 2384 1533164 1% /lib/modules/2.6.27-11-generic/volatile [16:53] Looks like the default one disk autopartitioned one [16:53] yup [16:59] Ok, I see it in the syslog on jaunty as well. Though the next line about symbols suggest it got system map somehow. Maybe you could verify the rootdelay. If that helps this is probably something timing replated in either grub or the init script. But probably grub. That is quite early in the boot [17:00] ok i will test it out, be right back [17:07] smb_tp_ that did not fix the problem [17:08] bcurtiswx, Ok, would have been strange if it did [17:10] smb_tp_: suggestions on importance of bug and if it has enough info for triage [17:23] smb_tp_: ? === smb_tp__ is now known as smb_tp [17:29] smb_tp: wb [17:30] bcurtiswx, Sorry, IRC doesn't like me today [17:31] smb_tp: no problem, IRC hates everyone. Do you have launchpad permissions to change importance of that bug? [17:31] About this bug. I think it can be counted as triaged. Importance is low I would say since it does not really affect usability of the systems [17:33] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/char/agp/intel-agp.c;h=7d8db5a611047bdf9179b002a25d0affc1516752;hp=9cf6e9bb017e6dca0b537bb04b70e5c49dbf705b;hb=a50ccc6c6623ab0e64f2109881e07c176b2d876f;hpb=4a6908a3a050aacc9c3a2f36b276b46c0629ad91 [17:33] bcurtiswx, I will see that it gets updated [17:33] that would be maybe a good backport [17:33] i can see that too (since im a bug traiger), i just don't have bug-squad permissions yet, so i can't set importance [17:34] added g41 chipset [17:34] bcurtiswx, So you need only importance set? [17:35] smb_tp: yeah, but i already requested bug-squad to take care of it [17:35] smb_tp: thx though [17:36] bcurtiswx, Ok [17:38] bcurtiswx, The puzzling question is still where the message exactly comes from. The "Inspecting", I do not find in the kernel, nor in the grub source code [17:39] yeah, i couldn't find exactly where either [17:40] im not knowledgeable to know exactly the right places to look, so im not going to say my search was anywhere near beneficial [17:41] bcurtiswx, cking_ found the strings in ksyslogd [17:41] smb_tp: http://lkml.indiana.edu/hypermail/linux/kernel/0507.1/1601.html [17:41] that help? [17:42] CarlFK1, Yes, seems to be the system log daemon [17:42] bcurtiswx, ^^^ [17:42] CarlFK1: ty [17:44] you're welcome === Omegamoon is now known as Omegamoon|away [17:45] Kano, that is likely to come in via the stable updates [17:46] Kano, i am looking at the revert you requested, doing some testing with some newer commits at the same time [17:46] well there was now .1 i would add it until you get it [17:46] hmm, idk how that helps fix my problem though [17:47] that appears to show that the system map file is found, giving no "cannot find map file" [17:48] yeah, all it helps to show its not the kernel... but who knows what.. lol [17:55] bcurtiswx: I've updated the bug report according to my findings [17:56] tyvm! [17:58] cking_: would u update the bug to triaged and an importance you see fit? nobody has responded to me in #ubuntu-bugs [17:58] bcurtiswx: OK [17:59] cking_: ty [18:10] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227 [18:10] Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [High,Triaged] [18:11] how important is it for me to repo that without "Tainted: P" (nvidia) [18:13] and I have logged 14 more netconsole dumps - http://dpaste.com/110823/ should I just keep attaching them till someone tells me to stop? [18:20] could someone pull the drm fixes I posted on the list? [18:23] tjaalton, its a holiday in the US today so i suspect people will be a bit slow picking those up [18:24] apw: oh, I wasn't aware of that [18:24] martin luther king day i believe, cirtianly obama seems to be painting something on my tb [18:24] tv [18:29] ok, I'll wait for a bit then [18:29] tjaalton, they were for jaunty correct? [18:30] apw: yes [18:32] smb_tp_: thanks for the pointer to gentoo/test [19:53] smb_tp_: any idea what the .deb version of "emerge -av boost" is? [19:54] in installed libboost-dev boost-build libboost1.35-dev, still get a ton of errors like: crashClnt.cc:(.text._ZN5boost15program_options16validation_errorD2Ev[boost::program_options::validation_error::~validation_error()]+0xab): undefined reference to `operator delete(void*)' [22:57] hi [23:44] Does canonical employ any kernel block subsystem developers?