[04:33] hi all! [04:34] I am testing jaunty beta, but I have an annoying regression: [04:34] when I reboot or halt, it stops at "will now halt" or "will now reboot" most of the times: any idea of how to debug that? [04:34] https://bugs.edge.launchpad.net/ubuntu/+bug/349778 [04:34] Malone bug 349778 in ubuntu "[jaunty] Dell Inspiron 1525 sticks on "System will now halt", works with 2.6.29" [Undecided,New] === asac_ is now known as asac [14:10] rtg: kees has got a patch for bug 350789 he'd like to see get in for jaunty final [14:10] Malone bug 350789 in linux "AppArmor Debug: Hook being called from interrupt context" [Medium,Triaged] https://launchpad.net/bugs/350789 [14:10] rtg: should he submit it to the kernel-team ml as well? [14:11] ogasawara: I looked at this, but I'm not wild about it. it seems like a hack to cover for a poorly written blue tooth driver. [14:12] kees: ^^ [14:18] lool: https://bugs.edge.launchpad.net/ubuntu/+source/linux/?field.searchtext=&orderby=-importance&field.tag=arm&search=Search [14:18] lool: current status of arm bugs. Anything else you need fixed _urgently_? [14:24] sconklin, I kicked the updated lpia configuration files to the list last night, which fixes d-i on ARM [14:33] NCommander: lpia config fixed d-i on arm? [14:33] wow [14:34] I think my brain crapped out half way through that sentence [14:34] lpia config to fix d-i on lpia :-/ [14:34] hehe... [14:34] * NCommander needs coffee .... lots of it [14:37] NCommander: I responded on list [14:50] sconklin, try this http://meandubuntu.wordpress.com/2008/11/18/real-64-bit-flash-on-amd64/ === __Purple__ is now known as _Purple_ === _Purple_ is now known as _Pink_ [16:09] hi guys, [16:10] one question: in kernel 2.6.28, is WideView WT-200U and WT-220U (pen) DVB-T USB2.0 support (Yakumo/Hama/Typhoon/Yuan) avail in this kernel? [16:14] rtg: jj said a similar thing when he saw the bug. perhaps a small modification to leave the "BUG" report and to correctly handle the memory allocation method just to reduce possible instability? [16:15] Please use and update as needed - https://wiki.ubuntu.com/GitCheatSheet [16:26] hi there, compiling custom kernel for macbook4.1 [16:26] all good, just need some info on how to get pretty package names [16:26] today I'm doing nasty hack, just replace config and let it generate [16:26] but generates as 2.6.28-11-GITHASH-generic [16:27] I guess it would be better to have it as 2.6.28-11-macbook41 (flavor=macbook41) [16:27] manjo mentioned to me I should update debian/changelog [16:28] but do I need a git-tag with the name within parenthesis? [16:29] you could change the 1st line on debian/changelog to something like ::: linux (2.6.28-10.33~lp326621manjo1) UNRELEASED; urgency=low [16:29] did it already [16:29] k [16:29] but before generating, I would like to know what more do I need [16:30] ie: why changing the config will lead to hash in the name? since I have debian/changelog it should use that top line, no? [16:30] so I'm guessing it does some git<->changelog mapping somehow [16:31] guys, does the 2.6.28 have the support for WideView DVB pen usb receiver? [16:31] WideView WT-200U and WT-220U (pen) DVB-T USB2.0 === _Pink_ is now known as _Purple_ [16:42] k-s, apw might know more abt git<->changelog stuff [16:43] manjo: ok, it's not possible to have '~' in tag name, so I suppose you don't do a tag and still have the package name correctly [16:43] maybe it was like that because I had uncomitted git changes, let's see if it works now with changelog + git commit [16:44] manjo: and thanks for your time, I know you're quite busy there [16:44] apw, ^^^ [16:44] k-s, apw is the git guru [16:44] apw: hey :-) [16:45] smb_tp: How long does the ltp suite take? [16:45] huh there is lots of info here, what was the question? [16:45] apw: if you have some time, it's more related to debian/ubuntu packaging than anything else, from what I've read I need to create a custom "flavor" to live side by side with "generic" [16:45] wahts the difference between your new kernel and generic? [16:45] apw: I want to have a custom macbook41 flavor, since I know all the hw it's there (except pluggable usb/firewire) [16:45] infinity, depending on the hw pretty long. never measured it [16:46] smb_tp: Minutes, hours, or days? :) [16:46] infinity, hours [16:46] Ow. [16:46] apw: I'm using it for some time already, compiles really fast (so no trouble to maintain) and works better, no need for initramfs and thus boots fast [16:46] * infinity kisses artigas goodbye for a bit. [16:46] also I like to have my own kernels, it's an old habit [16:47] so you want to stop is our kernel updates eating your kernel? [16:47] infinity, what was the question abt ltp ? [16:47] infinity, might be something in the size of 3hrs, but as said, I usually fired it up on a machine and looked back later [16:47] manjo, how long it is running [16:48] apw: no, just want to have a nice package name ;-) [16:48] apw: I already disabled my kernel being replaced in config files, that's fine [16:48] apw: but I'd like to have something better than 2.6.28-11-1c2a1a-generic [16:48] hrm, then i guess a flavour name is reasonable thats what a flavour is, a different config combination [16:49] depends on how you run it also... ie if you have genload running in the background it might take longer [16:49] genload will run if you run with system load options in runltp [16:50] apw: yep, but I tried to have my own flavour and it didn't work, at least followed a wiki+blog and it did not work, maybe I missed something obvious since I was in a hurry, AFAIR it was related to some files it expected in debian/ not being there like old version symbols or so [16:51] apw: also, what's annoying now is that it will always add -GITHASH to name, so I need to go there and update control{,.stub} [16:51] githash is addwhen when your tree is dirty [16:53] apw: I just do git clean -fxd before running debian/rules [16:53] there is an optiion somewhere, _AUTO in the config which triggers the addition [16:55] apw: which config? kernel or debian/*? [16:57] kernel config, in debian/configs/* [17:00] apw: from debian/rules.d/2-binary-arch I see that it will forcely disable it [17:03] ok, tried with git committed and changelog, still no luck [17:04] my cmdline reads: ./debian/rules binary-generic AUTOBUILD=1 NOEXTRAS=1 CONCURRENCY_LEVEL=2 no_dumpfile=1 [17:26] how do I make this auto inc so that it shows up as a default for new data? db.Field( 'seq', 'integer', ), [17:27] um.. that sounds weird... [17:29] woa.. wrong #chan [17:59] amitk: the FSL stuff is urgent, and is in your inbox [17:59] lool: it is already *in* [18:02] amitk: (I couldn't tell since I got no update via email) [18:03] I pulled the git tree now and I see some [18:40] smb_tp: Your kernel boots on artigas, userspace and dmesg seem happy, running ltp now to compare to the previous kernel. [18:40] smb_tp: (I'm comparing to -51-, since that's what was installed... If you need a comparison against -53- so we're only isolating your changes, I can do that later) [18:42] infinity, Err, I am a bit slow catching, by the numbers this sounds like hardy, which architecture is artigas? [18:42] smb_tp: Dapper. Even. Sparc. Testing your "omg, syscall tables completely rewritten" kernel. [18:43] infinity, Ah, cool. [18:44] Oh, yeah. For dapper its -53 and for hardy 24.52. That confused me === k-s is now known as k-s[AWAY] === Nicke_ is now known as Nicke [19:44] hi - how can I make sure that a certain changeset is the jaunty kernel? [19:44] hi - how can I make sure that a certain changeset is *in* the jaunty kernel? [19:45] I'm looking for changeset c073b2db006ba9370be1eecc36a1be1d9ce31310 [19:46] git log | grep [19:46] c073b2db006ba9370be1eecc36a1be1d9ce31310 === k-s[AWAY] is now known as k-s [19:59] hi, folks. with the desktop kernel turning non-preemptible, are there significant differences other than tick frequency and numa support between the desktop and server kernels? === k-s is now known as k-s[AWAY] [20:03] neuralis, http://www.ubuntu.com/products/whatisubuntu/serveredition/features/kernel [20:08] manjo: aha, neat. wasn't aware of that page. thanks! [20:09] np [20:31] any kernel hackers knowledgeable about the SATA subsystem? #257790 is bothering me (I have four new SATA disks I'd like to use), and I'd be glad to help debugging this [20:53] liw, does it work with jaunty ? [20:54] liw, have you tried the jaunty live cd to see if it works ? [20:55] manjo, as I said in the bug, I've tried everything from gutsy onwards; gutsy works, nothing later does [21:26] liw, can you try with kernel option iommu=soft ? === k-s[AWAY] is now known as k-s [21:44] smb_tp: Still around? [21:44] infinity, yep [21:44] smb_tp: http://lucifer.0c3.net/~adconrad/ltp-results/ [21:45] infinity, looking quickly, it looks like no diff which sounds good [21:46] smb_tp: 53 and 54 are identical. From 51 to 53, there were changes, which I'm not sure were intentional. [21:47] infinity, Have only been looking at the summary, so the overall was equal [21:48] infinity, have to get it downloaded and look [21:50] smb_tp: Still, given all the ridiculous mangling in your test kernel, the lack of regression from 53 to 54 is comforting. :) [21:51] infinity, true enough :) Either there are not many dapper users or nobody really had bad experience with that other change [21:52] smb_tp: Well, there were two fixes (pty and pwrite), and then the writev flip-flopping, I'd have to check to see what the test is actually doing to see if it's a regression, fix, or a wash. [21:52] smb_tp: But it seems fine to me. [21:53] kees, ^^^ I would be fine with it as -51 is quite some time ago [21:53] smb_tp: In a day or two, we won't be running dapper/sparc in the DC anymore either (I've been in the process of ugrading all our sparc machines to hardy), so the point's somewhat moot to me. [21:55] smb_tp: yeah, I'm fine with the -51 to -53 regresssions -- no one else seemed to notice. it's the -53 to -54 we need to study, and so far so good. [21:56] kees: Like I said, the test output for 53 and 54 were identical on artigas, and it seemed pretty happy with the whole thing. [21:56] smb_tp: I'm happy with the LTP output we've seen. shall I shove dapper into the build queue too? [21:56] infinity: yeah [21:57] smb_tp: If any of the patches touched smp-specific bits, might want to make sure sparc64-smp is also in good shape, but it's a thumbs-up here for UP. [22:02] sbeattie: you said you had a single test regression on your ultra60? is it smp? [22:05] infinity, O am not aware of anything smp specific out of my head. [22:08] kees: it is. [22:09] sbeattie: can you spin a few more tests on -53 and again on -54? [22:09] I've reproduced the oops; running ltp *outside* of screen seems to trigger it; I ran my -53 test under screen, so I'm seeing if it reproduces there. [22:10] kees: sure thing; like I said, it just takes a little while. [22:11] * kees nods [22:12] ironically, oopsing on -53 is okay in this case. :P [22:12] kees: indeed! I'd do a happy dance if it oopsed on -53. :-/ [22:12] alas, it appears not to. :-( [22:14] oh. dang [22:14] sbeattie: And this is actually reliably reproducible in -54? [22:15] There could be a chance this is related to "sparc: Fix mremap address range validation." as well [22:29] smb_tp: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blobdiff;f=drivers/bluetooth/btusb.c;h=d4ec9a98fb19a2cefccd4a0f71f22826dcd11fb6;hp=3b0545ba59f204301e1191dd27acc5e7816e4568;hb=1bb9aba826e75a31c719e5ef60ba616e53ae09bd;hpb=66f550e4f758fc8a0f78f35395d283d526dc9c37 has a compile error [22:37] smb_tp: If you do any more work on that kernel and need a re-test on artigas, let me know. [22:39] infinity, Ok, will do. Thanks === mathiaz__ is now known as mathiaz [22:45] amitk: follow up on 351924 is appreciated [23:01] bah; every time I think I have a grip on reproducing this oops, I then can't reproduce it. [23:02] has anyone pulled these? [23:02] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=395d73413c5656c6d7706ae91dcb441f9b7e3074 [23:03] DaemonFC: you can check yourself in ubuntu-jaunty.git [23:04] I was asking Eric Sandeen about that cause I just crashed a few hours ago [23:04] dtchen: will try to have it for you by tomorrow. Not near the machine currently [23:04] and lost some data that hadn't been committed [23:04] amitk: that's fine, thanks [23:54] hi, i found a missing firmware for 2.6.28+ for a dvb-s2 card for hauppauge [23:55] dvb-fe-cx24116.fw [23:55] should i write to the list? [23:55] or does somebody directly want to add it.. === k-s is now known as k-s[AWAY]