=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@dsl-165-202-116.telkomadsl.co.za]  has joined #ubuntu-kernel
[01:06] <crimsun> mjg59: (RE: #41015, #44066) yes, that's what I thought as well, since that's what the source in ac97_codec.c does, which is how -21- functioned. Note that the reporter of #41015 says that -21- has the bug whereas -22- fixed it. On the other hand, #44066 reports that -21- worked fine, but -22- broke the LED. And for kickers, they all have /identical/ sub{vendor,device} ids.
[01:09] <mjg59> crimsun: Right, but what change was there between -21 and -22?
[01:10] <mjg59> The only thing I can think of is that my magic quirk was broken and didn't do the headphones properly
[01:11] <crimsun> mjg59: I replaced AC97_TUNE_HP_MUTE_LED for 0x103c0934 with AC97_TUNE_HP_ONLY (which clearly explains #44066)
[01:12] <mjg59> crimsun: Right, but why was TUNE_HP_MUTE_LED not sufficient?
[01:13] <mjg59> HO_MUTE_LED is supposed to do what TUNE_HP_ONLY does
[01:13] <mjg59> If it's not, then that's the bug
[01:13] <crimsun> mjg59: that's what I can't figure out, since the code in ac97_codec.c clearly indicates that things _should_ work
[01:13] <mjg59> If there's no difference between them, then the submitter is on crack
[01:14] <crimsun> mjg59: right, I've reopened #41015 and asked for more information
[01:14] <mjg59> Ok, thanks
[01:14] <mjg59> It's known that over suspend/resume recent HPs seem to stop running the speakers
[01:15] <mjg59> I don't /think/ that's due to the TUNE_HP_MUTE_LED thing
[01:15] <crimsun> no, I'm pretty certain it's not
[01:18] <mjg59> The headphones still work, but, well
[01:18] <mjg59> And the ac97 registers are identical
[01:18] <mjg59> Which makes debugging it pain
=== jkakar [n=jkakar@204.174.36.228]  has joined #ubuntu-kernel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== _mike_ [n=mike@220.157.65.236]  has joined #ubuntu-kernel
[04:06] <crimsun> BenC: #44283 is legitimate, please merge http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=820fd69dc0f3a57236c7c7942cbd28a4bb9eae19;style=gitweb
[05:24] <BenC> crimsun: ok
[05:25] <crimsun> BenC: thanks!
=== allee [n=ach@dialin-212-144-128-204.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== Mithrandir [n=tfheen@c5100BC63.inet.catch.no]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-kernel
=== _mike_ [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== _mike_ [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== maswan [i=maswan@kennedy.acc.umu.se]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-212-144-129-128.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #ubuntu-kernel
=== karmak [n=olive@ryxeo.pck.nerim.net]  has joined #ubuntu-kernel
=== _human_blip_ [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-kernel
=== Petaris [n=Petaris@216.56.37.162]  has joined #ubuntu-kernel
=== Petaris [n=Petaris@216.56.37.162]  has left #ubuntu-kernel ["Out"] 
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
[02:41] <zul> heylo
=== karmak [n=olive@ryxeo.pck.nerim.net]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@60.254.67.17]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@60.254.67.17]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-145-254-255-053.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== alleeHol [n=ach@dialin-212-144-129-153.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== jkakar [n=jkakar@204.174.36.228]  has joined #ubuntu-kernel
=== stoat [n=stoat@zeniv.linux.org.uk]  has left #ubuntu-kernel [] 
[04:46] <zul> wq
[04:46] <zul> damn
[05:02] <zul> BenC: having fun writing documentation?
[05:16] <BenC> not really :)
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
[05:47] <BenC> mjg59: ping
[05:49] <mjg59> BenC: Hi
[05:49] <BenC> mjg59: You have a Core Duo macbook, right?
[05:49] <mjg59> BenC: Nope
[05:49] <mjg59> I have a core duo Sony
[05:49] <mjg59> And an imac
[05:49] <BenC> ok, core duo is all I need
[05:50] <BenC> can you see if you can confirm https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/43281 somehow?
[05:50] <BenC> according to the report, core duo's hmm at low power state because of CONFIG_HZ=1000
[05:50] <BenC> hum
[05:51] <mjg59> It's nothing to do with core duos
[05:52] <BenC> it claims Core Duo Mac's and Core Duo Dell's
[05:52] <mjg59> It's poor quality capacitors
[05:52] <mjg59> Well, poor quality power regulation
[05:52] <BenC> should I bother with it?
[05:52] <mjg59> Do you want the overhead of supporting another binary? :)
[05:53] <BenC> no, not really :)
[05:53] <mjg59> Then I wouldn't bother
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[06:37] <BenC> mjg59: Seems the problem with the latest bcm43xx isn't that it doesn't detect my chip, it's that it isn't initializing it correctly
[06:38] <BenC> hw addr is showing up as FF:FF:FF:FF:FF:FF
[06:38] <BenC> thought it might be some change in fw, but re-ripping fw with latest fw-cutter didn't help
[06:38] <BenC> bringing up the interface didn't help either
[06:43] <mjg59> BenC: Ah. There was a patch that was supposed to improve the mac address detection - it may have collided with the pcie patch
[06:43] <mjg59> Which could lead to it never setting the mac address at all. Hang on, I'll take a look
[06:44] <BenC> ok
[06:44] <BenC> there was some collision with your patch and current code, I thought I had made things proper
[06:47] <mjg59> BenC: Yeah, it loks ok
[06:47] <mjg59> I'd look around line 3488 or so
[06:49] <mjg59> Can you dump the different sprom macs and see which one it ought to be picking?
[06:49] <mjg59> Oh, does the interface come up at all (just with a silly mac address)
[06:50] <BenC> well, I didn't try much further after I saw the mac hosed
[06:51] <BenC> I wouldn't expect it to work well in that state anyway
[06:51] <mjg59> Well, that elts us know whether it's just the mac address or whether the entire card is hosed
[06:52] <BenC> let me see what this shows
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[06:59] <BenC> mjg59: Well, it lets me set all the wireless opts I have, and it sees the ap's mac address, but no link
[07:00] <mjg59> BenC: Ok, so it sounds like it's just the mac address
[07:00] <BenC> it uses the first eth address (et1macaddr)
[07:01] <mjg59> Is that valid?
[07:01] <BenC> I need to print it out, because if is_valid_ether_addr() returns ok, then that should not be FF's
[07:01] <mjg59> Yeah
[07:05] <BenC> disconnectiont coming...
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[07:10] <BenC> ok, is_multicast_ether_addr() was broken
[07:10] <BenC> so is_valid_ether_addr() was returning true for FF's
[07:10] <mjg59> Ah
[07:10] <BenC> I copied is_multicast_ether_addr from 2.6.16.13 and now bcm43xx works
[07:10] <mjg59> Yes, that would explain things
[07:10] <mjg59> Cool
=== alex_joni [n=juve@dsplabs.cs.upt.ro]  has joined #ubuntu-kernel
[07:12] <alex_joni> hello
[07:13] <alex_joni> need some help running debuild on a linux-source source package
[07:14] <alex_joni> I added an ADEOS patch to debian/patches/ , and debuild started working ok, compiled most (all?) it needed, but then errored out:
[07:14] <BenC> which linux-source are you trying to build?
[07:15] <alex_joni> linux-source-2.6.12 from breezy
[07:15] <alex_joni> hello BenC, I was the one mailing you the other day.. :)
[07:15] <BenC> what's the error?
[07:15] <alex_joni> can I paste the error in here? or should I use pastebin (4 lines)
[07:15] <BenC> 4 lines is ok
[07:15] <alex_joni> +vmlinux zone_table 0x00000000
[07:15] <alex_joni> make: *** [build]  Error 1
[07:15] <alex_joni> debuild: fatal error at line 765:
[07:15] <alex_joni> dpkg-buildpackage failed!
[07:16] <BenC> you have an ABI bump
[07:16] <alex_joni> got advice what I should do?
[07:16] <BenC> echo "Yes" > debian/abi/i386.ignore
[07:17] <alex_joni> then run debuild again?
[07:17] <BenC> mjg59: If I make a kernel-acpi team in lp, can I make you head honcho? :)
[07:17] <BenC> alex_joni: yeah
[07:17] <alex_joni> BenC: thanks
[07:18] <mjg59> BenC: Heh
[07:18] <mjg59> BenC: Sure
[07:18] <BenC> I'm trying to create some teams related to kernel bugs
=== lamont has sparc questions
[07:22] <zul> ooh...i wanna be on a team ;)
[07:23] <lamont> BenC: pretty please on the CONFIG_ACPI_DEBUG=y for debian/config/ia64/config?  and when will a new kernel hit the archive?
[07:23] <lamont> BenC: and then I have a stupid sparc question for you...
[07:23] <BenC> lamont: Yeah, I'll do that...hopefully be upload in the next day or so
[07:24] <lamont> given a CD in the drive, and an 'ok' prompt on the serial console, how do I boot from the CD?
[07:24] <zul> boot cdrom
[07:24] <lamont> danke
[07:24] <BenC> yeah, that was a stupid sparc question :)
=== lamont hasn't booted sparc before, you see..
[07:25] <BenC> lamont: this acpi thing you are working on for ia64, is that related to the ACPI oops I see at every boot where it disables the ACPI irq?
[07:26] <lamont> BenC: the specific issue for ia64 is that udevplug dies opening the acpi event sysfs file (kernel oops), so you don't boot
[07:27] <BenC> what I get is an IRQ unhandled event, and it disables the IRQ that ACPI is on, so ACPI is disabled
[07:27] <BenC> crimsun: ping
[07:28] <lamont> BenC: ouch.  that might be happening earlier in the boot, dunno.. which arch for you?
[07:29] <BenC> itanium
[07:29] <lamont> ah, ok.  malone 40286, iirc.
=== lamont brb
[07:29] <BenC> it happens very early in boot, prior to initramfs actually
=== ivoks [n=ivoks@lns01-0327.dsl.iskon.hr]  has joined #ubuntu-kernel
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
[07:39] <alex_joni> BenC: got 2 minutes to look at http://pastebin.com/713846 ? , I'm compiling for the xth time today.. hope I didn't forget anything ..
[07:40] <lamont> neet.  sparc box powers itself off if you leave it at that 'ok' prompt long enough.
[07:44] <crimsun> BenC: pong
[07:44] <BenC> crimsun: can you add ubuntu-kernel-team as a member of ubuntu-audio?
[07:44] <BenC> do you have admin for that team?
[07:45] <crimsun> sure
[07:45] <BenC> thanks
[07:45] <BenC> alex_joni: looks good
[07:46] <alex_joni> BenC: ok, thanks..
[07:50] <lamont> grumble
[07:50] <lamont> so after I type 'boot cdrom' it says "ok "
[07:55] <zul> thats should work
[07:56] <zul> unless there is something wrong with the openrom
[07:57] <BenC> lamont: It doesn't spit out a message?
[07:58] <BenC> What type of sparc is it?
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
[08:01] <lamont> Sun Blade 1000 (2 X UltraSPARC-III) , No Keyboard
[08:02] <lamont> screen not found.
[08:02] <lamont> keyboard not found.
[08:02] <lamont> Keyboard not present.  Using ttya for input and output.
[08:02] <lamont> Sun Blade 1000 (2 X UltraSPARC-III) , No Keyboard
[08:02] <lamont> OpenBoot 4.0, 8192 MB memory installed, Serial #16453963.
[08:02] <lamont> Ethernet address 8:0:20:fb:11:4b, Host ID: 80fb114b.
[08:02] <lamont> {0} ok boot cdrom
[08:02] <lamont> Boot device: /pci@8,700000/scsi@6/disk@6,0:f  File and args: 
[08:02] <lamont> SILO Version 1.4.10
[08:02] <lamont> Fast Data Access MMU Miss
[08:02] <lamont> {0} ok 
[08:03] <lamont> mind you, it could be a broken SB1000... or loose cables, or ....
[08:03] <zul> i think i have seen that before there was a bug in launchpad
[08:03] <lamont> something like yesterday's daily
[08:06] <lamont> ok.. how do I tell it to boot from 1.2.3.4?
[08:06] <zul> not sure :(
[08:15] <BenC> you can netboot a tftp image
[08:15] <BenC> boot net
[08:15] <BenC> just need to setup rarpd and tftp
[08:16] <maswan> BenC: btw, out of curiosity, how far away would a debug package with vmlinux for oprofile, etc, be away for the distribution kernels?
[08:16] <BenC> probably something for edgy
=== maswan nods
[08:17] <BenC> if you are interested in seeing it happe, write a spec for it in lp so it can be discussed at the distro sprint in June
[08:18] <maswan> Well, looking forward to se it, so I guess. :)
=== lamont sets up rarpd
[08:18] <lamont> no dhcp/bootp eh? feh.
[08:19] <BenC> you'll need the ether address in /etc/ethers
[08:20] <BenC> and the filename will need to be the ip address in hexformat, plus SUN4U
[08:20] <BenC> actually, no SUN4U
[08:20] <BenC> mine is: C0A80117
[08:21] <BenC> you can usually just do the netboot and watch /var/log/daemon.log for the filename it is requesting
[08:21] <lamont> hrm... how do I get stop+a on a serial console?
[08:21] <BenC> send a serial break
[08:22] <BenC> ^A f
[08:22] <BenC> in minicom
[08:25] <lamont> and there is booting.
[08:27] <lamont> hardware shut off just short of finishing the download... hrm.. wonder if it has overtemp issues....
[08:28] <BenC> sounds like it...the "power off at ok prompt" isn't usual of ultrasparc either
[08:28] <BenC> could be a loose power plug or something too
[08:30] <lamont> CPU casings seem rather warm...
=== lamont wonders how it picks the filename, since C0A82306 bears little resembance to 8:0:20:fb:11:4b
[08:32] <BenC> lamont: preference of the ubuntu hppa team being ubuntu-hppa or ubuntu-parisc?
[08:32] <alex_joni> lamont: what's the mac of the eth ?
[08:32] <lamont> hppa
[08:32] <BenC> lamont: it's the IP address in hex, not the mac
[08:32] <lamont> oh, doh
[08:33] <cjb> lamont: Silly you.  People represent IP addresses in hex all the time, I don't know how you could possibly have missed that.  ;-)
[08:34] <BenC> hehe
[08:35] <lamont> local mirrors are nice for installs.
[08:35] <lamont> hrm... 2 ea 9.1 GB hard drives... to raid, or not to raid.
[08:35] <BenC> not to raid
[08:36] <BenC> silo is very fickle about raids :)
[08:36] <lamont> ah, good point
[08:37] <lamont> does it need a silo partition or such?
[08:37] <BenC> nah
[08:37] <alex_joni> BenC: got another error from debuild, it was building udebs I think, and it complained that 'fan' the module is missing
[08:37] <BenC> lamont: just make sure not to delete the 3rd partition (Whole Disk)
[08:37] <lamont> so just give it a nice / and toss /home on sdb, eh>?
[08:38] <lamont> uh...
[08:38] <BenC> it's needed for Sun Disk Label foo
[08:38] <BenC> yeah
[08:38] <lamont> in the partitioner, told it to wipe the disk
[08:38] <lamont> was that bad?
[08:38] <BenC> nah, that should be good
[08:38] <BenC> it knows
[08:38] <BenC> alex_joni: just do debian/rules binary-debs
[08:39] <alex_joni> BenC: the patch I installed is not compatible with ACPI, so those modules are turned off
[08:39] <BenC> alex_joni: a full debuild isn't going to be useful unless you need the udeb's to create a bootable CD or something
[08:39] <alex_joni> BenC: that's exactly what I am after, the udebs
[08:39] <lamont> BenC: is there a debian/rules invocation to just build one flavor?  (besides just nuking the unwanted arch/config.flavor?
[08:39] <alex_joni> is there a way to see what modules it expects?
[08:39] <BenC> alex_joni: otherwise edit files in debian/d-i/
[08:39] <alex_joni> ok.. looking
[08:39] <BenC> lamont: debian/rules binary-debs flavours=686
[08:40] <lamont> ah, ok
[08:40] <BenC> that leaves the debs in debian/build/
=== lamont wonders if maybe the plastic knife was loose.
[08:41] <alex_joni> BenC: any way to run debian/rules binary-debs or udebs without having it recompile all?
[08:41] <BenC> alex_joni: don't use debuild :)
[08:41] <alex_joni> OK, thx
[08:43] <BenC> or pass -nc so it doesn't do a full clean/build
[08:43] <BenC> it will just start the build from where it left off (atleast dpkg-buildpackage does)
[08:44] <alex_joni> debuild -nc ?
[08:44] <alex_joni> or debian/rules -nc ?
[08:44] <lamont> debuild
[08:47] <BenC> lamont: You get the distinct privledge of owning two kernel arch teams :)
[08:47] <lamont> I feel so proud
[08:48] <BenC> will make it easier to assign bugs during the upcoming kernel hug day
[08:48] <lamont> thanks
[08:48] <lamont> note that I need that ia64 "fix" before I can do much with ia64...
[08:48] <BenC> I'll have it in the next kernel upload
[08:48] <lamont> anyone actually finding the bug is welcome to provide a real fix...
=== lamont will be away from hardware at debconf for the next week
[08:49] <BenC> almost wish I could reproduce it, but maybe with the debug enabled I can atleast fix my acpi bug aswell
[08:54] <alex_joni> BenC: any idea what 'find: lib: No such file or directory' means?
[08:54] <BenC> no idea
[08:55] <alex_joni> :( debian/rules binary-udebs fails with that message
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-kernel
[09:02] <lamont> hehehe... it wants to know what xorg driver to use on this headless box
=== lamont picks ati, since that's the most likely card to get plugged in
[09:03] <lamont> eventually
[09:03] <lamont> maybe.
[09:23] <alex_joni> did you guys ever use module-assistent ?
[09:27] <zul> nope
=== alleeHol [n=ach@dialin-212-144-131-209.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== human_blip [n=mike@220.157.65.236]  has joined #ubuntu-kernel
[09:52] <alex_joni> I meant module-assistant
[09:56] <lamont> why would SIOCSIFADDDR return EPERM, I wonder
=== lamont decides to finish the dist-upgrade before blaming too many things
[09:59] <zul> i blame foobared
[10:15] <alex_joni> anyone knows where the debian-installer package is?
[10:16] <alex_joni> nm, found it..
[10:48] <lamont> hrm.. and here I thought 3GB was a good amount for /...
[10:50] <lamont> fabbione: if you poke your nose in, machine is happy