=== dmk [n=dmk@host81-155-39-68.range81-155.btcentralplus.com]  has left #ubuntu-kernel ["Leaving"] 
=== doko_ [n=doko@dsl-084-059-065-068.arcor-ip.net]  has joined #ubuntu-kernel
[12:58] <mjg59> BenC: Hi - did you get my patch for fixing hibernate?
[01:05] <lamont> Adding console on ttyS0 at MMIO 0xff5e0000 (options '9600n8')
[01:05] <lamont> RAMDISK: Compressed image found at block 0
[01:05] <lamont> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
=== lamont pokes jbailey
[01:06] <lamont> checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd                                                                        
[01:06] <lamont> Freeing initrd memory: 9056kB freed
[01:06] <lamont> hrm... interesting
[01:35] <jbailey> lamont: Eh?  What's that from?
[01:36] <lamont> ia64, latest breezy
[01:36] <lamont> note that nothing 2.6.12-ish boots on ia64, but this is yet another new failuer
[01:37] <lamont> ii  initramfs-tool 0.21           tools for generating an initramfs
=== macgyver2 [n=eric@unaffiliated/macgyver2]  has joined #ubuntu-kernel
[01:37] <jbailey> lamont: file /initrd.img  should tell you that it's a gzip'd thing.
[01:38] <jbailey> file -z should tell you that it's a cpio archive.
[01:38] <lamont>  /boot/initrd.img-2.6.12-8-itanium-smp: gzip compressed data, from Unix, max compression
[01:38] <jbailey> If those are true, then there's some love needed in the kernel.  Otherwise lemme know and I'll get it sorted out.
[01:38] <lamont>  /boot/initrd.img-2.6.12-8-itanium-smp: ASCII cpio archive (SVR4 with no CRC) (gzip compressed data, from Unix, max compression)
[01:38] <jbailey> Yup, those are what they should be. =(
[01:39] <lamont> so that "checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd" is to blame?
[01:39] <lamont> where does that come from, I wonder?
[01:39] <jbailey> init/initramfs.c
[01:40] <jbailey> It calles into unpack_to_rootfs with the buffer.
[01:40] <jbailey> There doesn't look to be anything arch specific in there, so I would've thought if it works on ppc64 (which it does) it would work on ia64.
[01:42] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [N/y/?]  n
[01:42] <lamont> is that bad?
[01:42] <jbailey> Is there such thing as a DSDT on ia64?
[01:42] <jbailey> I didn't think there was any concept of power management. =)
[01:42] <lamont> what's a DSDT?
[01:42] <jbailey> acpi bits.
[01:42] <lamont> there is most certainly ACPI
[01:43] <lamont> as in, it's fatal to not have CONFIG_ACPI
[01:43] <jbailey> You replace the DSDT tables when your vendor sucls/
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [N/y/?]  (NEW) n
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [Y/n/?]  y
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [Y/n/?]  y
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [Y/n/?]  y
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [Y/n/?]  y
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [N/y/?]  (NEW) n
[01:43] <lamont>   Read DSDT from initrd or initramfs (ACPI_INITRD) [N/y/?]  n
[01:43] <lamont> so some of them have it...
[01:44] <lamont> /boot/config-2.6.12-8-itanium-smp:CONFIG_ACPI_INITRD=y
[01:44] <lamont> including the (failing-to-boot) kernel
[01:45] <jbailey> lib/inflate.c is what's failing for you.
[01:45] <jbailey> It claims bad magic number.
[01:45] <jbailey> Your guess as to whether it's got it wrong, or if the buffer handed in is wrong.
[01:45] <jbailey> Well, hex editor should tell you the first one.
[01:45] <jbailey> Although I'm be surprised if ia64 had a different gzip header.
[01:46] <lamont> 0000000: 1f8b 0800 4335 1643 0203 e43b 5b6c 1cd7  ....C5.C...;[l..
[01:46] <lamont> 0000010: 7567 6676 a9d9 e592 9ed5 c319 babb c4d0  ugfv............
[01:46] <jbailey> The joys of hex to octal conversion. =)
[01:47] <lamont> 0000000: 00011111 10001011 00001000 00000000 01000011 00110101  ....C5
[01:47] <lamont> 0000006: 00010110 01000011 00000010 00000011 11100100 00111011  .C...;
[01:47] <lamont> :-)
[01:47] <lamont> 0000000 105437 000010 032503 041426 001402 035744 066133 153434
[01:47] <lamont> 0000020 063565 073146 154651 111345 152636 014703 135672 150304
[01:47] <jbailey> 1F
[01:47] <lamont> there.
[01:47] <lamont> 1f == 037
[01:48] <lamont> otoh, if file says it's compressed data, then it is...
[01:48] <jbailey> 8b
[01:48] <lamont> 213
[01:48] <jbailey> 9e
[01:48] <lamont> 236
[01:48] <jbailey> The third character appears to be wrong.
[01:49] <jbailey> Food time, back in 30m or so.
[01:49] <lamont> zcat /initrd.img| cpio -i --list
[01:49] <lamont> that works just fine from the command line
[01:54] <lamont> BenC: you need more sigs on your key man...
[01:56] <lamont> jbailey: and we don't care that this initrd.img is > 9MB, right?
[02:03] <lamont> jbailey: actually, magic[0] == 037, and magic[1] ==0213
[02:03] <lamont> magic[2]  isn't checked...
[02:03] <lamont> magic[1]  is checked against both 8b and 9e
[02:04] <lamont> and method == 8, like it should be...
[02:21] <lamont> so either we're passing a bad buffer, we read it wrong, or there's a bug in get_byte() (which looks unlikely)
[02:23] <lamont> time for this one to run off to the back-to-school night
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[02:45] <zul> morning kids
[02:50] <jbailey> Baaaah
[02:51] <zul> whats up jbailey 
[02:52] <jbailey> Not much, just sitting down for more hacking.
[02:52] <zul> cool
[02:58] <zul> same here
[02:59] <jbailey> ROAR
[02:59] <jbailey> #12915
[03:00] <jbailey> Silly rabbit, but ah well.
[03:01] <zul> whoops
[03:03] <jbailey> Oh, hey.
[03:03] <jbailey> -rw-r--r--  1 root root 1309702 2005-06-24 13:54 vmlinuz-2.6.10-5-amd64-k8
[03:04] <jbailey> It's less than the size of a floppy!
[03:04] <jbailey> I thought it was bigger these days...
[03:04] <jbailey> Hmm
[03:04] <jbailey> I wonder if that's small enough to do the magic I wanted to with boot floppies.
[03:04] <jbailey> Ah well, it's a question for another time.
[03:08] <zul> hmmm...wtf
[03:08] <jbailey> What are you wtfing?
[03:08] <jbailey> And hows the laptop? =)
[03:08] <zul> when i try to commit something it say no arch user id set
[03:08] <zul> the laptop is fine very fine, very small, very hot...it has no fan
[03:08] <jbailey> I think there's a baz my-id command or something like that.
[03:08] <jbailey> No fan?
[03:09] <jbailey> What type of beast is it?
[03:09] <zul> dell latitude x1
[03:09] <zul> one of thos sub notebooks
[03:09] <jbailey> Cute. =)
[03:10] <zul> they keyboard is like the size of my hand
[03:11] <zul> ill bring with me if i make it to montreal
[03:14] <jbailey> Please do. =)
[03:15] <zul> so my probation is done oct 17 around there so hmmm...
[03:16] <jbailey> So at that point you can screw off a bit more? =)
[03:16] <zul> yeah sure :)
[03:21] <zul> hmm...one of my neighbours has an open wirless point
=== desrt watches jbailey ignore bug mail
[03:27] <desrt> :P
[03:30] <zul> yeah its fun..:)
[03:31] <zul> BenC: i added hotplug support for buslogic scsi cards...stupid vmware
[03:41] <jbailey> desrt: Hmm?
[03:41] <jbailey> Do you mean 12915?
[03:42] <desrt> that number seems too low
[03:42] <jbailey> Which bug?
[03:42] <desrt> i'm just joking around because i submitted a bug and it was assigned to you but you were on the "Excluding:" list :P
[03:42] <jbailey> Oh.  It must be assigned to me then. =)
[03:42] <desrt> it is :)
[03:42] <jbailey> I don't have it email me on updates for bugs that are assigned to me.
[03:43] <desrt> it's a simple bug report -- "[breezy]  please ship <linux/inotify.h>"
[03:43] <jbailey> Yup, 14456
[03:43] <jbailey> Are there really userspace components in that head?  What fails without them?
[03:43] <jbailey> Is it an interface that should be provided by a library instead?
[03:44] <desrt> i'm writing inotify support for gnome-vfs
[03:44] <desrt> it uses raw syscalls
[03:44] <desrt> (since nothing is really available yet)
[03:44] <desrt> the linux/inotify.h defines constants and the data structure for reported events
[03:44] <jbailey> So are you expecting just the defines and the struct?
[03:44] <desrt> exactly
[03:44] <jbailey> Hmm.
[03:45] <jbailey> How stable is inotify_event?
[03:45] <desrt> totally
[03:45] <jbailey> I know that inotify was recently added to glibc CVS.
[03:45] <desrt> it's in an official kernel release...
[03:45] <jbailey> Bah, doesn't mean stability. =)
[03:45] <desrt> ya it does :P
[03:45] <jbailey> This is *linux* that we're talking about. =0
=== jbailey pines for the glorious days of the Hurd.
[03:45] <jbailey> but ah well.
[03:45] <desrt> i tried to get rlove to change some stuff about it... he was like "man.. i wish you'd talked to me like 2 months ago"
[03:47] <jbailey> If I hand you a .h file, can you try it for me?
[03:47] <desrt> ...sure
[03:47] <desrt> i'm just using one i plucked out of the linux-source package
[03:47] <jbailey> Right, except that all of the header files I provide are cleaned for userspace.
[03:47] <desrt> cool.
[03:48] <desrt> hook it up :)
[03:48] <jbailey> http://people.ubuntu.com/~jbailey/inotify.h
[03:48] <desrt> man.. i love how firefox wants to open everything with less
[03:49] <desrt> almost
[03:50] <desrt> +#define IN_MASK_ADD            0x20000000      /* add to the mask of an already existing
[03:50] <desrt> watch */
[03:50] <jbailey> Umm.
[03:50] <jbailey> That wasn't in 2.6.12's headers AFAICT.
[03:50] <desrt> :)
[03:50] <desrt> it definitely is not :)
[03:50] <jbailey> Is it in 2.6.13?
[03:50] <desrt> nope.
[03:50] <desrt> it will be in .14 though
[03:50] <jbailey> Or is this the stability of the interface you were telling me about? =)
[03:51] <desrt> this is an ABI-compatible change :P
[03:51] <jbailey> Unhuh.
[03:51] <jbailey> Is it a backwards compatible change?
[03:51] <desrt> yes.  but definitely not forward.
[03:51] <jbailey> Like if someone uses that, will it still work correctly on the breeze 2.6.12?
[03:51] <jbailey> +kerney
[03:51] <jbailey> kernel
[03:51] <desrt> i'm going to file a bug about that now :)
[03:51] <desrt> i have an email in my inbox from this morning aobut that patch, Signed-off-by: Robert Love <rml@novell.com>
[03:52] <jbailey> Dude, I can't randomly add pieces to the Interface from future kernel versions...
[03:52] <desrt> ok.  fair enough.
[03:52] <desrt> i'll file this one separately
[03:52] <jbailey> Thanks. =)
[03:52] <jbailey> That should freak upstream out.
[03:53] <jbailey> I haven't committed anything to linux-libc-headers in months. =)
[03:53] <desrt> upstream = debian?
[03:53] <jbailey> Nope.  Our linux-kernel-headers are unrelated to Debian's.
[03:53] <jbailey> We share it with a couple other distros.
[03:53] <desrt> ah
[03:53] <jbailey> I couldn't convince Debian to play along.
[03:53] <desrt> "some guy on irc told me it's ok"
[03:53] <desrt> :)
[03:53] <jbailey> Well, that's why I won't accept your idea of randomly adding defines. =)
[03:54] <jbailey> Besides, you're Canadian..
[03:54] <jbailey> We have to stick together. =)
[03:54] <desrt> i'll cc you on the kernel bug then :P
[03:58] <zul> simpsons...bbiab
=== jbailey shakes his fist at Chuck.
[03:58] <jbailey> Damn you and your cable TV!
[03:58] <zul> hehe
[03:59] <zul> whoops...just kernel paniced the wrong box
[03:59] <desrt> jbailey; can i confirm this bug?
[04:00] <jbailey> Don't bother, I'll close it in a few minutes.
[04:01] <desrt> er
[04:01] <desrt> with or without random additions? :)
[04:01] <jbailey> I'm just looking at 9026 right now to see if I can fix it easily.
[04:02] <desrt> seems somewhat more important :)
[04:02] <desrt> thanks
[04:07] <jbailey> It's not.  Don't use kernel headers.
[04:07] <jbailey> It's always the rule.
[04:07] <jbailey> If they happen to work, then great.
[04:07] <desrt> hmm
[04:08] <desrt> so basically, the libc should build against the kernel headers
[04:08] <desrt> and you should always use libc
[04:08] <jbailey> Right.
[04:08] <jbailey> The kernel doesn't provide a stable user interface.
[04:08] <desrt> what about really really kernely stuff like input.h?
[04:09] <desrt> well, i guess that falls under the ", then great." clause :P
[04:10] <jbailey> Yup
[04:10] <jbailey> The *kernel* people have said "Don't use these headers"
[04:10] <desrt> nod.
[04:25] <mjg59> desrt: There's a project that works on maintaining a clean set of kernel headers that are usable for userland
[04:29] <jbailey> We do bastardly things. =)
[04:33] <mjg59> Oh argh.
[04:33] <mjg59> reboot=b doesn't work on all hardware.
[04:33] <mjg59> FFS.
[04:34] <mjg59> So now we may need to drop back to reboot=h by default and supply a mechanism for userspace to switch the kernel to reboot=b
[04:34] <jbailey> What do those mean? =)
[04:36] <mjg59> reboot=b gets the kernel to jump to the reset code in the bios
[04:36] <mjg59> reboot=h gets the kernel to trigger a reset through the keyboard controller
[04:36] <jbailey> Ah, evil.
[04:36] <mjg59> h is the default, except it doesn't work on some new HPs for reasons I haven't tracked down
[04:37] <mjg59> b is our default, and doesn't work on some machines
[04:38] <jbailey> Ah, cool.
[04:39] <jbailey> What happens in the failure case, does it just not reboot?
[04:39] <mjg59> Yes
[04:39] <jbailey> Is there a sane way to try the keyboard controller, and if we still happen to be running half a second later, jump to the bios?
[04:39] <mjg59> No, the machine hangs at that point
[04:39] <jbailey> Ah, suck.
[04:39] <mjg59> What's *insanely* annoying is that if I run the *same code from userspace*, it reboots
[04:40] <jbailey> Hopefully you mean from something other than ring 3 protected mode userspace...
[04:41] <mjg59> Nah
[04:41] <mjg59> Needs root, though
[04:41] <mjg59> It's just a matter of outbing to the keyboard controller
[04:43] <jbailey> Any chance of just doing the reboot from userspace then as K00reboot ?
[04:44] <mjg59> Hm. An interesting idea.
[04:45] <mjg59> Not really, though
[04:45] <mjg59> The kernel needs to shut down devices
[04:45] <mjg59> disk syncing, that sort of thing
[04:46] <jbailey> But..
[04:46] <jbailey> It'd be like the good old days.
[04:46] <jbailey> "sync; sync; sync; reboot"
[04:47] <mjg59> Haha
[04:47] <mjg59> But:
[04:47] <mjg59> No
[04:49] <desrt> mjg59; sounds like a suitably evil project :)
[05:11] <fabbione> morning
=== rtcm [n=jman@217.129.142.72]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[02:32] <zul> heylo
[02:33] <zul> mjg59: the tg3 network cards doesnt come back from suspend properly think i might have found a patch
[03:02] <mjg59> zul: What are you running?
[03:19] <zul> dell latitude x1
[03:19] <zul> i put it to sleep, waked it up and my irc sessions were dropped last night
[03:20] <zul> ill make a patch for it tonight with my syskonnect stuff
[03:22] <zul> stupid syskonnect
=== spayne [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
=== crimsun [n=crimsun@sh.nu]  has joined #ubuntu-kernel
=== sedak [n=fred@82-32-125-115.cable.ubr04.hawk.blueyonder.co.uk]  has joined #ubuntu-kernel
[03:59] <mjg59> zul: Colony 3 or a daily? (Or have you upgraded?)
[03:59] <mjg59> If you sleep for more than a minute or so, any open connections will probably have been dropped
[04:01] <BenC> zul: if you make a patch for tg3, run it past dave miller
[04:16] <BenC> anyone have some knowledge of suspend-to-ram?
=== Mithrandir points BenC to mjg59 
[04:21] <zul> Colony3
[04:24] <BenC> zul: sounds like you have a lot of patches queued up for me :)
[04:25] <BenC> zul: you have 13370 (dell libsata patch) already done?
[04:26] <zul> yep...not tested yet...was going to test it tonight am at work right now though :)
[04:31] <BenC> ok
[04:57] <zul> 2 patches so far, the buslogic hotplug and the libsata patch
[04:58] <zul> i have to compile a new kernel tonight and make sure that it compiles ok though
[04:59] <zul> im writing a script that will automate the build for me as well so *shrug*
[05:02] <mjg59> zul: Ok. Things might improve if you grab the latest acpi-support and acpid
[05:13] <zul> ok
[05:27] <chmj> hello
[05:28] <chmj> I found a kernel ops 
[05:28] <chmj> http://people.ubuntu.com/~charles/ath_failure.log
[05:28] <chmj> just by inserting a netgear wireless cardbus
[05:29] <chmj> after it is detected and the drivers are loaded I just typed bash$ iwlist scan 
[05:29] <chmj> scans and gives a segmentation fault and then the kernel crashes :( 
[05:32] <chmj> zul: any idea ? 
[05:38] <BenC> chmj: where is the source that contains ieee80211_iterate_nodes()?
[05:38] <BenC> not in the standard linux-source
[05:39] <mjg59> BenC: atheros is in l-r-m
[05:39] <BenC> ah, not my bug :)
[05:39] <chmj> eheh 
[05:40] <BenC> [4294818.012000]  Unable to handle kernel paging request at virtual address 0000ffff
[05:40] <chmj> yes, its in l-r-m 
[05:40] <BenC> just a guess, but that 0x0000ffff is just a little too coincidental
[05:41] <BenC> is atheros binary, or non-free source code?
[05:41] <BenC> or a little of both like nvidia?
[05:42] <chmj> I'm not sure 
[05:42] <BenC> should be an easy bug to find
[05:42] <zul> chmj: not mine either :)
[05:42] <chmj> bah!
[05:42] <BenC> that virtual address is non-random, so can be tracked without much debug
[05:43] <chmj> BenC: I'll give it a try
[05:43] <BenC> same virtual address verytime, right?
[05:43] <BenC> every time
[05:43] <chmj> I am a newbie though 
[05:44] <BenC> start putting some printk's all around ieee80211_iterate_nodes() (like printk("D: %s\n", __LINE__);)
[05:44] <BenC> not %s, %d
[05:48] <chmj> ok 
[05:48] <chmj> bbl, taking a break 
[06:44] <zul> hmm...xen udebs
[07:11] <jbailey> Food time.
=== lamont [n=lamont@15.238.5.156]  has joined #ubuntu-kernel
=== jbailey [n=jbailey@testhaus.cns.utoronto.ca]  has joined #ubuntu-kernel
[08:16] <zul> why did i think today is wednesday?
[08:19] <jbailey> You want a longer time at work to slack off with your laptop?
[08:56] <zul> shaddup
[08:57] <zul> wohoo...its my birthday monday
[08:57] <jbailey> Nice, it's your 30th?
[09:20] <zul> yeah it is..
[09:20] <zul> im so freaking old
[09:21] <BenC> I got 3 years on ya
=== spayne [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[09:22] <zul> well not quite old then :)
[09:23] <zul> BenC: do you go..."back in my day we had to write our own kernel driver to write a midi file"
[09:24] <zul> oi vey im tired
[09:26] <BenC> no, I usually say things like "back in the day, writing real programs was done in all hex"
[09:26] <BenC> or "I remember peeking and poking, but it wasn't considered vulgar"
[09:28] <jbailey> =)
[09:34] <zul> lol
=== Seveas [n=seveas@seveas.demon.nl]  has joined #ubuntu-kernel