[12:56] <zul> hey folks
[02:03] <jbailey> Should a mobile AMD Athlon(tm) use a k7 kernel?
[02:03] <zul> i believe so
[02:03] <jbailey> Cool, tx.
[02:04] <mkrufky> jbailey: i responded to that bugzilla about the dvb headers... the way i fixed it should solve the problem for all distros
[02:06] <jbailey> mkrufky: Nice, thanks!
[02:06] <jbailey> I'll look at the bug in a few minutes to see what the solution is.
[02:06] <mkrufky> ok... would be nice to hear from the original user if it works 
[02:06] <mkrufky> (before we close the bug)
[02:06] <jbailey> mkrufky: Are you still interesting in being involved in dvb/v4l with Ubuntu?
[02:06] <mkrufky> ya
[02:07] <jbailey> 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] <mkrufky> i guess ur right
[02:08] <mkrufky> but yes, i am interested in being involved in dvb/v4l w/ Ubuntu... 
[02:11] <jbailey> Cool.  Did you get a chance to talk with BenC about it at all?
[02:12] <zul> or just close it, some people open bug reports and never get back to you
[02:12] <mkrufky> he was discussing gcc dependencies for kernel-package that other day... didnt really say much to me
[02:13] <mkrufky> he did say i was always welcome here... thats basically iy
[02:13] <mkrufky> it
[02:17] <zul> gah...simpsons sucks
[02:25] <mkrufky> zul: ur right... this episode sux
[03:29] <zul> BenC: shouldnt it be CONFIG_ACPI_BOOT=n for 686-smp?\
[03:33] <zul> hah hah...ottawa is beating toronto in pre-season nhl
[03:44] <BenC> zul: I dunno, should it?
[03:47] <zul> i been reading some people have problems with smp and acpi 
[03:48] <BenC> will disabling acpi hurt anything?
[03:49] <zul> not sure...but its gone in 2.6.13
[03:49] <zul> maybe mjg59 would be the best person to ask :)
[03:50] <BenC> acpi is gone?
[03:50] <BenC> or the acpi/smp bug? :)
[03:50] <zul> for smp i think...gimme a sec...i saw it on bugme
[03:51] <BenC> yeah, acpi disabled on smp would make sense I guess
[03:52] <zul> 2745 on bugme.osdl.org
[03:53] <zul> uh...no thats wrong
[03:53] <zul> 2495
[04:13] <zul> night night
[05:34] <fabbione> morning fellas
[05:51] <fabbione> mkrufky: ping?
[06:06] <mkrufky> fabbione: pong
[06:07] <fabbione> hey mkrufky 
[06:07] <mkrufky> hello
[06:07] <fabbione> may i take a few minutes of your time? if you are not busy
[06:07] <mkrufky> sure
[06:07] <fabbione> great
[06:08] <fabbione> there is a friend of mine here on IRC that is building a HTPC
[06:08] <fabbione> (so am i)
[06:08] <mkrufky> ok
[06:08] <fabbione> 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] <mkrufky> what country does he live in?
[06:09] <fabbione> i would be really glad if you could give him some suggestions when he will be around
[06:09] <fabbione> italy
[06:09] <fabbione> and i am in denmark
[06:09] <mkrufky> ok... you should tell him to go into #linuxtv
[06:09] <fabbione> ok.. on this net?
[06:09] <mkrufky> yes
[06:09] <fabbione> ok
[06:10] <mkrufky> the dvb drivers are discussed in #linuxtv and the analog drivers in #v4l
[06:10] <fabbione> for me instead i am looking for a TV/FM card only for now...
[06:10] <fabbione> ok.. so i guess i need to join #v4l
[06:10] <fabbione> :)
[06:10] <mkrufky> hehe
[06:10] <mkrufky> most cards are supported
[06:10] <fabbione> thanks :)
[06:10] <mkrufky> if u get an unsupported one, you can help us to add support for it
[06:10] <fabbione> yeah but i have a very limited selection of hw
[06:11] <mkrufky> if u tell me what u have access to, i'll let u know which is better supported
[06:11] <mkrufky> bttv-based cards have the best support, but that is an older chip
[06:11] <fabbione> like pinnacle, asus (one model), Hauppauge and trust
[06:12] <mkrufky> cx2388x and saa713x based boards are also very well supported
[06:12] <fabbione> skipping trust that i don't like
[06:12] <fabbione> yeah but there is no indication of the chipset :/
[06:12] <fabbione> that's why i was seeking for help :P
[06:12] <mkrufky> those pinnacle and hauppauge are mostly supported
[06:12] <mkrufky> do u know any model #'s
[06:12] <fabbione> hauppauge claims to be "Win-TV" something....
[06:12] <fabbione> yeps
[06:13] <fabbione> i can take you there..
[06:13] <mkrufky> k
[06:13] <fabbione> www.shg.dk
[06:13] <fabbione> sec.. mozilla died.. again
[06:14] <fabbione> Hardware -> Tv-Kort (3rd col to the bottom)
[06:14] <mkrufky> i think all 4 of those carfds are supported
[06:14] <fabbione> click (alle)
[06:14] <mkrufky> we have a relationship with hauppauge
[06:15] <fabbione> ah
[06:15] <fabbione> that sounds good
[06:15] <mkrufky> if there is an unsupported card, they help us by giving us some info
[06:15] <fabbione> once you get to that page, if you click on the icon with the pic of the board, you get the specs
[06:15] <fabbione> but they never mention the chipset
[06:16] <fabbione> but there are the references to the producer site
[06:16] <mkrufky> ya i see
[06:16] <mkrufky> thats aannoying
[06:16] <fabbione> yeah. but it's a very good hw reseller here in sk
[06:16] <fabbione> dk
[06:16] <fabbione> http://www.hauppauge.com/Pages/products/data_pvr500mce.html
[06:17] <mkrufky> i think wintv pvr500 might not be supported yet
[06:17] <fabbione> perfect :)
[06:17] <mkrufky> but we just added support for 550
[06:17] <fabbione> (it's also too expensive)
[06:17] <mkrufky> so, you can buy the 500 and help us to test and add new support for it
[06:17] <mkrufky> the hardware is very similar to 550
[06:17] <mkrufky> so it would be easy
[06:18] <fabbione> yeah but i am hounest, i wouldn't be able to allocate time for it
[06:18] <fabbione> other than doing testing
[06:18] <fabbione> i am not into v4l code or DVB code at all
[06:19] <fabbione> and i guess you need such a board locally to be able to work on it
[06:19] <mkrufky> 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] <fabbione> mkrufky: can this stuff be done remotly?
[06:19] <mkrufky> card programming is simple... just a definition of what drivers to call with what options
[06:20] <mkrufky> yes, it can be done remotely, but it is handy to have someone nearby in case reboot is necessary
[06:20] <fabbione> yeah of course
[06:20] <fabbione> i can live with rebooting the box :)
[06:20] <mkrufky> :-)
[06:20] <mkrufky> u never know... maybe someone else will add support before you receive it in the mail
[06:20] <mkrufky> :-P
[06:20] <fabbione> eheh true
[06:21] <fabbione> but i can't see the 550 on their product line..
[06:21] <mkrufky> our cvs has been very active lately
[06:21] <fabbione> yeah i am sure it is :)
[06:22] <mkrufky> that pvr 500 looks real nice to me
[06:23] <fabbione> i like the idea of the 2 tuners
[06:23] <mkrufky> ya its nice
[06:23] <fabbione> they use a conexant chipset
[06:23] <mkrufky> looks like it does not do HDTV tho
[06:23] <mkrufky> yes, it is supported
[06:24] <fabbione> we don't have HDTV here anyway :)
[06:24] <mkrufky> ooh oops... this board... maauro has it
[06:24] <fabbione> we barely have an antenna ;)
[06:24] <mkrufky> mauro is v4l maintainer... hauppauge sent him that board for him to add support for it
[06:24] <fabbione> cool
[06:24] <mkrufky> cx23416 chipset
[06:24] <mkrufky> X2
[06:25] <fabbione> "each with their own hardware MPEG encoder!"
[06:25] <mkrufky> yes
[06:25] <fabbione> lovely
[06:25] <mkrufky> this is great... uses less cpu
[06:25] <mkrufky> the name of the driver is cx88-blackbird
[06:25] <fabbione> ah
[06:25] <fabbione> perfect!
[06:26] <mkrufky> and i think that board might be supported by ivtv , not sure
[06:26] <fabbione> oh
[06:26] <mkrufky> we're working with the ivtv people to merge their stuff into v4l
[06:26] <fabbione> you convinced me :)
[06:26] <mkrufky> :-)
[06:26] <fabbione> yeah i have been asked to merge ivtv once into the ubuntu kernel
[06:26] <fabbione> but there were too many bits i didn't like
[06:27] <fabbione> such as conflicting drivers
[06:27] <mkrufky> it is easier for distro's to do something like that.... vanilla kernel cant quite do that
[06:27] <mkrufky> yes
[06:27] <fabbione> but i will have to wait a bit to buy this card.. it's a bit too expensive atm
[06:27] <mkrufky> they could instead, have an ivtv package in the repository
[06:28] <mkrufky> and if you did that, you might as well also have a v4l update package in the repository as well
[06:28] <mkrufky> i think that would have to mask each other out though
[06:28] <fabbione> it's still an issue to provide kernel drivers in an external package
[06:28] <mkrufky> why is that?
[06:28] <fabbione> we have a simple rule..
[06:29] <fabbione> whatever is GPL and can be merged into the main kernel, we do it
[06:29] <mkrufky> hmmm... dont merge ivtv then... it DOES conflict with v4l
[06:29] <fabbione> the issue of having extra kernel drivers packages goes to security
[06:29] <fabbione> i didn't merge it :)
[06:29] <fabbione> let me explain in few words
[06:29] <fabbione> the main tech issue is when we need to provide security updates
[06:30] <fabbione> let say that we do update the main kernel and this gets to change its ABI
[06:30] <fabbione> as it is now: we upload 2 packages and everybody is happy
[06:30] <fabbione> if we start to ship N external packages, all of these need to be rebuild (and possibly fixed) against the new kernel
[06:31] <fabbione> that takes hell of a lot of time and resources
[06:31] <fabbione> so it's easier to a certain degree to keep everything in the main kernel
[06:31] <fabbione> but clearly we need to make a selection of what can go in
[06:31] <mkrufky> i c
[06:31] <fabbione> and what has to stay out
[06:32] <mkrufky> do u ever backport features from newer kernels into your current kernels?
[06:32] <fabbione> yes
[06:32] <fabbione> it of course depends what we need to backport
[06:33] <mkrufky> how conservative about that stuff is ubuntu?
[06:33] <fabbione> well if you are asking me to backport a new MM layer, i would clearly say no
[06:33] <fabbione> if we are talking about drivers we are more flexible
[06:33] <mkrufky> hehe ya of course
[06:33] <fabbione> it also depends on what development season stuff shows up
[06:34] <fabbione> right now at 3 weeks from release, it's only heavy bug fixing and security fixes
[06:34] <fabbione> we still have exceptions but they are more unique than rare
[06:34] <mkrufky> makes sense
[06:35] <fabbione> we are flexible to the point that in the beginning of the development season we can include all kind of junk
[06:35] <fabbione> if it results to be buggy, we kick it out before FeatureFreeze
[06:35] <fabbione> it means that we have no issue to push crack around to user for testing
[06:35] <fabbione> but it gets the time in which we make decision.. and sometimes it's though
[06:36] <mkrufky> 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] <fabbione> sure
[06:36] <fabbione> that would be very nice
[06:37] <mkrufky> i understand that your most likely not going to adopt 2.6.13
[06:37] <fabbione> not for breezy.. no
[06:37] <mkrufky> i wouldnt expect that you would want such a patch against 2.6.12 for breezy
[06:37] <fabbione> i am pretty sure we will got .13 or .14 for dapper (breezy+1)
[06:37] <desrt> shhhh
[06:37] <fabbione> mkrufky: it depends how big it is :)
[06:38] <fabbione> mkrufky: we are at 3 weeks from release
[06:38] <mkrufky> hmm... does that mean a lot of time or a little time?
[06:38] <desrt> dapper is ultra-secret codename :)
[06:38] <fabbione> little
[06:38] <fabbione> desrt: no it's not :)
[06:38] <fabbione> it's been announced on ubuntu-devel a while ago ;)
[06:38] <desrt> pfah.  jeff seems to think it is
[06:38] <desrt> ah.
[06:39] <desrt> a dingo is an awful animal
[06:39] <mkrufky> hmm... maybe tomorrow i'll see what a diffstat of our current stable snapshot looks like against 2.6.12
[06:39] <desrt> well... the animal isn't bad
[06:39] <desrt> but i mean... as a name!
[06:40] <fabbione> mkrufky: ok..
[06:40] <fabbione> mkrufky: thanks a lot for all your suggestions :)
[06:40] <mkrufky> fabbione: no problem
[06:40] <desrt> fabbione; is benc still the man?
[06:41] <mkrufky> ive got an unrelated question then....
[06:41] <fabbione> desrt: yeps
[06:41] <fabbione> mkrufky: sure if i can help
[06:41] <mkrufky> do u have zaptel in your kernel?
[06:41] <desrt> hm.  hopefully he is around tomorrow, then
[06:41] <fabbione> mkrufky: oh hmm.. can't remember
[06:41] <mkrufky> it is not in mainline, and probably will never be
[06:41] <fabbione> let me check
[06:42] <mkrufky> it is device driver for the digium boards
[06:42] <mkrufky> for asterisk
[06:42] <fabbione> i am checking..
[06:43] <mkrufky> k
[06:43] <fabbione> we added quite a bunch of external drivers
[06:43] <fabbione> so i don't exactly remember all of them
[06:43] <mkrufky> zaptel is also quite actively changing in cvs
[06:43] <fabbione> nope we don't
[06:44] <mkrufky> ya i didnt think so... 
[06:44] <mkrufky> so anyone that wants to make a pbx will have to install that kernel driver from cvs, and lose ubuntu support?
[06:45] <fabbione> mkrufky: well not really...
[06:45] <fabbione> or better.. it depends
[06:45] <mkrufky> i was told that installing external modules causes loss of support
[06:45] <fabbione> let say that the standard kernel works on machine foo
[06:45] <fabbione> and you add a module
[06:45] <fabbione> and the kernel starts to oops
[06:45] <fabbione> than well.. there isn't much i can do there
[06:46] <fabbione> (like with nVidia binary crap)
[06:46] <fabbione> but if the kernel oops before and after.. makes no difference
[06:46] <mkrufky> you could always say, "it must be your externel module... ask #foo for help with that"
[06:46] <fabbione> now.. if you are talking about commercial support.. i have no idea..
[06:46] <fabbione> mkrufky: well as i explained above, if the kernel works and only adding that module starts to oops..
[06:47] <mkrufky> ya i gotcha
[06:47] <fabbione> it is sort of clear that the module might either be buggy or exploit a bug in the kernel
[06:47] <fabbione> but if i get an oops that is related only to that driver..
[06:47] <fabbione> well than i need to forward you to #foo
[06:47] <mkrufky> ya
[06:49] <fabbione> but note.. this is true for drivers of which i can read the code..
[06:49] <fabbione> if i get bugs like "NVidia driver oops"
[06:49] <fabbione> i don't even bother to check
[06:49] <fabbione> i send them to nvidia forums
[06:50] <fabbione> no code.. there is nothing i can do
[06:50] <mkrufky> ya we do the same in #v4l 
[06:50] <fabbione> ok :)
[06:50] <mkrufky> nvidia should just open up their drivers
[06:50] <mkrufky> oh well
[06:51] <mkrufky> i use all ati
[06:51] <mkrufky> :-D
[06:51] <fabbione> they both should :)
[06:51] <mkrufky> true
[06:51] <mkrufky> but there are some good oss ati drivers
[06:52] <fabbione> yes
[06:52] <fabbione> they should still open up
[06:52] <mkrufky> i agree
[06:52] <fabbione> brb.. i have to wake up my wife
[06:52] <mkrufky> k
[06:52] <mkrufky> i'm actually goin to bed soon
[06:52] <mkrufky> was nice chattin
[06:57] <fabbione> thanks a lot mkrufky 
[06:57] <fabbione> good night
[06:58] <mkrufky> nite
[11:01] <Mithrandir> BenC: how do you feel about applying http://bugzilla.ubuntu.com/attachment.cgi?id=1985 ?
[11:02] <Mithrandir> (I know it's late in the release cycle, but I was made aware of it late.)
[01:44] <mjg59> BenC: When are we looking at a new kernel release?
[01:58] <BenC> mjg59: this week
[01:58] <mjg59> BenC: Any idea when?
[01:59] <BenC> Wed or Thu
[01:59] <Mithrandir> BenC: what about the p4-clockmod patch?
[02:00] <BenC> Mithrandir: which bug report is that for?
[02:00] <mjg59> BenC: Ok. Kernel freeze is the end of next week?
[02:00] <Mithrandir> BenC: http://bugzilla.ubuntu.com/show_bug.cgi?id=8587
[02:00] <fabbione> hey BenC 
[02:00] <fabbione> BenC: i did commit all the sparc stuff to baz
[02:00] <fabbione> let me know when it's time to prebuild before release
[02:01] <fabbione> this is the last kernel.. if we fuck it up, we lose sparc for breezy
[02:01] <mjg59> Uh. We're only doing one more release?
[02:01] <fabbione> mjg59: yes
[02:02] <fabbione> and i think we are already pretty late
[02:02] <fabbione> we should be already in Security only bug fixing iirc
[02:02] <mjg59> Ok. That presents certain problems.
[02:02] <fabbione> we are at 3 weeks from release
[02:03] <fabbione> let me check the schedule
[02:04] <BenC> 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] <BenC> I have about 3 bug reports that I need to do some hardcore kernel debugging with, before this next release
[02:04] <BenC> going to be time consuming
[02:04] <fabbione> kernel freeze is the 24th
[02:04] <fabbione> so that means friday
[02:05] <fabbione> sorry
[02:05] <BenC> Friday is the latest then
[02:05] <fabbione> 29th
[02:05] <fabbione> so in 10 days
[02:11] <Mithrandir> 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] <BenC> Mithrandir: hold a sec
[02:20] <BenC> Mithrandir: the patch is clean, so I think it can go in
[02:20] <Mithrandir> BenC: excellent, can you wrap it up or should I commit it to the archive?
[02:20] <BenC> it might also fix some other bug reports (powernowd causing screwed up mouse, cpufreq messing up the clock speed)
[02:21] <BenC> If you have the time, please do
[02:21] <BenC> if not, shoot me an email as a reminder
[02:21] <Mithrandir> I can just do it.
[02:21] <Mithrandir> (it's not that I don't have enough to do, but it's trivial enough. :)
[02:21] <BenC> :)
[02:24] <zul> hey peeps
[02:28] <BenC> hey zul
[02:29] <zul> how is it going ben?
[02:29] <BenC> not too bad
[02:29] <BenC> how about you?
[02:29] <zul> good...after recovering from a flu bug and a cold as well as good be expected
[02:30] <fabbione> hey zul
[02:30] <BenC> nasty, I hate the flu more than anything
[02:30] <fabbione> BenC: so we have only 3 pkgs that are FTBFS on sparc/main/breezy :)
[02:30] <fabbione> one of which we don't really care
[02:30] <zul> yeah i had chills and hot flashes...i think i got it from fabbio...
[02:30] <zul> hey fabbione 
[02:31] <fabbione> but kernel and klibc yes.. we do :)
[02:31] <fabbione> zul: i told you not to lick my nose while i am sleeping!
[02:31] <BenC> fabbione: you said klibc was getting fixed, right?
[02:31] <fabbione> BenC: jbailey was going to look at it...
[02:31] <fabbione> kernel is fixed if we don't change the hell in it
[02:31] <BenC> what's wrong with klibc on sparc?
[02:31] <zul> better than your nose than your nuts
[02:32] <fabbione> BenC: it builds in 64bit mode...
[02:32] <fabbione> and it fails in 32bit
[02:32] <BenC> zul: yeah, that'd probably be a whole different sickness :)
[02:32] <fabbione> mimatch = crash at boot
[02:32] <fabbione> probably busybox-initramfs
[02:32] <zul> hehe
[02:33] <fabbione> bah i have 15 minutes.. i can give it a shot
[02:33] <BenC> fabbione: kernel crash, or crash in klibc?
[02:34] <fabbione> BenC: same kernel works with initrd
[02:34] <fabbione> i get an oops
[02:34] <fabbione> but  it's too early in the boot process to understand what's wrong
[02:34] <BenC> does klibc run in kernel mode?
[02:34] <fabbione> no idea
[02:34] <fabbione> i don't think so
[02:34] <BenC> is it just a stripped down libc like uclibc?
[02:34] <fabbione> afaik yes
[02:35] <BenC> hmm, and 32-bit mode causes a kernel crash...that sounds more like a kernel bug (assuming klibc runs in userspace mode)
[02:35] <jbailey> BenC: It does.
[02:35] <fabbione> nope.. i think it's the mistmatch between klibc being built in 64bit and busybox in 32
[02:35] <fabbione> hey jbailey 
[02:36] <BenC> if klibc is causing a kernel crash on sparc64, that's really bad
[02:36] <jbailey> BenC: The kernel crash is almost certainly because there's nothing left to do, so the shell script dies.
[02:36] <jbailey> As opposed to a real crash.
[02:36] <BenC> ah
[02:36] <BenC> so it's like init dieing?
[02:36] <jbailey> Yup
[02:36] <BenC> ok, I feel better now :)
[02:36] <BenC> why is klibc being built as 64-bit?
[02:36] <fabbione> BenC: the same exact kernel boots perfectly if we use initrd
[02:37] <fabbione> that's why i pointed the finger at klibc
[02:37] <BenC> initrd uses installed libc?
[02:37] <jbailey> BenC: Because it sucks.  I haven't fixed it yet, I ran out of time this weekend.
[02:37] <fabbione> BenC: eh that's the interesting problem
[02:37] <fabbione> it's FTBFS on 32bit more
[02:37] <fabbione> the one in the archive was my mistake building it manually
[02:37] <jbailey> libgcc is pulling in .umul in 32 bit mode for some reason. 
[02:37] <BenC> ah, where's the package, I can have a look later tonight maybe
[02:37] <fabbione> and it did build in 64bit
[02:37] <jbailey> I don't think it'll be hard to fix.
[02:37] <fabbione> BenC: klibc
[02:37] <BenC> easy enough :)
[02:38] <fabbione> BenC: do you want access to the sparc with the chroots?
[02:38] <jbailey> It was totally a case of I spent all of Saturday polishing up the initramfs-tools package, and Sunday needed a break.
[02:38] <BenC> nah, I can just build it here
[02:38] <fabbione> jbailey: you polished it so much that somebody did open a critical on it :)
[02:39] <jbailey> fabbione: Great.  I'll punt it to mjg59.  He sent me the patch that broke it.
[02:39] <fabbione> ahahha
[02:39] <jbailey> Apparently USB drivers suck and can'tbe loaded before a resume.
[02:40] <fabbione> no shit...
[02:40] <jbailey> So we had to split up the driver passes and do a resume after only the controllers are walked.
[02:40] <fabbione> i managed today only after 6 months to get my USB webcam to work
[02:40] <jbailey> But that's before md runs, before lvm runs, before evms runs...
[02:40] <jbailey> Oh!  Since I have you both here.  I have update-initrfs in the package I just uploaded now.
[02:40] <jbailey> So I need to do a hack again to use that now instead.
[02:41] <mjg59> jbailey: Mm?
[02:41] <jbailey> mjg59: 15775
[02:41] <BenC> jbailey: can you unload drivers before a resume?
[02:41] <jbailey> mjg59: It looks like resume isn't working in some case there.
[02:41] <jbailey> 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] <jbailey> mjg59: Like, I could walk the tree and maybe *unload* the USB drivers or something...
[02:42] <BenC> err, I mean unload drivers before a suspend and then reload them
[02:42] <mjg59> BenC: We do
[02:42] <BenC> jbailey: the e100 and e1000 drivers fail if they are loaded during a suspend, and then are reloaded for the resume
[02:42] <fabbione> mplayer http://gordian.fabbione.net:8090/fabcam.rm <-
[02:42] <fabbione> not everybody all together please
[02:42] <mjg59> 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] <mjg59> jbailey: It's not just USB. It's basically *everything*.
[02:43] <BenC> 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] <mjg59> BenC: They *are* unloaded prior to the suspend
[02:44] <mjg59> All network and USB drivers are unloaded
[02:44] <BenC> mjg59: prior to the suspend state being saved to disk?
[02:44] <mjg59> Yes
[02:44] <BenC> then this bug report makes even _less_ sense
[02:44] <mjg59> BenC: Which one?
[02:44] <mjg59> The problem is:
[02:44] <zul> fabbione: what is it?
[02:44] <BenC> upon resuming from S3, e100/e1000 dumps out because the EEPROM is seen as corrupted
[02:45] <BenC> hold a sec...
[02:45] <fabbione> zul: my webcam
[02:45] <mjg59> BenC: If the driver isn't loaded, nothing saves/restores the PCI state
[02:45] <zul> ooh..scarey
[02:45] <mjg59> So in an ideal world, we don't unload the driver
[02:45] <BenC> 14790
[02:45] <mjg59> Except that most drivers are broken, so we do unload them
[02:46] <BenC> anyone know the command off hand for getting the eeprom with ethtool?
[02:46] <mjg59> jbailey: I'm not sure what cleaner ways there could be
[02:46] <mjg59> BenC: That one is probably the same issue as with USB
[02:47] <mjg59> BenC: initramfs loads the driver. The hardware is then in an initialised and running state. We resume from disk, and then try to load the module again. The driver doesn't know how to deal with this.
[02:47] <mjg59> jbailey: Either we unload all the drivers, resume and then reload them
[02:47] <mjg59> jbailey: Or we resume before we load those drivers
[02:48] <mjg59> The second of these takes less time. Both would appear to have identical failure modes.
[02:48] <BenC> mjg59: well, if the driver was unloaded prior to suspend, then there should be no saved state concerning the driver, and it should just do everything from scratch again, as if it was not resumed, right?
[02:48] <mjg59> BenC: Yes, but the initialisation code expects quiescent hardware
[02:48] <mjg59> Not running hardware
[02:49] <mjg59> BenC: That bug report isn't S3, it's S4
[02:49] <jbailey> mjg59: Right.  The issue I hit is that lvm and md cope poorly with devices missing.
[02:49] <BenC> right, the reports I read on other sites said S3
[02:49] <mjg59> jbailey: "Cope poorly" in what way?
[02:49] <mjg59> BenC: Right. That's probably them failing to unload/load it, or something.
[02:50] <BenC> mjg59: but if the driver was unloaded prior to suspend, then the hardware should not be running
[02:50] <BenC> what would make it "running"?
[02:50] <jbailey> mjg59: They'll activate anyway and then the missing devices require special handling to bring them online again (Like, remirroring, etc)
[02:50] <mjg59> BenC: Except it is, because initramfs loaded the driver
[02:50] <mjg59> jbailey: Oh, for christ's sake.
[02:50] <jbailey> I don't remember what lvm does is a missing device case for multipath
[02:50] <mjg59> jbailey: Hm. Is there any way that we can tell if there's a USB device in the lvm or md?
[02:51] <BenC> probably checking /sys/
[02:51] <jbailey> Not that I know of, but I haven't explored the idea.
[02:51] <mjg59> jbailey: Well, in that case we lose *anyway*
[02:51] <jbailey> The whole filesystem/mapper/ide-disk&&sd/block device sandwitch seems to be a bitch.
[02:52] <jbailey> At each layer nothing cleanly refers to the next.
[02:52] <mjg59> jbailey: Ok. Can we clearly define the problem?
[02:53] <mjg59> jbailey: We need to resume *after* the swap partition is available, but *without* USB/network modules loaded
[02:53] <jbailey> mjg59: "Suspend and resume suck.  We need to make it suck the least possible and piss off the fewest people in the failure cases"
[02:53] <jbailey> Right.
[02:53] <mjg59> So currently we should be doing that except in the case that the swap partition is on lvm
[02:53] <jbailey> Do we just say for now that anyone doing something crazy like multipath on usb or NBD will lose and we're not too fussed?
[02:54] <mjg59> Nobody's going to be doing md over NBD or USB
[02:54] <jbailey> Or on md, I realised.
[02:54] <mjg59> But they *might* be doing LVM on USB (they'd be fucking insane, but still)
[02:54] <Mithrandir> mjg59: I've actually considered doing md over nbd, but not usb.
[02:54] <jbailey> mjg59: The installer does this when you do lvm.
[02:54] <jbailey> Mithrandir: I've done md over USB. =)
[02:54] <Mithrandir> jbailey: some people will be doing raid over their USB enclosures.
[02:55] <jbailey> Unplug the USB drive and store it for backup.  Drop in the new drive and remirror over the course of the day.
[02:55] <jbailey> No waiting for overnight backups.
[02:55] <mjg59> jbailey: It's fine for us to say that we don't support hibernate in bizarre configurations
[02:55] <mjg59> jbailey: But we should support hibernate on plain LVM
[02:55] <mjg59> Since currently we *do* support hibernate on plain LVM
[02:56] <jbailey> Whats the right things long term?  Should the drivers eventually all work right?
[02:56] <mjg59> Eventually we don't unload the drivers on suspend and their resume code works
[02:56] <fabbione> later guys
[02:57] <Mithrandir> can't the resume check that the modules are already loaded and not try to reload them?
[02:57] <Mithrandir> (or is that a totally silly idea, since this is all handled through hotplug which does magic stuff)
[02:58] <mjg59> Mithrandir: ?
[02:59] <mjg59> Mithrandir: Ah - no, we're on a different kernel by then
[02:59] <mjg59> suspend unloads module, saves image. Resume loads module, loads image. Module is now not loaded.
[02:59] <Mithrandir> uhm, ok.
[03:00] <mjg59> The resumed image has *no idea* what's happened before it was read off disk
[03:01] <Mithrandir> is there any way to communicate that to it?
[03:01] <Mithrandir> whatsoever?
[03:01] <mjg59> No
[03:01] <mjg59> But it wouldn't help, because the module code wouldn't be loaded
[03:49] <jbailey> mjg59: alternatively, it should only attempt to load them if acpi has initialised.
[03:49] <jbailey> " "
[03:49] <jbailey> mjg59: Lovely, how do I do that? =)
[03:49] <jbailey> I didn't think I could detect that from userspace.
[03:49] <mjg59> Check for /proc/acpi
[03:50] <jbailey> Ah? Okay.  I thought that was created when the first modules was loaded/.
[03:51] <mjg59> No, it should be created when the interpreter starts
[03:52] <jbailey> 'k
[03:52] <jbailey> Is there any way of detecting which modules it's capable of accepting?
[03:52] <mjg59> Nope
[03:57] <Comte0> Hi. Can anyone have a look at bug #10307? I'm on that macintosh right now.
[04:02] <jbailey> Sure, I can.
[04:02] <jbailey> I'm also on a Mac G5 atm that's working.
[04:02] <jbailey> Probably a different superdrive, though.
[04:02] <BenC> me too
[04:02] <BenC> I have a CDR/DVDR Superdrive
[04:03] <BenC> it works (live cd)
[04:04] <jbailey> I'll let Ben take it, he's more knowledgable that I for this.
[04:04] <jbailey> (Still watching the screen, but doing marketplace updates in the other window)
[04:05] <BenC> Comte0: how old is your G5?
[04:07] <BenC> my superdrive is connected to my ATA according to System Profiler, but my harddrive is connected via sata, and the live-cd recognized it
[04:07] <BenC> I think it's all the same bus though
[04:08] <Comte0> BenC: it's quite new, I think it was bought for christmas
[04:08] <Comte0> it's a "computer in the flat panel"
[04:09] <Comte0> I suspect people who do not see the bug have a tower
[04:09] <BenC> ah, mine's a big aluminum tower model :)
[04:09] <BenC> still, the hardware for your ata/sata bus's are supported by the kernel
[04:09] <BenC> the pmac-ide module is built into the kernel
[04:09] <BenC> so it should see the cdrom with no problem
[04:10] <BenC> can you do "dmesg | grep -i ata"
[04:10] <BenC> and see if there is anything more specific?
[04:10] <Comte0> there's no lspci on the install cd. I suspect I can have a look at /proc to see the hardware there ?
[04:12] <BenC> cat /proc/ide/drivers
[04:12] <BenC> ls -l /proc/ide/
[04:13] <BenC> cat /proc/scsi/scsi
[04:13] <BenC> ls -l /proc/scsi/
[04:15] <Comte0> well, thanks
[04:23] <desrt> uh oh.
[04:23] <desrt> i think the new kernel contains some evil
[04:23] <desrt> my computer just hard froze (hasn't done that in ages)
[04:23] <desrt> what changed? :)
[04:25] <BenC> your computer obviously :)
[04:25] <BenC> no messages?
[04:25] <desrt> serious, dude :p
[04:25] <desrt> *hard* crash
[04:26] <desrt> mouse stops moving.  music stops playing.  machine stops responding to ping (much less ssh)
[04:27] <BenC> what type of machine and which kernel image?
[04:27] <desrt> 686-smp on a MT box
[04:27] <desrt> serial ata
[04:28] <desrt> intel p4 3.0ghz with 2gigs of ram... asus p4p800-se mainboard
[04:28] <BenC> how long was the machine up before it locked?
[04:28] <desrt> i'll file a bug with all this
[04:28] <desrt> about a day, i think
[04:28] <desrt> let me check the syslog
[04:28] <BenC> 2.6.12-8.13?
[04:28] <desrt> yes
[04:28] <BenC> did you find it locked up, or did it happen while you were using it?
[04:28] <desrt> reboot   system boot  2.6.12-8-686-smp Mon Sep 19 10:23          (00:05)
[04:28] <desrt> reboot   system boot  2.6.12-8-686-smp Sun Sep 18 01:25         (1+09:03)
[04:29] <desrt> so a day and 9 hours
[04:29] <desrt> while i was using it
[04:29] <BenC> anything special going on when it happened?
[04:29] <desrt> i was in the middle of surfing bugzillas
[04:29] <desrt> just stuff i normally do
[04:29] <desrt> the last time i had lockups like this was when i tried to enable CFQ
[04:30] <BenC> cpu frequency scaling?
[04:30] <desrt> no.
[04:31] <BenC> do you have powernowd installed?
[04:31] <desrt> yes but it's not running
[04:31] <BenC> ok
[04:31] <BenC> there's a p4 errata concerning cpu scaling, just making sure that wasn't it
[04:32] <Mithrandir> BenC: can you run baz lint in the source tree and see if you get errors about duplicated ids?
[04:32] <BenC> Mithrandir: no messages from baz lint for me
[04:33] <Mithrandir> it complains about d-i/amd64/modules/amd64/.arch-ids/=id and d-i/hppa/modules/hppa/.arch-ids/input-modules.id, d-i/amd64/modules/amd64/.arch-ids/pcmcia-storage-modules.id and  d-i/hppa/modules/hppa/.arch-ids/nic-shared-modules.id and last d-i/amd64/modules/amd64/.arch-ids/irda-modules.id d-i/hppa/modules/hppa/.arch-ids/usb-storage-modules.id
[04:34] <BenC> odd, those haven't been touched in awhile
[04:34] <Mithrandir> hm, weird
[04:34] <Mithrandir> I guess it's just baz being an ass
[04:37] <desrt> ben -- 15799
[04:43] <Comte0> re
[04:43] <Comte0> BenC: I haven't found anything :(
[04:43] <desrt> BenC; i was wondering if you could slip john mccutchan's inotify patch into the next release....
[04:44] <desrt> BenC; it solves a fairly nasty race condition
[04:44] <desrt> well... nasty as in impossible-to-work-around.... not as in the-kernel-will-panic
[04:44] <Comte0> there's a couple of entries in /sys/devices
[04:51] <BenC> desrt: does it change the kernel ABI?
[04:52] <desrt> BenC; a bit.
[04:52] <BenC> Comte0: there's nothing in /proc/ide/drivers or /proc/scsi/scsi?
[04:52] <desrt> but backwards compatibly (and almost forwards compatibly)
[04:52] <BenC> also do lsmod | grep sata
[04:52] <desrt> BenC; there's a one-liner addition to a header file, though... so yes... the API changes
[04:52] <BenC> desrt: if it changes the abi, it potentially breaks modules built against the kernel (versioned symbols change)
[04:52] <BenC> oh
[04:53] <BenC> no, not API, the binary ABI
[04:53] <Comte0> BenC: bugzilla has just been updated
[04:53] <desrt> BenC; definitely won't do that
[04:53] <BenC> ok, then sure, I can include it
[04:53] <desrt> BenC; no functions change prototypes, no data structures change layout
[04:53] <desrt> it's just an additional flag to an already-existing function (that's only called from userspace)
[04:53] <Mithrandir> uhm
[04:54] <Mithrandir> I think I might just have broken the baz archive
[04:54] <desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=14458
[04:54] <desrt> BenC; this is in the tree that will become linus's 2.6.14
[04:55] <BenC> Comte0: can you see if lsmod shows that any ata, sata or ide drivers are loaded?
[04:55] <BenC> also try "modprobe sata_svw"
[04:56] <Mithrandir> BenC: can you please fix your umask on rookery and chmod +x /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12 ?
[04:56] <BenC> my umask should be fine
[04:56] <Comte0> Sure, but I'd like to know if there's some file you want to see in /sys
[04:57] <BenC> Mithrandir: $ ls -ld /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12
[04:57] <BenC> drwxrwxr-x  8 bcollins warthogs 4096 Sep 19 15:55 /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--preX,14--2.6.12
[04:58] <BenC> Comte0: /sys doesn't matter at this point, right now we need to see if the module is loaded, if not then we need to try loading it manually to see if that resolves the problem
[04:58] <Mithrandir> sorry, I'm blind
[04:58] <BenC> if it is, then we need to see why it isn't working
[05:00] <Comte0> ok
[05:00] <lamont-away> Mithrandir: the only stuff in that archive that is owner-writable but not group writable is in kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,11,92-1,1--0/base-0/
[05:00] <lamont-away> which I don't think we care about anymore...
[05:01] <lamont-away> (since it's 4+ months old now..)
[05:01] <Mithrandir> lamont-away: I kicked it a bit and the problem went away.
[05:01] <lamont-away> heh
[05:01] <lamont-away> speaking of going away - back much later
[05:15] <BenC> desrt: can you make that inotify bug P1?
[05:16] <desrt> k.
[05:21] <desrt> done.  thanks.
[05:23] <Comte0> BenC: short answer, there is no sata modules
[05:24] <Comte0> I'll put the long one in the bugzilla
[05:49] <Comte0> bug #10307 has been updated. Anyone can check the live-cd initrd kernel has sata enabled ?
[05:50] <Comte0> (the ppc power4 one)
[06:18] <BenC> Comte0: you're using the power4 cd?
[06:18] <BenC> I used the powerpc one
[06:18] <BenC> that's probably your problem
[06:19] <Comte0> it's the one that works...
[06:19] <BenC> power4 wouldn't have the mac drivers
[06:19] <Comte0> erm, there's only one powerpc cd, isn't it ?
[06:19] <BenC> the powerpc one works for me, and no, the power4 one isn't working for you, else you wouldn't have filed a bug :)
[06:19] <BenC> well, you said power4
[06:19] <BenC> I assumed there was one specific to that system
[06:20] <BenC> are you booting with live64 (or whatever it is)?
[06:20] <Comte0> Is it the 64 bits kernel?
[06:20] <BenC> G5 is 64-bits
[06:20] <BenC> how do you boot the cd, what command do you type at yaboot?
[06:20] <Comte0> live-power4
[06:21] <BenC> that's the wrong one
[06:21] <BenC> live-powerpc64
[06:21] <Comte0> is hitting enter the good solution?
[06:21] <BenC> no, for G5, you have to type the live-powerpc64 (I did too)
[06:21] <BenC> yaboot doesn't auto detect yet
[06:24] <BenC> Comte0: this would explain a lot
[06:26] <Comte0> (it also means you have read comment #4 too quickly ;) )
[06:26] <Comte0> oh, nevermind
[06:45] <Comte0> re
[06:45] <BenC> does it work?
[06:46] <Comte0> BenC: when is the deadline for kernel changes on breezy? I'll try to rip a preview iso before
[06:46] <BenC> 10 days
[06:46] <BenC> did the system boot with live-powerpc64?
[06:46] <Comte0> no, ther's no install/powerpc64 directory on my cd
[06:47] <BenC> download the latest breezy preview
[06:47] <BenC> I'm quite sure that it will work, and that the problem has just been that you are booting the wrong kernel
[06:47] <Comte0> the blank cd was left at home :(
[06:47] <BenC> ah, ok
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> $ ls /Volumes/Ubuntu_PowerPC_hoary/install/
[06:50] <Comte0> boot.msg        power3          powerpc         yaboot.conf
[06:50] <Comte0> ofboot.b        power4          yaboot
[06:50] <Comte0> that was why I was so slow to reply: The computer is my father's
[06:50] <Comte0> ...and I hate MacOs X cut&paste ...
[06:50] <Comte0> sight
[06:51] <zul> wth...oh..sorry
[06:51] <Comte0> well, thank you very much for your help
[06:51] <Comte0> BenC: I'll try next saturday
[07:05] <mjg59> Have we fixed the ndiswrapper build on amd64?
[07:10] <mjg59> Also:
[07:10] <mjg59> sky2 isn't going to be ready in time for Breezy
[07:10] <mjg59> zul: Did you get anywhere with the sk98lin stuff?
[07:32] <zul> mjg59: i have it in my arch, the sk98lin stuff im going to work on tonight
[07:34] <zul> work had really busy the past couple of days
[07:36] <mjg59> zul: Ok - it's fairly urgent, so I can do it now if that would be easier
[07:37] <mjg59> Hmm. Uhm.
[07:37] <mjg59> Do we actually have sk98 in the kernel already?
[07:39] <mjg59> Ah, yes
[07:48] <zul> mjg59: please
[07:48] <mjg59> zul: Ok, no problem
[07:58] <mjg59> Waa why must it be a 1 MB patch?
[08:06] <zul> because its syskonnect and they are bastards
[08:10] <mjg59> Ok, done.
[08:11] <mjg59> It seems to build, and the PCI IDs don't overlap with skge
[08:14] <zul> do you want to forward to me so i can do a build test tonight?
[08:15] <mjg59> Sure. Email address?
[08:15] <zul> zulcss@gmail.com
[08:16] <mjg59> Ok, sent
[08:16] <zul> cool...ill do it when i get home tonight
[09:12] <BenC> mjg59: thanks for the patch
[09:13] <mjg59> BenC: NP
[11:46] <mjg59> BenC: There's a one character error in the diff I sent you. I'll resend.
[11:58] <BenC> ok
[11:58] <mjg59> BenC: Right, done