[12:04] <lamont> now we just need a working klibc, and we can go to initramfs
[12:05] <BenC> i got a WARN_ON() in free_initmem(), but it looks harmless
[12:05] <lamont> yeah - that's um, expected
[12:06] <BenC> well, it calls smp_call_function during a point when I belive irqs aren't enabled yet, so it makes sense :)
[12:10] <BenC> going to do a full binary-arch build now to make sure udeb creation works and all
[05:00] <infinity> How many arches are still building the kernel with gcc-3.4?
[05:00] <infinity> Just hppa?
[05:09] <BenC> yeah
[05:22] <infinity> So dangeoursly close to LRM working right now...
[05:23] <infinity> OTOH, after all this effort, the thing may well maintain itself for the rest of the release cycle without me touching it.
[05:23] <infinity> Which would be nice.
[05:59] <ispiked> mjg59: did you ever play with the stick and buttons not working on resume from hibernate on your laptop?
[05:59] <mjg59> ispiked: Works fine on mine
[06:00] <ispiked> mjg59: it's in and out on mine.
[06:01] <ispiked> mjg59: you wouldn't know anything about messing with the wireless on/off light, would you?
[06:03] <mjg59> Yeah, there's a kernel option to enable it
[06:03] <mjg59> In the Intel case, it's driven by the card
[06:05] <ispiked> hrm...
[06:06] <ispiked> if it's enabled does it work?
[06:06] <mjg59> Yes
[06:06] <mjg59> But it's an experimental option, so it's not enabled yet
[06:07] <ispiked> where is the code and what's the option?
[06:08] <mjg59> Oh, it might actually be built in
[06:08] <mjg59> Check modinfo -p ipw2200
[06:10] <ispiked> yeah, it's there. the question is how to get it on.
[06:11] <ispiked> ooh. lemme try the readme.
[06:26] <ispiked> mjg59: got it working. now for the bluetooth light.
[09:30] <CataEnry> hi all
[10:09] <CataEnry> bbl
[10:26] <CataEnry> hi all
[02:19] <BenC> jbailey: ping
[02:22] <jbailey> BenC: pong
[02:22] <BenC> jbailey: get my email regarding ac880 for that customer?
[02:23] <jbailey> BenC: I did, thanks.  Do they need the new kernel that you're about to upload, or do they need the next one that will go in?
[02:23] <BenC> -6.8, which will be my next upload
[02:24] <BenC> jbailey: I got to thinking that maybe, if I fix the crash in breezy, the sound will work, but the hda driver is so different between the two that I have no idea if that's a correct assumption or not
[02:24] <jbailey> And I need to test a ppc64 kernel for you.
[02:24] <BenC> jbailey: I may do a test kernel build with the fix for 2.6.12-10, and we can let them test that in the meantime, if you'd like
[02:25] <BenC> yes, that would be nice, thanks :)
[02:25] <jbailey> It seems like the best thing to do is get them to test the next dapper kernel, first.
[02:26] <jbailey> That way we know that the problem is actually completely solved in the development branch.
[02:27] <BenC> I'm almost 100% sure that it is fixed in dapper now, but a test would be a good idea
[02:27] <crimsun> which codec for hda-intel?
[02:27] <BenC> ac880
[02:27] <crimsun> if it's alc, it should be.
[02:27] <crimsun> yeah.
[02:27] <BenC> alc880, yeah
[02:27] <BenC> I added the one-liner fix from l-k, so that should fix it
[02:28] <crimsun> great :)
[02:28] <jbailey> rebooting for 2.6.15 test, bbias
[02:32] <jbailey> 'kay, I'm on 2.6.15.
[02:33] <jbailey> BenC: You wanted my dmesg if the fan staarts speeding up?  It sounds like it might, but I can't tell yet.
[02:33] <BenC> just full dmesg
[02:33] <BenC> just so I can see if there's anything weird
[02:33] <jbailey> 'kay, /me emails /var/log/dmesg
[02:33] <jbailey> Yup, it's speeidng up.
[02:33] <BenC> and then "cat /proc/driver/rtc"
[02:34] <BenC> and the full part of that (including any "BENC: ..." lines
[02:34] <BenC> it will oops, just so you know :)
[02:34] <BenC> I didn't fix anything
[02:35] <jbailey> You asked about whether the command succeeded, I appear to get a bus error.
[02:36] <jbailey> I've emailed /var/log/dmesg and the oops to you.
[02:37] <jbailey> Anything else you need? If not, I'll reboot to the older kernel so that the fans can shut off. =)
[02:37] <BenC> did any BENC lines get printed in the oops?
[02:37] <jbailey> Two, at the top
[02:37] <BenC> sweet, thanks
[02:37] <BenC> that should be it
[02:37] <jbailey> [  260.287465]  BENC: Obtaining rtc_lock in rtc_proc_show
[02:37] <jbailey> [  260.287474]  BENC: at 1157
[02:37] <jbailey> Cool
[02:37] <BenC> just as I suspected
[02:43] <BenC> jbailey: can you do "dmesg | grep BogoMIPS" on your breezy kernel?
[02:44] <BenC> and also, just to be sure, can you do "cat /proc/driver/rtc"
[02:45] <BenC> no need to send me any output, just need to know the bogomips
[02:45] <BenC> and if the cat worked ok
[02:49] <jbailey> root@starshine:~# dmesg | grep BogoMIPS
[02:49] <jbailey> [   27.452696]  Calibrating delay loop... 66.56 BogoMIPS (lpj=33280)
[02:50] <jbailey> BenC: And the cat works fine.
[02:50] <BenC> guess bogomips is just supposed to be that low for ppc
[02:50] <BenC> thanks
[02:50] <jbailey> BenC: I think this box has cpu scaling.
[02:51] <BenC> even my G4 only shows ~45, and I don't think it has scaling
[02:51] <BenC> my i386 shows 4000 :)
[02:53] <infinity> Your G4 shows 45 bogomips?
[02:54] <infinity> That's weird that they use a different loop for G3 and G4, since they're virtually identical.
[02:54] <infinity> (My G3 is ~2000 bogomips..)
[02:54] <jbailey> G3's were clearly 'leeter.
[02:54] <fabbione> your G3 cheats to look cooler
[02:54] <infinity> Well, they were.
[02:54] <infinity> Full speed cache.
[02:55] <infinity> (And who needsa altivec anyway?)
[02:55] <infinity> Still, odd.  Something to ask benh about some day, and he'll say "Like I remember why I did that", and I'll go "oh.."
[03:14] <BenC> is benh ever on linuxnet?
[03:16] <BenC> jbailey: as of right now, I only have two possible reasons for this crash...1) GCC-4 related, may need to try a gcc-3.4 compile
[03:16] <BenC> the crash is happening in either out_8() or in_8(), which are assembly
[03:16] <BenC> 2) it might be caused by the fact that breezy ppc64 was using discontiguous memory model and dapper is flatmem
[03:17] <BenC> I'm leaning toward the first
[03:18] <BenC> the code for CMOS_READ(), where it is crashing is the same in 2.6.12 and 2.6.15, so it's not a bug from that code directly
[03:20] <fabbione> BenC: yes he is, but not 24h
[03:21] <infinity> I'm scared to death of this switch to gcc-4.0 for the kernel, personally.
[03:23] <BenC> I had already heard that ppc64 may need gcc-3.4, so this wouldn't be a surprise
[03:23] <BenC> but everything else should be fine, and so far I haven't seen, nor heard of any problems from it
[03:24] <infinity> I have a lovely OOPS from fglrx, but my hardware has never liked fglrx, so I'm unwilling to commit to it being the driver, kernel, or compiler's fault until I get more bug reports from this upload.
[03:24] <zul> heylo
[03:25] <BenC> looks like ppc and hppa may be the only ones left still using gcc-3.4
[03:25] <infinity> Other than that, my kernel has been solid.  (Well, buggy in neat ways, like my lack of CD drive, but nothing crashy)
[03:25] <BenC> hey zul
[03:25] <infinity> And yes, I still have no CD drive in -5.7... I need to corner you tomorrow and talk to you about it.
[03:25] <BenC> yeah, we need to pin that down
[03:26] <BenC> jbailey: will you be able to test another kernel in about 15 minutes or so?
[03:37] <jbailey> BenC: About 5m from now?
[03:37] <BenC> 5-10
[03:37] <BenC> build is almost done
[03:37] <jbailey> Cool.
[03:37] <jbailey> No ccache? =)
[03:37] <BenC> compiler switch, so it wouldn't help anyway :)
[03:38] <jbailey> Ah, dropping back to 3.4?
[03:38] <BenC> yeah, about the only thing I can think of right now that might cause this
[03:39] <BenC> it's getting some sort of sigbus trap on a byte sized read/write from IO memory...it's very odd for it to do that
[03:39] <BenC> for all I know the trap is expected, and the trap to fix it up just isn't set :/
[03:54] <infinity> include/linux/highmem.h:12:25: error: asm/highmem.h: No such file or directory
[03:54] <infinity> (building LRM on powerpc)
[03:54] <BenC> ARCH=powerpc, not ARCH=ppc
[03:54] <BenC> make sure it's not something like that
[03:55] <BenC> plus, there's no such thing as highmem on ppc :)
[03:55] <infinity> Erm, but it used to be ARCH=ppc.
[03:55] <fabbione> "used" exactly
[03:55] <infinity> (Must have been, since I didn't touch anything ppc-specific)
[03:56] <jbailey> BenC: I thought there was.  My ppc64 box only generally sees 4gb of the 6 in it, IIRC.
[03:56] <infinity> ifeq "$(DEB_HOST_ARCH)" "powerpc"
[03:56] <infinity> export karch=ppc
[03:56] <infinity> So, this needs to be "powerpc" now?
[03:56] <fabbione> yes
[03:57] <jbailey> BenC: How's the build?
[03:57] <BenC> jbailey: done
[03:57] <BenC> jbailey: same location, same file, just updated
[03:59] <jbailey> BenC: We're looking for both the fan fix and the rtc fix here?
[03:59] <BenC> I'm hoping atleast rtc, but the fan would be a nice bonus
[03:59] <BenC> jbailey: your 4-6gig mem problem is likely memory layout and not highmem related
[03:59] <jbailey> Paramtrage de linux-image-2.6.15-5-powerpc64-smp (2.6.15-5.7) ...
[04:01] <BenC> ppc32 has highmem.h, but ppc64 doesn't
[04:03] <jbailey> Suspect fan issue is still there, will know in a couple of minutes.
[04:03] <jbailey> rtc issue is still there.
[04:03] <jbailey> [  121.941299]  BENC: Obtaining rtc_lock in rtc_proc_show
[04:03] <jbailey> [  121.941305]  BENC: at 1157
[04:03] <jbailey> [  121.941314]  Oops: Machine check, sig: 7 [#1] 
[04:03] <jbailey> [  121.941915]  SMP NR_CPUS=4 POWERMAC
[04:03] <BenC> damn, thanks for testing
[04:04] <BenC> cat /proc/version please
[04:04] <BenC> see if it shows the 3.4 compiler
[04:04] <jbailey> jbailey@starshine:~$ cat /proc/version
[04:04] <jbailey> Linux version 2.6.15-5-powerpc64-smp (root@davis) (gcc version 3.4.5 20051015 (prerelease) (Ubuntu 3.4.4-9)) #1 SMP Wed Nov 30 14:27:17 UTC 2005
[04:04] <jbailey> I was just looking for that.  Tried uname -a and dmesg first. =)
[04:04] <BenC> ok, and also, do a "free" for me
[04:04] <BenC> see if it shows your memory
[04:04] <jbailey> jbailey@starshine:~$ free
[04:04] <jbailey>              total       used       free     shared    buffers     cached
[04:04] <jbailey> Mem:       4008868     310692    3698176          0       9820     134340
[04:04] <jbailey> -/+ buffers/cache:     166532    3842336
[04:04] <jbailey> Swap:     19531232          0   19531232
[04:04] <BenC> so you have 6gigs, huh?
[04:04] <jbailey> FWIW, the cat still results in a bus error.
[04:05] <jbailey> According to t-bone when I read him the serial number of the machine.
[04:05] <jbailey> I don't know Mac hardware enough to say for sure.
[04:05] <jbailey> Fan issue definetly not fixed.
[04:05] <jbailey> Although it occurs to me that it might be a side effect of the oops.
[04:05] <jbailey> I haven't tried *not* oops'ing the kernel to see if it happen.s
[04:05] <infinity> BenC : Feh, both variants used to have highmem.h, or lrm-2.6.12 wouldn't have built.  (or something else is goofy)... So, WTF do I do now? :)
[04:06] <BenC> infinity: breezy kernel doesn't have asm-ppc64/highmem.h
[04:06] <jbailey> BenC: Lemme reboot and see if the fan issue is a side effect.
[04:06] <BenC> ok
[04:06] <infinity> BenC : Actually, wait, this isn't in ppc64 anyway, this is in ppc..
[04:06] <infinity> (And yes, I just switched to ARCH=powerpc, same problem)
[04:06] <BenC> hmm
[04:08] <infinity> BenC : /usr/src/linux-headers-2.6.15-5-powerpc/include/linux/highmem.h tries to include asm/highmem.h
[04:08] <infinity> BenC : Clearly, something is in the wrong here. :)
[04:08] <BenC> infinity: you're correct, I need to fix that for -6.8
[04:09] <infinity> Feh.  Alright, well LRM is stalled on that, then.  As is linux-meta and udev and friends.  Your turn to be the blocker. :)
[04:09] <infinity> ETA on -6.8?
[04:09] <infinity> BenC : And can you do a test build of LRM against -6.8's headers on PPC before you upload?
[04:10] <BenC> is lrm uploaded now?
[04:10] <infinity> Yup.
[04:10] <infinity> I uploaded it before testing on powerpc.  Stupid me.
[04:10] <BenC> sweet, I'll have -6.8 out tonight then
[04:10] <infinity> So it's built on i386, amd64, and ia64.
[04:10] <BenC> I can get a rebuild for ppc
[04:10] <infinity> Oddly enough, so can I.
[04:11] <infinity> I happen to know the buildd guy personally.
[04:11] <BenC> well, we'll really need an ABI bump anyway
[04:11] <infinity> (But it'll need an ABI... yeah)
[04:11] <BenC> two words....smart and ass... :)
[04:11] <jbailey> BenC: Fan issue definetly not side effect.  Going strong and no oops in dmesg.
[04:11] <jbailey> Need anything else from this kernel?
[04:11] <BenC> jbailey: nah, we're good, thanks
[04:12] <infinity> BenC : Define "tonight"... 6-8 hours?
[04:12] <BenC> closer to 8
[04:12] <infinity> BenC : If so, I'll go to bed now, and re-do LRM in the morning.  I kinda want to babysit it for paranoia's sake.
[04:12] <BenC> sure thing
[04:12] <infinity> So don't bother doing the ABI bump yourself this time.
[04:12] <infinity> Next time, it's all yours. :)
[04:13] <BenC> check topic in AM, and if you see -6.8 uploaded, kick lrm for me :)
[04:13] <infinity> It shall be done.
[04:13] <infinity> Thanks, dude.
[04:30] <BenC> no problem
[04:58] <CataEnry> bye all
[05:24] <zul> doh...my cron script doesnt want to work..aiiee
[05:42] <mjg59> BenC: Current softmac+bcm43xx should be able to scan
[05:53] <BenC> I have current softmac fairly recent bcm
[05:53] <BenC> mjg59: I pulled rtl8180 and rtl8187, since they are both unable to load (missing symbols)
[05:54] <mjg59> BenC: Ok
[05:54] <BenC> just did a compile out of CVS and it doesn't work
[05:54] <mjg59> What are the missing symbols?
[05:54] <BenC> ieee80211_wx_read_name and some such
[05:54] <mjg59> Oh, right
[05:54] <mjg59> Fun
[05:54] <BenC> doesn't show up as a function in ieee80211 or ieee80211_softmac
[05:54] <mjg59> How about in -netdev?
[05:54] <BenC> possible, but I haven't pulled a netdev
[05:55] <BenC> I'll ask jgarzik and davem and see if it's safe to pull from there
[05:56] <mjg59> Ok
[06:53] <jbailey> BenC: For ppc64, should I just continue to use 2.6.12, or are we hoping that -6.8 has more love for ppc64?
[07:00] <BenC> hold off till I can talk to benh about what might be the problem
[07:01] <BenC> I can easily "fix" the rtc issue by not compiling the module, but the fan issue is more of a problem
[07:05] <jbailey> Makes sense. thanks.
[07:21] <mkrufky> hey guys, i know this is off topic, but it's an easy question --
[07:22] <mkrufky> last year i had some ubuntu installation cd's sent to me, i think i had ordered them from a web site, i dont remember
[07:22] <mkrufky> anyhow, we're thinking of switching a whole bunch of boxes in the office here over to ubuntu
[07:22] <mkrufky> does anyone know where i can find that web site for the cd mailers?
[07:22] <mkrufky> not easily found on ubuntu.org
[07:23] <fabbione> shipit.ubuntu.com
[07:24] <mkrufky> awesome
[07:24] <mkrufky> thanks
[07:24] <fabbione> np
[08:37] <mjg59> BenC: Is there a list of which 2.6.12 patches are included in our 2.6.15, and which have been dropped?
[08:37] <mjg59> BenC: It looks like we're still missing the Toshiba acpi hotkeys patch
[08:38] <BenC> mjg59: the large acpi patch sets I didn't include, but I was pretty sure I got most of the smaller ones (especially machine specific ones)
[08:38] <mjg59> I get errors on boot about an invalid option on the Toshiba hotkeys
[08:39] <BenC> I didn't add the old patch names to the git log, but I wish I had of
[08:45] <mjg59> BenC: Looks like we haven't had anything applied to toshiba_acpi
[08:45] <BenC> ok, I'll find the patch from breezy and apply it
[09:24] <mkrufky> i just noticed em8300 in the ubuntu kernel tree
[09:24] <mkrufky> is that fair game for us in v4l to play with?
[09:24] <mkrufky> i mean, it is GPL and everything?  is there any reason it hasnt been included in vanilla kernel?
[09:25] <mjg59> It's GPL, yeah
[09:25] <mjg59> I've no idea why it's not upstream
[09:25] <mjg59> Possibly the developers have just never pushed it
[09:25] <mkrufky> okay... i'll see what i can do
[09:25] <mkrufky> i see it has some brooktree encoders also in the same dir
[09:26] <mkrufky> hmm
[09:26] <mkrufky> is there a list anywhere of the drivers in the ubuntu tree that are NOT in the vanilla tree?
[09:26] <mkrufky> i saw a small list on kernelgitguide
[09:26] <mkrufky> but doesnt look to be complete
[09:30] <zul> mkrufky: pretty much things like ndiswrapper is not in the vanilla tree..previous versions have a list of external-drivers
[09:30] <mkrufky> okay, i'll have to take a closer look
[09:30] <mjg59> mkrufky: Yeah, there's drivers for a couple of TV encoders in there
[09:31] <mkrufky> but something like em8300 ... would probably be nice for us to import
[09:31] <mkrufky> i see it also has bt865, em9010, adv717x 
[09:31] <mkrufky> adv717x ... someone was asking for that the other day
[09:32] <mjg59> http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fbcollins%2Fubuntu-2.6.git&a=search&h=0235c9b32a0f66e94da2d6bd8edf7f55224ce1c2&s=external+driver should give you all of them
[09:32] <mkrufky> nic
[09:32] <mkrufky> nice
[09:32] <mjg59> But the commit title doesn't always give the driver name
[09:32] <mkrufky> hmm i see
[09:34] <mjg59> BenC: Is at76c50x still dropped?
[09:35] <BenC> if it isn't in there, it'e because it's broken
[09:35] <mjg59> Ok
[09:37] <mkrufky> does anybody here know where you got em8300 from?
[09:37] <mkrufky> there is something in linuxtv cvs .... not sure if it's the same
[09:38] <mkrufky> oops, i found it in the commit msg
[09:38] <mkrufky> thanx
[10:06] <mkrufky> ok, the em8300 driver in  DVB cvs (not dvb-kernel) has also em8300 dvb driver, but it is completely different code
[10:09] <mjg59> Weird
[10:13] <mkrufky> ya... my interest has been sparked....... i ordered an em8300 card from ebay by accident last month.... so now i have a use for it
[10:14] <mkrufky> i bet the dvb driver does the same thing, but using a dvb interface instead of a v4l interface ..... 
[10:40] <zul> later
[10:40] <CataEnry> hi all
[12:01] <mkrufky> bye all