=== mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has joined #ubuntu-kernel === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [12:56] hey folks === mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has left #ubuntu-kernel [] === mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has joined #ubuntu-kernel === Seveaz [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel === ik5pvx_ [i=bofh@host164-143.pool8257.interbusiness.it] has joined #ubuntu-kernel === doko__ [n=doko@dsl-084-059-068-011.arcor-ip.net] has joined #ubuntu-kernel [02:03] Should a mobile AMD Athlon(tm) use a k7 kernel? [02:03] i believe so [02:03] Cool, tx. [02:04] jbailey: i responded to that bugzilla about the dvb headers... the way i fixed it should solve the problem for all distros [02:06] mkrufky: Nice, thanks! [02:06] I'll look at the bug in a few minutes to see what the solution is. [02:06] ok... would be nice to hear from the original user if it works [02:06] (before we close the bug) [02:06] mkrufky: Are you still interesting in being involved in dvb/v4l with Ubuntu? [02:06] ya [02:07] People often don't answer, it's not usually worth waiting for them to reply if you beleive that it's actually fixed. [02:07] i guess ur right [02:08] but yes, i am interested in being involved in dvb/v4l w/ Ubuntu... [02:11] Cool. Did you get a chance to talk with BenC about it at all? [02:12] or just close it, some people open bug reports and never get back to you [02:12] he was discussing gcc dependencies for kernel-package that other day... didnt really say much to me [02:13] he did say i was always welcome here... thats basically iy [02:13] it === ik5pvx__ [i=bofh@host185-143.pool8257.interbusiness.it] has joined #ubuntu-kernel [02:17] gah...simpsons sucks [02:25] zul: ur right... this episode sux === ik5pvx__ [i=bofh@host95-143.pool8257.interbusiness.it] has joined #ubuntu-kernel === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel [03:29] BenC: shouldnt it be CONFIG_ACPI_BOOT=n for 686-smp?\ === macgyver2 [n=eric@unaffiliated/macgyver2] has joined #ubuntu-kernel === macgyver2 [n=eric@unaffiliated/macgyver2] has left #ubuntu-kernel ["Leaving"] [03:33] hah hah...ottawa is beating toronto in pre-season nhl === ik5pvx__ [i=bofh@host26-64.pool8259.interbusiness.it] has joined #ubuntu-kernel [03:44] zul: I dunno, should it? [03:47] i been reading some people have problems with smp and acpi [03:48] will disabling acpi hurt anything? [03:49] not sure...but its gone in 2.6.13 [03:49] maybe mjg59 would be the best person to ask :) [03:50] acpi is gone? [03:50] or the acpi/smp bug? :) [03:50] for smp i think...gimme a sec...i saw it on bugme [03:51] yeah, acpi disabled on smp would make sense I guess [03:52] 2745 on bugme.osdl.org [03:53] uh...no thats wrong [03:53] 2495 [04:13] night night === mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has left #ubuntu-kernel [] === ik5pvx__ [i=bofh@host149-143.pool8257.interbusiness.it] has joined #ubuntu-kernel === mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has joined #ubuntu-kernel === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel [05:34] morning fellas [05:51] mkrufky: ping? === ik5pvx__ [i=bofh@host117-143.pool8257.interbusiness.it] has joined #ubuntu-kernel [06:06] fabbione: pong [06:07] hey mkrufky [06:07] hello [06:07] may i take a few minutes of your time? if you are not busy [06:07] sure [06:07] great [06:08] there is a friend of mine here on IRC that is building a HTPC [06:08] (so am i) [06:08] ok [06:08] he is not online now, but i think he would like to talk with you to have some suggestions about what kind of DVB cards to buy [06:09] what country does he live in? [06:09] i would be really glad if you could give him some suggestions when he will be around [06:09] italy [06:09] and i am in denmark [06:09] ok... you should tell him to go into #linuxtv [06:09] ok.. on this net? [06:09] yes [06:09] ok [06:10] the dvb drivers are discussed in #linuxtv and the analog drivers in #v4l [06:10] for me instead i am looking for a TV/FM card only for now... [06:10] ok.. so i guess i need to join #v4l [06:10] :) [06:10] hehe [06:10] most cards are supported [06:10] thanks :) [06:10] if u get an unsupported one, you can help us to add support for it [06:10] yeah but i have a very limited selection of hw [06:11] if u tell me what u have access to, i'll let u know which is better supported [06:11] bttv-based cards have the best support, but that is an older chip [06:11] like pinnacle, asus (one model), Hauppauge and trust [06:12] cx2388x and saa713x based boards are also very well supported [06:12] skipping trust that i don't like [06:12] yeah but there is no indication of the chipset :/ [06:12] that's why i was seeking for help :P [06:12] those pinnacle and hauppauge are mostly supported [06:12] do u know any model #'s [06:12] hauppauge claims to be "Win-TV" something.... [06:12] yeps [06:13] i can take you there.. [06:13] k [06:13] www.shg.dk [06:13] sec.. mozilla died.. again [06:14] Hardware -> Tv-Kort (3rd col to the bottom) [06:14] i think all 4 of those carfds are supported [06:14] click (alle) [06:14] we have a relationship with hauppauge [06:15] ah [06:15] that sounds good [06:15] if there is an unsupported card, they help us by giving us some info [06:15] once you get to that page, if you click on the icon with the pic of the board, you get the specs [06:15] but they never mention the chipset [06:16] but there are the references to the producer site [06:16] ya i see [06:16] thats aannoying [06:16] yeah. but it's a very good hw reseller here in sk [06:16] dk [06:16] http://www.hauppauge.com/Pages/products/data_pvr500mce.html [06:17] i think wintv pvr500 might not be supported yet [06:17] perfect :) [06:17] but we just added support for 550 [06:17] (it's also too expensive) [06:17] so, you can buy the 500 and help us to test and add new support for it [06:17] the hardware is very similar to 550 [06:17] so it would be easy [06:18] yeah but i am hounest, i wouldn't be able to allocate time for it [06:18] other than doing testing [06:18] i am not into v4l code or DVB code at all [06:19] and i guess you need such a board locally to be able to work on it [06:19] thats all u'd really need to do... we would need u to read us some #'s off the card and run some tests [06:19] mkrufky: can this stuff be done remotly? [06:19] card programming is simple... just a definition of what drivers to call with what options [06:20] yes, it can be done remotely, but it is handy to have someone nearby in case reboot is necessary [06:20] yeah of course [06:20] i can live with rebooting the box :) [06:20] :-) [06:20] u never know... maybe someone else will add support before you receive it in the mail [06:20] :-P [06:20] eheh true [06:21] but i can't see the 550 on their product line.. [06:21] our cvs has been very active lately [06:21] yeah i am sure it is :) [06:22] that pvr 500 looks real nice to me [06:23] i like the idea of the 2 tuners [06:23] ya its nice [06:23] they use a conexant chipset [06:23] looks like it does not do HDTV tho [06:23] yes, it is supported [06:24] we don't have HDTV here anyway :) [06:24] ooh oops... this board... maauro has it [06:24] we barely have an antenna ;) [06:24] mauro is v4l maintainer... hauppauge sent him that board for him to add support for it [06:24] cool [06:24] cx23416 chipset [06:24] X2 [06:25] "each with their own hardware MPEG encoder!" [06:25] yes [06:25] lovely [06:25] this is great... uses less cpu [06:25] the name of the driver is cx88-blackbird [06:25] ah [06:25] perfect! [06:26] and i think that board might be supported by ivtv , not sure [06:26] oh [06:26] we're working with the ivtv people to merge their stuff into v4l [06:26] you convinced me :) [06:26] :-) [06:26] yeah i have been asked to merge ivtv once into the ubuntu kernel [06:26] but there were too many bits i didn't like [06:27] such as conflicting drivers [06:27] it is easier for distro's to do something like that.... vanilla kernel cant quite do that [06:27] yes [06:27] but i will have to wait a bit to buy this card.. it's a bit too expensive atm [06:27] they could instead, have an ivtv package in the repository [06:28] and if you did that, you might as well also have a v4l update package in the repository as well [06:28] i think that would have to mask each other out though [06:28] it's still an issue to provide kernel drivers in an external package [06:28] why is that? [06:28] we have a simple rule.. [06:29] whatever is GPL and can be merged into the main kernel, we do it [06:29] hmmm... dont merge ivtv then... it DOES conflict with v4l [06:29] the issue of having extra kernel drivers packages goes to security [06:29] i didn't merge it :) [06:29] let me explain in few words [06:29] the main tech issue is when we need to provide security updates [06:30] let say that we do update the main kernel and this gets to change its ABI [06:30] as it is now: we upload 2 packages and everybody is happy [06:30] if we start to ship N external packages, all of these need to be rebuild (and possibly fixed) against the new kernel [06:31] that takes hell of a lot of time and resources [06:31] so it's easier to a certain degree to keep everything in the main kernel [06:31] but clearly we need to make a selection of what can go in [06:31] i c [06:31] and what has to stay out [06:32] do u ever backport features from newer kernels into your current kernels? [06:32] yes [06:32] it of course depends what we need to backport [06:33] how conservative about that stuff is ubuntu? [06:33] well if you are asking me to backport a new MM layer, i would clearly say no [06:33] if we are talking about drivers we are more flexible [06:33] hehe ya of course [06:33] it also depends on what development season stuff shows up [06:34] right now at 3 weeks from release, it's only heavy bug fixing and security fixes [06:34] we still have exceptions but they are more unique than rare [06:34] makes sense [06:35] we are flexible to the point that in the beginning of the development season we can include all kind of junk [06:35] if it results to be buggy, we kick it out before FeatureFreeze [06:35] it means that we have no issue to push crack around to user for testing [06:35] but it gets the time in which we make decision.. and sometimes it's though [06:36] well, i guess when it comes time to upgrade your kernel to the next mainline version, i could give you a v4l/dvb update patch against that mainline version [06:36] sure [06:36] that would be very nice [06:37] i understand that your most likely not going to adopt 2.6.13 [06:37] not for breezy.. no [06:37] i wouldnt expect that you would want such a patch against 2.6.12 for breezy [06:37] i am pretty sure we will got .13 or .14 for dapper (breezy+1) [06:37] shhhh [06:37] mkrufky: it depends how big it is :) [06:38] mkrufky: we are at 3 weeks from release [06:38] hmm... does that mean a lot of time or a little time? [06:38] dapper is ultra-secret codename :) [06:38] little [06:38] desrt: no it's not :) [06:38] it's been announced on ubuntu-devel a while ago ;) [06:38] pfah. jeff seems to think it is [06:38] ah. [06:39] a dingo is an awful animal [06:39] hmm... maybe tomorrow i'll see what a diffstat of our current stable snapshot looks like against 2.6.12 [06:39] well... the animal isn't bad [06:39] but i mean... as a name! [06:40] mkrufky: ok.. [06:40] mkrufky: thanks a lot for all your suggestions :) [06:40] fabbione: no problem [06:40] fabbione; is benc still the man? [06:41] ive got an unrelated question then.... [06:41] desrt: yeps [06:41] mkrufky: sure if i can help [06:41] do u have zaptel in your kernel? [06:41] hm. hopefully he is around tomorrow, then [06:41] mkrufky: oh hmm.. can't remember [06:41] it is not in mainline, and probably will never be [06:41] let me check [06:42] it is device driver for the digium boards [06:42] for asterisk [06:42] i am checking.. [06:43] k [06:43] we added quite a bunch of external drivers [06:43] so i don't exactly remember all of them [06:43] zaptel is also quite actively changing in cvs [06:43] nope we don't [06:44] ya i didnt think so... [06:44] so anyone that wants to make a pbx will have to install that kernel driver from cvs, and lose ubuntu support? [06:45] mkrufky: well not really... [06:45] or better.. it depends [06:45] i was told that installing external modules causes loss of support [06:45] let say that the standard kernel works on machine foo [06:45] and you add a module [06:45] and the kernel starts to oops [06:45] than well.. there isn't much i can do there [06:46] (like with nVidia binary crap) [06:46] but if the kernel oops before and after.. makes no difference [06:46] you could always say, "it must be your externel module... ask #foo for help with that" [06:46] now.. if you are talking about commercial support.. i have no idea.. [06:46] mkrufky: well as i explained above, if the kernel works and only adding that module starts to oops.. [06:47] ya i gotcha [06:47] it is sort of clear that the module might either be buggy or exploit a bug in the kernel [06:47] but if i get an oops that is related only to that driver.. [06:47] well than i need to forward you to #foo [06:47] ya [06:49] but note.. this is true for drivers of which i can read the code.. [06:49] if i get bugs like "NVidia driver oops" [06:49] i don't even bother to check [06:49] i send them to nvidia forums [06:50] no code.. there is nothing i can do [06:50] ya we do the same in #v4l [06:50] ok :) [06:50] nvidia should just open up their drivers [06:50] oh well [06:51] i use all ati [06:51] :-D [06:51] they both should :) [06:51] true [06:51] but there are some good oss ati drivers [06:52] yes [06:52] they should still open up [06:52] i agree [06:52] brb.. i have to wake up my wife [06:52] k [06:52] i'm actually goin to bed soon [06:52] was nice chattin [06:57] thanks a lot mkrufky [06:57] good night [06:58] nite === mkrufky [n=mk@user-12lcl1s.cable.mindspring.com] has left #ubuntu-kernel [] === jorgp2 [n=jorgp@bnet-dial-32.bartnet.net] has joined #ubuntu-kernel === karlheg [n=karlheg@host-250-237.resnet.pdx.edu] has joined #ubuntu-kernel === JaneW [n=JaneW@wbs-146-149-243.telkomadsl.co.za] has joined #ubuntu-kernel [11:01] BenC: how do you feel about applying http://bugzilla.ubuntu.com/attachment.cgi?id=1985 ? [11:02] (I know it's late in the release cycle, but I was made aware of it late.) === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel [01:44] BenC: When are we looking at a new kernel release? === Seveaz [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel [01:58] mjg59: this week [01:58] BenC: Any idea when? [01:59] Wed or Thu [01:59] BenC: what about the p4-clockmod patch? [02:00] Mithrandir: which bug report is that for? [02:00] BenC: Ok. Kernel freeze is the end of next week? [02:00] BenC: http://bugzilla.ubuntu.com/show_bug.cgi?id=8587 [02:00] hey BenC [02:00] BenC: i did commit all the sparc stuff to baz [02:00] let me know when it's time to prebuild before release [02:01] this is the last kernel.. if we fuck it up, we lose sparc for breezy [02:01] Uh. We're only doing one more release? [02:01] mjg59: yes [02:02] and i think we are already pretty late [02:02] we should be already in Security only bug fixing iirc [02:02] Ok. That presents certain problems. [02:02] we are at 3 weeks from release [02:03] let me check the schedule [02:04] if anyone wants patches added to the kernel before this next release, please can you send me a diff with the .dpatch, changelog entry and 00list-8.14 entry added? [02:04] I have about 3 bug reports that I need to do some hardcore kernel debugging with, before this next release [02:04] going to be time consuming [02:04] kernel freeze is the 24th [02:04] so that means friday [02:05] sorry [02:05] Friday is the latest then [02:05] 29th [02:05] so in 10 days [02:11] BenC: well, I would like a comment on the bug I mentioned above; I don't know kernel stuff enough to tell whether it's correct or not. [02:18] Mithrandir: hold a sec [02:20] Mithrandir: the patch is clean, so I think it can go in [02:20] BenC: excellent, can you wrap it up or should I commit it to the archive? [02:20] it might also fix some other bug reports (powernowd causing screwed up mouse, cpufreq messing up the clock speed) [02:21] If you have the time, please do [02:21] if not, shoot me an email as a reminder [02:21] I can just do it. [02:21] (it's not that I don't have enough to do, but it's trivial enough. :) [02:21] :) === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [02:24] hey peeps [02:28] hey zul [02:29] how is it going ben? [02:29] not too bad [02:29] how about you? [02:29] good...after recovering from a flu bug and a cold as well as good be expected [02:30] hey zul [02:30] nasty, I hate the flu more than anything [02:30] BenC: so we have only 3 pkgs that are FTBFS on sparc/main/breezy :) === chmj [n=chmj@wbs-146-149-215.telkomadsl.co.za] has joined #ubuntu-kernel [02:30] one of which we don't really care [02:30] yeah i had chills and hot flashes...i think i got it from fabbio... [02:30] hey fabbione [02:31] but kernel and klibc yes.. we do :) [02:31] zul: i told you not to lick my nose while i am sleeping! [02:31] fabbione: you said klibc was getting fixed, right? [02:31] BenC: jbailey was going to look at it... [02:31] kernel is fixed if we don't change the hell in it [02:31] what's wrong with klibc on sparc? [02:31] better than your nose than your nuts [02:32] BenC: it builds in 64bit mode... [02:32] and it fails in 32bit [02:32] zul: yeah, that'd probably be a whole different sickness :) [02:32] mimatch = crash at boot [02:32] probably busybox-initramfs [02:32] hehe [02:33] bah i have 15 minutes.. i can give it a shot [02:33] fabbione: kernel crash, or crash in klibc? [02:34] BenC: same kernel works with initrd [02:34] i get an oops [02:34] but it's too early in the boot process to understand what's wrong [02:34] does klibc run in kernel mode? [02:34] no idea [02:34] i don't think so [02:34] is it just a stripped down libc like uclibc? [02:34] afaik yes [02:35] hmm, and 32-bit mode causes a kernel crash...that sounds more like a kernel bug (assuming klibc runs in userspace mode) [02:35] BenC: It does. [02:35] nope.. i think it's the mistmatch between klibc being built in 64bit and busybox in 32 [02:35] hey jbailey [02:36] if klibc is causing a kernel crash on sparc64, that's really bad [02:36] BenC: The kernel crash is almost certainly because there's nothing left to do, so the shell script dies. [02:36] As opposed to a real crash. [02:36] ah [02:36] so it's like init dieing? [02:36] Yup [02:36] ok, I feel better now :) [02:36] why is klibc being built as 64-bit? [02:36] BenC: the same exact kernel boots perfectly if we use initrd [02:37] that's why i pointed the finger at klibc [02:37] initrd uses installed libc? [02:37] BenC: Because it sucks. I haven't fixed it yet, I ran out of time this weekend. [02:37] BenC: eh that's the interesting problem [02:37] it's FTBFS on 32bit more [02:37] the one in the archive was my mistake building it manually [02:37] libgcc is pulling in .umul in 32 bit mode for some reason. [02:37] ah, where's the package, I can have a look later tonight maybe [02:37] and it did build in 64bit [02:37] I don't think it'll be hard to fix. [02:37] BenC: klibc [02:37] easy enough :) [02:38] BenC: do you want access to the sparc with the chroots? [02:38] It was totally a case of I spent all of Saturday polishing up the initramfs-tools package, and Sunday needed a break. [02:38] nah, I can just build it here === jbailey really needs to find a null modem cable to get his U5 running. [02:38] jbailey: you polished it so much that somebody did open a critical on it :) [02:39] fabbione: Great. I'll punt it to mjg59. He sent me the patch that broke it. [02:39] ahahha [02:39] Apparently USB drivers suck and can'tbe loaded before a resume. [02:40] no shit... [02:40] So we had to split up the driver passes and do a resume after only the controllers are walked. [02:40] i managed today only after 6 months to get my USB webcam to work [02:40] But that's before md runs, before lvm runs, before evms runs... [02:40] Oh! Since I have you both here. I have update-initrfs in the package I just uploaded now. [02:40] So I need to do a hack again to use that now instead. [02:41] jbailey: Mm? [02:41] mjg59: 15775 [02:41] jbailey: can you unload drivers before a resume? [02:41] mjg59: It looks like resume isn't working in some case there. [02:41] mjg59: Wondering if you've thought of some magic way of making this all Just Work without me rewritting all of the logic in there? [02:42] mjg59: Like, I could walk the tree and maybe *unload* the USB drivers or something... [02:42] err, I mean unload drivers before a suspend and then reload them [02:42] BenC: We do [02:42] jbailey: the e100 and e1000 drivers fail if they are loaded during a suspend, and then are reloaded for the resume [02:42] mplayer http://gordian.fabbione.net:8090/fabcam.rm <- [02:42] not everybody all together please [02:42] BenC: The problem is that the driver gets loaded by initramfs, the old image is read back and then the module is loaded again [02:43] jbailey: It's not just USB. It's basically *everything*. [02:43] if e100 and e1000 can be unloaded prior to the suspend, it may be a workaround that is needed if I can't figure out this 1 year old bug [02:43] BenC: They *are* unloaded prior to the suspend [02:44] All network and USB drivers are unloaded [02:44] mjg59: prior to the suspend state being saved to disk? [02:44] Yes [02:44]