#ubuntu-kernel 2005-08-01
<fabbione> morning
<fabbione> hey jbailey 
<jbailey> Heya Fabio
<jbailey> I'm about to upload initramfs-tools 0.14
<fabbione> nice
<jbailey> Just need to figure out why bzr doesn't feel like commiting.
<fabbione> jbailey: did you hear anything about binutils to fix that link problem on sparc?
<jbailey> No, but I haven't had a chance to dig in yet.
<jbailey> Sorry about that. =(
<fabbione> no need to be sorry please
<fabbione> :)
<fabbione> i was only asking...
<fabbione> the situation still looks good
<jbailey> Well, I feel bad that I haven't had a chance.
<jbailey> Feeling a bit swamped.
<fabbione> but the gnome pkgs starts to pile up
<jbailey> bzr commit done.
<jbailey> This version actually now detects IDE correctly on my box, SATA on another one, and LVM and Raid1.
<fabbione> nice
<fabbione> i hope i won't crash today
<fabbione> and give it a shot
<fabbione> i am so tired you have no idea
<jbailey> Still no evms or cryptroot.
<jbailey> I just don't have test scenarios for those, so it'll be a bitch.
<fabbione> if you have md and lvm you also have evms
<jbailey> I do?
<jbailey> I'll ask you sometime when I'm awake.
<jbailey> I promised mdz that I'd put out a call for testers today on what I have.
<fabbione> as it stands now.. evms and lvm are "only" 2 interfaces towards device-mapper
<fabbione> if you get one, somehow you get the other
<jbailey> Ah, okay.
<fabbione> but mdz can give you more details about evms
<fabbione> he was the maintainer
<jbailey> 'cept that he's insanely busy.
<fabbione> well he can spend 2 minutes
<fabbione> at least this is at kernel level..
<fabbione> if userland does something "weird" i dunno
<fabbione> i was never able to make evms work in a decent way
<jbailey> evms ate my partition table
<jbailey> So I'm not inclined to try it again.
<fabbione> ehhe
<jbailey> Rejected: binary uploads are not allowed - please only upload source.
<jbailey> Bah
<jbailey> I must get that wrong like *half* the time.
<fabbione> ehhehe
<fabbione> jbailey: when i am linking.. can i avoid to specify -m $emulation ?
<fabbione> or is it somewhat mandatory?
<jbailey> Mmm, I thought it was supposed to detect it from the module.
<jbailey> I might be mistaken.
<fabbione> what i mean is:
<jbailey> It's been so long since I've used ld directly.
<fabbione> ld -m elf_i386 -r -o $dest $modules
<jbailey> Right.
<fabbione> if i omit -m elf_i386, which one will be selected?
<jbailey> I think you ought to be able to leave it out.
<jbailey> It should be detected, so in this case elf_i386
<fabbione> i guess i need to try it
<fabbione> yeah it works on i386
<jbailey> Sleep time. 
<jbailey> fabbione: Hey - did you get a chance to try the initramfs-tools stuff at all?
<fabbione> no :(
<zul> heylo
<fabbione> hey zul
<zul> hey how is it going?
<fabbione> as usual
<zul> exciting
<fabbione> what's exciting about it?
<zul> i was being sarcastic
<lamont__> fabbione: rebooting now
<fabbione> kw33l
<lamont__> well.  that was painful
<fabbione> so?
<lamont__> good news for doko... it's not 3.4
<fabbione> bad news for the ia64 porter :P
<lamont__> bad news for me: it's not 3.4
<lamont__> yeppers
<lamont__> means I have to actually work on it.
<fabbione> lamont__: the only thing i try to do is disable acpi on ia64
<lamont__> ??
<fabbione> it's the only big ia64 chunk of code that's different from Debian
<fabbione> sorry. "i would try to do"..
<lamont__> I should try booting with noacpi?  or there's a kernel patch I should try removing?
<fabbione> try booting with noacpi first
<jbailey> W00t Got my drivers license.
<jbailey> Angie has to wait until she gets better proof of residence.
<jbailey> So stupid.
<zul> its the same in ontario dude
<jbailey> Umm, no.
<jbailey> Her lease was good enough, and a bank statement was good enough for me.
<zul> well..for health card i guess
<jbailey> Well + old license. =)
<jbailey> But here, I needed passport,  ontario health card, ontario drivers license, and a current bill showing transactions only in quebec since I moved sent to this address.
<jbailey> Andit has to be a bill from a 'respectable place'
<zul> so pornos are out? :)
<jbailey> The fact that she bought $3500 worth of appliances from Future Shop that got sent to the appartment that she leased isn't good enough.
<jbailey> Nor is the confirmation from Hydro Quebec saying that her account is now open good enough.
<jbailey> She had a visa bill with her, but the lady just said that it doesn't matter.  The bank will send a statememnt anywhere.
<jbailey> *my* visa bill was fine, though, since it has a u-haul on it, a bunch of gas stops along the 401 and a dozen or so transactions in montreal after that.
<zul> lol...stupid quebec
<jbailey> I thought it was a bit extreme.
<jbailey> But I got mine for now, anyway.
<jbailey> The Hydro bill is in her name, so when that gets sent, that'll be good enough.
<zul> getting married in quebec is pretty extreme i hear as well
<jbailey> Oh?
<jbailey> What's the story there?
<zul> i dont really remmeber unforuntately..
<jbailey> fabbione: ping?
<jbailey> fabbione: any idea if this is going anywhere upstream: http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch
<fabbione> jbailey: acpi -> mjg59 .. really...
<jbailey> Hmm.  This is more initramfs handling, but alright. =)
<jbailey> mjg59_: *poke* ^^^
<jbailey> It looks like we need to apply either that one or this one:
<jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch
<mjg59_> acpi upstream aren't keen on it
<mjg59_> If it's needed for initramfs, then push it
<lamont__> mjg59_: the ia64 issue is more basic... nothing from the kernel but timeout/machine-checks
<mjg59_> lamont__: Mm?
<lamont__> 2.6.10-5 boots fine and all, 2.6.12-current is not so happy.  with or without 'noacpi'
<lamont__> so somewhere in there, I have issues to figure out.
<mjg59_> Can you revert the acpi patch?
<lamont__> could be a fun little bios interaction
<mjg59_> Hmm. Hang on - I seem to remember something that may be related. Hang on.
<lamont__> mjg59_: that's certainly on the list...
<lamont__> mjg59_: the "one console" issue?
<jbailey> mjg59_: Do they have specific concerns that I should work with?  Having it right in the filesystem is elegant in a number of ways.
<mjg59_> jbailey: "Vendors should fix their hardware"
<jbailey> mjg59_: Not the least of which that you can swap dsdt's at boottime with a trivial hack to grub.
<mjg59_> lamont__: If it boots without that, can you grab the latest bleeding-edge ACPI patch and see if that's any better?
<lamont__> mjg59_: certainly.  will probably pester you for where to grab said bleeding-edge razor
<jbailey> fabbione: I have a really strong preference of the acpi-dsdt-initrd-v0.7d.... patch.  It has the advantage that if someone does a custom kernel, they just won't get a DSDT.  With the other one, if they run a stock kernel, the kernel can't load an initramfs with a DSDT in it.
<jbailey> mjg59_, fabbione: What prep/testing do you need me to do in order to test it adequately for you to bless it?
<fabbione> jbailey: are the 2 patches mutal exclusive?
<fabbione> so it's either one or the other
<jbailey> No
<mjg59_> jbailey: The initramfs one looks correct. Break your DSDT, boot with it, see if your machine breaks
<mjg59_> If so, I'm happy with it
<jbailey> mjg59_: The one that just alters the read size to compensate for the DSDT hanging off the end?
<mjg59_> Hang on
* jbailey hangs
<zul> ding dong the wicked witch...er..
<mjg59_> jbailey: Ok. What's the precise issue?
<jbailey> zul: Funny enough, there are bells rining outside.
<zul> lol
<jbailey> mjg59_: With an initramfs, using the traditional way of appending the DSDT to the initramfs causes a boot failure.  The people at this web site are proposing two solutions.  1) (http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch) makes the initramfs read function calculate the size of the initramfs without including the files so that it unpacks the initramfs correctly.  The rest of th
<jbailey> e sstem should go on to process the dsdt correctly.
<mjg59_> Yes. That looks clean enough.
<jbailey> 2)  http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch makes the initramfs system available earlier so that acpi can simply open the file off of the filesystem and read it in.
<mjg59_> Right. I've no preference.
<mjg59_> The first seems less invasive
<jbailey> So here's the catch.
<jbailey> 1) Means that if someone does a custom kernel, but includes a DSDT at the end, they won't have the patch, so the machine won't boot.
<mjg59_> Yes
<jbailey> 2) Means that if someone does a custom kernel, and includes a DSDT in the initramfs, it simpy won't get read by anything.
<mjg59_> Well, either is fine with me. 
<jbailey> Have you seen either of these on upstream lists?  I have a preference for #2 to reduce the support nightmare.
<jbailey> But I suspect that #1, being less invasive, is more likely to get accepted.  But that's entirely a guess.
<mjg59_> Neither is going to make it upstream while acpi upstream are hostile
<jbailey> If neither will make it upstream, then I'll do #2 =)
<jbailey> fabbione: What sort of testing do you want me to do before I say "Please include this patch"?
<fabbione> jbailey: it's enough it works for you....
<jbailey> 'kay
<jbailey> I guess I need to figure out how to compile a kernel now. =)
<fabbione> it looks to me we already have 2
* jbailey blinks
<jbailey> Oh?
* jbailey apt-get source's the kernel to check
<mjg59_> fabbione: I think we only have an earlier version of the patch that doesn't deal with initramfs
<jbailey> Hmm, can I apt-get source the i386 kernel from a ppc?
* jbailey hops onto concordia
<fabbione> jbailey: the kernel is only one
<fabbione> there is only ONE source
<zul> use the source luke
<fabbione> mjg59_: well i have no issues to update it..
<jbailey> Ah, handy
* jbailey blinks.
<jbailey> 26k source?
<jbailey> Oh, that's linux-meta
<jbailey> 47mb, much better
<jbailey> Err..  Is i386 only at 2.6.12-3 ?
<jbailey> That's all concordia seems to have in its chroot's apt sources
<fabbione> jbailey: you can grab the sources from my home on concordia
<fabbione> take 4.4 please
<fabbione> 4.5 is the playground atm
<jbailey> Hmm
<fabbione> desrt: what kernel flavour do you use?
<jbailey> I thought drivers-acpi-osl_attach-dsdt-to-initrd.dpatch
<jbailey>  was already upstream
<lamont__> hrm.. external-global-acpi_update.dpatch is pretty *&(^^%_ invasive
<desrt> fabbione; 686-smp and powerpc64-smp
<fabbione> desrt: ok.. i will make 686-smp for you to test
<lamont__> mjg59_:  external-global-acpi_update* were the two you wanted me to pull?
<desrt> fabbione; the hardware arrived today for our cluster :)
<desrt> fabbione; so, as of tomorrow i'm gonna be running 5 boxes with powerpc64-smp :)
<desrt> (and some time later about 12)
<fabbione> desrt: cool!
<fabbione> desrt: what kind of cluster are you going to run?
<desrt> our own thing
<fabbione> yeah.. i mean. HA or HP cluster?
<fabbione> A=Availability
<fabbione> P=Performance
<mjg59_> lamont__: Yeah
<jbailey> Anyone have a SuSE kernel source handy?
<jbailey> I'd love to see if they apply this other one, it's one of their folks that wrote it:
<jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/acpi_dsdt_initrd_initramfs.patch
<jbailey> http://gaugusch.at/acpi-dsdt-initrd-patches/initramfs-before-acpi.patch
<fabbione> dpkg-deb: building package `linux-image-2.6.12-4-686-smp' in `../linux-image-2.6.12-4-686-smp_2.6.12-4.5_i386.deb'.
<fabbione> and NO ABI breakage!
<fabbione> (....yet)
<jbailey> This too shall pass ;)
<fabbione> desrt: http://people.ubuntu.com/~fabbione/
<fabbione> desrt: there are 3 linux-*-4.5*.deb
<fabbione> can you test inotify with them?
<fabbione> they include all the latest fixed
<fabbione> fixes
<fabbione> just rememeber that is NOT 4.5 final
<fabbione> so you might have to upgrade it later
* lamont__ watches the whole *&%)_ world rebuild, curses acpi
* fabbione goes offline
* desrt downloading now
<desrt> sorry for the delay.  got busy for a moment
<fabbione> desrt: no problem, take your time to test.
<fabbione> i need to go out now
<fabbione> i will bbl
<fabbione> ps don't use SYSCALLS 289 and 290.. they are fake and unsecure atm
<fabbione> i already have a better patch done..
<fabbione> but i need to know if it works for you now with the 291/292/293
<fabbione> in sync with *
<fabbione> later
<desrt> fabbione; problem is not fixed
<desrt> :q
<desrt> erp
<desrt> fabbione; looking at your source package, nothing has changed
<desrt> fabbione; (from looking at source) sys_inotify_rm_watch is still doing improper input validation and (from testing against your binary) i'm still getting the crash
<desrt> from 2.6.13-rc3-git8: http://manic.desrt.ca/inotify.c
<desrt> search for /* verify that this is indeed an inotify instance */
* lamont__ adds external-drivers-ide_sleep to his list, since it's ftbfs without acpi...
<fabbione> desrt: i didn't put any source there...
<fabbione> did you take 4.5 ?
<fabbione> or by mistake you took 4.4?
<desrt> i took linux-source-diff that was in the group of them :)
<fabbione> it's not the one to look at
<desrt> ahh
<desrt> well, in any case, the binary still exibits the crash :)
<fabbione>  /* verify that this is indeed an inotify instance */
<fabbione> this is there
<desrt> uname -a shows Jul 27
<fabbione> twice
<desrt> weird.....
<fabbione> dpkg -l linux-image-2.6.12-4-686-smp
<desrt> 2.6.12-4.5
<fabbione> yeah that's it
<desrt> want me to send you a testcase?
<fabbione> it's all the latest inotify
<fabbione> desrt: did you change the syscalls to match the real ones?
<desrt> yes
<desrt> i'm using 293 now, i think
<fabbione> well.. can you recheck please :)
<desrt> you're using the same syscall numbers as the official 2.6.13, right?
<fabbione> also.. did you check that it is fixed in git8?
<fabbione> yes. right
<desrt> no.  i haven't.
<fabbione> by running it...
<fabbione> well that would be something to do :)
<desrt> cool
<desrt> 293 is, in fact, the right number
<desrt> will test git
<fabbione> thanks
<zul> ohwee...i got business cards
<desrt> man... it's times like this when i'm building a kernel that i wish i had a nice pentium D system
<desrt> crimsun; w3rd.
<crimsun> 'lo desrt 
* desrt plays a good beatles song to honour your presence
<desrt> "nothing's gonna change my world....."
<desrt> fabbione; i get -EINVAL on that syscall on 2.6.13-rc3-git8
<desrt> and no crash
<desrt> so 2.6.13-rc3: bad
<desrt> so 2.6.13-rc3-git8: good
<desrt> and 2.6.12-4.5: bad
<fabbione> desrt: ok.. i will give you another kernel in a few minutes..
<desrt> :)
<fabbione> it looks like not all the patches in git as commented as they should...
<fabbione> desrt: it's building..
<fabbione> if this one still crash, i know exactly what it is
<fabbione> but
<fabbione> it's not going to be fun at all
<fabbione> desrt; http://people.ubuntu.com/~fabbione/desrt/ <-
<fabbione> i will be back in few minutes..
<fabbione> desrt: ?
<desrt> fabbione; just installed and am rebooting now
<fabbione> cool
<desrt> Jul 27 18:25:09 UTC
<desrt> no crash
<fabbione> perfect
<desrt> ship it! :)
<fabbione> do you want to know what it was?
<desrt> ya.  for sure
<fabbione> NEVER TRUST PATCH!
<desrt> uhm... what happened?
<fabbione> basically i was doing cg-mkpatch -r $id | patch -d $pathtokernel -p1
<fabbione> on all inotify commit
<fabbione> no rejects
<fabbione> no fuzzyness
<fabbione> it ended with 2 different files
<fabbione> (same base of course)
<desrt> like what?
<fabbione> there were diffs in the order of some hunks
<fabbione> the final inotify.c was different
<fabbione> @@ -990,6 +991,8 @@
<fabbione>         filp = fget_light(fd, &fput_needed);
<fabbione>         if (unlikely(!filp))
<fabbione>                 return -EBADF;
<fabbione> +       dev = filp->private_data;
<fabbione> +       ret = inotify_ignore (dev, wd);
<fabbione> 
<fabbione>         /* verify that this is indeed an inotify instance */
<fabbione>         if (unlikely(filp->f_op != &inotify_fops)) {
<fabbione> @@ -997,9 +1000,6 @@
<fabbione>                 goto out;
<fabbione>         }
<fabbione> 
<fabbione> -       dev = filp->private_data;
<fabbione> -       ret = inotify_ignore(dev, wd);
<fabbione> -
<fabbione> something like this
<desrt> er
<desrt> that's the inverse of the patch you need :)
<desrt> actually, it's just nonsense
<fabbione> yes sorry..
<desrt> it's like "do it first, check later" :)
<fabbione> i did it the wrong way
<fabbione> but it still landed in the wrong order in the final inotify.c
<fabbione> that's the point
<desrt> nod.
<desrt> well
<desrt> it all seems to be working fine now
<fabbione> never mind the direction of that patch
<desrt> maybe the cg-mkpatch wasn't generating enough lines of context
<desrt> so it just went blindly by linenumber and put it in the wrong place
<fabbione> possibly
<desrt> that'd also explain why it didn't mention any fuzz
<fabbione> baz commit -s'Update inotify'
<desrt> ok.  so is this when a bug becomes PENDINGUPLOAD?
<fabbione> M  patches/sth-fs_inotify.dpatch
<fabbione> M  changelog
<fabbione> yes
<fabbione> but iirc you can't change from UPSTREAM to PENDINGUPLOAD directly
<fabbione> so we will close it after we upload...
<fabbione> not a big deal
<desrt> nod.
<fabbione> jbailey mjg59_: ping?
<jbailey> pong
<fabbione> otherwise you need to put it as ASSIGNED and than PENDINGUPLOAD
<desrt> ya.  evil bugzilla :P
<fabbione> jbailey: remember i will be VAC from 1st of Aug
<fabbione> infinity will take care of the kernel
<fabbione> but i plan an upload for no later than friday
<fabbione> so if there is something important or urgent, it has to be withing friday morning
<fabbione> mjg59_: the above is valid also for ACPI
<fabbione> because the 8th of Aug is Feature Freeze
<fabbione> (or the 5th.. i can never remember)
<zul> hmmm...i think im going to be busy this weekend ;)
<fabbione> zul: no crack please.. only tested committs...
<fabbione> we need to go very stable and very fast
<zul> yep
<fabbione> zul: specially.. test before commit
<fabbione> or at least build
<fabbione> i don't want to come back and have to cleanup a mess :)
<zul> heh...
<zul> all of my group has gone home for the day. and its only 3:13pm
<zul> slackers
<fabbione> ok
<fabbione> time to stop
<fabbione> it's only 9:20 pm
<fabbione> and i started at 6am
<desrt> :)
<desrt> fabbione++ 
<fabbione> another 2 bug fixes done..
<fabbione> desrt: i might upload tomorrow..
<fabbione> or max friday
<fabbione> you can use the temp kernel in the meanwhile
<desrt> it's cool.  it's not actually affecting me
<desrt> i can just avoid passing an invalid fd to inotify :P
<fabbione> uh no.. the other 2 bug fixes are ACPI and USB related
<zul> i think we might have to close some more non-responsive user bugs tonight as well
<fabbione> zul: go ahead
<fabbione> KILL THEM ALL!
<zul> users or bugs?
<fabbione> users of course
<Mithrandir> both, preferably
* fabbione switches to bastart mode
<fabbione> Mithrandir: why so much blood?
<fabbione> users are enough
<fabbione> unresponsive user on bug -> CLOSE
<fabbione> i need to buy another THX
<fabbione> after i moved mine in the living room i miss to listen to music in a decent way
* fabbione goes offlinw
<fabbione> there.. i can't even type anymore...
<jbailey> <fabbione> unresponsive user on bug -> CLOSE
<jbailey> <fabbione> i need to buy another THX
<jbailey> buy another user?
<jbailey> Dude, you don't PAY for those.
<jbailey> They come free. =0
<jbailey> =)
* Mithrandir tickles the man with blue streaks in his hair.
<lamont__> Mithrandir: who went tropical-fish on us?
<Mithrandir> lamont__: http://www.raspberryginger.com/jbailey/weblog/entries/photos/hpim2587.jpg
<jbailey> Mithrandir: eh... =)
<jbailey> Mithrandir: I'm *not* adding a highlight on "blue".  That would be a bit too much. =)
<lamont__> jbailey: you need more elmers glue.
<jbailey> lamont__: Err.  Why?
<Mithrandir> jbailey: looks nice, though
<lamont__> jbailey: no spikes.  that's why. :-)
<jbailey> Mithrandir: Thanks.  What's fun is that 1) There are 10 of them, but most are buried, so they only poke out occasionally.  2) They're all on the side and the back, so I still look respectable if I tie my hair back.
<jbailey> lamont: *lol*
<jbailey> lamont__: The funny part is that they're extensions, so they're basically epoxied onto other hair near the roots.
<lamont__> heh
<Mithrandir> jbailey: have you read citizen cyborg?  I think you may find it interesting.
<Mithrandir> s/may/might/
<jbailey> I haven't, I'll look for it.
<lamont__> fabbione: still awake
<lamont__> ?
<fabbione> lamont__: not for more than 2 minutes
<fabbione> i am crashing
<fabbione>  /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
<fabbione> GREAT
<fabbione> now what did reintroduce this...
<fabbione> bah
<fabbione> i am going to sleep
<fabbione> good night
<lamont__> g'night fabbione 
<lamont__> jbailey: ping
#ubuntu-kernel 2005-08-02
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* desrt wonders why all of this work is being done on 2.6.12
<lamont__> mjg59_: btw - sent someone your way wrt latest thinkpad acpi stuff.
<mjg59_> lamont__: Ah, thanks
* lamont__ adds one beer to what he owes mjg59_ 
<jbailey> lamont__: pong
<TheMuso> .c
<TheMuso> crap
<weridcreep> hello
<lamont__> jbailey: figured it out... although... 
<lamont__> what's the easiest way to abuse an initrd to debug in it?
<weridcreep> what kernel does ubuntu run
<jbailey> lamont__: Existing one, or can you create a new one?
<lamont__> jbailey: (original question involved a brainfart trying to mount the initrd locally to look)(
<jbailey> Editting existing ones is teh suck.
<lamont__> given the recipie, I could create a new one...
<jbailey> Okay, edit /etc/mkinitrd/mkinitrd.conf
<jbailey> Set DELAY=5 and BUSYBOX=yes
<jbailey> (Make sure busybox-cvs-static is installed)
<jbailey> as root:
<jbailey> mkinitrd -o /boot/initrd.img-$(uname -r) $(uname -r)
<jbailey> NOTE:  This will overwrite your current initrd.
<lamont__> yeah - I see that
<jbailey> If you have a sane bootloader (That is, grub grub or grub), you can make it /boot/initrd or something like that and just change it at boot time.
<lamont__> jbailey: elilo :-(
<jbailey> Add an entry for your testing then.
<lamont__> yep
<jbailey> You won't get grub2 for efi for another couple of months.
<jbailey> (although someone has now started on it)
<lamont__> actually, the current state is that 'Linux' doesn't boot, and 'Good' does. :-)
<jbailey> Great!  Overwrite the one for Linux then, nothing to lose.
<lamont__> yeah
<jbailey> Oh!
<lamont__> yeah
<jbailey> Missed a step.
<lamont__> ??
<jbailey> Edit /etc/mkinitrd/modules and add the modules you need to have a working keyboard.
<lamont__> serial atm
<jbailey> 'k =)
* lamont__ has a 2700+ line config diff, and somewhere in there is a fatal option
<jbailey> *blink*
<jbailey> config?
<lamont__> happy happy joy joy.  binary searches are _SO_MUCH_FUN_!!!
<lamont__> kernel config
<lamont__> defconfig vs itanium
<jbailey> I didn't think there were 2700 options in there.
<jbailey> 'sthis breezy?
<lamont__> rather, defconfig vs breezy/itanium
<lamont__> just a sec and I'll dump stats for you - Good has almost booted.
<jbailey> If you feel up to it after this, I'd appreciate feedback on the initramfs-tools, since it's scheduled to become default on Friday.
<jbailey> Since I will be away this weekend, I'd rather clobber as few UndercluedUsers as possible.
<jbailey> (You know... For the racks of Itaniums running Breezy out there...)
<lamont__> diff -u debian/config/itanium debian/config/ia64/itanium | wc
<lamont__>    2732    5643   61682
<jbailey> *ouc*
<jbailey> +h
<lamont__> yeag
<lamont__> must run
<lamont__> back later
<fabbione> morning
<desrt> word.
<desrt> i have a question that i asked earlier after you'd gone to bed :P
<desrt> why are you packaging 2.6.12?
<fabbione> what should i be packaging?
<desrt> 2.6.13-rc's
<fabbione> no
<fabbione> we are in UVF
<fabbione> Upstream Version Freeze
<fabbione> we need to release quite soon
<desrt> since how long?
<desrt> hmm
<fabbione> 3 weeks?
<fabbione> more or less
<desrt> so 2.6.12 is the breezy kernel
<desrt> weird
<fabbione> yes
<desrt> ok.  that's a good reason :)
<fabbione> that's what in our conffile
<fabbione> ops
<desrt> is gnome a blanket exception to UVF or is 2.11 considered like a 2.12 prerelease?
<fabbione> gnome is an exception
<fabbione> it has been since the beginning
<desrt> it's a good exception :)
<fabbione> infinity: ping?
* lamont__ starts to fade fast, heads for home
<calc> any chance of getting a working version of ipw2200 into the kernel soon?
<calc> fabbione: still here?
<fabbione> calc: ipw2200 is working
<calc> 1.0.4 -> 1.0.1 for WEP but broke WPA completely
<fabbione> calc: 1.0.4 did break completely ipw2100
<fabbione> and i had no time for that release to test 1.0.6
<calc> too bad its not even for the ipw2100
<calc> i have 1.0.4 on ipw2200 and it works more or less fine
<fabbione> also.. people should read what's on the ipw2x00 sties
<fabbione> sites
<calc> i get those error messages about resetting firmware but 1.0.4 does actually work 1.0.1 doesn't at all
<fabbione> 1.0.X releases
<fabbione> for x = 0 stable
<fabbione> for x > 0 development
<fabbione> 1.0.6 = development
<calc> 1.x.y
<calc> x is stable
<calc> when x = 0
<calc> or else why not go all the way back to 1.0.0 ? :)
<fabbione> Versions with the last number is not a zero is an unstable release, for example 1.0.1, 1.1.3, etc.
<calc> yes
<calc> 1.0.0 is basically useless
<calc> 1.0.1 is nearly that way
<fabbione> because ipw2100 is alligned with 1.0.1 ipw2200
<calc> what does ipw2100 have to do with ipw2200?
<fabbione> so your x.y interpration is wrong
<fabbione> calc: they share ieee8$something layer
<fabbione> they splitted only recently in 3 projects
<calc> that doesn't avoid the point that ubuntu is still using a development driver and one that is more broken than the current one which fixes about an additional 30 bugs
<calc> ah yea i see about the 802.11 stuff
<fabbione> calc: the plan was to revert to a more stable release
<fabbione> and than try the new split in the next kernel
<fabbione> before the ieee code was duplicated and misalligned between the 2
<fabbione> (ipw2x00)
<fabbione> so it was creating all sorts of problems
<fabbione> only recently they splitted ieee out of the 2 trees
<fabbione> and that needs to be tested
<calc> ok i'll just hang onto my -3 kernel since its the only one that will work for the forseeable future then
<fabbione> so if you can be nice to give us the time to merge
<fabbione> you will get it
<calc> i thought you said earlier that the final kernel will be out within 3 weeks?
<fabbione> who said so?
<calc> 23:37 < fabbione> we need to release quite soon
<calc> 23:37 < fabbione> 3 weeks?
<fabbione> 3 weeks was related to UVF
<fabbione> 3 weeks ago...
<fabbione> the release will probably be tomorrow
<fabbione> there is no final kernel until breezy releases
<calc> oh is this just a temporary colony freeze?
<calc> ok :)
<fabbione> and we will start doing only security updates to the kernel approx 2/3 weeks before final release
<calc> sorry i was confused
* fabbione starts fetching the latest ipw2*00 crack...
<fabbione> calc: will you be able to test for me?
<calc> yea
<calc> what types of tests do you need run?
<fabbione> hmm this also means another ABI change...
<fabbione> SUCKAGE
<calc> changing the driver causes abi change?
<fabbione> calc: yes. the ieee thing has an abi change
<fabbione> and ipw2* depends on it
<fabbione> you can't change interchange the modules at your own pleasure
<calc> oh
<calc> oh btw i am using 2915abg on amd64 arch
<fabbione> what's that?
<fabbione> i am not 100% familiar with all these wireless drivers..
<fabbione> i only use cisco stuff
<calc> its the intel 802.11a/b/g minipci
<calc> uses same driver as ipw2200
<fabbione> ah ok
<calc> i'm going to bed now, bbl
<fabbione> night
<infinity> I'm using a 2915abg on i386. ;)
<fabbione> hey JaneW 
<fabbione> see...
<fabbione> even after the split they are still not synced properly
<fabbione> GRRRRRRRRRRRRRRRRRRRRR
<fabbione> #define IPW_HEADER_802_11_SIZE           sizeof(struct ieee80211_header_data)
<fabbione> infinity: do you have any clue about the size of that struct?
<fabbione> never mind.. i found it
<fabbione> now they share code...
<fabbione> so let's TRIPLICATE all the definitions
<fabbione> JaneW: i will need a name for tomorrow my far far away so lovely lady :)
* fabbione hopes he got the define right or ipw2100 won't work
<fabbione> JaneW: ??
<fabbione> ok guys we need a name for the kernel
<fabbione> + release
<fabbione> JaneW disappeared...
<fabbione> The:
<fabbione> begin 644 -
<fabbione> 41S%"0C!2($TS(%0S2"!#4C1#2PH`
<fabbione> `
<fabbione> end
<fabbione> Release
<desrt> that's an interesting name
<fabbione> eheh
* desrt g1bb0rs you some cr4ck
<fabbione> nah i did set it to something more normal
<fabbione> people have lost the sense of humor..
<fabbione> they won't get the joke part
<desrt> boo to people
<fabbione> desrt: i know.. i am talking from experience
<fabbione> i have to issue to write *interesting* stuff :)
<fabbione> time to start the build orgy :)
<desrt> exciting.
* desrt thinks we should have a build-pr0n package to lure former-gentoo users to ubuntu land
<fabbione> aha
<desrt> just videos of compiles scrolling by
<fabbione> HAHHAAH
<fabbione> desrt: if you collect the videos and make them BSD/GPL licence
<fabbione> i am going to upload them as gentoo-emulator
<desrt> :)
<fabbione> we can make it as a screensaver or something
<desrt> hey.. that'd be a pretty sexy screensaver
<fabbione> similar to cappuccino
<desrt> mmm.  i think gnome-screensaver needs a module called "gentoo" :)
<fabbione> desrt: ehehe sure...
<fabbione> if you do it, i will upload it for you
<fabbione> just the code.. no need to package it
<fabbione> making a deb for it will take 2 minutes
<desrt> hmmm :)
<desrt> ok.  i'll look into it
<fabbione> actually
<fabbione> it would be even more cool to use the kernel screen blanking
<fabbione> CONFIG_GENTOO_EMULATION
<desrt> ....as compared to the X one?
<desrt> oooh.
<desrt> i see
<fabbione> that you can enable or disable with a syscall/ioctl or whatever
<desrt> and you can have a bunch of kernel options
<fabbione> that will just fake to compile hello.c millions of times :)
<desrt> [*]  Include build log from Xorg
<desrt> [*]  Include build log from kernel source
<fabbione> ahahah
<desrt> etc
<fabbione> the problem is that it would bloat the kernel or the module...
<desrt> nah
<fabbione> including these logs
<desrt> you gotta imagine that build logs compress really well
<desrt> every single line is like gcc -flags -flags -flags -Dsomething -Isomething blah blah blah flags filename.c
<fabbione> desrt: X builg log is 10MB uncompressed
<desrt> and the only part that changes is filename.c
<fabbione> even if you compress it to death is still 300K
<desrt> hmm
<desrt> this is problematic.
<desrt> !
<desrt> i know
<desrt> we launch a project
<desrt> gentoo@home
<desrt> as an outreach programme to gentoo users
<fabbione> aHAHAHA
<desrt> donate our spare CPU cycles to actually help them compile
<fabbione> desrt: it would be easier to write a name generator to print gcc -O31337 blablabla foo.c
<desrt> you forgot to omit the framepointer
<desrt> man... it's so easy to get caught-up in the gentoo-teasing
<desrt> i used to use gentoo... and i liked it a lot... i still do
<desrt> if, for example, sadfdl were to ever pull another ubuntu_spatial type thing i'd go back to gentoo :P
<fabbione> eheheh
<fabbione> i doubt he is going to do it again
<desrt> ok
<desrt> my screensaver is about done now :)
<fabbione> ehehhe
<desrt> so far it just says "test" once per second
<desrt> i have to find something more interesting for it to say
<fabbione> desrt: can i see the code?
<desrt> it's pretty rough
<desrt> but sure
<fabbione> we can work on it together...
<fabbione> given i just uploaded the kernel i have the right for 10 minutes free :)
<desrt> http://manic.desrt.ca/gentoovision.c
<fabbione> heheh
<desrt> hmm
* desrt encounters chicken + egg problem
<desrt> fabbione; if you want to help, there's a good task needs to be done
<fabbione> desrt: i first need to figure where is gtk.h :)
<desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information
<desrt> gcc -o gentoovision gentoovision.c -Wall `pkg-config --cflags --libs gtk+-2.0`
<desrt> it might segfault :)
<fabbione> gentoovision.c:118: warning: passing argument 2 of 'gtk_timeout_add' from incompatible pointer type
<fabbione> tsk :)
<desrt> pfft
<desrt> i didn't feel like looking up the right cast type :)
<desrt> it's some (GTimeoutFunc) or something
<fabbione> ahah
<fabbione> it works here :)
<fabbione> so what's the task?
<desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information
<desrt> i think the file format will be like
<desrt> 1234:gcc -o some compile output blah blah blah
<desrt> where 1234 is how many ms that output should stay on the screen
<fabbione> why not just generating random gcc stuff?
<desrt> it'd be cool to have authentic builds :)
<desrt> they'd be the new ringtones
<desrt> instead of downloading a blink182 ringtone for your phone you download a glibc build log for your screensaver :)
<fabbione> actually... gentoo@home is an easy project to do :)
<desrt> well.. there's already distcc...
<fabbione> exactly :)
<desrt> fabbione; are you working on that program?
<fabbione> desrt: not right now.. sorry.. i did a little mistake building on hppa
<desrt> s'ok
<desrt> i'm gonna go to bed now anyway :P
<desrt> it's waay past my bedtime
<fabbione> eheh good night :)
<Nafallo> could you please sync rt2400 && rt2500 from CVS before next upload?
<mjg59_> fabbione: I'm a bit stuck getting stuff integrated until I actually have internet connectivity here. What are you defining as feature freeze in the context of the kernel?
<fabbione> mjg59_: like the rest of the distro and i will be vac from tomorrow
<fabbione> Nafallo: why?
<Nafallo> fabbione: lot's of bugfixes.
<fabbione> Nafallo: i will look if i have the time
<mjg59_> fabbione: Sure, but what's a feature in terms of the kernel?
<Nafallo> fabbione: it might actually begin to work without all those ifdown && ifups I have to do now :-)
<fabbione> mjg59_: adding new crack.. bug fixes are ok of course
<Nafallo> fabbione: k, kewl.
<mjg59_> fabbione: Ok. There's one (trivial) driver that I'd like to push, but there's no way I can generate a dpatch by tomorrow.
<mjg59_> I just don't have bandwidth at the moment
<fabbione> mjg59_: for the next 2 weeks (while i am away) infinity will take care of the kernel
<fabbione> iirc Feature Freeze is by the 5th of Aug
<fabbione> or something around that
<fabbione> so you have sometime
<fabbione> but don't count on me being around
<fabbione> so you will have to triple check everything
<fabbione> from patches to configs to portability and so on...
<mjg59_> 11th of August
<mjg59_> Ok, no problem
<mjg59_> fabbione: There's a load of PCI drivers that need fixing up for suspend/resume to work. I'm looking into it.
<fabbione> mjg59_: *sighs*
<mjg59_> (biggest problem is with sound cards, since we unload network drivers)
<fabbione> hmm what has net to do with sound?
<mjg59_> Basically, due to ACPI changes (to fix a bug) PCI drivers all need to call pci_disable_device on suspend and pci_enable_device on resume
<mjg59_> The same bug is present in sound and network drivers, but we unload network drivers
<fabbione> JEEEEEE
<fabbione> dude that patch is going to be A BIG FAT MOFO to maintain
<mjg59_> It's only a problem with devices on shared interrupts, so IDE isn't an issue
<mjg59_> USB is, but we unload that as well, so...
<mjg59_> Which leaves, uh, 47 drivers to fix up. Hmph.
<mjg59_> The ALSA people may already have done it. I'll check their tree.
<fabbione> i have the feeling that with all these big fat crack .12 is going to suck more than .10
<fabbione> hey zul
<zul> hey fabbione 
<mjg59_> fabbione: The alternative is to revert that hunk, which takes us back to .10 for that behaviour
<Nafallo> zul: yay! maybe you should do what I asked fabbione earlier? :-)
<mjg59_> However, it is a real bug that gets fixed
<Nafallo> zul: update rt2400 && rt2500 from CVS. fixes lots of bugs.
<Nafallo> zul: also we might want to consider rt2570?
<fabbione> mjg59_: ok.. try to contain the mess :))
<fabbione> Nafallo: please stop nagging
<fabbione> it's the 3rd time you ask the same
<fabbione> gimme a break and the time to do it
<mjg59_> Oh argh.
<Nafallo> fabbione: oki.
<mjg59_> Alsa has its own power management layer. How horrible.
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,6--2.6.12
<zul> wtf?
<fabbione> zul: what?
<zul> oops...typo...was commenting code
<fabbione> ahha
<zul> holy crap Nafallo i just woke up and am at work so its not going to be done anytime soon
<Nafallo> oki. I will not ask before they fix another one of those _really_ irritating bugs that seems to be in the driver :-).
<fabbione> Nafallo: let me explain
<fabbione> between your request and time i can upload such change
<fabbione> i need AT LEAST 4 hours
<fabbione> you asked this morning.. wait
<fabbione> AT LEAST = update the patch, build everywhere, fix the breakage, go back
<fabbione> the build = 3 hours
<fabbione> if you are in such a hurry, you can provide us with .dpatches directly
<fabbione> tested of course...
<fabbione> so i can save 4 hours
<fabbione> and you can spend 2 days building around...
<fabbione> because the patch needs to work on N arches
<Nafallo> fabbione: I know. I didn't know if you saw it this morning. and last time they fixed a big one I do not believe it was updated. that's why I asked when you where alive aswell.
<fabbione> Nafallo: this morning i did even answer to you
<fabbione> and we did talk
<fabbione> so.. i fail to see how i could have missed that...
<fabbione> 12:19Nafallocould you please sync rt2400 && rt2500 from CVS before next upload?
<fabbione> 12:26fabbioneNafallo: why?
<fabbione> 12:26Nafallofabbione: lot's of bugfixes.
<fabbione> 12:27fabbioneNafallo: i will look if i have the time
<fabbione> so that was 2 hours ago :)
<Nafallo> fabbione: I asked in #ubuntu-devel earlier (I belive yesterday after checking the logs).
<fabbione> Nafallo: that's why i said 3 times..
<fabbione> when i read the backlog you were not around..
<Nafallo> fabbione: anyway. no hard feelings. those bugs keeps me on cable, that's why I wanted to make sure you knew. and the when zul came along, I asked him because he's been my SPOC on this driver :-).
<Nafallo> until now indeed...
<zul> oh if im not needed ill just go away..thanks..
<zul> besides i dont see you submitting patches
<Nafallo> zul: I will not touch the kernel before I got lot's more experience. I watch the changelogs on this driver, and that's all I will do :-). I belive the issue is sorted now anyway :-).
<Nafallo> sorry for the nagging, now I'm sure this will get fixed and can get on with MOTU-things.
<JaneW> chmj: I thought someting interesting was happening here
<chmj> what you mean ? 
<chmj> JaneW: O.o 
<lamont> morning JaneW
<fabbione> hey lamont 
<fabbione> lamont: do you happen to remember why you were pinging me yesterday?
<lamont> fabbione: actually running out the door...  need to leave 5 min ago.
<fabbione> ok
<fabbione> ttyl
<lamont> about 45-60 min
<fabbione> sure
<zul> heh i might be conververting my boss from fedora to ubuntu
<JaneW> hi lamont
* JaneW is off to a meeting
<lamont> Adding console on ttyS0 at MMIO 0xff5e0000 (options '9600n8')
<lamont> RAMDISK: cramfs filesystem found at block 0
<lamont> RAMDISK: Loading 9152KiB [1 disk]  into ram disk... done.
<lamont> XFS: bad magic number
<lamont> XFS: SB validate failed
<lamont> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3)
<lamont> hrm... clearly I'm missing something important...
<fabbione> is that ia64?
<lamont> yeah... I mutilated the .config, and it booted.  now to add some more stuff back.
<mjg59_> Is it an XFS filesystem?
<lamont> mjg59_: no
<lamont> ext3 everywhere, although hda1 is fat
<lamont> actually vfat
<fabbione> oh you have a copy of Windows IA64?
<lamont> elilo partition is vfat
<fabbione> ah ok
<lamont> because vfat is so cool.  that and intel engineers are windoze-centric, so that's what they made it.
<lamont> you should see the builtin editor in efi...
<fabbione> notepad? ;)
<fabbione> or word?
<lamont> notepad like/nano-like.  but absolutely sucky termio
<fabbione> brrrrrr
<fabbione> ok .. last universe full kick back before starting to check the c++ transition status...
<fabbione> and that's it for today...
<fabbione> i can't work anylonger...
* lamont pushes the kernel back to the top of the hill again
<fabbione> so.. should i try to remount some extra i386 hw or should i mount the 2 mk68k ??
<fabbione> m68k even
<fabbione> lamont: did you find what's wrong?
<lamont> dude.  take the m68k to the firing range
<lamont> fabbione: well, I have a kernel that at least gets started, and one that doesn't.  the diff is rather large still
<fabbione> ok :/
<lamont> but since it's mostly driver crap, I just added back in PCCARD support, to see how fatal that is.
<fabbione> lamont: remember you still have baz capabilities...
<fabbione> and i will go VAC from tomorrow around 14:00 UTC
<lamont> fabbione: yeah, yeah... once I actually have a fix...
<fabbione> lamont: it's more because of me going away..
<fabbione> you know i don't mind to do merges and changes around for porting
<lamont> % diff -u config.last itanium | wc
<lamont>    2701    5585   60917
<fabbione> sh: line 1: gcc: command not found
<lamont> yeah - np
<fabbione> doh!
<lamont> lol
<lamont> you're gonna kinda need that... :-)
<fabbione> lamont: that's in a chroot buildd
<fabbione> there is gcc
<fabbione> OPS
* lamont notes that gcc is almost always a symlink
<fabbione> sbuildd and buildd SHOULD fail if the chroot-$release is NOT there
<lamont> which sbuild are you using?
<fabbione> the standard one from db.d.o
* lamont looks, finds that he only changed ubuntu's to require --dist, not that the chroot must exist
<fabbione> if the chroot doesn't exists, it uses the "host" system
<fabbione> BAD BAD sbuild
<fabbione> at least it explains the several give-backs...
<lamont> fabbione: that's per specification... the chroot is optional...
<lamont> although a config variable might be nice
<fabbione> desrt: http://people.ubuntu.com/~fabbione/gentoovision_random_o.diff <-
<fabbione> desrt: changelog:
<fabbione> * switch to use gcc-snapshot
<fabbione> * use random -O
<fabbione> for better code corruption/optimization
<fabbione> desrt: note that the gtk_timeout_add is dangerous
<fabbione> i get it to segfault with timeouts < 200
<zul> hmmm..../proc/apci/button has disappeared
<zul> mjg59_: ^^^^ should we add it back some users are complaining
<zul> http://bugzilla.kernel.org/show_bug.cgi?id=1920
<fabbione> OMG!
<fabbione> there is no /dev/inotify!
<fabbione> it MUST BE BROKEN!!!!
<jbailey> zul: die, proc... DIE!
<fabbione> i am supposed to cook dinner, but i really don't feel like...
* fabbione considers the option of junk food (again)
<karlheg> jbailey, You there?
<jbailey> karlheg: Yup!
<jbailey> karlheg: How's things?
<karlheg> Just emailed you... re: the move-mount of dev from initramfs to real root fs.
<desrt> hmm
<desrt> what do we have here
<desrt> a new kernel?  i think so.
<karlheg> I thought I'd submitted a patch for that against initramfs-tools init, but it's not there afaict.  The 'udev' /etc/init.d script is set up to deal with that now.
<desrt> Les NOUVEAUX paquets suivants seront installs: linux-image-2.6.12-5-686-smp
<jbailey> karlheg: You had submitted a patch, but I wanted the udev maintainer in DEbian to be on board with it as well.
<karlheg> Right, and I think he was, since it looks like the udev init can deal with it now.
<jbailey> karlheg: A guy from RH said that they've just removed udev from their initramfs because it's just easier to walk through sysfs yourself and create the block devices we need.
<jbailey> Cool.
<karlheg> He made my recommended changes.
<jbailey> I'll tkae a look at that, since that would work nicely too, for capturing early events.
<jbailey> When I had been thinking was a small hotplug handler to buffer all the events to be replayed later.
<karlheg> I don't see how that's easier.  It's more work and a whole 'nuther routine to write and maintain.
<jbailey> Then just make the /dev stuff as discardable and do it as soon as possible on the new system.
<karlheg> It seems easier to just re-use 'udevinit'.
<jbailey> Well, the case that my thing covers is how to deal with events where the driver isn't available in the initiramfs.  Right now it'll get lost.
<jbailey> We could ideally skip the whole coldplug phase by just grabbing all the events as they come from the kernel
<karlheg> It seems to me that there's no real need for hotplug in the initramfs, since we first probe all modules and then run the udevinit... ?
<jbailey> Right.  The only thing is that there's a ton of events right now that go by - we just ignore them and trust hotplug to pick them up in the coldplug pass.
<jbailey> Either is fine, I think.
<karlheg> I need to study that system some more, I think.  so, hotplug-ng is dead, and should be ignored?
<karlheg> I should look only at 'udev' then?
<karlheg> ... and at the Linux kernel support for it?
<jbailey> Yes.
<jbailey> The whole thing is shifting around, it's hard to keep up with.
<jbailey> udevsend gets the event - it sits on the hotplug handler.
<karlheg> Ok.  I think if we move mount the /dev onto the real file system, that anything having a file in /dev open can keep running no problem.
<jbailey> It serialises it to make sure that if it's handling something once, that it doesn't run over itself.  It then calls out to various hotplug scripts to handle the event (load drivers, etc)
<jbailey> I don't know enough about move mounts to say that it's true, but I suspect it is.
<karlheg> So a dummy hotplug script setup could queue the events for replay?
<karlheg> I tracked around in the kernel source for that information, and am fairly certain that moving a mount point is Ok in the case where files are open on it.  They stay open and the inode is the same.
<jbailey> Right.
<jbailey> Sweet, thanks for looking at that.
<karlheg> Sorry I got side-tracked and did not work on any of this for the last few weeks.
<karlheg> I think I have a few days at least, and will try and stay busy on it.
<jbailey> No prob, I appreciate the time you're putting into it. =)
<karlheg> Any work in progress re porting udev to klibc?
<jbailey> My task right at the moment is to finish the DSDT stuff that I need and then do evms.
<jbailey> Nope, since I was going to get rid of it. =)
<jbailey> It really should replace a 60k binary with a couple hundred lines of shell to generate the block devices that exist on the system.
<karlheg> So... does 'udev' do device detection somehow?  I'm not clear on that yet...  Hmmm... for USB and PCI only, I suppose, plus perhaps a few easy to recognize devices?  Even 'discover' has dropped support for ISA; it was not designed for device detection and the heuristics do not always work right.
<karlheg> Ah, ok; you are dumping 'udev' from initramfs then?
<jbailey> Well, udev just receives the events from the kernel.  It's entirely up to each subsystem.
<jbailey> udev  hands it off to the scripts in /etc/hotplug.d
<jbailey> Basically blindly by subsystem.
<karlheg> Ah, ok... Hey, let me read code a while before I try to discuss this.
<jbailey> It took me a bit to wrap my head around it.  Going to OLS helped alot.
<karlheg> OLS?
<jbailey> Ottawa Linux Symposium.
<karlheg> Are you coming to Portland for the OSScon?
<karlheg> Fun.
<jbailey> It was 820 or so people involved in various bits of Linux development.
<jbailey> I like it because it gives me a chance to swap ideas with other distro folks.
<jbailey> Like the tip to get rid of udev came from a redhat guy.
<karlheg> I cannot afford to attend any pay-for events, but if the convention center is open for booths, etc. I'll probably walk over there and hang out a while.
<karlheg> Huh.  Are you sure he's not throwing you a red herring?
<jbailey> Unfortunately, portland is a little far right now.  I'd love to get out there for alot of reasons.  (Lots of  friends that I miss)
<karlheg> I don't know if they do that... some people are just like that.
<karlheg> Most in OSS are probably not though.
<jbailey> Pretty certain.  It was all in context.
<karlheg> I quit eating beef.
<jbailey> Besides, I c ould grab rawhide and verify it easy enough.
* jbailey blinks.
<karlheg> Can we get a copy of their code?
<jbailey> Yup
<jbailey> It's all public.
<karlheg> :-)
<karlheg> I've not looked into how to do that.  Do they use CVS or what?  (I'll google it)
<jbailey> karlheg: I can recommend a number of good vegan places in Portland, assuming any of them are still open. =)
<jbailey> SRPMS.
<jbailey> I don't grab stuff from there often, so I have to fiddle with it to get it out.
<jbailey> I think you just apply alient to turn it into a .tar.gz or somethign.
<karlheg> I'm not going vegan; just no more beef.
<karlheg> Alright; I'll try that.
<jbailey> I'm vegan.  That's the limit of the places I've been to in recent memory. =)
<jbailey> (Where recent memory == ~4.5 years ago)
<karlheg> Do you know what they call the relevant package?  udev is probably same-name.
<jbailey> Dunno
<karlheg> Ok.
<karlheg> Well, I'm off now to grab a sandwich and then to read code.  BBL8r.
<jbailey> Thanks, Karl!
* jbailey needs food
<zul> jbailey: yes die proc die but it breaks apps
<zul> mmmm...love crippled perl
<mjg59_> zul: Yeah. It's hit 2.6.13 as well, so there should be a reversion patch soon
<zul> ok  ill keep a watch on it
#ubuntu-kernel 2005-08-03
<fabbione> morning
<fabbione> morning JaneW :)
<JaneW> hello
* JaneW tries to be more in time for fabbione today...
<fabbione> JaneW: eheh don't worry my far far away lovely lady :)
<fabbione> i don't think i will upload a kernel today
<fabbione> for 3 reasons:
<fabbione> 1) it's friday and you never break stuff on friday
<fabbione> 2) in 7 hours i will start my holidays
<fabbione> 3) i won't be able to test all the changes before 2
* desrt is reminded
<fabbione> JaneW: speaking of 2).. i need somebody to take care of my students....
<fabbione> hey desrt 
<desrt> 'sup?
<fabbione> desrt: did you grab my patch for gentoovision?
<desrt> oh no
<desrt> where is it?
<fabbione> http://people.ubuntu.com/~fabbione/gentoovision_random_o.diff
<desrt> oo
<fabbione> changelog:
<fabbione> * add first cut for randomization
<fabbione> * compile with gcc-snapshot
<fabbione> * use random -O to break the code better
<fabbione> * reduce the compile time to 200ms
<fabbione> i mean.. they RUN FAST!
<desrt> k.  i seriously want actual build log support
<JaneW> fabbione: glad to hear about all 3 reasons, but especially 1 :)
<desrt> plus.. i got some suggestions from #gnome-hackers
<desrt> we should have an option to emulate different CPU types
<fabbione> btw.. gtk_timeout_add is "dangerous"
<fabbione> it tends to segfault
<desrt> hm.  has never done so for me.
<fabbione> desrt: ehehe that too
<JaneW> fabbione: re your students, how long will you be gone again? A week or 2 right? Can you suggest someone appropriate to fill for you there?
<fabbione> 2...
<fabbione> desrt: it does for me if i reduce the time to 100ms
<desrt> oh no.  your patch rejected :P
<fabbione> JaneW: suggesting?
<desrt> i cleaned up the source a lot compared with the one you made the changes to :P
<fabbione> JaneW: hmmm...
<fabbione> desrt: put it in a RCS :)
<fabbione> desrt: but i think we should have 2 runtime options.. --random | --use-reallog .. or something like that
<desrt> i agree
<fabbione> JaneW: i would probably suggest infinity .. but he is awake now.. so he will complain.. 
* fabbione points the finger at jbailey 
<desrt> are you a C programmer?
<fabbione> desrt: not really.. i don't write code on a regular base, so it's always rusty and hackish
<desrt> it's valid for a function to return char *
<desrt> you don't have to cast to int then back to char * again
<fabbione> desrt: tell that to gcc-4.0 :)
<desrt> desrt@moonpix:~/code/desrt/gentoovision$ gcc -o gentoovision gentoovision.c `pkg-config --cflags --libs gtk+-2.0` -Wall
<desrt> desrt@moonpix:~/code/desrt/gentoovision$
<desrt> i made the change to your code... no complaint here
<desrt> hahah.  gcc-snapshot
<desrt> i love it :)
<fabbione> desrt: gcc --version ?
<desrt> gcc (GCC) 4.0.2 20050720 (prerelease) (Debian 4.0.1-2ubuntu3)
<desrt> Copyright  2005 Free Software Foundation, Inc.
<desrt> Ce logiciel est libre; voir les sources pour les conditions de copie.  Il n'y a PAS
<desrt> GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.
<fabbione> skip the french :)
<desrt> http://manic.desrt.ca/gentoovision.c
<desrt> w/ your changes, plus some minor changes to them -- no warnings
<fabbione> i see...
<fabbione> good
<desrt> btw.  the memset isn't required... sprintf will add the proper termination
<fabbione> desrt: i prefer to wipe the memory...
<fabbione> i am just paranoid about string handling.
<desrt> i think i am going to write a buildlog capture utility now :)
<desrt> perl is best, i suspect :)
<desrt> oh man.. perl makes getting high resolution timing information a pain in the butt
<fabbione> Nafallo: ping?
<desrt> oh man
<desrt> i got awesomeness
<fabbione> uh?
<desrt> http://manic.desrt.ca/gentoovision.tar.gz
<desrt> compile gentoovision.c like normal and run it out of the current directory
<desrt> (ie: so that libwnck.log is in the cwd)
<fabbione> gentoovision/gentoovision.c.rej
<desrt> eh
<desrt> your diff is in there too
<desrt> i just tarred up what i had :)
<fabbione> ahaha cool
<desrt> this is what i want :)
<desrt> btw.. build logs gzip down to about 10% of their original size
<fabbione> we should still consider doing some sed on the logs
<fabbione> for -O and gcc-snapshot :P
<desrt> :)
<desrt> yes
<fabbione> dude you should put it in a RCS
<desrt> where?
<fabbione> so we can work on it together.. after my VAC
<fabbione> RCS= cvs.. svn.. baz.. tla...
<desrt> i don't think we have anywhere that we both have accounts
<fabbione> desrt: if we use baz we don't need to share an account
<desrt> i think it's final home will be gnome cvs
<fabbione> we can just publish our branches
<desrt> *its
<desrt> k.  i refuse to use baz for something like this :P
<fabbione> oh ok.. well i don't have access there
<fabbione> for small stuff it's fun to use :)
<desrt> (./configure --prefix=/opt/gnome; make -j3) 2>&1 | ~/code/desrt/gentoovision/time.pl > logfile
<desrt> ^^ this is how you generate the logs with timing info
<fabbione> desrt: i can give you the debian/ dir once it's ready...
<desrt> cool
<desrt> but i think i want to upload this upstream
<fabbione> but again.. we need to share at least one RCS :/
<fabbione> i don't want to start fiddling with patches
<fabbione> it's a pain
<fabbione> (still after my holidays)
<desrt> i'm gonna talk to the gnome-screensaver maintainer
<desrt> nod :)
<desrt> where are you going, btw?
<fabbione> oh well.. if you get it in there directly the better
<fabbione> i will stay home... have to work in and outside the house
<fabbione> painting/doing walls and stuff
<fabbione> but i won't be spending time in here
<desrt> i should talk to sebastien and find out if breezy will use gnome-screensaver or xscreensaver by default
<desrt> cool
<desrt> it's good to get away from work
<fabbione> ehheh
<fabbione> well i work from home!
<fabbione> there is no such a thing like going away :(
<desrt> right... but to completely cut yourself off and refuse to do anything work-related
<desrt> how long have you been working for ubuntu anyway?
<fabbione> from the beginning
<desrt> how did you get involved?
<fabbione> hehh.. i got a mail from Mark, asking me if he could phone me
<fabbione> i almost trashed it as spam
<desrt> hmm.  why did he email you, though?
<fabbione> but i was like.. nah.. let's see
<fabbione> somebody mentioned me to him
<fabbione> and it's some sort of nostalgic reasons
<desrt> cool :)
<fabbione> he was one of the first apache1.3 maintainers in Debian
<desrt> were you a kernel hacker before?
<desrt> or debian guy?
<fabbione> and i have been maintaing for a while ...
<fabbione> debian guy
<fabbione> than we did build the apache team
<fabbione> took down the bugs from > 200 down to 46
<desrt> ubuntu has a nice mix of people
<fabbione> after that i got too busy again
<fabbione> and now is up to 100 and something again i think
<fabbione> i didn't do an upload in ages
<fabbione> desrt: i am a royal bastard.. how can you say that i am nice!
<fabbione> you are ruining my reputation! :P
<desrt> i wasn't talking about you
<desrt> :)
<fabbione> ah ok thanks :)
* fabbione feels better
<desrt> i'd love to work for ubuntu if i had any time :P
<fabbione> desrt: ehe you are already doing your sharing of stuff
<fabbione> all the time you spent with me for the kernel headers and stuff...
<fabbione> idiotify...
<desrt> hahah
<fabbione> that's hell of a lot of work for a volunteer...
<desrt> i mean more seriously though
<desrt> my dream is to upload :)
<fabbione> you mean that the kernel is not serious enough for you? ;)
<fabbione> desrt: ehehe... start joining the MOTU's
<desrt> ya.. crimsun tried to get me involved with that
<fabbione> it's a good place to start with
<fabbione> well actually.. the only place
<desrt> :)
<desrt> but again... i'll only say that i wish i had the time
<desrt> my boss is already annoyed that i spend too much time working on gnome, etc
<desrt> he's totally good-natured about it, though
<fabbione> i understand that...
<desrt> he says things like "but don't you find the kernel to be SO MUCH more exciting than messing around with gtk?"
<fabbione> ehheheh
<desrt> actually... i suppose i can count the kernel-related stuff we've done as work-related
<desrt> since that -is- my job
<desrt> i feel a little better already :)
<fabbione> well you can still hack kernel stuff into ubuntu
<fabbione> and push stuff back
<fabbione> that's a valuable contribution
<desrt> our stuff is pretty special-purpose
<fabbione> i wouldn't mind to merge from you stuff, if you do it
<fabbione> oh in that case yeah...
<desrt> it's extremely high performance network drivers and a runtime system for a cluster
<fabbione> desrt: are they going to be GPL drivers?
<desrt> yes
<desrt> they have to be
<fabbione> well why not include them in ubuntu than...
<fabbione> at what stage is the code?
<desrt> because they really serve no purpose to anyone who isn't hacking the kernel
<desrt> i can send data across the network at full wire speed with approximately 0% CPU utilisation on both ends
<fabbione> that's cool
<desrt> we have some nice evil hacks, too
<desrt> to make the data receipt favourable
<desrt> ie: it gets written directly into the memory where it will be used... with all of the junk like headers/checksums/etc conveniently stripped out
<desrt> some nice scatter/gather tricks to make that work :)
<fabbione> are these drivers associated to special hw?
<desrt> intel gigabit ethernet cards
<fabbione> oh.. kweel
<desrt> today was christmas at work... i got 4 boxes of dualport cards
<desrt> plus 30 gigs of ram
<fabbione> EHHEHE
<fabbione> ah
<fabbione> i wouldn't mind both :)
<desrt> so now all the ram and pci slots on my powermacs are full
<fabbione> the only reason why i don't run gbic is the switch
<fabbione> a good one is way too expensive
<desrt> ah... all of our links on the intel cards are point-to-point
<desrt> gigabit is nice... it has automatic cross-over detection
<fabbione> yeah but i can't use p2p without tons of cards :)
<fabbione> + i use a lot vlans 
<fabbione> so a switch is mandatory
<desrt> we got a bunch of 8 port gigabit switches for $150 each, i think
<desrt> but they don't do anything like vlan
<desrt> just unmanaged dumb switches... the most they do is blink their lights :)
<fabbione> the smallest switch i have here is a Cisco 2924
<fabbione> yeah and i don't like stuff like that
<desrt> this is in your home? :)
<fabbione> i need managed :)
<fabbione> yes
<desrt> hahah
<desrt> wow.  i have an 8 port 10/100 here :P
<desrt> i feel so ghetto
<fabbione> let me take a pic :)
<desrt> oh btw.. can i nuke your account on copacetic?
<fabbione> desrt: sure.. go ahead..
<fabbione> i tough i told you last time...
<desrt> hm.  i may have missed the message
<fabbione> http://www.fabbione.net/new_office.jpg
<fabbione> http://www.fabbione.net/new_office2.jpg
<fabbione> this is after last weekend
<fabbione> with a lot of cleanup
<desrt> holy crap
<desrt> how many channels are you on?
<fabbione> what you can't see in the pics is all the other equipment hidden behind me
<fabbione> still unconnected
<fabbione> 15/16
<fabbione> not that many
<fabbione> but i use different client sessions for each network
<desrt> is that a sun switch or rackmount server?
<fabbione> server
<desrt> heh
<fabbione> it's the Ubuntu sparc buildd :)
<desrt> l33t.
<desrt> woh
<desrt> what crazy country do you live in?
<fabbione> dk
<fabbione> why?
<desrt> weird plugs
<fabbione> oh yeah
<desrt> btw: smoking will kill you :)
<fabbione> so does bitching smokers :P
<fabbione> desrt: btw.. the plug you see in pic 2 with 3 pins in a raw is italian
<fabbione> not danish
<desrt> it's funny that ubuntu sparc builds on a server sitting in a corner in your house
<fabbione> they look 6 because of the shade
<fabbione> there is another buildd in a uni in sweden
<desrt> that's a little more normal
<desrt> happen to know where ppc builds?
<fabbione> desrt: hosting here is too expensive
<fabbione> desrt: yes they are at the Lodon DC
<fabbione> like all the others
<fabbione> only sparc and hppa are not in the DataCenter
<fabbione> (..yet)
<desrt> we had one of those ciscos at work until we got rid of it
<desrt> it was too noisy
<desrt> and it was seriously underutilised
<desrt> these two pictures are taken at different times
<desrt> deceit!
<fabbione> uh?
<fabbione> yeah the pics have been taken with a week difference
<fabbione> the first one was last sunday
<fabbione> as soon as i finished to cleanup
* desrt takes a camera to work tomorrow :)
<fabbione> the ohter few minutes ago to show the server corner ;)
<desrt> i have my 6 ubuntu servers in a row :)
<desrt> gabriel, gorecki, velocity, cocteau, breezy, copacetic
<fabbione> ehhe
<fabbione> all ppc64?
<desrt> copacetic is a PC
<fabbione> ah ok
<desrt> it's the gateway
<fabbione> yup i recall that
<desrt> and gabriel is my workstation
<fabbione> mine is still a mixture
<desrt> they're both hoary
<fabbione> reinstalling my server is not an option right now
<desrt> the other 4 (gorecki, velocity, cocteau, breezy) are all running breezy and accessible from inside only
<fabbione> ok i need to start the build orgy...
<desrt> :)
<fabbione> gimme a sec otherwise i will mess up like yesterday :)
<desrt> er
<desrt> didn't you say you weren't gonna break things on friday? :P
<desrt> yay.  i successfully played devil's advocate today and convinced an innocent ubuntu maintainer to break UVF :)
<fabbione> desrt: of course i am not breaking UVF
<fabbione> i didn't upload .13 ..
<desrt> not you.  someone else :P
<fabbione> well you see it's not strict strict...
<fabbione> there are still pkgs allowed to go higher versions
<desrt> nod.  flexible rules are the best
<fabbione> it will be stricter stricter close to release
<desrt> who is matt?
<fabbione> mdz = CTO
<fabbione> God of Ubuntu
<desrt> he approves freeze breaks?
<desrt> heh
<desrt> i thought that was mark :)
<fabbione> mark is Self Appointed Benevolent Dictator For Life
<fabbione> God of the Gods ;)
<desrt> anyway.. a new version of hal is going in, it seems
* fabbione sighs
<desrt> and i may be evil enough to cause an even newer one :)
<fabbione> desrt: everything related to gnome will be updated to death
<fabbione> don't worry about it
<desrt> that's good, at least
<fabbione> infinity: if you are around, please do a checkout from baz playground..
<fabbione> infinity: we can look at the TODO list together
* fabbione goes offline for the next 20 minutes...
<fabbione> ok guys.. i just uploade 2.6.12-6.6
<fabbione> i am going to do the baz dance after lunch
<fabbione> infinity: we need to talk after..
<welson> there a way to turn off a second keyboard from inputting onto tty1?
<Nafallo> fabbione: pong
<fabbione> Nafallo: your drivers have been updated..
<Nafallo> fabbione: nice. thank you :-).
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,7--2.6.12 probably coming up soon
<fabbione> yoyo
<infinity> Word.
<fabbione> just one sec that i did quite a lot for you
<fabbione> i upload 6.6 this morning
<fabbione> with all the most critical things updated
<fabbione> i added a debian/TODO for you
<fabbione> nothing too fancy...
<fabbione> just what to look after...
<infinity> Cool.
<fabbione> we need to look at the TODO together...
<fabbione> just give me a minute that i had to recover ther kenrl baz archive
<fabbione> and i pre-preparing 6.7 for you
<fabbione> hey zul
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--preX,7--2.6.12
<fabbione> infinity: ok can you please get the playground?
<fabbione> infinity: dude??
<zul> hey..
<zul> why so many uploads?
<fabbione> zul: to leave a bit of peace to infinity whille i will be back
<fabbione> be VAC even
<zul> oh yeah where are you off to?
<fabbione> i am off to work at home for the next 2 weeks
<zul> ah
<fabbione> gotta finish dining room and hopefully bedroom too
<zul> doesnt sound like much of a vacation
<fabbione> my parents are coming to do the garden the room
<fabbione> no it's no real VAC
<zul> infinity: ill have some stuff to push to you this weekend as well
<zul> dont worry i wont break anything
<zul> like last time fabbione is away
<zul> i learned my lesson ;)
<fabbione> guys if you are going to break.. i won't come back :O
<zul> wohooo! :)
* chmj takes note not to break anything 
<fabbione> heehhe
* infinity starts a baz get and goes to grab a drink.
<infinity> fabbione : Right, I've read the TODO.  Very informative.
<fabbione> i know :)
<fabbione> good.. i am already in holidays.. so you are fucked :)
<Nafallo> lol
<zul> infinity: fabbione left you a present http://bugzilla.ubuntu.com/show_bug.cgi?id=13075
<fabbione> zul: not a bug
<fabbione> it's not the archive yet
<fabbione> that's the meta package
<zul> ah...damn it :)
<chmj> ehehehe
<infinity> Uploading meta before the real thing is considered harmful.
<infinity> (I assume the real packages are stuck in NEW)
<fabbione> infinity: ENOCARE.. it's breezy and X has been broken for months.. if the kenel is not installable for 3 hours... tought luch
<fabbione> luck
<fabbione> they can all suck my left nut
<fabbione> oh did i mention that i am in holidays?
<chmj> already ?
<fabbione> yeah
<fabbione> since 49 minutes :)
<infinity> Then get off IRC, you dope.
<fabbione> nah
<fabbione> why?
<chmj> its an addiction 
<fabbione> i am going to mount my 2 m68k now
<fabbione> i am FREE until tomorrow at lunch.. time at which my wife will be back
<infinity> Dude, that sounds really dirty.
<fabbione> I CAN NERD FOR FREE!!!!
<zul> use a condom if you are going to mount it
<fabbione> zul: them :)
<chmj> hhahahha 
<fabbione> infinity: should we bootstrap m68k breezy server? :P
<infinity> Do your boxes have reasonable specs, or should i do it on one of mine?
<fabbione> infinity: they are the same as last time we talked :)
<fabbione> plenty of harddisk .. decent processor.. no ram
<infinity> Yeah, no RAM == shit.
<fabbione> i know...
<infinity> Especially for C++/
<fabbione> send me some
<infinity> Buy some.  RAM is cheap.
<fabbione> ENOMONEY
<fabbione> i have a wife dude...
<zul> hah..
<lamont> In file included from drivers/input/cpad/cpad.c:84:
<lamont> drivers/input/cpad/kernel-compatibility.h:5:2: #error : kernel has no USB support. Compile kernel with CONFIG_USB.
<lamont> that is a bug
<fabbione> uh?
<fabbione> what arch is that?
<lamont> (CPAD should depend USB in Kconfig
<fabbione> yeah exactly...
<fabbione> that's easy to fix...
<fabbione> but i am in holidays.. 
<lamont> that's me ripping major pieces of kernel out of .config, slowly turning itanium into defconfig, trying to find the fatal option
<fabbione> did i mentioned it before?
* lamont was just venting
<fabbione> :)
<fabbione> lamont: if you don't have time to do it, open a bug and i will fix it when i am back
<lamont> I'll fix it
* fabbione is waiting for m68k to finish cron.d
<fabbione> Linux tosti 2.4.26 #1 Wed May 19 16:13:28 CEST 2004 m68k unknown
* fabbione grins
<doko> fabbione: assuming we have a i386 biarch compiler again, please can we build an amd64 kernel for i386?
<fabbione> doko: i am VAC
<fabbione> doko: but assuming.. i can try
<fabbione> not as breezy goal tho
<doko> fabbione: not as a breezy goal, or not for breezy?
<fabbione> doko: it depends what that implies in terms of changes into the kenrel build infrastructure
<fabbione> if it is easy, than yes.. otherwise sorry no..
<fabbione> feature freeze is the 11th of Auh
<fabbione> Aug
<fabbione> and i am vac from 3 hours and 15 minutes till the 15th of Aug
<zul> hey yo
<lamont> fs/asfs/dir.c: In function `asfs_readdir':
<lamont> fs/asfs/dir.c:77: warning: cast from pointer to integer of different size
<lamont> fs/asfs/dir.c:112: warning: cast to pointer from integer of different size
<lamont> ew
<lamont> cache hit                            245
<lamont> cache miss                          9646
<lamont> grumble
<lamont>                 startnode = (int)filp->private_data;
<lamont>                                         filp->private_data = (void *)be32_to_cpu(obj->objectnode);
<lamont> I'll take bugs-in-code for $200, bob
<zul> gcc4?
<lamont> 64-bit system
<zul> ah..
<zul> whoops
<lamont> sizeof(int) != sizeof(void*)
<lamont> then again, it's unlikely that someone will want to mount an Amiga SFS file system on {amd,ia,powerpc,sparc}64
<lamont> fs/coda/upcall.c:551: warning: comparison is always false due to limited range of data type
<lamont> fs/gfs/ops_address.c:477: warning: initialization from incompatible pointer type
<lamont> fs/gfs/proc.c:310: warning: 'sdp' might be used uninitialized in this function
<lamont> \
<lamont> (also 268.198.160)
* lamont tsks at gfs
<lamont> fabbione: btw, CPAD fix committed
<fabbione> lamont: ok :)
<jbailey> fabbione: I know how two systems that I can routinely produce some sort of severe crash that keeps me from running sudo on.  Some day  when you're bored, I should get you to show me how to troubleshoot this...
<jbailey> bumps[17574] : segfault at 0000002a964c8000 rip 0000000000402410 rsp 0000007fbffff1d8 error 6
<jbailey> rd-bomb[18440] : segfault at 0000002a963cf000 rip 00000000004028c9 rsp 0000007fbffff020 error 6
<fabbione> jbailey: the hw is broken.. change it
<jbailey> on the console
<jbailey> fabbione: Eh?  Two systems, different arch's, same glibc tests...
<fabbione> i dunno.. that's amd64, isn't it?
<jbailey> amd64 and ppc, yeah.
<fabbione> i have no idea...
<fabbione> not today at least :)
<lamont> SCORE!!! it booted... much smaller bracket to play in now.
* jbailey misses the Hurd where he could at least attach gdb to pieces.
<fabbione> my brain is basically turned off
<fabbione> lamont: cool!
<jbailey> fabbione: Right, that's why it's some day when you're bored.
* fabbione hands kgdb to jbailey 
<lamont> fabbione: of course, some of it was turning things into 'yes' that were 'module' before.
<jbailey> fabbione: apt-cache search doesn't find it. /me googles.
<fabbione> lamont: i would blame initrd for that
<fabbione> jbailey: it's not a package
<lamont> much smaller, fwiw, is +330/-80 on the diff
<fabbione> it's a patch iirc..
<lamont> actually, I'm leaning toward CONFIG_PRINTK_TIME and firends
* jbailey needs to go out an get food for when his wife comes home.
<jbailey> fabbione: Thanks.  Lamont would probably love the buildds to stop dying whiler we're at it too. =)
<lamont> now that's just amusing...
<jbailey> Somehow running simple interface tests blocks a test indefinetly, and kills whatever sockets sudo needs to run.
<lamont> ah, probably hotplug stuff
<lamont> (why the network doesn't autoconfig)
<fabbione> lamont: I am not 100% sure how you are playing with the configs
<lamont> fabbione: with a sledge hammer
<lamont> anything taht prints a kernel message is considered "good".  Things that machine check before the first printk are considerd "fail"
<fabbione> but you need to always compared the generated .config in the build dir with the original and the expected config yuo are modifying
<lamont> and it's semi-binary-search week
<lamont> yes
<fabbione> you might manually disable an option that might be turned back by Kconfig and you don't know...
<lamont> so I have defconfig (good) and itanium (fail), and several passes between, as I make itanium look more and more like defconfig...
<fabbione> or switch something to m and at the end is y
<lamont> oh, it's vi .config; make oldconfig; diff; diff; diff.
<lamont> and occasionally make menuconfig
<fabbione> the config is still changed :)
<fabbione> but i guess you know that
<fabbione> anyway it's time for me to sleep
<lamont> the config is changed in 'make oldconfig', and then I diff it.  once I like the diff, then I build, which does another make oldconfig, but so what
<lamont> g'night
<fabbione> the first of the 2 amiga is distupgrading to sarge
<jbailey> fabbione: You starting the m68k port?
<fabbione> jbailey: no. my 2 amigas are too slow for that
<fabbione> jbailey: that's why i was asking about the cross compiler
<jbailey> fabbione: Right, but there are apparently decent emulators for m68k now.
<jbailey> fabbione: m68k is one of the micro-buntu targets that I was thinking about.
<fabbione> jbailey: yes.. but waht i was thinking about is to try to build breezy via cross compile
* lamont just wants a bootloader for uae...
<jbailey> I wouldn't do it in a cross compiler.
<jbailey> I'd do it in an emulator.
<fabbione> and use the results to test on real m68k
<jbailey> Most apps don't cross compiler well.
<fabbione> jbailey: afaik emulator will boot AmiOS
<fabbione> not linux
<jbailey> If I get bored this weeked I'll look for the link I found.
<fabbione> but if you know of any of these emulators that can run m68k i will be glad to give it a shot
<jbailey> I was putting stuff together to run on my ia64
<fabbione> i don't mind to setup a buildd 
<jbailey> (The most power EVER consumed by an m68k!)
<fabbione> hahaha
<fabbione> i also promised Al Viro to test his stack smasher something on m68k
<fabbione> so that they can finally kill that 120K patch that linus will never accept 
<jbailey> But if you are interested in this, I'll also get around to writing down the embedded Ubuntu stuff that Thom and I talked about.
* lamont tries the promising PRINTK options as the only real diff from itaniu
<lamont> m
<fabbione> jbailey: i don't mind to use one of my m68k as test machine...
<fabbione> i have fun with them
<fabbione> but no real bootstrapping or compiling there...
<jbailey> Right.  I'm not willing to debug on them though, so.... =)
<fabbione> + i know a bit of m68k asm...
<fabbione> i think i still remember most of it :)
<jbailey> It would be a lovely excuse for me to learn it.
<jbailey> Gotta run.  g'n Fabio! (And l8r, all)
<fabbione> a long time ago i did propose Simon Richter to work on a linux boot loader to install directly in the bootblock
<fabbione> instead of having to boot AmiOS first
<fabbione> cya Jeff
<fabbione> night guys
<crimsun> 'night.
#ubuntu-kernel 2005-08-04
* lamont finds a config that is almost exactly itanium, only it boots. :-)
<lamont> couple more refinements, and we'll be happy
<lamont>   * Drop CONFIG_PRINTK_TIME from ia64 configs, since it's fatal.
* lamont does the happy dance
<lamont> ipv6: disagrees about version of symbol struct_module
<lamont> ew
<lamont> fabbione: what's the current baz dance for a release (or I can go stare at it and figure it out...)  I'd like to ship 6.7 sometime soon, so that I can get daily CD's with it on (that therefore boot...)
<lamont> and what else do we have for -6.7?
<fabbione> lamont: there might be more for 6.7
<fabbione> there is one of our external upstream that is going stable soon
<fabbione> and we definetely want it in.
<fabbione> lamont: if ipv6 disagree. it means an ABI bump
<fabbione> so i strongly suggest to wait for the other upstream
<fabbione> and go with it in one go
<desrt> fabbione; leave now.
<desrt> fabbione; or you will be trapped forever :)
<fabbione> desrt: eehhehe i am having fun now :)
<fabbione> it's my last day of quitness before starting to work in the house
* desrt rewired a good chunk of the basement earlier tonight
<desrt> any electrical/plumbing stuff in your future... or mostly painting-type stuff?
<fabbione> desrt: mostly painting stuff
<fabbione> doing walls...
<fabbione> and alike
<fabbione> the electric plant has been redone properly...
<fabbione> the old one would have exploded
<desrt> ya.. ours was scaring me too
<desrt> it had some really bad stuff... most of the lighting in the basement was wired completely backwards
<desrt> like... for the bulbs... the outer ring was hot
<fabbione> here there was a 20 years old electric plant...
<desrt> and the inside bit was neutral
<desrt> and the neutral was switched
<desrt> is your use of "electric plant" a language disparity or an actual difference in how houses are done?
<fabbione> i think the former :)
<desrt> what do you mean?
<desrt> like, the breaker box?
<fabbione> all the wiring around the house
<fabbione> the breaker box.. 
<desrt> ah.  weird
<fabbione> stuff like that
<fabbione> it was 20 years old :)
<fabbione> and no safety at all
<desrt> ya.  that's not normally called the electric plant :)
<fabbione> so we did change all of it
<fabbione> desrt: eheh ok:)
<desrt> how did you get at stuff in the walls?
<fabbione> i took down part of the walls
<fabbione> removed the old crap
<fabbione> and put the new one
<desrt> wow
<desrt> nothing so interesting happened here today :P
<fabbione> ehheh
<desrt> i just did some lights and junction box rerouting in a room with open ceilings :)
<desrt> (my bedroom is directly over top of the work room in the basement, which has open ceilings... SO convenient)
<fabbione> eheheh
<mjg59> Digging through the Fedora patches, there's 2 or 3 there that we want to grab (mostly PPC suspend stuff)
<zul> heylo
#ubuntu-kernel 2005-08-05
<zul> ick...no http://bugzilla.ubuntu.com/show_bug.cgi?id=13106
#ubuntu-kernel 2005-08-06
<zul> infinity: i have a bunch of patches to push to you 
<lamont> fabbione: kernel-package is b0rked
* lamont floods a little...
<lamont>        ifneq ($(strip $(architecture)),$(strip $(DEB_BUILD_ARCH)))
<lamont> -        #KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_ARCH_OS))-
<lamont> -        KERNEL_CROSS:=$(DEB_HOST_GNU_TYPE)-
<lamont> -        ifeq ($(architecture), amd64)
<lamont> -          KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_ARCH_OS))-
<lamont> -        endif
<lamont> +        KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_GNU_SYSTEM))-
<lamont> +        #KERNEL_CROSS:=$(DEB_HOST_GNU_TYPE)-
<lamont> +        #ifeq ($(architecture), amd64)
<lamont> +        #  KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_ARCH_OS))-
<lamont> +        #endif
<lamont>        endif
* lamont looks at the sparc stuff to see how that interacts...
<lamont> hppa is the only one that actually cross-compiles, yes?
* lamont pokes zul
<lamont> fabbione: at any rate, hppa is ftbfs unless KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_GNU_SYSTEM))-
<lamont> and then there's the question of what, if anything, sparc needs...
* lamont will wait until morning to upload kernel-package, so that fabbione can scream
<zul> what did i do now?
<zul> ....its not time for school...
<lamont> zul: was hoping for an answer on cross-compiling... but it was just a forlorn hope.
<fabbione> morning
<fabbione> lamont: in theory all arches do crosscompile
<fabbione> the sections in kernel-package should be per arch.
<fabbione> but if it can't find the compiler, i think it's because the gcc symlinks are missing from gcc-*
<fabbione> because it builds in hoary
<lamont> no.  it's because the compiler is named hppa64-linux-gnu-gcc, not hppa64-linux-gcc
<lamont> and that was a 3.3->3.4 change, I expect
<lamont> or rather, it's a breezy binutils change
<fabbione> nope.. that was hory -> breezy change..
<fabbione> doko needs to add the symlinks to gcc
<fabbione> kyle was telling that in #parisc
<lamont> it'll be the only package in existance that has them....
<fabbione> ah
<lamont> Jul 31 15:10:45 <lamont>         /bin/sh: hppa64-linux-objdump: command not found
<lamont> Jul 31 15:10:52 <lamont>        dpkg --contents pool/main/b/binutils/binutils-hppa64_2.16.1-2ubuntu2_hppa.deb | grep objdump
<lamont> Jul 31 15:10:52 <lamont>        -rwxr-xr-x root/root    262376 2005-07-27 10:15:56 ./usr/bin/hppa64-linux-gnu-objdump
<lamont> Jul 31 15:10:55 <lamont>        which one should change?
<lamont> Jul 31 15:11:58 <doko>  linux-gnu is the new / correct one
<fabbione> than ok, the part in kernel-package is arch specific
<fabbione> so if you change that it should be ok
<lamont> right, so does my diff look OK then?
<lamont> kernel build with that change is running now on hppa, figured I'd let it finish before uploading in any case
<fabbione> lamont: i need to look at it... gimme a sec :)
<fabbione> i just woke up because my wife forgot to remove the alarm clock at the first day of vac :)
<lamont> hehe
<fabbione> where is the offset for that patch?
<fabbione> lamont: what is the offset for the kernel-package patch you have?
<lamont> 2765 or so
<lamont> 2765 is the first occurance of KERNEL_CROSS in the file
<lamont> and ${destination_architecture}-${DEB_HOST_GNU_SYSTEM} is the correct prefix for the cross compiler everywhere
<lamont> then it's just a question of whether or not a cross compiler is needed.
<lamont> note that the ppc64 ifneq there breaks cross compiling ppc64 kernels on any arch other than ppc.
<lamont> but I'm not going to change that today.. :0)
<fabbione> neither we care :)
<fabbione> lamont: KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_ARCH_OS))-
<fabbione> so this one should be the only correct one...
<fabbione> for all arches..
<fabbione> and return?
<fabbione> $arch-linux- ?
<fabbione> sparc-linux-gnu-gcc-3.4
<fabbione> i have the -gnu- in the middle
<fabbione> root@vultus5:~ # dpkg-architecture -qDEB_HOST_ARCH_OS
<fabbione> linux
<fabbione> what adds -gnu ?
<lamont> DEB_HOST_GNU_SYSTEM is the right one
<doko> fabbione: DEB_BUILD_GNU_TYPE or DEB_BUILD_GNU_SYSTEM
<doko> good morning, btw ...
<fabbione> oh i see
<fabbione> ok
<fabbione> it seems fine for sparc
<fabbione> lamont: go ahead..
<lamont> so my change was to uncomment the line at 2765, and comment out the ones following
<lamont> :-)
<lamont> fabbione: ok.  I'll do that after the kernel build finishes in a few hours...
<lamont> and I wake up again
<fabbione> lamont: bump the B-D for 6.7
<fabbione> just to ensure to use the proper one
<fabbione> the baz dance is:
<fabbione> 1) start from playgroud
<fabbione> 2) merge into mainline--2.6.12
<fabbione> 3) tag
<fabbione> 4) branch the new pre
<fabbione> 5) switch to the new pre
<fabbione> 6) ./debian/rules startnewrelease (or something)
<fabbione> 7) baz lint
<fabbione> 8) add new files
<fabbione> 9) check the diff
<fabbione> 10) copy the abi
<fabbione> 11) commit
<fabbione> if there is no ABI change: baz mv debian/abi/2.6.12-6.6 debian/abi/2.6.12-6.7
<fabbione> because you are working on the new 6.8 
<fabbione> doko: dude.. i really really need a fixed binutils..
<fabbione> do you know if there is any progress?
<lamont> fabbione: will bump
<lamont> hehe..  branch with one arg switches.. :)  so 4,5 is one step
<lamont> fabbione: and i'm not worried about a -6.x ABI transition on ia64, since non-booting->booting is a good change.. :0)(
<fabbione> lamont: the point is that if there is an abi change, it will FTBFS because of the checker
<fabbione> the files must be there
<fabbione> otherwise even make clean will fail
<lamont> ah, right
<lamont> how do I know there's no abi change? test builds everywhere?
<fabbione> so if there is an abi change use the nice target in debian rules: bumpabi (needs fakeroot)
<fabbione> lamont: you did change only one CONFIG_ on ia64, right?
<lamont> yrd
<lamont> yes
<fabbione> so just build on ia64
<lamont> CONFIG_PRINTK_TIMING or some such was fatal
<lamont> ah, ok
<fabbione> if it goes trough all of the 4 without screaming and yelling, there is no ABI change
<fabbione> otherwise it will tell you that there are symbols mistmatches
<lamont>  /bin/sh: hppa64-linux-objdump: command not found
<doko> fabbione: no, drow just '*sigh*'ed about it
<lamont> WTF?
<fabbione> it's missing -gnu-
<lamont> yeah.  that's with my change
<fabbione> doko: ok thanks
<lamont> fabbione: so that's "it's _still_ missing -gnu"
* lamont is going to go to sleep now..
<fabbione> good night lamont
<zul> that dvb card patch looks correct
<dilinger> fabbione: ping
<dilinger> fabbione: actually, nm
<lamont__> sigh... hppa's build issue is, well, hppa.  OTOH, kernel-package should still be fixed,dammit
<lamont__> doko: the ${ARCH}-linux-gnu-objdump change, when does that hit debian?
<doko> lamont__, it already did
<lamont__> way cool
<lamont__> hrm... any patches from anyone for -6.7?
<jbailey> lamont__: You doing a new kernel?
<lamont__> yes
<jbailey> lamont__: I buillt a new kernel on the weekend with the initramfs/dsdt patch in it, but I haven't tested it yet.  When do you need it by?
<lamont__> so far, it's one semi-non-bug, and hppa/ia64 fixes...
<lamont__> I want a better excuse... :)
<jbailey> This will be a good enough excuse.  Lemme test the patch. =)
<lamont__> hrm... 1600 UTC or so... but that's past already... so we have time. :-(
<lamont__> before midnight UTC-0600 would be way cool
<zul> i have a bunch of patches in my baz
<jbailey> Hmm, well the acpi patch doesn't keep it from booting anyway.  Now let's try a DSDT replacement.
<jbailey> Old style DSDT replacement still works.
<lamont__> zul: anything significant?
<lamont__> anything that wants/needs to get into -6.7?
* lamont__ lunches for a few
<zul> lamont__: acerhk support, bug fix, and a couple of patches i stole from git
<zul> everything is signifacant ;)
<zul> heh...redhat is a bit behind the times
* jbailey does another build with the patch actually applying this time.
<jbailey> Dear keybuk, why did you taunt us with Wigg&Penn?  
<lamont__> zul: if you want to merge from the playground, and test your stuff, i expect I can include it... I'd like to avoid an ABI bump though...
<zul> lamont__: did that yesterday i didnt notice an abi bump it wouldnt build if it did would it?
<lamont__> right.  but I really don't want to follow -6.7 with -7.8 just because of that...
<zul> true
<zul> did you commited anything to the playground today?
<lamont__> playground has all my stuff
<zul> ok ill re-build my stuff in a bit and ill let you know 
<zul> with the playground+my patches
<lamont__> thans
<lamont__> if you have a reachable archive somewhere, I can toss it at the DC machines to do test builds around
<zul> yep its at http://zulinux.homelinux.net/arch/zulcss@gmail.com--2005
<zul> crap i still have *.orig in my patches
<lamont__> coolness - holler once your merge is done, eh?
<zul> ok
<zul> bbl...im building right now i need to finish off the house work
#ubuntu-kernel 2005-08-07
<infinity> lamont : If you're planning on doing a -6.7 release (and hey, you won't see me complaining about someone else doing it), hold off, I need to test a ppc64 patch and get it in.
<lamont__> infinity: targetting tonight late to start test builds
<lamont__> as in, somewhere before 0500 UTC or so
<infinity> Hrm, that'll be a tight squeeze, but I'll see what I can do.
<infinity> Otherwise, I'll just have to followup with a release with one change. ;)
<lamont__> well, mostly it's because I want to go to sleep... worst case, I'll dump doing the test builds and upload on you
<infinity> Sleep?  Pfft.
<lamont__> hehe
<infinity> <blink>
<infinity> Can someone explain to me why onoffice.org2 has suddently started depending on a full build environment?
<infinity> openoffice, too.
<lamont__> because they will ruin your life
<infinity> Seriously, a dist-upgrade on my laptop wants to install like 5 compilers and a bunch of dev libs.
* infinity grumps in doko's direction.
<lamont__> infinity: just wait - they're bootstrapping i386/amd64 biarch, which will churn things a bit
<doko> infinity: openoffice? no
<zul> lamont, : 686 built without a problem
<lamont__> zul: coolness
<zul> you can get from my arch to test if you wish
<lamont> zul: OK.  But that'll be in several hours.
<zul> morning
<chmj> morning chuck 
<zul> morning charles
<zul> so lively
<zul> lamont: is the build going on?
<lamont> zul: I went to bed, still waiting for jbailey and infinity
<zul> okie dokie
* lamont -> office
<zul> ummm...ok http://bugzilla.ubuntu.com/show_bug.cgi?id=12739
<jbailey> lamont: Oy.
<jbailey> lamont: My patch seems to work so far.
<jbailey> I need to do two more tests, and then do I hand it to you?
<lamont> jbailey: yeah.  or you can commit it to the playground...
<jbailey> lamont: Does that mean learning enough baz to do that?
<lamont> hehe
<lamont> just give me the patch
<lamont> jbailey: oh - btw, how does mkinitrd decide what modules to put in the initrd it's building?
<lamont> currently loaded modules? hw lists? what?
<jbailey> in MODULES=dep mode, or MODULES=most ?
<lamont> both
<jbailey> Hmm.
<jbailey> Excellent question.
* jbailey comments yet again that Perhaps Xu thought he was programming in Perl.
<jbailey> initramfs-tools is going to just walk the /sys tree on the local machine.
<jbailey> most will just include a list of modules that I specify.
<jbailey> lamont: Do you have a particular problem you're trying to solve?
<lamont> answering a question for support types...
<lamont> I think that answers the question
<lamont> infinity: did you have kernel patches for me?
<lamont> jbailey: so =most is really =dep + jbailey's list?
<jbailey> On initramfs, yes.
<jbailey> On initrd it seems to calculate it.  Following it involves following the rabbit through the file descriptor maze.
<lamont> hehe
<lamont> hoary (and sarge) use initrd, yes?
<jbailey> Yes
<lamont> was really just wondering if =most was a superset of =dep, or if it was "just this list, kthxbye"
<lamont> for initrd :-(
<jbailey> Oh. yes.
<jbailey> That's an easier answer. =)
<jbailey>                 most)
<jbailey>                         add_modules_most
<jbailey>                         add_modules_dep maybe
<jbailey>                         ;;
<jbailey>                 dep)
<jbailey>                         add_modules_dep
<jbailey>                         ;;
<lamont> lol
<lamont> btw, ext2_fs.h sucks
<lamont> (debian, that is...)
<lamont> the boot loader portion of palo still needs love.
<lamont> jbailey: and "calculate" == ??  just wondering what sorts of things... 30000 ft handwaving answer is ok
<jbailey> calculate?
<jbailey> I don't see that in the script or the manpage.
<lamont> <jbailey> On initrd it seems to calculate it.  Following it involves following the rabbit through the file descriptor maze.
<jbailey> add_modules_dep calculates the modules list somehow.
<jbailey> But I don't see at a glance how it calculates it.
<lamont> ok.  no hints on what it uses as inputs either, eh?
<lamont> bummer
<lamont> jbailey: initramfs-tools is for grub2, or just a simple dropin replacement/upgrade to initrd?
<jbailey> replacement for initrd
<lamont> woot
<jbailey> This acpi patch I think is my last major blocker for making it default
<lamont> nearly done? or what's the status?
<lamont> ah, ok
<jbailey> (I found a slight bug that I want to fix.  Will test again tomorrow since it takes a while to build)
<lamont> that's the kernel patch you have for me?
<lamont> or what's that status atm?
* lamont wonders if jbailey is planning 2.4 support in initramfs-tools. :-)
<jbailey> lamont: No
<jbailey> Yes, that's the patch I'm working on.
<lamont> ok
<jbailey> It doesn't support the old style initrd DSDT.
<jbailey> It ought to, so it'll just be a slight bug.
#ubuntu-kernel 2006-07-31
<darkbyte> Hi all !
<darkbyte> Anyone knows how I can recompile the current dapper kernel without modifying version number (2.6.15-26-386) to be able to use the current restricted modules available ?
<crimsun> sorry, but the question's confusing. Why would you need to recompile the current Dapper kernel to use the current [Dapper]  l-r-m?
<darkbyte> I need to modify the ide-probe.c driver file to be able to use a Promise TX4 card with my VIA chipset motherboard. And I would to use as much as posible of the repository packages, as the linux restricted modules.
<darkbyte> If I can rebuild the kernel only with the patched ide driver I don't need to touch enything else.
<crimsun> do said modifications to ide-probe.c export additional symbols or anything of the like? If so, you'll still need to bump the ABI, which means you'll end up recompiling l-r-m
<darkbyte> I only need to comment 3 lines of code
<crimsun> then just recompile using the infrastructure you get via ``apt-get source linux-image-$(uname -r)''
<crimsun> it's documented on the wiki (see topic) afair
<darkbyte> I don't see this (glups) ...
<darkbyte> downloading rith now, thanks crisum a try it ...
<darkbyte> right, I try
<crimsun> BenC: hi, hope the tourney went well. The patches sent to the list should be applied to Dapper's and Edgy's linux-sources. There are enough fixes in alsa's tree that syncing the aoa driver to Edgy's linux-source is recommended.
<TheMuso> C
<thom> right, i guess i get to find out in a while whether i've fixed #37452 finally
<rodarvus> BenC, ping
<zul> hey
<zul> BenC: how was the tournament?
<BenC> rodarvus: pong
<BenC> zul: didn't play the tournament, just played for some cash
<rodarvus> BenC, I have two FTBFS, depending on (theoretical) updates to l-k-h, do you think you can spend some time on these issues today? (or soon)
<rodarvus> in both cases, missing include files
<rodarvus> BenC, I talked with fabbione last week, but he wanted to talk to you, before adding/changing stuff on l-k-h
<rodarvus> BenC, http://librarian.launchpad.net/3640193/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<rodarvus> and
<rodarvus>  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall -Wall -g -O2 -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c ../../src/evdev.c  -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o
<rodarvus> In file included from ../../src/evdev.c:66:
<rodarvus> ../../src/evdev.h:74:24: error: asm/bitops.h: No such file or directory
<rodarvus> ../../src/evdev.c: In function 'EvdevReadInput':
<rodarvus> ../../src/evdev.c:95: warning: format '%ld' expects type 'long int', but argument 6 has type 'unsigned int'
<rodarvus> ../../src/evdev.c: In function 'EvdevParseBits':
<rodarvus> ../../src/evdev.c:348: warning: implicit declaration of function 'set_bit'
<rodarvus> make[3] : *** [evdev_drv_la-evdev.lo]  Error 1
<rodarvus> (the second one was from xserver-xorg-input-evdev, which I didn't uploaded yet, due to the FTBFS be happening on all archs)
<rodarvus> the two are rather serious: the first prevents xorg-server (and and thus *all* drivers) to be built on sparc
<rodarvus> the second basically prevents anyone from using evdev on current Edgy
<zul> BenC: ah cool..
<BenC> rodarvus: ok, I can fix that
<BenC> rodarvus: bitops.h is a bogus include
<BenC> well, it is on some arch's anyway
<BenC> on sparc, it's wrapped in __KERNEL__, so it's blank
<BenC> if all it's using is set_bit(), then evdev should just define that locally using a generic one
<BenC> rodarvus: look in include/asm-generic/bitops/atomic.h for a version of set_bit that evdev.c can use locally
<BenC> rodarvus: as for kbio.h:
<BenC> $ find include/ -name kbio.h
<BenC> $
<BenC> there is no such file, so that definitely is bogus
<rodarvus> BenC, so just remove asm/kbio.h from xorg-server, then?
<BenC> yeah
<rodarvus> BenC, I'll do it - thanks!
<infinity> BenC: Have you tried to push -fno-stack-protector upstream yet?
<infinity> BenC: It'd be swell if upstream sources built on the edgy toolchain unmodified by the time we release.
<BenC> infinity: someone grabbed it from Ubuntu source and sent it upstream, but I don't know if it got accepted
* BenC tries to install Ubuntu on his new OpenPower box
<zul> there was a patch to fix the kernel so it can compile with ssp
<zul> hey jeff
<jbailey> Heya Zul
<jbailey> There was something you asked me the other day.
<jbailey> hmm
<zul> the xen stuff..
<jbailey> I replied, and someone else had stolen your nick  /me checks for logs.
<jbailey> Right!
<jbailey> I confused some guy because he wanted to know why a stranger was asking for straces of ls on his bsd system.
<zul> hmmm..
<zul> thats weird
<jbailey> I'll paste the conversation to you.  It was amusing.
<zul> heh ok
<BenC> I had to switch my nick to secure because if I'm off for > 12 hours, there's always this same guy that grabs my nick and I end up having to /kill him from nickserv
<zul> jbailey: lol
<jbailey> BenC: Is that the auto-kick if you don't identify stuff?
<zul> same here..
<BenC> jbailey: if I understand correctly, /m nickserv set secure on, makes it so you have to identify or you get /kill'd
<jbailey> Nice!  I should set that.
<BenC> I should let one of you guys take my nick for a minute to see if it works :)
<jbailey> Sure.  I'll use my jb-home account.
<BenC_> jbailey: ok
<benc> -NickServ- This nickname is owned by someone else
<benc> -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
<benc> So let's see. =)
* infinity waits...
<BenC_> it's been > 60 seconds
<infinity> This feature seems lacking.
<BenC_> very
* benc clears his through and announces that the next upload will be a BSD kernel.
<infinity> Yay!
<BenC_> lol
<benc> Even that wasn't enough to shock the system into working
<benc> Clearly defective.
<BenC_> specially, darwin :)
<thom> BenC_: 15:12 <thom> set kill on
<thom> 15:12 -NickServ(NickServ@services.)- Kill Protection is disabled on this network
<benc> Suck
<thom> so i don't think secure on will kill, regardless
<zul> need to reboot again
<jbailey> zul: Send me the strace, please ;)
<BenC> that sucks because this same guy is always taking my nick if I disconnect for a half a day or more
<BenC> and I /kill him everytime and he doesn't seem to get it...to not, like, use my nick and such
<jbailey> thom, infinity: Hello btw. =)
<BenC> maybe he's just a masochist
<infinity> BenC: Same thing happens to me.  Always the same guy as well.
<infinity> But in my case, I'm usually connected for weeks at a time.
<infinity> And if I'm off for more than a few minutes, he's got my nick.
<BenC> same here...it's just times like when I travel
<infinity> Bizarrely antisocial behavious.
<infinity> behaviour, too.
<thom> infinity: irc
<infinity> thom: yeah, but it's not eactly efnet.
<BenC> hehe...efnet
<thom> infinity: true 'dat
* BenC remembers those days
<BenC> it's strange that I can go on there every few months or so and see ppl that I used to chat with 6-7 years ago still hanging out in the same channels
<infinity> it's hard to give up one's channel list.
<infinity> I have a 25 year old friend who still hangs in "#12-15teenz", cause he founded it (ironically, when we was 11)
<BenC> lol
<BenC> those are the kinds of channels just begging for pedaphiles :)
<infinity> I'm pretty sure no one in there is 12-15 anymore, since it's been the same group of friends from around the globe since its inception, and no one else seems to poke their heads in.
<infinity> THough I made the same comment, when I first saw it on his channel list.
<zul> jbailey: once i get it working :)
<BenC> mdz: ping
<mdz> BenC: pong
<BenC> mdz: nm, you replied via email
<BenC> thanks
<jbailey> BenC: BTW,  last kernel I tried on the G5 still had the sata_ whatever problem and the kernel panic (if you turn off quiet and splash)
<jbailey> BenC: Got magic smoke out the back of the power supply on Friday, though, so it might be a bit before I can test again.
<jbailey> I had planned this weekend to copy down the oops and post it.  Oh well.  =/
<kbyrd> mdz: just got your email.
<BenC> jbailey: ok
<mdz> kbyrd: welcome
<kbyrd> thanks. 
<kbyrd> So, I completely misunderstood the l-r-m packages. I thought it was a single user-installable package containg a bunch of .ko files.
<BenC> kbyrd: mostly it is, but we can create separate module .deb's from it if needed
<kbyrd> perfect. 
<mdz> kbyrd: currently it builds one binary package per kernel ABI containing kernel modules, plus a few extra things (like X drivers) which aren't tied to a kernel ABI
<BenC> but being built from a common source package means we can keep the ABI in sync more easily
<mdz> kbyrd: what will complicate things is needing to keep things in sync as the kernel ABI changes
<kbyrd> That sounds like the right spot then. The player package we handed off to mvo builds both a binary and source package (so people can use module-assistant)
<mdz> kbyrd: we handle that with metapackages built from linux-meta which pull in the rgiht versions
<mdz> this will mean two additional metapackages for the vmware modules, which is doable but not very convenient
<kbyrd> Since there is not vmware-server yet (our legal team is doing it's thing right now), what can I do to help get vmware-player-kernel in the l-r-m build?
<infinity> Fix the license to not require a click-through.
<infinity> That's the only thing preventing me from rolling it in.
<infinity> Cause I refuse to require a click-wrap on all of LRM, for the sake of one module.
<kbyrd> I didn't do the original player-kernel package, I didn't realize the player-kernel package had a EULA. That's not right. 
<infinity> (Well, fix the license, fix your policy regarding the license, whichever. :))
<kbyrd> inifinity: I agree. 
<infinity> The guy who originally did the packaging was told from on high that he had to do it that way.  He also violently disagreed with the whole idea.
<kbyrd> So, we'll still have a click thru on vmware-player, just not on vmware-player-kernel. That work?
<infinity> Yeah, that would be fine.
<kbyrd> Yea, we're fighting that from that ground up.
<infinity> I'd be happy to roll it into LRM as soon as we can do so, which was discussed in the dapper cycle.
<kbyrd> (maybe we'll get the modules open sourced here if we get what we want).
<kbyrd> but not soon.
<infinity> It would be amazingly cool if the modules were not only open-sourced, but shared a common code-base between player/workstation/server, but that'll be a while to co-ordinate, I suspect.
<infinity> (Cause it would be pretty cool if we shipped the "right modules" out of the box for any of your products)
<kbyrd> infinity: For us, those are two different problems. VMware has never had a good, co-install story. The code is all very similar, just different branches for QA / support reasons.
<infinity> Yeah, I know, I've discussed this in the past. :)
<infinity> But it's a shame, that's all.
<kbyrd> embarrassing actually.
<kbyrd> When I've got a non-click thru vmware-player-kernel package source, should I just come back here?
* infinity nods.
<kbyrd> thanks all.
<BenC> wow, we are totally not ready to have ubuntu work on pSeries machines...having trouble even doing a boot with our stuff that expects a lot of mac'isms
<zul> BenC: send me one and i can help ;)
<mdz> BenC: any objection to me tightening the linux-meta dependencies as discussed?  it only affects the top-level metapackages which depend on -image-foo and -restricted-modules-foo
<mdz> BenC: also, can we make linux-686-smp and linux-k7-smp transitional packages now?  they seem obsolete
<BenC> mdz: yeah, sounds good
<kbyrd> infinity: you around?
<kbyrd> anyone else then... Earlier, infinity said the thing holding up vmware-player-kernel being built as part of l-r-m was that it had a click-thru EULA. I just downloaded the package and checked it out. I found nothing requiring user interaction. I bet we had something like this originally, but it's not in the current version. There is still a click-thru EULA for vmware-player, just not the kernel mod
<kbyrd> ules. 
<BenC> kbyrd: if that's the case, then we can just pull it into lrm for edgy no problem
<kbyrd> BenC: 1) Can one of you confirm I'm not crazy? If I'm wrong, I'd rather find out now and fix it now. 2) Is there any way to get it done before the next kernel ABI update for Dapper? 
<BenC> doubtful that it will happen for dapper
<BenC> I just need to add vmware modules to my list of things to update for dapper kernel ABI bumps...but since those wont happen very often (if ever again), then I don't expect it to be a problem there
<kbyrd> BenC: hmmph. Ok, any way to get notified when an kernel ABI change is in the queue for Dapper before  it hits the repository?
<kbyrd> That "ever again" thing worries me. Since it happened twice pretty quickly so far. 
<kbyrd> Since you said that out loud, it's sure to happen again ;-)
<BenC> that's because we had a lot of updates for dapper that just didn't make release
<BenC> heh, well, even if it does, we always get it our within a day or two of the update, or likely at the same time now
<kbyrd> Cool, thanks. Ok, last thing for now. Is someone looking at my *-9 update that I sent last week? That'll fix the  bug about module-assistant builds not working.
<BenC> ping zul, he did the last few uploads of the modules, which by law makes him responsible for everything after that with the package :)
<kbyrd> Nice, sort of like when I comment on some code in our source. I'm forever destined to fix all future bugs about it even it it's not my code.
<BenC> you've experienced this development model before...excellent :)
<kbyrd> I just msg'd zul, is his email @ubuntu.com as well?
<BenC> zulcss@gmail.com I think
<zul> or zulcss@ubuntu.com
<zul> since when was i responsible :)
<thom> BenC: wrt #37452 i at least have a built kernel with the two patches i mention. I'll test them tomorrow morning.
<BenC> thom: ok
<zul> BenC: oh yeah im entering in a tournament tonight
<BenC> private or casino?
<BenC> or online?
<zul> casinoish...its at a restatunt/bar
<zul> i should last about an hour ;)
<BenC> is it a freeroll?
<zul> yeah
<BenC> ah, those are mainly an all-in fest
<BenC> no skill involved :)
<zul> yeah but i rather play live than online
<BenC> play tight...if you get aces, just go all-in, someone will call you
<BenC> no doubt
<jbailey> BenC: Did you read about the world strip poker championships going on next month?
<jbailey> I have a feeling that's one tournament I wno't watch...
<zul> if they have women in it i would watch
<BenC> heh, I imagine I wont be watching it either :)
<BenC> High Stakes Poker on Game Show Network has become my new Poker TV addiction
<BenC> it's much more exciting and the game play is much more realistic to what you normally see in a live game
<BenC> ppl watching World Poker Tour and WSOP tend to think you play poker just like those guys, but it's a totally different situation than most poker games that ppl play :)
<jbailey> Right.  As opposed to "Let the bear win" type of strategy. =)
<mdz> BenC: any reason to keep l-s-2.6.15 and l-r-m-2.6.15 around in edgy?
<BenC> mdz: none
<mdz> BenC: please request their removal via ubuntu-archive then, so that we don't forget before the release and pitti doesn't cry
<BenC> mdz: ubuntu-archive@lists.ubuntu.com?
<mdz> BenC: file it in Malone and subscribe ubuntu-archive to the bug
<BenC> ok
<BenC> mdz: done
<mdz> thanks
<zul> ouch...BLK_LOOP is compiled into the kernel
<jbailey> BenC: Got a checkout of reasonably current upstream git handy and a sec to look something up for me?
<zul> later folks
<jbailey> g'n chuck
<BenC> jbailey: sure
<jbailey> BenC: I managed to trace it, sorry for the noise.
<BenC> np
<makx> hmm bogl uses PAGE_SIZE inside of asm/page.h
<makx> is that still exported?
<BenC> there's nothing in it
<BenC> at least not on ppc
<makx> yup it's failing to build on ppc debian buildd
<BenC> PAGE_SIZE is a little ambiguous on ppc
<BenC> depends on 32-bit or 64-bit kernel, so even if it's 32-bit userspace, if you are really concerned about what the kernel is using, then you cannot be sure
<BenC> I suggest getpagesize(2)
<makx> yup will do
<jbailey> live checks, good. =)
#ubuntu-kernel 2006-08-01
<crimsun> hum.
<crimsun> I'm pretty sure 6.06 LTS has udev 079, not 071 as stated at http://lkml.org/lkml/2006/7/31/71
<rodarvus> infinity, ping
<infinity> rodarvus: If it's about LRM, that'll be first thing tomorrow, so in about 10 or 11 hours.
<infinity> rodarvus: If it's not about LRM, then go ahead. :)
<rodarvus> haha
<rodarvus> I was going to ask about lrm :)
<rodarvus> thanks!
<rodarvus> infinity, its the last package needed for an update on xorg-server
<rodarvus> (adding Breaks: all-old-servers)
<rodarvus> s/all-old-servers/all-old-drivers/
<jbailey> Breaks on a virtual package works?
<rodarvus> jbailey, well, expand <all-old-drivers> :)
<jbailey> Ah, I was hopeful for a moment. =)
<rodarvus> heh, ok :)
<doko> BenC: ping
<BenC> doko: pong
<doko> BenC: what did happen to the idea of the amd64 kernel for i386?
<BenC> doko: I have one major reservation about it and that's the fact that usblp doesn't have 32-bit->64-bit ioctl thunking, so people who used the amd64 kernel with 32-bit userspace would suffer problems that might not get fixed, and they would end up going back to a 32-bit kernel anyway
<BenC> If I can get that fixed, then I'll probably create an amd64-generic for i386
<doko> ok, just wanted to know ...
<BenC> not only that, but then there's the whole issue of uname -m reporting x86_64, which will create all sorts of compile problems for those users
<infinity> linux32 uname -m
<infinity> AKA, "that's their problem, they can sort it"
<BenC> yeah, but try having to answer that 1 million times
<BenC> actually, if we provide the kernel, it suddenly becomes our problem :)
<infinity> *shrug*, we're providing it as a non-standard option.
<infinity> And we don't guarantee that any sort of development stuff ever works out of the box without the user having a brain attached.
<BenC> Linux powder 2.6.17-5-powerpc64-smp #2 SMP Mon Jul 24 11:00:28 UTC 2006 ppc64 GNU/Linux
<BenC> not sure why the installer for this openpower box freezes, but a manual install using debootstrap runs just fine
<BenC> [10727.696722]  Brought up 4 CPUs
<BenC> yummy
#ubuntu-kernel 2006-08-02
<BenC> yeah, quad 1.65Ghz G5 cpu's is a bit faster at building kernels than my old 500Mhz G4
<BenC> just a bit
<ajmitch> nice
<crimsun> thanks for the merges, BenC.
<BenC> crimsun: thank you
<BenC> platform        : pSeries
<BenC> machine         : CHRP IBM,9123-710
<BenC> pretty sure this is the first time we've had ubuntu on a pSeries
<BenC> still need to figure out why I can run a fully installed system without problems, but the installer freezes
<zul> heylo
<ajmitch> hi zul 
<Petaris> hello
<Petaris> I have installed a new kernel via apt but it is complaining that the modules.dep file has problems
<Petaris> It also complains it cannot run depmod
<Petaris> Is there a way to either bypass this or fix it?
<Petaris> Hello ajmitch
<zul> what kernel?
<Petaris> zul: 2.6.15-26-amd64-k8
<zul> hmm...
<Petaris> just for kicks I tried the amd64-server kernel and it did it aswell
<zul> did you compile your own kernel at some point?
<Petaris> nope
<Petaris> fresh install
<zul> not sure...you might want to open a bug in launchpad
<Petaris> hrm
<Petaris> I should maybe note that the system has not completed its first reboot
<Petaris> that is the reboot after initial install
<Petaris> as it hangs
<Petaris> so I used the install disk rescue mode
<Petaris> mounted my drives and chrooted in to apt-get these kernels
<Petaris> would that cause the issue?
<Petaris> brb
<Petaris> back
<makx> Keybuk: around?
<rodarvus> @now
<rodarvus> argh. sorry
<lamont> has anyone tried an edgy kernel on ia64 with ACPI_DEBUG=n?
<zul> not me...but if you want to send me on my way i can ;)
<zul> later
#ubuntu-kernel 2006-08-03
<chuck> well that was fun..
<zul> power went out all of the sudden
<johanbr> I'm guessing it's back now. :)
<zul> hey
<jwest-> Would I be crazy to try to create a gentoo chroot inside of ubuntu so that I can have a gentoo install to play it?
<zul> try #ubuntu...ttoally offtopic here
<jwest-> ok
<kozz> I have a script in /etc/kernel/postinst.d that uses db_get, but it fails when using it from /var/lib/dpkg/info/linux-image-2.6.17-5-powerpc.postinst, seems like that script locks the database or such
<kozz> anyone knows about that problem? or knows where the database is used in /var/lib/dpkg/info/linux-image-2.6.17-5-powerpc.postinst
<kozz> I can run the script standalone without problem, but as soon as it runs from the postinst script in the kernel it fails with return code 20
<kozz> http://www.copypot.com/347
<kozz> and the script, http://www.copypot.com/348
<kozz> if I replace db_get with bootloader="mkvmlinuz" it works
#ubuntu-kernel 2006-08-04
<zul> BenC: ping
<zul> hi
<makx> mjg59, Keybuk: where should i send you debian usplash patches?
<mjg59> makx: What sort of patches?
<mjg59> Emailing them to me and Scott is probably good
<makx> mjg59: minor fixes atm
<mjg59> makx: Ok
<mjg59> To which area?
<makx> some bogl stuff, some usplash stuff
<makx> mjg59: ok will email.
<makx> :)
<mjg59> Cool
<mjg59> makx: But note that on x86 and amd64, we don't use bogl any more
<makx> mjg59: i noticed due to vesa switch?
<mjg59> Yeah
<makx> i've heard you are working on theme support?
<mjg59> Me? Nope
<mjg59> But Dennis Karsemaker is
<makx> h01ger wanted to have a restored usplash after cryptsetup pwd typing
<makx> i guess an usplash -c restart by the cryptsetup hook would do that
<makx> mjg59: also would appreciate your input on http://bugs.debian.org/380752
<mjg59> makx: Looks broadly ok, but won't currently work
<mjg59> Since svgalib and bogl need fonts in different formats
<mjg59> I'll try to fix that up
<makx> ok cool
<makx> mjg59: woow i missed your last revisions
<makx> hmm could you add usplash to the list that mails to pts@packages.d.o?
<mjg59> makx: Hrm. How?
<makx> mjg59: no idea how Keybuk has set up the patch repo
<makx> i had thought that there were no usplash updates as https://lists.ubuntu.com/archives/ubuntu-patches/ and pts not fed
<makx> would ease me to sync up with you guys :)
<mjg59> Ah
<mjg59> It started off as a package in Ubuntu, so the syncing may be a little weird
<mjg59> I'll ask Scott
<makx> thanks
<makx> yes also had trouble with the version string for native package
<dilinger> hello
<dilinger> the sata_mv in dapper is terribly broken w/ a chipset that i've got in some 1U machines
<dilinger> would there be a chance of getting a backported sata_mv into dapper kernels?
<crimsun> how intrusive is the fix? (there's a pretty good chance if it's utterly broken)
<dilinger> i'm not sure yet.  i backported 2.6.16's sata_mv.c (no other files necessary) to dapper's 2.6.15, and it worked
<dilinger> i can try and figure out what specifically fixed it
<crimsun> that would be most helpful to Ben :)
<dilinger> dapper install images aren't regenerated w/ updated kernels, right?
<dilinger> so there would still be a broken sata_mv.ko in the official iso
<crimsun> well, it's unfortunate that you didn't mention this a few days ago, since the latest kernel is in the 6.06.1 images.
<dilinger> d'oh
<jbailey> dilinger: I think sata_mv might be the one that's screwed on ppc64 in edgy...
<dilinger> actually, they look pretty similar
<dilinger> same version, even (0.5); just an MSI fix
<dilinger> some const-ness updates, and some ordered write change
<dilinger> jbailey: does it work in dapper?
<dilinger> jbailey: i have no idea how 2.6.17 fares on these machines..
<jbailey> Dapper works on my ppc64 box.
<jbailey> Well, worked until the power supply spewed magic smoke.
<jbailey> (last friday, sigh)
<dilinger> ok, got it
<dilinger> it's the MSI fix
<dilinger> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ddef9bb367b19383df627e388cb4c01c86ddba6c
<crimsun> yeah, just ask ben to cherry-pick that one
<dilinger> BenC: ping? :)
<dilinger> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/55234
#ubuntu-kernel 2006-08-05
<zul> BenC: any problems with the xen stuff?
<kylem> BenC, ping.
<zul> hey kylem 
<kylem> evening.
<kylem> zul, any idea who i bug to get stuff in the edgy d-i dailies?
<zul> argh..
<crimsun> kylem: kamion, more than likely.
<kylem> ok. it's so much easier in debian, where i can just svn ci it. ;o)
<Nafallo> I found badness in the latest dapper kernel :-/
<crimsun> neat. where does it asplode?
<Nafallo> I'll post a .txt, hold
<Nafallo> http://www.magicalforest.se/~nafallo/kernel_badness.txt
<crimsun> interesting, coming from the network stack
<Nafallo> seems to have been introduced by the latest security-kernel :-/
<Nafallo> Aug  5 23:22:47 ogre racoon: INFO: begin Identity Protection mode. 
<Nafallo> Aug  5 23:22:47 ogre racoon: ERROR: sendfromto failed 
<Nafallo> Aug  5 23:22:47 ogre racoon: ERROR: failed to begin ipsec sa negotication.
<Nafallo> this seems to be the what hits me now :-/
<Nafallo> over and over again...
<crimsun> Nafallo: and fine in 26.45, correct?
<Nafallo> I haven't checked yet.
<Nafallo> I'll have to see if the routing works as it should first...
<Nafallo> downloading 26.45 from launchpad now...
<Nafallo> ehrm... 26.45 didn't fix it...
<Nafallo> crimsun: can it be hardware error?
<crimsun> hmm, possible but unlikely
<crimsun> that just expands the number of commits to be searched, unfortunately
<Nafallo> :-(
<crimsun> what is the most recent ubuntu revision that doesn't exhibit said error?
<Nafallo> hmm, will have to work my way backward for that...
<crimsun> yeah, then it's a matter of git-bisecting
<Nafallo> okidoki
#ubuntu-kernel 2006-08-06
<Nafallo> this seems strange. worked before reboot, and now I'm about to test linux-image-2.6.15-25-server_2.6.15-25.43_i386.deb
<Nafallo> crimsun: still there?
<crimsun> hi.
<Nafallo> I don't know what caused the bug, but I can't reproduce it.
<crimsun> even on 2.6.15-26.46?
<Nafallo> I "think" I runned the box some hours with heavy network load on the internet interface and then dropped one of my ipsec tunnels constantly... something must just have made it explode :-P.
<Nafallo> I thought the tunnel dropping was what caused the bug at first, but it was rather my firewall configs that didn't get saved properly.
<Nafallo> sorry for the confusion. if it happens again I'll make sure to investigate more closely what could have caused it before rebooting.
<Nafallo> thanks for the help anyway :-)
<crimsun> np
<Nafallo> gnight
#ubuntu-kernel 2007-07-30
<kraut> moin
<IntuitiveNipple> morning :)
<abogani> amitk_: Please don't forget this: https://lists.ubuntu.com/archives/kernel-team/2007-July/001586.html Thanks.
<zul> morning
<abogani> BenC: May i disturb you for a second?
<abogani> BenC:  Could you enable my git repo (-rt) for gitweb? Thanks.
<BenC> abogani: it will get enabled automatically when the scan occurs
<BenC> scans every hour
<abogani> BenC: ah thanks. Sorry for disturb! :)
<BenC> abogani: oh, hey, where's that patch again for fglrx to fix the '__rcu_read_unlock' symbol problem for -rt ?
<stdin> BenC: can you take a look at Bug #129022 ?
<BenC> stdin: first I've heard of that...but I think that restricted-manager is actually the proper way now anyway
<infinity> Uhh, that bug's crack.
<stdin> BenC: maybe, I don't actually use the package but was asked why "the command in the package description" wasn't working, in #kubuntu (as the restricted-manager isn't in kubuntu, not without explicitly installing it)
<infinity> nvidia-xconfig is never the "right" way to enable it, cause it gets you out of sync with debconf/dexconf.
<infinity> If nvidia-glx-config hasn't been fudged to work with the newer nvidia drivers, it should be.
<BenC> as far as I can tell it works
<infinity> BenC: Is it time for me to give LRM some TLC at some point? :P
<BenC> I used it before with nvidia-glx
<BenC> stdin: ok, then that's the actual bug
<BenC> infinity: I been lovin on it plenty, but don't let that stop you from trying to get it on it :)
<stdin> the file "/usr/bin/nvidia-glx-config" is only installed in the -legacy package, so it doesn't work with the normal and -new package
<BenC> $ dpkg -S /usr/sbin/nvidia-glx-config
<BenC> nvidia-glx: /usr/sbin/nvidia-glx-config
<BenC> stdin: that's just not true
<stdin> hmm, hold on :P
<stdin> BenC: it's not listed in http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=nvidia-glx&version=gutsy&arch=i386
<stdin> BenC: opps, no, it is
<stdin> oh well 
<stdin> should have looked harder
<BenC> stdin: I am quite sure that restricted-manager calls that to enable/disable nvidia for all cases
<BenC> so if it's working, then I suspect the script is too
<stdin> yeah, the the problem is with the manual install, for those without the restricted-manager
<stdin> but that's another issue all together 
<BenC> stdin: you misunderstand...restricted-manager calls that script, so the script has to work
<BenC> even if called manually
<stdin> hmm, yeah. not sure why it didn't work for the person that asked about it then
<BenC> could be they've manually modified their xorg.conf
<BenC> in which case the md5sum wont match, and the script will assume it is out of sync with debconf
<BenC> IOW, it wont touch it
<stdin> well, I guess I should set the bug to invalid
<abogani> BenC: In lrm?
<BenC> abogani: yeah
<BenC> abogani: you had sent it to me once before I believe
<abogani> BenC: Where i can download lrm?
<BenC> abogani: apt-get source linux-restricted-manager-2.6.22
<abogani> BenC: Ok.
<BenC> s/manager/modules/
<abogani> ok.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.20 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
<lamont> II: Checking modules for hppa32...previous or current modules file missing!
<lamont>    /build/buildd/linux-source-2.6.22-2.6.22/debian/abi/2.6.22-9.19/hppa/hppa32.modules
<lamont>    /build/buildd/linux-source-2.6.22-2.6.22/debian/abi/2.6.22-8.18/hppa/hppa32.modules
<lamont> make: *** [module-check-hppa32]  Error 1
<lamont> could we maybe please add the missing files for .20????
<lamont> or does .20 have them I wonder?
<lamont> nope.  .20 doesn't have them.
<lamont> BenC: amitk_: any reason that not all of my patch was taken?
<lamont> and if I roll the patch forward, can I have a .21 that has the rest of the patch?????
<lamont> so that maybe the kernel will finally build???
<BenC> lamont: oops...forgot about that, my fault
<BenC> lamont: yes, please, and I will do another upload
<lamont> BenC: since .20 hasn't published yet, I'll capture with .19 and should have a current patch for you later today.
<lamont> kernel builds aren't exactly speedy
<IntuitiveNipple> Any ACPI bods about?
<xivulon> mjg59 any news on suspend2ram for wubi (root within file within fuse fs)?
<mjg59> xivulon: Not yet
<mjg59> I'm in the US (on holiday) right now
<mjg59> Ought to be able to take another look next week
<xivulon> thx
<xivulon> I am writing a report for cjwatson
#ubuntu-kernel 2007-07-31
<kraut> moin
<kraut> hi
<kraut> are there any issues concerning nfs-handling in the feisty-kernel?
<kraut> i have problems with fast chainging permissions
<kraut> two nodes using the same nfs-share on a fileserver. one node changes permissions and the other node see this changes only a minute later.
<Lost__> anyone answering questions on kernel support yet?
<kraut> Lost__: not really ;)
<Lost__> kraut, such is life - always waiting for something!
<kraut> Lost__: indeed, but not over 24 hours everytime :/
<zul> besides this channel isnt for support
<ICU> so says the topic :)
<Lost__> zul please enlighten me as to its purpose if not to answer issues with kernel support?
<ICU> "topic: Ubuntu kernel development discussion ONLY"
<kraut> discussion about a bug isn't a development-issue? sounds interesting
<soren> kraut: You didn't mention any bugs. You said "support". That's different.
<kraut> soren: i said "support"?!
<soren> kraut: If it's about a bug, it might very well be relevant.
<Lost__> My question has to do with missing kernel files to properly install a vid card. Where would I go to find answers?
<soren> kraut: Sorry, no.
<kraut> soren: it was about i bug wich i described tomorrow and i am still waiting for an answer...
<soren> kraut: tomorrow?
<kraut> this morning, sorry
<soren> kraut: "morning" is not a very good reference. :) I'm for instance in CEST while most of the kernel team is in the US.
<ICU> several hours ago?
<kraut> i am also using CEST. ok, it's over six hours ago
<amitk_> kraut: if your feel it is a kernel bug specific to Ubuntu, file a bug on Launchpad.net. If it a generic kernel bug, file it upstream.
<kraut> where do i find the changelog about the ubuntu-kernel?
<kraut> or is that a support-question?
<Mithrandir> /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz ?
<amitk_> Here is the link to the kernel git repository: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=summary
<kraut> Mithrandir: thanks
<kraut> amitk_: i just want to verify the chanegs ubuntu did between 2.6.15 and 2.6.20, because 2.6.15 is running fine but the hardware-support is worst in it.
<amitk_> kraut: are you comfortable using git?
<kraut> yes, why?
<amitk_> clone the repository above
<amitk_> then run 'git log v2.6.15..Ubuntu-2.6.22-9.20 ' to find _everything_ that changed
<amitk_> kraut: to restrict to changes in a particular subdirectory add the path after the git log command
<kraut> amitk_: the website is fine for me. also i only need a diff between 2.6.15 and 2.6.20.
<amitk_> e.g. git log v2.6.15..Ubuntu-2.6.22-9.20 fs/nfs
<amitk_> kraut: ok. great
<kraut> amitk_: if you want to see, what i mean: http://exodus.packetloss.biz/~kraut/temp/nfs_issue-2.6.20-3
<kraut> erm, ignore that
<ICU> heh
<kraut> http://exodus.packetloss.biz/~kraut/temp/nfs_issue-2.6.20-3
<amitk_> kraut: 'git log Ubuntu-2.6.17-10.25..Ubuntu-2.6.20-4.5 fs/nfs* | grep UBUNTU' does not yield any Ubuntu-specific patches. So you breakage is likely causes upstream
<kraut> hmmmmm, severall changes between 2.6.17 and 2.6.20 in write.c of nfs. only documentated with "cleanup" :/
<kraut> amitk_: http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-feisty.git&a=search&h=HEAD&s=write.c
<amitk_> kraut: those are 'cleaning up' sysfs, not nfs
<amitk_> ohh wait
<kraut> amitk_: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-feisty.git;a=commit;h=49a70f278658894d2899824cd4037095fb6711fe
<kraut> that one for example
<amitk_> kraut: these are coming from _upstream_. Have you verified this with newer kernels from other distros? or from kernel.org kernels?
<kraut> not until yet
<kraut> amitk_: i am just searching through lkml
<amitk_> kraut: Just repeating myself here: 'git log Ubuntu-2.6.17-10.25..Ubuntu-2.6.20-4.5 fs/nfs* | grep UBUNTU' does not yield any Ubuntu-specific patches. So you breakage is likely causes upstream.
<kraut> i read it ;)
<amitk_> I would urge you to file a bug on kernel.org :)
<kraut> yes yes
<kraut> ;)
<kraut> first i should give 2.6.20-29 a try
<lamont> BenC: eta to a kernel with hppa happiness?
<lazka> i guess this has been asked a thousand times... but what are the chances for 2.6.23 in gutsy?
<zul> lazka: nil im thinking
<lazka> zul: k, thanks
<zul> considering 2.6.23 hasnt even been released yet
<kylem> why do you want .23?
<lazka> kylem: nothing really important... while playing counterstrike i often get lags and i thought maybe the new scheduler might change this,,
<zul> lazka: doesnt stop you from building your own from source though
<pmjdebruijn> lazka, probably not
<pmjdebruijn> lazka, if you only run a single application, the schedular does not make much of a difference....
<pmjdebruijn> lazka, and if you run multiple apps... you plain shouldn't while gaming
<lazka> zul: that's on my todo list :)
<lazka> 2.6.22 seems to be a good one... i hope BenC will get some more sleep then last time right before the release :P
<doko> BenC: please could you prepare a linux-libc-dev for lpia? I don't care, if kernels are built, maybe build just a generic kernel, with -march=i686 -mtune=i586, and use explicitely gcc-4.1
<BenC> doko: you could probably use i386 package and force install it (or dpkg-deb munge it for lpia arch)
<doko> BenC: so scared that you leave? ;-P
<BenC> doko: trying to get this laptop stable :)
<doko> BenC: no, we're done with the bootstrap, now needing to make build-essential workable. could you upload a new package today?
<doko> BenC: one more reason to build linux-libc-dev from separate source ...
<BenC> doko: not really, tribe-4 freeze is in affect
<doko> BenC: what's the problem, just the lpia change
<BenC> building it from separate source sort of defeats the purpose :)
<BenC> doko: it's the rebuild of all of linux-image's and pitti will shoot me
<infinity> pitti will understand, iff you don't break the build of the other arches...
<BenC> doko: if the bootstrap is done, how did it get done?
<infinity> We have i386 packages in the chroots.  We'd really like to not.
<infinity> (Would be nice to be able to debootstrap lpia...)
<BenC> doko: but linux-source-2.6.22 doesn't even know what lpia is...it would take me some time to add a new arch
* infinity was sure he asked for this "within a week or so" when he was in London...
<doko> infinity: debootstrap worked =)
<infinity> doko: Sure, but it's incomplete.
<doko> BenC: just copy the i386 bits for now and just build one kernel (or none, if thats possible)
<BenC> Ok, I'll try to get an upload tonight
<djavolo> hi all
<djavolo> how i can update kernel?
<JanC> djavolo: with apt-get or synaptic
#ubuntu-kernel 2007-08-01
<cyph3r> wad up peeps ?
<AndyP> i just installed gutsy to a minimal level using debootstrap and noticed that the lilo recommends of the linux-image-* packages are being satisfied by default now so lilo gets pulled in. should i file a bug about that or would it not be a problem for a properly installed system?
<stgraber> amitk_: I have added another oops which seems to be related to bug 129226, let me know if there is anything I can try (I'm connected to Internet till 11:30 UTC (prepaid wifi))
<abogani> BenC: May i disturb you?
<BenC> abogani: sure
<abogani> BenC: :-)
<abogani> BenC: Now i successfully compiled Lrm for rt but i don't hardware (in this case ati video card) to test the patch. How i should proceed?
<zul> BenC: btw I should have a new xen snapshot for the next kernel upload
<BenC> abogani: if it compiles, it should be ok
<BenC> abogani: get me a patch and I can upload
<kraut> amitk_: the nfs-issue is fixed in upstream-kernel 2.6.22 btw.
<infinity> BenC: Hey!
<infinity> BenC: Hate to be the bearer of nags, but.  Well.  Nag.
<infinity> BenC: And lamont's begged me to beg you to apply his hppa love at the same time as you do my lpia upload. :)
<BenC> infinity: I gots an lpia prepped kernel upload pending in just a few minutes :P
<BenC> infinity: nag nag nag, thought I got rid of my wife damnit :)
<kraut> ChangeLog-2.6.22             08-Jul-2007 23:39  3.8M  
<kraut> arghs
<infinity> BenC: Hey, I know how lonely it is, I'm just trying to fill in.
<kraut> much to read :/
<BenC> hehe
<infinity> BenC: Any chance hppa is in that upload too?  lamont and I are looking to get hppa back into the DC soon.
<infinity> (About time...)
<infinity> (lpia's obviously more important, though)
<BenC> infinity: should be easy to pull his changes in too
<infinity> \o/
<abogani> BenC: Sorry internet connection problem. Do you have a reply for me?
<BenC> BenC abogani: if it compiles, it should be ok
<BenC>  abogani: get me a patch and I can upload
<BenC> infinity: do we need udeb's for lpia?
<infinity> Eventually we might do, certainly don't right now.
<BenC> lamont: please use the files in debian/commit-templates/ in the future
<BenC> lamont: like: git-commit -s -F debian/commit-templates/patch -e
<lamont> BenC: ok.  sorry about that
<BenC> lamont: makes our changelog auto-fill work better
<BenC> np
<BenC> lamont, infinity: 2.6.22-9.21 uploaded with lpia (hope it works) and hppa pulled in
<BenC> doko: ^^
<doko> \o/
<lamont> BenC: thanks
<BenC> be warned, there's a good chance lpia wont build, since I have no way to test it
<BenC> but I am pretty sure I got all the instrumentation in there
<BenC> if it fails, I'll do another upload
<infinity> Testing it is easy enough...
<BenC> how do I force an lpia build?
<BenC> maybe I could setup an lpia chroot on my x86_64 box
<infinity> Yes, you can do that.
<infinity> chinstrap:~adconrad/chroot-ubuntu-gutsy-lpia.tar.bz2
<infinity> Let me give you a sources.list that works a bit better than the one in there. :)
<infinity> chinstrap:~adconrad/sources.list.lpia
<infinity> Untar (A), spice with a little (B), toss your resolv.conf in, chroot in, and have fun.
<infinity> And don't unhold the packages that are on hold, or you're in for a world of hurt.
<infinity> (The apt build in there is a fancy one that pulls multiple architectures at once)
<BenC> infinity: thanks
<joejaxx> BenC: is linux-image-2.6.22-9-xen an intentional depend of linux-restricted-modiles-2.6.22-9-rt?
<infinity> BenC: Failed.
<infinity> BenC: make: *** No rule to make target `debian/rules.d/i686.mk'.  Stop.
<infinity> BenC: I assume that chroot I gave you will help shed some light. :)
<joejaxx> s/modiles/modules/g
<BenC> infinity: that comes from dpkg-architecture
<BenC> joejaxx: no, mistake, and I'll have it fixed soon
<joejaxx> BenC: oh alright
<BenC> infinity: doh, I use DEB_HOST_ARCH_CPU for that, guess it should be just DEB_HOST_ARCH?
<BenC> infinity: will upload a fix in a bit
<lamont`> BenC: hppa's abi files should just rename over I expect...
<lamont`> BenC: what's the best way for me to get the new abi files from a build back to the tree?
<lamont`> (the target is mid august for getting hppa live in the DC)
<doko> BenC: DEB_HOST_ARCH stays fixed, DEB_HOST_ARCH_CPU may change
<doko> BenC: could you make the binary linux-libc-dev package available somewhere?
<BenC> doko: will get another upload shortly
<bdmurray> BenC: I resumed from Hibernate and my caps lock button is blinking and I seem to have a kernel oops message in dmesg.  What would be useful to gather?
<kylem> bdmurray, hmm. same here, but sans oops.
<bdmurray> I've captured dmesg at least but was wondering if there was anything else worth grabbing.
<bdmurray> kylem: I'm missing a cpu too
<kylem> the cpus are hotplugged, so if something has died on the way back up, that's perfectly plausible.
<bradley> if you are looking to file a bug report, start here: https://wiki.ubuntu.com/KernelTeamBugPolicies
<bdmurray> thanks bradley
<bradley> no problem, for the second output command, you may have to shorten it to cat /proc/version...i don't have a /proc/version_signature file
<BenC> bdmurray: lol, you're getting schooled on filing a bug :)
<kylem> bdmurray is our QA department, i imagine he knows this already.
<bdmurray> bradley: you should have /proc/version_signature what kernel are you running?
<JanC> now bradley is oops'ing  ;)
<BenC> bdmurray: version_signature in gutsy didn't show up until this week with the -9 kernel
<bdmurray> Come on now. He was trying to help.
<bradley> lol...sorry guy, i was just here to ask a question and saw his, so i thought id answer it :)
<JanC> of course he was
<BenC> bradley: it's no problem, we like help...It just gave me a good laugh :)
<bradley> bdmurray: im running the latest gutsy kernel
<bdmurray> really? it sounds like you should have version_signature then.
<BenC> bradley: if you have the latest, you should have it
<bradley> i did the outputs a few days ago and didnt have version_signature
<bradley> got and error when I tried to putput it
<kylem> it's back in -9.
<bradley> i was using -8 when i did the ouputs for my bug, so that would explain it
<bdmurray> bradley: You said you had a question though?
<bradley> yeah, um, it's about a bug report I filed.  I know you guys are super busy and all that, but I have a feeling the fix could be very simple and it doesn't seem as though it's been looked at.
<bdmurray> what bug number is it?
<bradley> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/126140
<bradley> hasn't been looked at by anyone that could fix it, I should say
<bradley> For the time being, I've created a simple , one-line script that runs and shut down, just before the halt script is invoked.  All it does is remove the module.
<bdmurray> bradley: the output of 'sudo dmidecode' may be helpful too
<bdmurray> bradley: and is your BIOS up to date?
<bradley> ok, i added the dmidecode log.  As far as BIOS goes, I'm at v1.40 right now.  1.70 works but I downgraded on an unrelated problem.  BIOS V.1.80 and 2.00 mess with my system to the point that i cant login
<bradley> i had this bug with v1.70
<bradley> 1.80 and 2.00 are BIOS updates for Vista and aren't friendly toward Ubuntu
<JanC> heh?
<bdmurray> that's interesting
<bradley> JanC: sorry if that didn't make sense, I have a tendency to ramblew
<JanC> I was just wondering why & how they would block Ubuntu?
<IntuitiveNipple> bradley:  can you add the output of " cat /proc/asound/card0/codec#0"
<bradley> to be honest, I dont know what the problem is.  all i know is that when i tried to boot with the 1.8 and 2.0 BIOS, i would get to the gnome-splash and everything locks up
<holycow> hi guys
<holycow> does anyone know if the intel g33 chipset is supported?
<holycow> either in feisty or dapper?
<bradley> IN: i added your requested output
<IntuitiveNipple> thanks
<allee> should be bug 129130 assigned to linux-source or debian-installer or ???
<bdmurray> dyslexia strikes again
<bdmurray> 129310 is about something totally different
<bdmurray> allee: the two systems in that bug seem quite different
<bdmurray> allee: but to answer your question linux-source-2.6.22 would be the right package for that bug
<allee> bdmurray: thx.  Yeah, different.  but identical error output ;)
<bdmurray> allee: the same symptoms, identical error output, can be due to vastly different reasons.
<IntuitiveNipple> bradley: Can you test something for me whilst your here?
<bradley> certainly
<allee> bdmurray: yeah, but I've no idea how to provide more useful output.  I'm working my way the KernelTeamBugPolicies. 
<IntuitiveNipple> I just Googled your problem and found a potential solution, depending on what the cause is.
<IntuitiveNipple> bradley: Switch to a tty console (using Ctrl+Alt+F1), login, then close down Gnome, then shutdown
<bdmurray> allee: You can get a BusyBox prompt for a ton of different reasons and that is why a separate bug report would be a good idea.
<IntuitiveNipple> so you'd do "sudo /etc/init.d/gdm stop" then "sudo shutdown -h now"
<allee> bdmurray: k, as soon as I find some useful output, other then 'can't allocate tty' I create a new one
<JanC> holycow: AFAIK the G33 hit the market after the Feisty release...
<bdmurray> allee: cool, do you have any other distro on it?
<bradley> IN: OK, I'll be back shortly to give you the results
<allee> bdmurray: only the preinstalled Vista from DELL.
<allee> bdmurray: ahhhh: access bejond end of device!
<bradley> IN: following you instructions, my laptop shutdown just fine.
<IntuitiveNipple> Great! I saw a Google post over at Fedora saying it might be an X issue
<IntuitiveNipple> It looks like it is, so can you add the xorg package to the 'affects' list ?
<IntuitiveNipple> So, what we can work out for you is an additional shutdown script that unloads snd_hda_intel as a workaround
<bradley> i already have a workaround script that shuts things down just by removing that module
<bradley> and sorry, how do I add to the affects list?
<bradley> i see affects upstream and affects distrobution
<IntuitiveNipple> I've done it for you :)
<IntuitiveNipple> You use the Add Distribution button, select Ubuntu, then the package
<bradley> i got an error message saying this bug has already been reported on xorg
<IntuitiveNipple> yeah... I must have beat you to it :)
<bradley> ok, nevermind, it's there
<bradley> lol
<IntuitiveNipple> Can you add your script workaround instructions to help others and the developers zero in on it, please?
<IntuitiveNipple> I've recently been doing a lot of work with snd-hda-intel and ACPI, so I was pretty sure it isn't an ACPI issue. I suspect it'll turn out to be an alsa issue when someone who knows about that side of things looks at it.
<bdmurray> IntuitiveNipple: I think the Xorg bug is a bit hasty
<bdmurray> Couldn't it be gnome or a component of it?
#ubuntu-kernel 2007-08-02
<bradley> IN: thanks for all the help on getting this bug rolling.  I guess I also curious for a more in depth explanation of your reasoning purely for education
<IntuitiveNipple> From what I've read of the upstream kernel.org bug report, they initially (back in 2006) thought it was ACPI but then narrowed it down to the X server, then got confused as lots of other similar reports were attached to the bug, and finally marked it as "insufficient data"
<IntuitiveNipple> It'd be good to run a debug kernel on that PC, see what else it reveals
<bradley> maybe this isn't important, but when you said you read a post on Fedora forums..I was playing with fedora7 when it came out and didn't have this problem
<bradley> Suse, when I played with it for a week or so didn't show this issue either.
<bdmurray> bradley: How do you normally shutdown the system?
<bradley> normally i shut it down graphically....click the icon that brings up log out, restart, shutdown, suspend, hibernate, etc, and then click shut down
<bdmurray> bradley: without logging out though?  It might also be interesting to see what happens if you log out and then shutdown.
<IntuitiveNipple> bradley: Can you add the PC's ACPI DSDT to the bug, just in case, with "sudo acpidump -t DSDT > DSDT.aml; tar -cjvf DSDT.aml.tar.bz2"
<IntuitiveNipple> bradley: If you need to install acpidump: "sudo apt-get install acpidump"
<bradley> lol its "cowardly refusing to create en empty archive
<IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
<IntuitiveNipple> bradley: you may need to separate the commands I gave you into separate lines :)
<bradley> i tried that as well
<Nafallo> sudo -i and then the commands.
<bradley> same error
<Nafallo> sudo can't > things
<IntuitiveNipple> acpidump, is it creating a DSDT.aml ?
<bradley> fanafallo: i know that much :)
<IntuitiveNipple> Nafallo: it can, and did, I tested it here first
<bradley> yeah, it created the aml
<Nafallo> when did it learn that? :-)
<zul> evening
<IntuitiveNipple> bradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml"
<bradley> ok, that worked, ill attach it
<IntuitiveNipple> (it does help to specify *what* is being put in the tar) lol *slaps self*
<IntuitiveNipple> I was doing some suspend/resume hacking of snd_hda_intel a few weeks ago so that module source-code is still fresh in my mind
<IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
<bradley> im using the latest gutsy kernel
<bradley> against all warnings i know, but it's stable for me
<bradley> bdmurray: before i applied the workaround no shut down worked for me, from desktop, loginscreen or otherwise, after i applied the work around, everything works
<IntuitiveNipple> bradley: ok, that makes it easier for me then, I'll just build a debug-version from the git
<IntuitiveNipple> bradley: Do you think you could clear  /var/log/kern.log then do a single startup/shutdown procedure (without the workaround script, so it fails to shutdown), and then attach that kern.log to the bug report?
<bradley> yeah, can i disable the script through sysctlrc...that's not the right name, but its something like that
<bradley> the program that allows me to see and edit what's running on which runlevels
<bradley> otherwise ill just delete the scripts and remake them
<IntuitiveNipple> bradley: You mean update-rc.d ?
<bradley> yeah, i think thats what i meant, but im retarded sometimes.  ill just comment out the line that removes snd_hda_intel
<bradley> that should make things not work again, and its much easier to put back to working
<IntuitiveNipple> yeah :)
<bradley> alright, i'll give it a go
* lamont` notes that suspend/hibernate are broken on his laptop with -8 and -9
<lamont`> (compaq nw840)
<lamont`> (compaq nw8440, even)
<bradley> IN: ok, added the kern.log
<IntuitiveNipple> bradley: I've just skimmed the DSDT for anything obvious, but nothing that stands out.
<bradley> what does that imply?
<IntuitiveNipple> There's nothing in the way of obvious ACPI DSDT faults apparent
<IntuitiveNipple> This kern.log, it only has a boot-up sequence in it. I think the file we need is kern.log.0 - can you check?
<bradley> sure, brb
<bradley> ok, the kern.log.0 isn't cooperating with me.  i cleared it out and did a reboot etc, but now it's not filling wiht messages
<IntuitiveNipple> bradley: ahh... maybe some confusion... kern.log is the logfile the system writes to, but when it 'backs-up' it moves it to kern.log.0
<IntuitiveNipple> The kern.log you uploaded appears to have been generated during the start *after* the failed shutdown, so I guessed the log we wanted would be kern.log.0
<bradley> that makes sense...hmmmm, ok, let me look around some more
<IntuitiveNipple> Maybe do another start/shutdown sequence with a freshly cleared kern.log, and then check what you've got in both files when you restart
<bradley> ok
<IntuitiveNipple> bradley: hang on a minute....
<IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
<IntuitiveNipple> oops!
<IntuitiveNipple> ha, you ran off before I could finish what I was saying!
<bradley> ok a did a clean, shutdown, start, shutdown, start sequence.  kern.log.0 is still empty. kern.log _seems_ to have start, shutdown and start in it
<bradley> unless im mistaken
<IntuitiveNipple> I had just typed...
<IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
<bradley> sorry, this bug hunting has me all fired up
<IntuitiveNipple> but you went! I'm used to loads of output for suspend/resume - I just assumed shutdown was as prolific! The only shutdown logging I can find is in syslog and its brief to the point of useless
<bradley> yeah, now that you say it, kern.log IS all startup
<IntuitiveNipple> there's all but nothing in any of the logs, except for 'tty exiting' messages
<bradley> well thats disappointing
<bradley> though i have to think signifcant progress now be made on this bug
<IntuitiveNipple> I'm just digging to see if we can make it more talkative
<bradley> by all means, i really appreciate you taking time out to help me with this.
<IntuitiveNipple> According to the (convoluted) documentation, we use "sudo sysctl -w variable=value" to control the log-level of klogd, but when I do "sysctl -a" to report all the possible names I can't find a variable that sets the log-level!
<mjg59> There isn't one
<mjg59> All kernel output will be logged
<mjg59> All you can change is whether stuff hits the console or not
<IntuitiveNipple> Really? another case of the docs not matching reality! I saw "-c" but that is no good
<IntuitiveNipple> Is there a way, without kernel recompiling, to increase the logging during shutdown?
<mjg59> Any output from the kernel will be logged until klogd is stopped or the filesystem unmounted
<mjg59> If you want more output, then you need to add more output to the kernel
<IntuitiveNipple> I thought there was logging of driver-unloading etc., but there's almost nothing 
<mjg59> We don't unload drivers
<IntuitiveNipple> Well, stop them then
<mjg59> That's after the root filesystem has been unmounted
<IntuitiveNipple> ahhh
<IntuitiveNipple> small round spherical objects
<mjg59> You can edit /etc/default/halt
<mjg59> And set it to "halt" rather than "poweroff"
<mjg59> Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops
<IntuitiveNipple> The issue was to look for any messages during shutdown for bradley's Toshiba, which needs snd_hda_intel unloaded in order to shutdown cleanly, and it seems to be an X issue, since shutdown is fine if gdm is stopped first.
<IntuitiveNipple> anyway, aren't you supposed to be on vacation?!
<mjg59> Yes
<IntuitiveNipple> can't keep away?
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.21 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
<infinity> BenC: Kernel fix didn't happen, I guess?
<kraut> moin
<amitk_> kraut: did you find a solution to your problem?
<kraut> amitk_: not really, i know that it is fixed in 2.6.22. that's why i'll now tryout the gutsy-kernel.
<kraut> amitk_: i didn't found the exactly problem, because there were many changes in nfs-client between 2.6.20 and 2.6.22 :/
<amitk_> true
<kraut> amitk_: do you maintain the ubuntu-kernel?
<amitk_> kraut: Not really, I am just a member of the kernel team.
<kraut> amitk_: the question is, how long does it take. when i fill in a bug-report, until it is fixed in the feisty-kernel.
<kraut> i've also mailed an emploeyee of netapp concerning this, but still waiting on an answer.
<kraut> perhaps he could tell me the problem and wich fix is missing in the feisty-kernel.
<amitk_> kraut: possibly. So I take it that it's not possible for you to migrate to the Gutsy kernel (in a few weeks after it stabiliizes)
<bullgard4> In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for?
<mjg59> It's a programming language
<mjg59> It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler
<infinity> It really needs a "Phew, we made it!" in there.
<infinity> Every time a PC manages to boot past real mode, I think it's a minor miracle.
<bullgard4> Ok. Thank you.
<kraut> amitk_: not really, i need the new one for an urgent project :/
<kraut> anyone tried out the gutsy-kernel on a x86_64 system?
<kraut> it won't boot without any usefull message before it will scan the scsi-bus.
<kraut> there is a problem concerning a lsi-logic controller :/
<kraut> is it possible to change the magic key to something else then "print screen"?
<kraut> lsi-logic is broken in 2.6.22 :/
<BenC> infinity, doko: 9.22 being uploaded with fix for lpia build
<infinity> Good timing, we were just talking about you behind your back.
<infinity> BenC: Is your link fast enough to get it up before cron.daily?
<doko> just talking =)
<BenC> infinity: it's already done
<infinity> Awesome.
<BenC> we have a .orig.tar.gz now, so it's just a ~3Meg upload
<infinity> Ahh, cool.
<infinity> Shows how long it's been since I did a kernel upload. :)
<zul> oh goody my wife is up
<zul> BenC: ping there is a request to sync rt2400 source from debian should we even bother?
<BenC> zul: nope
<BenC> reject it as Invalid
<zul> BenC: thanks
* lamont kicks self, builds -9.21hppa1 to verify that the bad abi file was the only thing wrong
<infinity> Bah, where did Ben go?
<lamont> hrm... and -9.22 is in the archive.  sigh
<infinity> lamont: Don't worry, there's another upload required ASAP. :P
<infinity> lamont: (broken on lpia, which was the whole point for this upload)
<lamont> heh
<lamont> I expect my change will fix hppa finally (mailed kernel-team ml, etc)
<lamont> mind you, testing that will take several hours...
<lamont> where several is between 2 and 4
<lamont> closer to 2, it appears.. (abicheck of 2nd-and-final kernel failed at 1:55:23)
<lamont> so just including it should be fine.
<lamont> (it won't be any _more_ broken than what's in -9.22) :-)
* lamont crashes the -9.22 build attempt on hppa
<lamont> infinity: at any rate, I'll be afk for a bit, feel free to help my patch get from my git tree into the real one.
* lamont even used the right template this time.
<infinity> lamont: Not sure how much I can do on that front, short of bribing people with hookers and beer.
<infinity> And I'm starting to run out of hookers.
<lamont> good bribes
<lamont> heh.  it's more of a "since you have to turn this for me, pls include lamont's latest. kthxbye"
* netjoined: irc.freenode.net -> kubrick.freenode.net
<lamont> and afk
<doko> infinity: it fails again for the udebs after fixing the linux-libc-dev header
<infinity> doko: Ugh.
* lamont returns, waves
<kylem> doko, i can debootstrap a lpia chroot now?
<kylem> doko, how does it fail?
<doko> kylem: yes, see my email to distro
<doko> you just need http://people.ubuntu.com/~doko/tmp/linux-libc-dev_2.6.22-9.22_lpia.deb for now
<doko> for dev things
<doko> make: *** [binary-udebs]  Error 1
<doko> kylem: ^^^
<kylem> dude.
<kylem> not terribly helpful, that.
<infinity> doko: You may have noticed some text on your terminal slightly before that error.. :P
<doko> dilist=$(dh_listpackages -s | grep "\-di$") && \
<doko>         for i in $dilist; do \
<doko>           dh_fixperms -p$i; \
<doko>           dh_gencontrol -p$i; \
<doko>           dh_builddeb -p$i; \
<doko>         done
<doko> dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)
<doko> [...]  repeated 100 times
<doko> make: *** [binary-udebs]  Error 1
<infinity> Still running the old dpkg, I see...
<kylem> indeed
<doko> kylem: better? looks like no udebs are produced, so just copying the config from i386 would be fine (I assume)
<infinity> Though, in this case, it's helpful to point out that dpkg-architecture is being run a crapload of times. :)
<doko> grep "\-di$" looks suspicious, missing architecture
<infinity> dh_listpackages limits to the current arch, I assume.
<infinity> Yeah.
<infinity> That's precisely what it does, in fact.
<kylem> doko, yes. d-i is completely absent.
<doko>         dilist=$$(dh_listpackages -s | grep "\-di$$") && \
<doko>         [ -z "$dilist" ]  || \
<doko>         for i in $$dilist; do \
<doko> ok, that works.
<doko> kyle: how do I correctly increment the version number? just for producing a correct debdiff
<kylem> debian/rules startnewrelease
<doko> kylem: if you can commit this, and maybe prepare a new upload, tested that it works on lpia  http://people.ubuntu.com/~doko/tmp/linux-source-2.6.22.debdiff
<kylem> 17:06:22 < kylem> doko, yes. d-i is completely absent.
<kylem> the correct fix would be to add d-i...
<doko> kylem: that can be done later, we just need linux-libc-dev for now
<infinity> kylem: Yeah, the lack of d-i was intentional at this point.  BenC asked if I wanted udebs, I said "maybe later, don't care for now".
<kylem> er, ok.
<kylem> ... it's like a two line addition though...
<infinity> (Who knows if we'll ever even build lpia installation media)
<kylem> alright. fine.
<infinity> Oh, if it's easy and guaranteed to work, just do it, then.
<doko> kylem: as you like it, I can test build it here
<infinity> Won't hurt to have 'em, just in case.
<doko> infinity: it would be nice to have installer and/or live cd's just to offer something for testing
<kylem> i'm hoping there are proper sdvs when these cpus become available...
* lamont reads KernelGitGuide, wonders why the top section doesn't say 'git fetch origin; git rebase origin' under "preserve local changes"
<zul> its in there somewhere :)
<zul> oh i hate cvs
<zul> hey BenC 
<lamont> zul: the rebase option is at the bottom under 'if you have access to kernel.u.c', not up at the top for others...
<bullgard4> What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log?
<mjg59> It's the portion of the driver suspend called after interrupts are disabled
<lamont> mjg59: btw, remember how putting the gutsy kernel on my laptop made suspend work?  well, it doesn't now...
<bullgard4> mjg59: Thank you very much for explaining.
<lamont> somewhere between -5 and -8, -9 also b0rked
<lamont> mjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that?
<mjg59> lamont: git bisect is probably the easiest
<kylem> lamont, go to www.united.com, book a flight to heathrow, underground to kings cross, national rail to cambridge.
<mjg59> Except you probably can't, because the kernels are rebased
<mjg59> Which means the git history bears no resemblance to the release history
<lamont> mjg59: any chance you have a compaq mumble8440?
<mjg59> lamont: Nope
<mjg59> I've a 6220, but that's previous generation
<lamont> yeah
<lamont> and smaller.
<mjg59> Per-generation, the hardware is pretty similar
<lamont> mjg59: bisect could still work for me, although it may be fun to get from the eventually-found commit to the actual commit... :-)
* lamont wonders if maybe using the SD card reader plays into it..
<lamont> or if there were any bits that needed to be blacklisted/whatever to get it to work
<mjg59> lamont: If it previously worked, then bisect is probably as good as you're going to get
<lamont> ye
<lamont> p
<mjg59> You're just going to have to be handwavy in finding the last "good" kernel
<lamont> yeah
<mjg59> If we didn't rebase the tree, this would be a lot easier
<lamont> why do we rebase the tree again?
<lamont> I could see starting a new branch off upstream each time we release, and then merging all our stuff onto that new branch, that'd give us all kinds of good history...
<mjg59> Ben finds it easier
<mjg59> Whereas I find having to pull into a branch and then merge that murder inducing
<kylem> lamont, the commit you want pulled is not in your tree.
<lamont> hrmpf.
<lamont> heh
<lamont> pushing
<lamont> pushed
<mjg59> BenC: Could we not rebase the tree repeatedly? It makes it *much* harder to figure out whether regressions are due to our code or to upstream
<kylem> it won't be rebased anymore now that 2.6.22 is out.
<mjg59> kylem: Not even to 2.6.22.1?
<mjg59> (Or other parts of the stable branch)
<zul> have we actually pulled in 2.6.22.1?
<makx> in debian yes :)
<zul> nerver mine I answered my own question
<zul> ergh
<BenC> mjg59: it was pretty easy for me to test that by testing with stock 2.6.22 and with our 2.6.22
<BenC> mjg59: in fact, I would argue that it's easier to see if it's us or upstream, considering we are rebased on top of stable 2.6.22 instead of intermixed with it
<BenC> s/stable/stock/
<mjg59> BenC: But we don't ship a stock 2.6.22
<mjg59> What users know is "-5 worked, -7 doesn't"
<mjg59> That's easy to map back to a tree that matches the development history, but very difficult to map to a rebased tree
<lamont> mjg59: keithp says that one should never use 'git pull', instead one should use 'git fetch' and an appropriate merge
<BenC> true, but even mapping it back to proper history wont help much, considering the amount of upstream kernel changes mixed with our uploads
<BenC> actually, you can get decent history just looking at the changelog
<kylem> keith is just being difficult, pull is just a fetch+merge.
<lamont> BenC: creating a 2.6.22-9.23 _branch_ at the time of upload would preserve history for us
<lamont> kylem: yeah, but he finds  that the merge is seldom the one he really wanted
<mjg59> BenC: Given that the number of bisect jumps you need to do is log2 of the number of commits, it's not really a problem
<BenC> lamont: well, it's pointless now since we wont be rebasing anymore
<lamont> BenC: for the future, I meant
<mjg59> lamont: That doesn't actually solve the problem in any case :)
<BenC> lamont: good point, we can definitely do that
<kylem> we have a branch, since we have a tag.
<BenC> lamont: tags wont work?
<lamont> mjg59: it renders it more-solvable, I expect
<BenC> right, you can do "git-branch Ubuntu-2.6.22-9.23 Ubuntu-2.6.22-9.23"
<lamont> would a tag add a reference to the un-rebased commits?
<mjg59> lamont: The tree refers to a different history to the one in my local repository
<mjg59> BenC: Tags won't work across a rebase in any meaningful way
<mjg59> lamont: So it's impossible to pull/fetch/whatever
<lamont> hrm.
<BenC> mjg59: but if you're bisecting, then you are building kernels for the user or yourself and you can easily testing stock 2.6.22 vs ubuntu-2.6.22 :)
<kylem> Subject: Accepted linux-source-2.6.22 2.6.22-9.24 (source)
<BenC> kylem: I never uploaded -9.23
<mjg59> BenC: You continue to have issues. It may be an interaction between a new upstream patch and one of ours. 
<BenC> just so you know :)
<kylem> BenC, hence it's still unreleased
<mjg59> If a user has a good and a bad commit already (by virtue of knowing which package versions worked), that's going to make the bisect much easier
* lamont goes to appointments
<kylem> blef.
<BenC> mjg59: if v2.6.22 works and HEAD doesn't, you can easily rebase between those two points
<kylem> coffee.
<mjg59> BenC: ?
<BenC> mjg59: true, you miss the super rare case where an upstream commit during devel actually interacts bad with one of our patches
<BenC> s/rebase/bisect/
<mjg59> Well, yes, you can do that
<mjg59> But it's not actually going to be significantly faster
<BenC> it's not going to be slower either :)
<amitk_> lamont: you might be suffering from bug #129226, perhaps?
<mjg59> But, as you said, it misses one entire class of problem
<amitk_> bug# 129226 even
<amitk_> damn.. i can never quite figure out how to trigger the bot
<BenC> mjg59: one extremely rare class, as I've never experienced it before :)
<mjg59> BenC: I've hit it a couple of times.
<BenC> amitk_: it's missing from this channel
<BenC> mjg59: either way you do it, it doesn't give you full info
<mjg59> ACPI is hard. Shopping time.
<mjg59> BenC: Sure it does. One way actually reflects the history that we've published, and the other doesn't.
<BenC> mjg59: without rebase, you wont know which patch of ours is interacting badly, and with rebase, you wont know which patch from upstream is the cause
<BenC> mjg59: you still miss the info to know which patch of ours is interacting with a commit from upstream...unless I'm missing some detail
<mjg59> I mean, in addition to it being a nightmare to remember to fetch into a branch and then use that as origin
<mjg59> error: no such remote ref refs/heads/origin.old
<mjg59> Ngh.
<doko> \o/ 2.6.22-9.24
<doko> infinity: wake up call ;-)
<kylem> hopefully it builds on more than one flavour of amd64. ;-)
<Nafallo> hmm.
<Nafallo> sata_nv busted?
<Nafallo> since like... feisty?
<BenC> Nafallo: worked on my one system, even in feisty
<Nafallo> BenC: are you aware if there are any bugs with sata_nv hangs? 
<Nafallo> starts with: [  438.240000]  irq 7: nobody cared (try booting with the "irqpoll" option)
<mjg59> Nafallo: Does /proc/interrupts claim that sata_nv is bound to irq 7?
<kylem> ah crap, i'm a muppet. forgot to -mv the abi files to 9.23
<Nafallo>   7:       9820     264076    XT-PIC-XT        libata
<mjg59> Ok, that's a good start
<mjg59> So for some reason, sata_nv doesn't believe that the interrupt was its
<Nafallo> I got libata on 5,7,10,11
* Nafallo makes a pastebin with the full errormessage
<Nafallo> http://paste.ubuntu-nl.org/32273/ <-- mjg59 
<Nafallo> I haven't really cared about the statement up until now that my two raptors arrived :-P
<mjg59> Nafallo: The rest of dmesg would help
<Nafallo> http://home.nafallo.info/bugs/sata_nv.txt
<Nafallo> mjg59: feisty running now. same error on the gutsy tribe-3 server iso
<mjg59> What's kind of weird is that you don't seem to have anything on the ports connected to irq 7
<mjg59> So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug
<mjg59> amitk_: Why not just fudge the USB autosuspend code so it only triggers on mass storage and HID class devices?
<Nafallo> I think sdf and sdg are on IRQ7, cause those drives died after the error.
<Nafallo> also I'm booting with noapic for a reason :-)
<mjg59> No, they're on irq 10
<mjg59> Why are you booting with noapic?
<mjg59> It's quite possible that the board irq routing has never been tested with xtpic
<amitk_> mjg59: to keep in sync with upstream. Oliver Neukum pushed a similar patch to GregKH's tree
<mjg59> amitk_: But it's likely that there's more devices that are broken
<Nafallo> mjg59: the kernel refuse to start telling me to boot with that option :-)
<mjg59> And I'm sceptical that autosuspend of most USB devices is actually useful
<mjg59> Nafallo: Well, attempting to debug that would be helpful
<mjg59> Right now you're passing an option that has a reasonable chance of breaking things in exactly the way you're seeing
<Nafallo> mjg59: I'll boot with the debug command next time I restart then. will need to keep the server up until the weekend now though :-)
<Nafallo> mjg59: aha. how... evil.
<Nafallo> mjg59: so right now it is boot || sata then? ;-)
<mjg59> So I suspect there's no problem with sata_nv
<amitk_> mjg59: I agree. It's more than likely there are more devices. But how can we be sure that this affects only scanner-type devices?
<Nafallo> hmm. oki :-)
<mjg59> amitk_: For reference, the only devices Windows suspends are hid, bluetooth and serial
<mjg59> (http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx)
<Nafallo> mjg59: do you think there would be a difference if I move the cables from ports 1 and 2 to ports 3 and 4
<Nafallo> ?
<Nafallo> maybe someone on IRQ7 starts caring then :-P
<mjg59> Nafallo: Could work, but it would be preferable to actually debug it
<amitk_> interesting... mjg59, thanks for the link. I will work on a patch and talk to Alan
<Nafallo> mjg59: agreed :-)
<mjg59> amitk_: So I strongly suspect that pretty much everything outside those classes has never been tested with autosuspend, and if it works it's more by accident than by luck :)
<amitk_> i would agree. I would also suspect that everything out of these classes are not connected to laptops very often
<mjg59> Well, other than mass storage
<mjg59> But if that's connected it's probably mounted (and therefore in use)
<mjg59> amitk_: If you could cc me on the patch, that would be great
<amitk_> mjg59: sure
<amitk_> mjg59: Just had a thought: would disabling autosuspend be something that should be relegated to userspace? After all there is a sysfs entry to do so.
<mjg59> amitk_: It could be, but in that case why have a blacklist in-kernel at all?
<mjg59> I think it would make more sense to have a userspace whitelist rather than a "Break my hardware by default" kernel option
<mjg59> Given that all we get out of it is a small amount of power saving
<amitk_> mjg59: I haven't followed usb-devel, but I would suspect this blacklist is a knee-jerk reaction to solve immediate problems and keep users happy
<mjg59> amitk_: I suspect we'll keep users somewhat happier if they don't have to keep sending patches to upstream (either kernel or hal) to make their hardware work :)
#ubuntu-kernel 2007-08-03
<Toroman> hi!  I have an usb wifi dongle (usr805422), when i try to boot up ubuntu with my usr805422, I receive host system error and I cant use my dongle until next reboot....   it only works when i boot up my ubuntu without usb dongle and wait to load desktop manager and ndiswrapper :(    http://pastebin.com/me5a7918   here is more inf. please help me
<defcon> belkin ralink rt73 wifi dongle causes a kernel panic when I plug it in
<defcon> Toroman, same problem here, kernel panic my caps/scroll lock blink
<defcon> everything worked fine in feisty
<Toroman> with usr805422 no kernel panic problem but only my usb host dies :D
<Toroman> i try my dongle with other distros such as pardus, no problem occured...
<JanC> many ralink drivers heave issues with multiprocessing
<JanC> so if you have a multi-core/multithreading CPU...
<Toroman> I'v very very single and old core :D
<JanC> so then there is another issue...  ;)
<Toroman> i try this dongle with 3 different computers but they all deliver same error
<mjg59> amitk_: http://www.codon.org.uk/~mjg59/tmp/usb_autosuspend
<Toroman> I have to unplug my dongle and boot my comp wait  ndiswrapper loads then plug my dongle
<defcon> ikm having an issue with gutsy and the 2.6.22-9 kernel, when I plug in my belkins usb wifi dongle I get an instant kernel panic
<lamont`> defcon: neato.  what exactly is the panic?>
<defcon> how do I debug this and properly report it
<\x6e\x65\x72\x64> Hi, I'm trying to compile a dapper kernel on a feisty machine, because the feisty machine is faster, but I'm getting some errors, do I have to make any special changes for this to work?
<defcon> it instantly freezes my box and blinks caps lock/scroll lock
<defcon> lamont, I have tried -rt and it doesnt panic but I am unable to modprobe the module rt73.ko from serialmonkey, and cannot use the supplied drivers with ubuntu
<defcon> 2.6.22-9-386 got the same issue
<lamont`> defcon: and the actual panic message is????
<lamont`> ah - it freezes the machine, rather than panicing... got it
<defcon> i didnt write it down, should there be a log of it
<defcon> apon boot it does the same
<lamont`> given that panic doesn't trust anything, it tends to only record the info on the console....
<defcon> wont boot when initializing interfaces
<lamont`> that makes sense
<defcon> capslock/scroll lock blink
<defcon> what does that mean
<lamont`> OTOH, without knowing what the panic message was, life sucks.  If there's no panic message, then life gets more interesting for tracking things down
<lamont`> defcon: dunno what the blinking stuff means
<mjg59> Blinking means that the kernel has oopsed
<defcon> ok so I'll reinstall the kernel and try again supplying u with an error message, I only get it during recovery mode
<lamont`> mjg59: cool.  I'll remember that
<defcon> am i in the right place for this to be resolved? 
<lamont`> defcon: I'm close to running out the door for home, and will be gone for at least an hour at that point.  I'll read scrollback when I get there.
<lamont`> defcon: either here, or (better yet), all the detail you can provide, into a bug filed in launchpad
<defcon> lamont, ok
<lamont`> that way it gets some tracking.
<lamont`> and actually, this is the right channel to be discussing your fix for the bug, to make sure that it's implemented correctly, etc.  rather than a support channel....
<lamont`> likewise, discussions on figuring out how to best debug the problem are on topic.
<lamont`> "fix my bug please, kthxbye" would be off topic. :-)
<lamont`> at least, that's how i read things...
<defcon> cool
<defcon> I appreciate it lamont 
<defcon> i'll work on this
<defcon> dling/installing the kernel now
<defcon> going to reboot now and write this down
<defcon> bbl
<defcon_> lamont,  lamont` gotta type this out now
<defcon_> [39.928296]  kobject_add failed for :d-0000008 with -EEXIST dont try to register things with the same name in the same directory
<defcon_> [39.928660]  Kernel Panic - not syncing Creation of kmalloc slab kmalloc_dma-2 size=2 failed
<defcon_> where can I post this on launchpad
<mjg59> Sounds like a bug in p54
<mjg59> defcon_: There should be several other lines as well
<defcon_> keep in mind this is a belkins F5D7050 USB wifi card
<defcon_> if that matters
<defcon_> new bug https://bugs.launchpad.net/ubuntu/+bug/130078
<mjg59> defcon_: We need the rest of the message
<defcon_> thats where it froze
<defcon_> it didnt give any more
<mjg59> defcon_: What are the lines before that?
<defcon_> I dont remember, let me try and think, it all looked normal
<defcon_> something about b**** doesnt have a config file, I know its an app for security policies
<defcon_> but I didnt enable it
<defcon_> I know
<defcon_> bastille does not have a configuration file
<defcon_> thats it
<defcon_> I did not set anything for bastille, so it shouldnt effect anything I dont think
<defcon_> I just removed bastille
<bullgard4> kern.log prints: "pnp: Failed to activate device 00:06." How can I determine what '00:06' stands for?
<johanbr> lspci
<mjg59> No
<bullgard4> johanbr: My lspci -vv outputs in the format xxxx:yy:zz.z. How does this format map to the pnp format aa::bb?
<bullgard4> aa:bb
<mjg59> It doesn't
<johanbr> x=a and y=b, I think.
<kylem> no.
<kylem> god.
<mjg59> That output isn't from the pci system
<kylem> bullgard4, install pnputils and run lspnp.
<johanbr> Oh... sorry for spreading misinformation.
<bullgard4> kylem: lspnp prints: "00:06 PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support)." --  Thank you very much.
<kylem> bullgard4, no problemo.
<lamont> EE: Missing modules (start begging for mercy)
* lamont crys
<lamont> kylem: so are we already committed to -9.26?
<kylem> pardon?
<lamont> hppa64.modules was also incorrect.
<lamont> mind you, I'm happy just pushing -9.25hppa1 for the moment, in my archive
<lamont> as long as we make sure things get right in -9.26 when it does hit...
<kylem> i have a few patches i want in tribe4, but they're likely abi-breaking, so i'll have to schedule them with Ben.
* lamont has pushed the good modules file to lamont/hppa-ia64.git, will just drop -9.25hppa1 in the hppa archive for now.
<lamont> build takes a couple hours, so we'll know in the morning if it's any good.
<kylem> if it's just a simple patch, please just post it to kernel-team (instead of asking for a pull for just a single commit)
<lamont> I'll post the diff, although it's basically a "replace hppa64.modules with the good one"
<kylem> ok.
<lamont> I wonder... if it's -9.25hppa1 do I want it to be abi/2.6.22-9.25 or abi/2.6.22-9.24?
<lamont> 25
<defcon_> lamont, https://bugs.launchpad.net/ubuntu/+bug/130078
<lamont> defcon_: and what did it say _before_ those two lines?
<lamont> full context is kinda important...
<defcon_> before it said that it said cannot load bastille config, I never configured it so I dont believe thats a problem
<defcon_> I had to write down then type that out whats on there hehe
<defcon_> before that it said loading network interfaces
<defcon_> and thats it
<defcon_> brb
<lamont> ok
<defcon_> lamont, is there a way to get the log without writing it all down
<defcon_> or a script or something to log it all
<lamont> defcon_: personally, I tend to use a camera
<defcon_> hehe
<lamont> serial consoles are also kinda cool
<defcon_> i could enable bootlogd
<defcon_> ./etc/default/bootlogd
<defcon_> im suprised it is disabled by default
<lamont> kylem: fwiw, the diff is 5kb, 500 lines, all of it hppa64.modules
<lamont> short enough to just email to the list
<lamont> once the build succeeds
<infinity> s/once/if/
<infinity> Although I have every confidence in your test building process, LaMont. :P
<defcon_> brb reboot
<lamont> infinity: heh./
<lamont> the only oddity is that it's test-building -9.25hppa1 instead of -9.26
<lamont> it's doing hppa64/modules build right now... I wish it'd hurry up
<lamont> hrm.. should be OTOO 40 minutes
<defcon> I see bootlogd is disabled, and broken
<defcon> any other app to log the boot seq so I can get a kernel log of it Panicing
<defcon> I dont have a digital camera to snap it
<defcon> new kernel update still bombs when it see's my belkin usb dongle
<defcon> will a kern.log help with a kernel panic
* Starting logfile irclogs/ubuntu-kernel.log
<Nafallo> mjg59: http://paste.ubuntu-nl.org/32346/ <-- that's what I could save from the serial window booting with apic=debug
<Nafallo> mjg59: http://home.nafallo.info/bugs/sata_nv_take2.txt <-- and that's with the drives at ports 3 and 4.
* Nafallo adds more to the last URL as he sees it one the console
<mjg59> Nafallo: Does acpi_use_timer_override work?
<Nafallo> mjg59: instead of noacpi?
<Nafallo> apic even
<mjg59> Yes
<Nafallo> we shall see. brb.
<Nafallo> http://paste.ubuntu-nl.org/32360/
<Nafallo> http://paste.ubuntu-nl.org/32361/
<Nafallo> the first one without apic=debug
<Nafallo> http://home.nafallo.info/bugs/sata_nv_take3.txt
<Nafallo> mjg59: any ideas? :-)
<Nafallo> putting current gutsy -server on there should work, right?
<Nafallo> well, that didn't work... :-P
<mjg59> Wow. Your hardware is impressively broken.
<Nafallo> ASA M2N-E
<Nafallo> ASUS even
<Nafallo> mjg59: so. what can I do? :-)
<mjg59> Get a new motherboard?
<Nafallo> ouch
<mjg59> Hm. apic=debug doesn't seem to have helped much.
<Nafallo> indeed it didn't :-/
<mjg59> There ought to have been a dump of the apic mappings
<Nafallo> can I force it to do that on the running system or somethiing? :-)
<mjg59> Oh, wait, I see the output now
<Nafallo> mjg59: I found logcheck have nice logs. do you want all the latest reboots? ;-)
<mjg59> No, I don't think that would really help
<Nafallo> ehrm. I think you might want to see this one... what's you mailaddress?
<Nafallo> ah, no. seems the .txt on the server has the info.
<mjg59> Nafallo: It, uh, seems to have the same problem?
<Nafallo> they all have :-P
<Nafallo> hmm. a friend told me to remove the disabling code from spurious.c :-P
<mjg59> Nafallo: So why would I want to look at that one especially?
<mjg59> I suspect your machine just has wrong IRQ routing for the noapic case
<mjg59> You could try pci=noacpi
<mjg59> But it would be more interesting to fix the actual bug (the fact that it doesn't seem willing to boot with the apic)
<mjg59> Have you tried the 64-bit version?
<Nafallo> I agree. but what more can I do to nail down the cause?
<Nafallo> yes. when I removed all drives except the raptors and installed gutsy tribe-3 x86_64 server
<ivoks> mjg59: (sorry for distraction) could you take a look at bug 119130 when you have time; it has a solution, so it should be an easy one...
<mjg59> Nafallo: And?
<Nafallo> mjg59: same thing.
<mjg59> Nafallo: Which same thing?
<Nafallo> the irq 7: nobody cared thing
<mjg59> Nafallo: And without noapic?
<Nafallo> and had to boot with noapic
<mjg59> ivoks: I don't really have time to deal with acpi-support right now
<mjg59> With the same failure message?
<Nafallo> yes.
<Nafallo> dapper worked though :-)
<ivoks> mjg59: ok
<Nafallo> with noapic...
<Nafallo> so "worked"
<Nafallo> atleast I didn't get the irq7 on 2.6.15 :-)
<BenC> Anyone else have a Turion x2 laptop that they are running or have tried to run gutsy on?
<BenC> rtg: I'm going to start a new thread on lkml about this problem...it's pretty serious regression for us
<rtg> BenC: There are several LP reports that I think are related.
<BenC> rtg: any pointers?
<rtg> I'll see if I can round 'em up.
<lamont> BenC: btw, more hppa tweaks for .26 :-(
* ..[topic/#ubuntu-kernel:lamont] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.25 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/
<BenC> rtg: Cc'd you
<lamont> imagelist=$(cat kernel-versions | grep ^hppa | awk '{print $4}') && \
<lamont>         for i in $imagelist; do \
<lamont>           dpkg -x $(ls ../linux-image-$i\_*hppa.deb) \
<lamont>                 debian/d-i-hppa; \
<lamont>         done
<lamont> dpkg-deb: --extract takes at most two arguments (.deb and directory)
* lamont grumbles about that code dying when there are downrev versions of linux-image-$foo in the parent directory
* Nafallo ponder how he'll fix this problem for now.
<BenC> Nafallo: override the PCI slot IRQ's in the BIOS?
<BenC> Nafallo: in a lot of cases, the "irqX and nobody care" is a symptom of a broken BIOS, so check for an update on that as well
<Nafallo> BenC: thanks :-)
<Nafallo> a slightly more expensive solution is PCI-E 3ware RAID1 ;-)
<Nafallo> but I'll check this one out first :-)
<Nafallo> I should have PNPOS installed in BIOS, right? :-)
<BenC> should, yes
<Nafallo> well, I'll look soon enough then.
<Nafallo> need to put VGA in the box again :-P
<Nafallo> hmm. beta bios? ;-)
<Nafallo> http://support.asus.com/download/download.aspx?SLanguage=en-us&model=M2N-E <-- /me is confused
<abogani> BenC: Could you enable linux-image-debug build for rt? Thanks.
<BenC> abogani: can't, the custom-binary builds don't support that
<abogani> BenC: Uh, sorry!
<BenC> kylem: Do you have a Turion laptop?
<kylem> nope.
<kylem> i only have one amd box these days.
<mjg59> BenC: There's a discussion about missing timer interrupts on mobile AMDs on lkml right now
<BenC> mjg59: ah, that's exactly what I need, thanks
<BenC> mjg59: subject?
<mjg59>  ACPI on Averatec 2370
<mjg59> nolapic_timer ought to work if it's the same issue
<kylem> Regarding the issue described above that Frank and I are having, I've
<kylem> narrowed it down to commit e9e2cdb4[1] : [PATCH]  clockevents: i386 drivers
<kylem> heh, must be the same problem.
<BenC> mjg59: It didn't work for me
<BenC> kylem: same commit that Tim and I came up with
<BenC> so three of us separately bisected to the same one
<kylem> check out the message from Linus there.
<BenC> yeah, I'm about to test that
<BenC> kylem: data point, x86_64 kernel boots fine for me
<kylem> BenC, it would, it uses completely different code.
<BenC> another reason to merge i386/x86_64 :/
<mjg59> Andi insists on maintaining different timer code because, erm, well.
<kylem> BenC, well, x86_64 hasn't got the new time code yet, because it's still buggy. (clearly. :)
<amitk_> mjg59: Patch looks good. Can you send it with a sign-off?
<mjg59> amitk_: Didn't it have one?
<mjg59> amitk_: Oh - I tried to mail you, but amitk@u.c doesn't work
<mjg59> It's on lkml and usb-dev
<kylem> mjg59, it's just amit@
<amitk_> mjg59: thanks
<BenC> rebooting to test the amd broken timer thing
<BenC> sweet, it worked
<kylem> yeah, i figured it would. the probelm seems to be with nohz, you can't turn off the lapic timer
<BenC> I wonder if "nolapic nohz=on" would work
<BenC> err nohz=off
<BenC> kylem: do you think forcing "return 1" is a good work around for us to use?
<BenC> in production I mean
<BenC> kylem: does a broken lapic timer mean that kernel disabled nohz?
<kylem> i say we add the proper define in now (test the cpuid) and reevaluate the decision after before -rc?
<kylem> a lot of testing should happen for beta, so we can see if the issue reoccurs now that we know what to do...
<BenC> kylem: you sounds like you're on top of this...can you get a patch in, and a new kernel today (or before Monday)?
<kylem> BenC, er, well, need info from you or tim first.
<BenC> let me know what you need and I can get it
<kylem>  (b) make that function print out the values it uses for debugging (ie the
<kylem>      xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR
<BenC> I assume cpuid
<kylem>      values)?
<kylem> right.
<BenC> ok
<Nafallo> BenC, mjg59: I think the damn upgrade fixed it.
<Nafallo> BIOS
<mjg59> Nafallo: Hurrah. Does it work without noapic now?
<Nafallo> mjg59: I think so. I'll check my commandline :-)
<Nafallo> [   64.748254]  Kernel command line: root=/dev/md1 ro console=tty0 console=ttyS0,38400n8 break=premount
<Nafallo> :-D
<mjg59> Excellent.
<Nafallo> too easy :-P
<Nafallo> why didn't I think about this before? :-)
<rtg> BenC or mjg59: Am I smoking crack on this one: https://bugs.launchpad.net/ubuntu/+bug/129477 ? What does a Synaptics touchpad do under windows that these guys expect?
<mjg59> rtg: It's a new-model ALPS pad. The kernel doesn't recognise it.
<rtg> mjg59: So PS/2 emulation is the best we can expect w/Feisty, right?
<mjg59> With Feisty, yes
<rtg> mjg59: Thanks.
<mjg59> rtg: In PS/2 emulation mode it only reports relative motion. In native mode it gives absolute coordinates which give the synaptics userspace driver the ability to implement additional functionality (like scrolling)
<rtg> I guess I've never used a touchpad like taht.
<mjg59> Basically everything (other than very old stuff and bleeding-edge alps) works like that in Linux
<Nafallo> http://home.nafallo.info/bugs/sata_nv.txt btw :-)
<Nafallo> I can't see anything weird :-)
<mjg59> Yeah, looks fine
<mjg59> Note how stuff is all on different interrupts now
<gnomefreak> we are tptally against putting 2.6.23 in multiverse right?
<gnomefreak> totally even
<mjg59> Do you mean universe?
<gnomefreak> yeah sorry
<mjg59> And I suspect the answer is yes
<gnomefreak> someone asked this this morning im getting around to it now
<zul> i am against it
<gnomefreak> once gutsy stable we cant really touch it
<infinity> We've had newer kernels in universe before, and it was a complete disaster.
<infinity> So, yeah, we're pretty firmly against repeating that fiasco.
<mjg59> Oh, yes, I'd forgotten that
<mjg59> 2.6.11, wasn't it?
<mjg59> Back in Hoary
<infinity> Yeah.
* mjg59 shudders
<rtg> mjg59: I'm about to instrument a Feisty kernel to extract the Dell 1420 ALPS touchpad E7 report. Is there an easier way? Do you think simply adding alps_model_info will enable the scroll bars?
<mjg59> rtg: The issue came up on lkml - simply adding the device to the table didn't seem to work, so I suspect the protocol has changed slightly
<rtg> mjg59: drat.
#ubuntu-kernel 2007-08-04
<defcon> chuck short here?
<defcon> he replied to my posted kernel bug https://bugs.launchpad.net/ubuntu/+bug/130078 and he requested a full "oops" is oops the output of the error or the whole boot log, btw bootlogd and logd isnt working, its not logging my boot process
<tampafl> evening all
<tampafl> I am looking for my kernel src code.  I guess in /usr/src... but I have script that says, " Kernel source from "/lib/modules/2.6.20-16-generic/build" will be used to build the module.
<infinity> apt-get install linux-headers-`uname -r`
<infinity> I'm assuming you just need the headers here, if it's just to compile something against your running kernel.
<tampafl> thanks you ;) ;)
<tampafl> said everytrhing  up to date, 0 done
<infinity> Err, then you have the headers installed.  You win.
<tampafl> make -C /lib/modules/2.6.20-16-generic/build SUBDIRS=/home/bob/vpnclient modules
<tampafl> make[1] : Entering directory `/usr/src/linux-headers-2.6.20-16-generic'
<tampafl>   CC [M]   /home/bob/vpnclient/linuxcniapi.o
<infinity> (note that /lib/modules/2.6.20-16-generic/build is a symlink to /usr/src/linux-headers-2.6.20-16-generic)
<tampafl> hummm
<tampafl> any ideas for the first make error?
<mjg59> tampafl: You haven't pasted an error yet...
<infinity> Yeah, I'm not seeing any errors.
<lamont> mkdir -p debian/d-i-hppa
<lamont> imagelist=$(cat kernel-versions | grep ^hppa | awk '{print $4}') && \
<lamont>         for i in $imagelist; do \
<lamont>           dpkg -x $(ls ../linux-image-$i\_*hppa.deb) \
<lamont>                 debian/d-i-hppa; \
<lamont>         done
<lamont> dpkg-deb: --extract takes at most two arguments (.deb and directory)
* lamont wishes that the kernel build process wasn't sensitive to old debs lying around in the parent directory
* lamont kisses another 2 hours good bye, requeues the build
<mjg59> rtg: There's a (apparently) working patch for alps
<rtg> mjg59: Where?
<mjg59> rtg: I've attached a link to the bug
<rtg> mjg59: Thanks.
<rtg> mjg59: Is Vostro the model of the ALPS touchpad?
<mjg59> No, it's a range of Dell laptops
<rtg> Its not a term I've heard from Dell.
<mjg59> http://www.dell.com/content/products/category.aspx/vostronb?c=us&cs=04&l=en&s=bsd
<rtg> mjg59: Huh. Marketing stuff. All I ever deal with are the engineers and they use different terminology.
<rtg> mjg59: I'll post a test kernel in the LP report later today (if it works).
<Nafallo> is atheros working those days? :-)
<Nafallo> AR5005G to be exact :-)
<BenC> Nafallo: should be
<Nafallo> nice. I just ordered a cheapas laptop to have until I can afford a better one :-)
<Nafallo> has all sorts of weird hardware in it :-/
<lamont> BenC: I won't say my tree is ready to be synced yet...  In somewhere around an hour I expect that I will say that...
<lamont> BenC: and it would be nice if the extraction mess above had the kernel deb version in the expansion for dpkg -x, so that it quits bitching when there is cruft above
<BenC> lamont: we don't expect cruft in a build, but I guess it makes sense :)
<lamont> it's cruft in the parent directory, though... :-)
<lamont> and yeah.  hence the "it'd be nice" instead of a patch.. :)
<BenC> I should "rm -f ../*.deb" in the clean target :)
<lamont> that'd get you a bug report, for certain. :-)
<BenC> hehe
<login_> hi guys. any of you know how to enable 1000Hz while compiling kernel?
<kylem> eh?
<kylem> make menuconfig -> processor type -> timer frequency
<lamont> morning kylem 
<movi> kylem -> no_Hz
<mjg59> movi: So?
<mjg59> It's a point, though - I don't think there's any real downside to 1000Hz on a dyntick system
<lamont> find: debian/nic-usb-modules-2.6.22-9-hppa64-di: No such file or directory
<lamont> nic-usb-modules-2.6.22-9-hppa64-di will be empty
<lamont> make: *** [binary-udebs]  Error 1
<lamont> is it trivial to tell the build to not expect that directory?
<lamont> for just one kernel image on one arch?
<BenC> mjg59: if that were true, wouldn't they disable that option when NOHZ is enabled?
<mjg59> BenC: It still has an influence
<mjg59> The most likely poor influence would be a slight drop in throughput
<mjg59> But there's none of the power-related issues
<BenC> what's the gain then?
<mjg59> Reduced latency
<lamont> timer granularity, polled-event granularity
<mjg59> The same reason the -rt people have always wanted CONFIG_1000HZ
<BenC> might be worth it for -generic then
<lamont> we use 1000 on the telco stuff HP ships
* lamont wanders
#ubuntu-kernel 2007-08-05
<lamont> Built successfully
<lamont> Purging chroot-gutsy-stage0/build/buildd/linux-source-2.6.22-2.6.22
* lamont sends the patch to kernel-team
<doko_> http://robilad.livejournal.com/16780.html?thread=23692#t23692
<mjg59> I suspect that the generic ATA driver would drive it in the short term
<Nafallo> mjg59: I bought an Acer today
* Nafallo hides
<Nafallo> :-P
<mjg59> I know plenty of masochists
<Nafallo> lol
<mjg59> So I won't hold it against you
<Nafallo> I got it damn cheap, so will be replaced in tops three months or so :-)
<Nafallo> I'd guess even Acer Aspire would be better then nothing at all :-)
<bullgard4> How can I obtain acpiexec from http://developer.intel.com/technology/iapc/acpi/downloads.htm?
<mjg59> Which acpiexec utility?
<bullgard4> That one which Thomas Renninger mentioned in his HowTo "How to debug ACPI problems" in the Mailing list linux-acpi@vger.kernel.org
<mjg59> Oh, right. Have you downloaded the acpica sources?
<bullgard4> Half a year ago I downloaded iasl but apparently not all acpica sources. Where should I store acpica-unix-20061109.tar.gz on my Ubuntu 7.04?
<mjg59> Wherever you want to
<mjg59> Your home directory if you want to keep it, /tmp if not
<bullgard4> I have found a directory 'acpiexec' containing aecommon.h, aeexec.c, aemain.c, Makefile, osunidir.c but no executable file acpiexec
<mjg59> You'll need to build it
<mjg59> (If you're not sure how to do that, I'm afraid this really isn't the right place to ask)
#ubuntu-kernel 2008-07-28
<sven-tek> Hi! Ubuntu's kernel config has disabled force feedback drivers (CONFIG_HID_FF is not set). Is there a reason for this? I'd like to use this feature.
<BenC> emgent: not a kernel bug...and I've never used it so can't really comment on it
<emgent> BenC: package is the same, but have problem with the last kernel.. (thinking to wireless card driver)
<BenC> emgent: it's probably because the wireless api changed and that package needs to be updated
<afflux> Hi. There is a number of people suffering from a regression introduced in the 2.6.24 kernel, where the RTL8111/8168B network chipset does not work at all. The bug is fixed with the intrepid kernel. It's bug 221499
<smb_tp> afflux, do you own a card like this?
<afflux> no, a friend does.
<smb_tp> afflux, I just scanned over the issue, so this might be inaccurate
<smb_tp> afflux, I noticed something about interrupt 220
<smb_tp> afflux, I saw such high numbers when msi was used 
<smb_tp> afflux, maybe it would help to try pci=nomsi as a test
<afflux> oh okay, I'll give it a try
<afflux> thanks for the hint
<smb_tp> afflux, I would appreciate to know whether that changed anything
<afflux> smb_tp_: it seems to work with pci=nomsi
<smb_tp_> afflux, ok, great. that give me some place to start
<afflux> okay. I'll post that to the report for the record.
<smb_tp_> afflux, ok, had posted that option, but feedback for the record is good. I'll dig for a solution
<afflux> great, thanks
#ubuntu-kernel 2008-07-29
<poningru> anyone around?
<poningru> I had a quick question
<poningru> I wanted to package up a module
<poningru> but the module is included in lrm by default
<poningru> the only difference is I want to update the module as it includes a driver sorely needed for a particular community
<poningru> aspire one community needs the latest madwifi
<poningru> so what should I do? package up the atheros seperately?
<tseliot> ï»¿poningru: you can use DKMS for the package
<poningru> or update lrm?
<poningru> oh hmm
<poningru> looking into it more
<tseliot> ï»¿poningru: with DKMS there would be no conflict with the version in the lrm
<poningru> ah awesome
<poningru> that is exactly what I am looking for
<tseliot> and you would only have to keep the linux-headers installed (and the compiler) so that the kernel module is rebuilt every time the kernel is updated
<poningru> any official ubuntu packaging guides for dkms?
<poningru> that is exactly what I was looking for
 * tseliot looks for an easy example
<tseliot> maybe the dvb driver is easy enough: https://launchpad.net/~pitti/+archive
<tseliot> and of course: sudo apt-get install dkms
<tseliot> man dkms
<poningru> ah hmm
<poningru> danke
<poningru> hmm quick question
<poningru> tseliot, does the dkms require it to be installed in the to be installed computer?
<poningru> oh nvm
<poningru> this seems a little wrong
<poningru> too easy
<AlmightyCthulhu> latest email from Foxconn, more motherboard models affected, BIOS patch is top priority
<AlmightyCthulhu> so far we're up to Foxconn, ASUS, MSI, and Intel
<AlmightyCthulhu> especially G31, G33, G35, and P33 and P35 based boards
<AlmightyCthulhu> all have AMI BIOS
<stgraber> BenC: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222 <-- Any idea why dsdt-in-initrd doesn't work ?
<BenC> stgraber: because the patch wasn't there until -4, IIRC
<BenC> stgraber: wait, just got down to the end of the bug report...
<BenC> stgraber: I'll check on it later today
<stgraber> cool, thanks
<poningru> question any reason why madwifi drivers are in /lib/kernel_vers/madwifi instead of /lib/kernel_vers/kernel/drivers/net/wireless ?
<poningru> rather what was the reasoning behind that?
<tormod> rtg, hi I think the patch for bug #245026 is now ready for you.
<tormod> rtg, and thanks for committing that Hauppauge WinTV thing for Hardy!
<mkrufky> what Hauppauge WinTV thing?!?
<mkrufky> tormod: ^
<tormod> mkrufky: support for the cheapo Nova-T CE / SE cards, bug #238164
<mkrufky> ah, ok... thats already in 2.6.26, i believe, so no worries
<mkrufky> oh!  actually... i heard complaints about that one not being supported in some other distros (asus eee)
<mkrufky> tormod: sorry for being nosey -- i work for Hauppauge now, and i just wanted to make sure it wasnt a patch missing from upstream ... thanks :-)
<tormod> mkrufky: interesting :) it's in 2.6.26 since March I think
<mkrufky> January
<tormod> mkrufky: and if I had knew the needed patch was so small, I would have pushed for it earlier...
<tormod> s/had //
<mkrufky> :-) no worries... if i realized it was missing from 2.6.24 i would have pushed it to stable
<mkrufky> but now its too late
<mkrufky> no problem
<tormod> mkrufky: since you for them, I must say the card works very nicely. and it's cheap.
<tormod> *you work for them
<mkrufky> ya
<mkrufky> i wasnt involved in that one... but i appreciate the positive feedback :-D
<tormod> mkrufky: I guess you are into v4l-dvb ?
<mkrufky> yup
<mkrufky> thats where Hauppauge found me :-D
<tormod> do you know why the card/driver doesn't work in Norway? they use another encoding there h264(?) and I wonder if just a little patch is needed?
<mkrufky> brb 
<tormod> mkrufky: http://linuxtv.org/pipermail/linux-dvb/2007-October/020851.html
<mkrufky> tormod: that is not related to the product / driver
<mkrufky> tormod: if the user has an app that can decode h264, then said user will not have a problem with the stick
<tormod> it's in v4l general?
<mkrufky> this has nothing to do with v4l
<mkrufky> DVB is a glorified network adapter
<mkrufky> a DVB device receives a transport stream and provides it to userspace
<tormod> only the viewer? I tried "scan" but it would not list it.
<mkrufky> userspace decodes that stream and plays it
<tormod> I tried me-tv. Is it in me-tv or gstreamer or ??
<tormod> what is there between v4l and "scan"?
<mkrufky> me-tv uses xinelib
<mkrufky> v4l is video4linux, a api and kernel subsystem that deals with analog video, and has absolutely nothing to do with digital television
<mkrufky> (me-tv uses xinelib, *not* gstreamer)
<poningru> tormod, try dumping the stream and then try out various decoding stuff using mplayer or vlc
<poningru> EGret1029W{}|A5867NOomV
<tormod> mkrufky: I guess I meant v4l-dvb and not v4l...
<tormod> poningru: can not, I am not in Norway...
<mkrufky> tormod: im sorry... are you asking me something?
<tormod> mkrufky: my question is, what has to be fixed? xinelib?
<mkrufky> tormod: what is the problem?
<mkrufky> h264?
<mkrufky> tormod: try it in mplayer, it might work there
<mkrufky> oh... h264 sucks in linux
<mkrufky> you need an extremely powerful system if you want a chance of smooth playback
<mkrufky> ...or a graphics chipset that has hardware decoding support available in linux
<mkrufky> h264 hardware decoding support
<mkrufky> ... when you find that graphics chipset, please let me know -- i'll buy one for myself
<tormod> sounds like it's getting a lot more expensive than just buying that dvb-t dongle :)
<mkrufky> if you record them on your PC, you can play them back on a PS3
<mkrufky> not much else i can say
<mkrufky> i live in ATSC-land
<tormod> is h264 so more resource-hungry, or it just that the linux support is not worked on?
<poningru> tormod, both
<poningru> search for drm/dri implementations under X
<mkrufky> nah, there is linux support available
<poningru> mkrufky, there is?
<mkrufky> i dont think the distros have taken the latest ffmpeg stuff yet
<poningru> hardware support?
<mkrufky> hardware, nah
<mkrufky> i know Nvidia has h264 decode support in the 8600 and later models
<mkrufky> but no support in the drivers, afaik
<poningru> iirc intel also has it but no support in the drivers
<poningru> 965 and up
<poningru> but what I cant wait for is dirac support in hardware
<poningru> that is going to be awesome
<tormod> dvb-t works nice with my old laptop here in Switzerland (mp4 I guess), I just feel sorry for those in Norway (and other h264 places)
<poningru> meh less bandwidth usage
<DB42> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/114312 | more specificly: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/114312/comments/47 <-- can anybody help ?
#ubuntu-kernel 2008-07-30
<sn9> is the lack of master mode in nearly all of hardy's mac80211-based drivers a limitation of those drivers individually, or of the version of mac80211 used in the hardy kernel?
<wcr2007>  hi, everyone. Is the kernel option CONFIG_M686=y compatiable with AMD Phenom 8450? Thanks
<sn9> phenom should use a x86_64
<wcr2007> I failed to install 32bit ubuntu(8.04 desktop) on AMD phenom 8450 CPU. I have turned acpi and apic off. Can anyone has such expericnce tell me how to? Is there any kernel options to turn on or off? Or the kernel is not compatiable with AMD64?Thanks a lot.
<wcr2007> I donot want to use 64 bit on my PC.
<sn9> i put a 32bit distro on a phenom 8650
<sn9> don't turn anything off
<wcr2007> whera can I get it?
<sn9> get what?
<wcr2007> The distro you put
<wcr2007> sn9: you just install it as a normal one?
<sn9> yes
<sn9> is the lack of master mode in nearly all of hardy's mac80211-based drivers a limitation of those drivers individually, or of the version of mac80211 used in the hardy kernel?
<MementoMori> hi all
<MementoMori> I'm having problem building a source using ipc_perm struct
<MementoMori> in particular seems like ipc_perm struct hasnt a member named key
<MementoMori> which is an error: ipc_perm at include/linux/ipc.h has the key member
<MementoMori> icp_perm declared in /usr/include/bits/ipc.h is diffent from the one present in /usr/include/linux/ipc.h
<sn9> is the lack of master mode in nearly all of hardy's mac80211-based drivers a limitation of those drivers individually, or of the version of mac80211 used in the hardy kernel?
<sn9> anybody?
<mkrufky> sn9: do you find different behavior in the vanilla 2.6.26 kernel?
<mkrufky> oops
<sn9> 2.6.26 has a different mac80211 ABI
<mkrufky> i meant the vanilla 2.6.24 kernel
<sn9> i have not compared the mac80211 in vanilla .24
<mkrufky> if you compare it, there will be your answer
<sn9> how so?
<mkrufky> if they're the same, then you know its not hardy-specific
<sn9> i was not asking about hardy vs. not hardy, but of the version used in hardy, regardless of where else it may be used
<mkrufky> so, you're question is about the mac80211 in the 2.6.24 kernel .... not necessarily in relation to hardy
<sn9> as it's used in hardy, yes, if hardy's mac80211 is vanilla, which i doubt
<Kano> hi, current interpid git does not compile, ist has errros in osl.c, is that known?
<zul> yes
<Kano> well i am waiting ;)
<Kano> i want to test a patch
<Kano> http://lkml.org/lkml/2008/7/24/286
<Kano> because the kernel shuts down some laptops
<sn9> any chance intrepid could still be re-slated for 2.6.27?
<Kano> hmm there is a next branch
<amitk> sn9: Intrepid probably won't get 2.6.27 unless Linus announces one next week :)
<amitk> but as pointed out there is now a -next tree
<sn9> amitk: .27 is already way past -rc1
<amitk> sn9: it takes an average of 3-4 months to shake things out, that is well past our freeze date
<sn9> i think the average will not mean much in this case
<sn9> -rc2 may even happen this week
<amitk> I am guessing .27 won't be out before Sept, but if it does come out I am sure we would be willing to review.
<SSD> are they adding ext4 in intrepid?
<sn9> i am not so sure .27 will take that long
<SSD> for intrepid?
<sn9> SSD: watch for BTRFS in intrepid+1
<SSD> thats not even in the kernel
<Nafallo> hmm
<Nafallo> anything known in kernel world about hardy not being able to speak multicast?
<Nafallo> over vlan interfaces I should add.
<Nafallo> possibly subinterfaces in total. eth0.xxx in my case.
<sn9> kylem: are you subscribed to debbugs #429734 ?
#ubuntu-kernel 2008-07-31
<Rocket2DMn> mjg59, are you available?
<Rocket2DMn> mjg59, I am forums staff, in contact with saaya RE: Foxconn.  s/he is asking about getting in contact with kernel developers either with Ubuntu or further up about opening lines of communication.  Please ping me when you get this, much appreciated.
<sn9> kylem: are you subscribed to debbugs #429734 ?
<Rocket2DMn> mjg59, if you can PM on the forums when you get my messages, I would much appreciate it, otherwise I will try to contact you again tomorrow - http://ubuntuforums.org/member.php?u=310232 - thanks
<doko> rtg, BenC: please could you apply the patch for #230315? the guy is a bit vocale, but the current behaviour is annoying anyway
<rtg> doko: I'll look at it.
<doko> thanks
<Kano> hi BenC , when do you fix the intrepid source - as it does not build
<Kano> hi rtg , could you fix compiling of the intrepid sources?
<rtg> Kano: probably not today., but BenC is around.
<Kano> well he does not say anything, i askes yesterday too ;)
<rtg> Kano: we've been traveling
<Kano> will try tomorrow, hopefully it compiles then
<Rocket2DMn> mjg59, I don't know if you got my messages last night RE: Foxconn.  I was told this morning by Mike Basinger that you no longer work on Ubuntu.  I responded to saaya (Sascha Krohn) about getting in contact with linux/Ubuntu devs and said to email the kernel team mailing list so that you all could point in the right direction
<Rocket2DMn> I said you would probably want to send those guys upstream to work directly with linux kernel devs but I wasn't entirely sure
<mjg59> Rocket2DMn: I'm in touch with the UK technical guy at Foxconn
<Rocket2DMn> mjg59, OK.  Is there anything you would like me to tell Sascha other than what I have already said?
<mjg59> I don't think so, no
<Rocket2DMn> i can message you his email address
<mjg59> Just let him know that I'm working with Chuck
<mjg59> s/Chuck/Carl/
<Rocket2DMn> alright, Carl it is
<Rocket2DMn> back to the forums for me, thanks for helping with this whole Foxconn mess mjg59 
#ubuntu-kernel 2008-08-01
<ajonat> hmm I've got some merge conclicts after pulling from ubuntu-intrepid git: http://pastebin.ubuntu.com/32875/.. is this ok?
<TheMuso> ./c
<abogani> ./c ?
<TheMuso> abogani: typo
<abogani> ah ok
<sn9> yes, should be ./d :)
<abogani> What mean ./d? :-?
#ubuntu-kernel 2008-08-02
<Kano> hi BenC , rtg , would you like to merge 2.6.26.1 (then you could drop my uvcvideo patch)
<Kano> basically only the position and comment is differnt
<mermaidman> I ask that the kernel devs include ext4
<mermaidman> its not that hard to tick the option in the kernel config
<sn9> not that hard to use dkms, either
<mermaidman> all other major dists have ext4
#ubuntu-kernel 2008-08-03
<pwnguin> mermaidman: thats nice, but from wikipedia: The file system is currently marked as developmental and is titled "ext4dev".[5] It is considered unstable and so is not recommended for use in production environments, since data corruption is possible in this early stage of development."
<pwnguin> im kinda thinking anyone interested in ext4 outta learn how to build kernels anyways
<mermaidman> pwnguin: Umm you have to add some special test_fs code to ext3 in order to mount ext4 which the ubuntu devs dont understand
<pwnguin> mermaidman: when you say "dont understand"
<pwnguin> is there specific evidence?
<mermaidman> they never respond to all my suggestions
<pwnguin> im not sure those are equivilent
<pwnguin> where can i read these suggestions?
<mermaidman> forums
<pwnguin> oh well duh
<pwnguin> you'd get more attention from IRC or the mailing list
<mermaidman> http://ubuntuforums.org/showthread.php?t=837589
<mermaidman> went there to still no answer
<pwnguin> on -kernel?
<mermaidman> yup
<pwnguin> gotta grab dinner
<pwnguin> but i'll check the archive
<pwnguin> john nelson?
<mermaidman> yeah
<pwnguin> We need to talk about effective writing 
<mermaidman> i was in a rush that day
<pwnguin> https://lists.ubuntu.com/archives/kernel-team/2008-July/002793.html
<pwnguin> well, then the little time you did spend was wasted =/
<mermaidman> Since i have all the time of the night I will write another one right now
<pwnguin> if you communicate intelligently, you may find people are more willing to talk with you
<pwnguin> but I believe there's also some structural bias
<pwnguin> from what ive seen many in the kernel team are paid canonical employees who work 9-5
<mermaidman> just sent it its in the moderation queue now
<pwnguin> being the weekend, there's probably a bit less attention to go around, if you know what i mean
<mermaidman> Yeah
<pwnguin> well pizza time
<mermaidman> cool
<pwnguin> you know what, if ted doesn't think it's ready, i don't think we should bother enabling it
<mermaidman> ted Tso?
<pwnguin> yes
<mermaidman> finally finshed the annoying fsck on ext3
<benje> hi there a bug in the se401 driver i get this [ 3335.080589] se401: probe of 3-1:1.0 failed with error -5
<benje>  with a kensington webcam Bus 003 Device 004: ID 047d:5001 Kensington 
<benje> under hardy 
<sn9> benje: you're sure it's not bug 88746?
<sn9> !bug 88746
<sn9> where's ubottu?
<benje> i go to see i just searching there
<benje> shure sn9 it's about ehci but it using usb 3-1: new full speed USB device using uhci_hcd and address 4
<sn9> any hub involved?
<benje> since a long time this webcam not working 
<benje> no directly on face pc (dell 1800)
<sn9> ok...
<benje> it was working a day
<benje> do you want full dmesg ?
<benje> sn9, http://pastebin.com/m3d7c3f1e
<sn9> 404
<benje> sn9, :/
<benje> this is working for me 
<benje> sn9, do you have an other paste 
<benje> prefered 
<sn9> i probably won't learn anything from it, anyway
<benje> yes nothing particular 
<benje> detect w"ebcam firware format 
<benje> but [ 3335.080563] /build/buildd/linux-2.6.24/drivers/media/video/se401.c: Bayer format not supported!
<benje> the light at webcam stay lighting
<benje> sn9, what is it need for post bug about this ? i have even post bug 
<sn9> have you looked at upstream info about the driver?
<benje> but what will be usefull
<benje> there a patch for version http://members.chello.nl/~j.vreeken/se401/
<benje> but only for epcam
<benje> it's now in kernel tree
<benje> no sn9 
<sn9> do you know whether this works in later kernels?
<benje> sn9, here http://cateee.net/lkddb/web-lkddb/USB_SE401.html .
<benje> no i don't know 
<benje> this was working in dapper and edgy at start
<benje> at bigining
<benje> begining
<benje> but she is in all list as working :/
<benje> http://lxr.linux.no/linux/Documentation/video4linux/se401.txt
<sn9> so, it's a regression?
<benje> yes 
<benje> it 's avery old webcam doesn't work in xp 
<benje> ;)
<benje> no driver but it always working under linux
<benje> sn9, where can i find upstream of ubuntu ? 
<sn9> if the driver is in the mainline kernel tree, the upstream is often the mainline kernel itself, unless patches are applied
<sn9> ubuntu maintains local kernel trees for each version on kernel.org, too
<benje> ok
<benje> i haven't try with an other distrib 
<benje> i try under debian etch 
<sn9> under debian, you may need to use module-assistant
<benje> same error
<benje> :/
<benje> not needed ;) 
<benje> thanks sn9 
<benje> sn9, do you know what is the problem ? 
<benje> or seems 
<sn9> it sounds like the upstream driver might be broken
<benje> ok thanks sn9 i will post bug or do you think it s not necessary 
<sn9> search for existing bug reports first
<benje> i found nothing about se401 and kensington webcam
<sn9> no se401 bugs at all? file it, then
<benje> no, oki 
<benje> no now i discution with friend but i will ;)
<benje> thanks and bye 
<DHR> I reported this problem a few days ago.  IOCTL interface to MTRRs appears broken in 8.04.1.  Thoughts?  https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
<pwnguin> who moderates mail to ubuntu-kernel?
<sn9> it should say at the bottom of the listinfo page for that list
<BenC> pwnguin: rtg does
<BenC> DHR: looking at it now
<pwnguin> ok thanks; a guy came by yesterday asking about ext4 and he said it was waiting moderation approval
<pwnguin> probably it'll be taken care of on monday
<pwnguin> a bit unfortunate for our weekend hackers
<DHR> BenC: thanks!
<BenC> DHR: it seems to be specific to the system, so the fact that it works on fedora9 is misleading
<DHR> BenC: in what sense is it specific?
<BenC> DHR: on my laptop, it prints all of them, but on my 8-way Core2 box, it only prints the first two
<BenC> and they are running the exact same kernel
<DHR> OK.
<BenC> my laptop has 4 registers enabled, and it prints all 4...the workstation has 3 registers and it only prints the first 2
<DHR> There seem to be some problems with MTRRs on Intel systems with >4G.  
<BenC> Nope
<BenC> neither of these has > 4G
<DHR> Sorry: not *this* problem, but it is the reason I care about MTRRs.
<BenC> Ah
<DHR> Some BIOSes set MTRRs with overlapping ranges.  X drivers cannot then change their frame buffer to Write Combining.
<DHR> So: I wanted to write a C program to eliminate overlapping ranges.
<BenC> isn't that something you can do in your BIOS?
<DHR> There is a kernel patch to do this.  I'm trying to understand the code (right now).  I'm not convinced it is great code.
<DHR> No, I cannot write a new BIOS easily :-)
<BenC> No, I mean you can set it in your BIOS config :P
<DHR> no.  Not normally.  The usual work-around is to remove memory!
<DHR> You can also hack away with echos to /proc/mtrr.  I thought ioctl interface would be cleaner.  But it is broken, I think.
<DHR> kernel patch as discussed on LKML: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/1/1686464
<DHR> example of the problems caused by overlapping MTRRs: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404
<DHR> BenC: since you have observed to problem with the ioctl interface too, could you add to https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
<BenC> DHR: ...
<BenC>                 /* Hide entries that go above 4GB */
<BenC>                 if (gentry.base + size - 1 >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT))
<BenC>                     || size >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT)))
<BenC>                         gentry.base = gentry.size = gentry.type = 0;
<BenC> that's from the MTRRIOC_GET_ENTRY code in the kernel
<DHR> interesting!
<BenC> So it has nothing to do with > 4G of memory, just mapped to > 4G
<DHR> what file is that in?
<BenC> and sure enough, but 3rd entry on the workstation is mapped at 4G
<BenC> arch/x86/kernel/cpu/mtrr/if.c
<BenC> s/but/my/
<DHR> Why would that be the correct thing to do?  Especialy on amd64 (which I'm on)?
<mjg59> What's the size of the field in the structure that the address gets returned in?
<BenC> mjg59: ah, it's unsigned int
<DHR> "unsigned int size"
<BenC> that's pretty stupid
<mjg59> Yeah, so ABI concerns
<BenC> well, that still shouldn't be a problem...the base is unsigned long, so it should still be able to print up to 4G size
<mjg59> Probably best to add a new ioctl...
<mjg59> (nngh ioctls)
<BenC> yeah, best to just shove it in /sys somewhere and add something to X to use that
<DHR> if you look at /usr/include/asm/mtrr.h, i386 differs from amd64.  So no excuse.
<BenC> ioctl's are just ugly anyway, I don't blame them for not fixing it by now
<BenC> plus they are working on something better for X to use, so focus is probably there
<DHR>  /proc is ugly too: race conditions and all.
<mjg59> You probably want to be using PAT on newer systems anyway
<BenC> right, PAT is what I was thinking of
<DHR> if the IOCTL cannot return the correct value, it ought to return an error.
<DHR> EOVERFLOW       Value too large to be stored in data type (POSIX.1) ??
<DHR> ERANGE          Result too large (POSIX.1, C99) ??
<DHR> is a size >= 4G legal on i386?  It could well be, given PAE.
#ubuntu-kernel 2009-07-27
<cwillu> okay, so it looks like some recent xorg changes have fixed up the intel immediate crashing on resume from suspend, so now I can actually sensibly bug people about my delayed slow-crash after resume-from-suspend that I've had from early 2.6.30rc's through to present 2.6.31rc4
<cwillu> now if only I could remember who I was talking to about that :p
<cwillu> apw, I think that might have been you
<cwillu> apw, yep, that was you:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380807
<ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] 
<cwillu> apw, the other bug that was confounding things is fixed and closed, so it might be a little easier to get something done now :p
<jjohansen> cwillu: with this bug does your filesystem still require the fsck after reboot using reisub?
<cwillu> jjohansen, you know, I can't remember.  The last couple times I just rebooted and came back a minute or two later
<jjohansen> cwiilu: if so, is it possible to test with an alternate fs, say ext3
<cwillu> was thinking about that
<cwillu> s/was thinking/was just thinking/
<cwillu> looks like I've got enough room on my backup disk to take an image and reinstall fresh
<jjohansen> cwillu: that would be really helpful
<cwillu> okay, so I'm going to just do an rsync, recreate an ext3 filesystem and rsync back (so, not actually a fresh install)
<cwillu> is that still useful?
<cwillu> I could do a complete reinstall and just restore /home, but that'll be more... annoying, than I'd like
<jjohansen> yeah the rsync to ext3 is useful
<cwillu> k, waiting for the backup to finish... will probably take a little while as it hasn't been home for the nightly backup in a couple weeks
 * cwillu looks around
<cwillu> what, doesn't everyone do an automatic nightly backup? :p
<jjohansen> basically with reisub not working (ie. having fsck) the first place I would look is the fs layer
<jjohansen> cwillu: I think most people around here use rsync, though I have played with simple backup config and it is easy and not too bad
<cwillu> dtchen, also, I remember poking you about some pulseaudio instability and drop-outs, which was blamed on a bad driver.  Indeed, 2.6.31 on this machine (different from the laptop I'm talking about to jjohansen) hasn't had any audio issues that I've noticed.
<apw> cwillu, heh sounds good
<lesshaste> the touchpad on my toshiba tecra a9 fails intermittently and I see this in dmesg psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
<lesshaste> http://bugzilla.kernel.org/show_bug.cgi?id=12577 appears to fix my problem
<ubot3> bugzilla.kernel.org bug 12577 in Input Devices "DualPoint TouchPad at isa0060/serio1/input0 lost sync" [Normal,New] 
<apw> lesshaste, is there an ubuntu bug for that one?
<lesshaste> apw, yes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/365968
<ubot3> Malone bug 365968 in xserver-xorg-input-synaptics "touchpad randomly failing" [Undecided,New] 
<lesshaste> actually there seem to be a few
<lesshaste> lots of people are reporting something similar
<lesshaste> I emailed the kernel mailing list too
<apw> no wonder we have not seen it, its not got a linux task, nor does it have a link to the upstream bug
<lesshaste> apw, that's bad... in general the triaging of kernel related bugs on launchpad is really weak
<apw> we do our best given our team is small, we can only triage those bugs marked for the kernel after all
<apw> normally the x group is pretty good at triaging those and pushing them to linux for us
<apw> this one sounds like its fallen through the holes.
<apw> i've done the admin on it so at least we can see it
<lesshaste> thanks
<lesshaste> and yes the problem is that they are not even marked for the kernel usually
<lesshaste> so the problem happens before you :)
<lesshaste> I should say that it's a pretty fatal bug
<lesshaste> I have to reboot to recover
<apw> lesshaste, so you can trigger this?
<lesshaste> apw, actually I don't know how to trigger it but it happens after I use X for a bit
<lesshaste> every day I would say
<apw> ok
<apw> lesshaste, what arch you using i386 or amd64
<lesshaste> i385
<lesshaste> err.. i386
<lesshaste> apw, although this is slightly OT, some teams don't seem to exist at all.. I had a grub bug that I fixed myself but no one from the grub team ever contributed to it as far as I can see
<lesshaste> is there anyone on that team?
<apw> there is probabally no specific team for grub.  foundations tend to care as its a critical package, we care as it impacts us directly as in interfaces directly with us
<apw> though i would say we are concentrating on grub2 this cycle
<lesshaste> that was the fix in fact
<apw> move to grub2?
<lesshaste> https://bugs.launchpad.net/bugs/389930
<ubot3> Malone bug 389930 in grub "grub menu does not display after cold boot on Toshiba laptops" [Low,Confirmed] 
<lesshaste> apw, yep
<lesshaste> scott howard was very friendly but I don't feel this was his expertise
<apw> noone upon noone really wants to work on grub, upstream has moved on to grub2 and so should we
<lesshaste> apw, ok.. does anyone want to work on grub2?
<apw> we are taking an interest in it from a bug point of view, not planning any dev for it here
<apw> as a distro we are blazing a trail being one of the first mainstream distros to jump
<lesshaste> apw, :) yes
<ibrar> Can Any body tell me how to set ALL_PATCH_DIR
<ibrar> I am compiling kernel using "fakeroot make-kpkg --initrd --append-to-version=-my --added-patches equal.patch   kernel-image kernel-headers"
<ibrar> and always getting error 
<ibrar> debian/ruleset/misc/patches.mk:108: *** Could not find patch for equal.patch.  Stop.
<ibrar> ?
<apw> ibrar, can't say i've ever used it sorry
<apw> lesshaste, ok am pushing some packages with that 9-byte format patch applied, will update the bug when they are up
<ibrar> apw: I have made changes to kernel! I only want to incremental build that 
<ibrar> apw: Can you guide me how 
<apw> i generally build using either in a ppa, or using the direct build interfaces myself
<ibrar> apw: this fakeroot make-kpkg --initrd --append-to-version=-my --added-patches equal.patch   kernel-image kernel-headers command does not pick my changes so I have to clean and rebuild the whole kernel which waste a lot of time 
<apw> generally you have to remove the build stamps from debian/stamps to get a partial rebuild, iirc.
<ibrar> apw: These are really higher level timestamp and removing this cause almost compiling whole kernel again
<apw> generally if the build one is still there it cleans the whole thing when using the debian/rules targets
<apw> generally i am building using fakeroot debian/rules binary-generic
<apw> and removing the build specific stamp lets me redo that without a full rebuidl
<rtg_> ibrar, apw: how about a command of this form 'make -C debian/build/build-generic M=/my-module-directory-here' ?
<apw> one doesn't end up with a whole kernel but if all you need is the .ko that can work
<apw> rtg_, you prolly noticed i pushed a startnewrelease
<rtg_> apw, yep
<apw> i am also testing an aufs update, seems to be a few small bug fixes upstream so pulling them into karmic
<rtg_> cool. Have our Live CD users noticed anything? Was A3 even built using aufs?
<apw> yep the live cds are pretty magic, they use aufs if it exists so they switch automatically when we uploaded.  just before A3 the images were using it, and direct reports of goodness in testing
<apw> lesshaste, pushed ... all yours
<rtg_> apw, I might get back on LTS backports this week.
<apw> that sounds cool.  its one of the laggers though we should separate it out as its not a release goal persee
<lesshaste> apw, thanks!  how would I find them?
<apw> details in the bug
<lesshaste> apw, ah yes.. thanks
<rtg_> apw, I'm pretty close to having the first batch of uploads. Just need to review the -meta details.
<apw> so we should be able to get -server to test on it and let us know if it might work for them
<rtg_> apw, yep, they are the only audience I'm interested in.
 * cwillu proposes renaming livecd's to magiccd's
<cwillu> oh, incidently, is it expected that wireless devices default to off in 2.6.31?
<cwillu> I always have to hit the killswitch to turn it back on now
<rtg_> cwillu, what laptop do you have?
<cwillu> acer aspire 3690
<cwillu> wireless has worked fine since edgy
<rtg_> cwillu, its likely the acer WMI or RFKILL driver that is causing the problem. the rfkill subsystem was completely rewritten
<gnarl> There has been an rfkill rework in 2.6.30/1 which still could have some problems
<gnarl> rtg_, Yeah, apw was looking on some cases iirc
 * cwillu pokes apw with the laptop-from-hell :p
<cwillu> but it should or shouldn't be defaulting to off?
<rtg_> cwillu, no, it should default to off
<gnarl> It should be defaulting to the state it had last imo
<cwillu> I can file a bug once I know if its actually a bug and not just something finally working as expected ;p
<cwillu> k
<rtg_> should not*
<cwillu> (k, in the 'misread that to mean what you intended' sense :p)
* You're now known as ubuntulog
<apw> cwillu, do you find hitting the h/w switchy thing twice sorts it out?  generally where the default is inverted we see that occuring
<cwillu> apw, I'll have to try that
<cwillu> just heading off to work, but I'll let you know
<cwillu> but... after startup, hitting it once brings it back.  after resume from suspend, I have to hit it once, and then restart networkmanager before it'll kick in
<cwillu> the latter may just be my usual delayed and gradual crashing of everything
<cwillu> (on resume)
<Q-FUNK> howdy!  is there any 2.6.31 without DRM support that I could test?  I'm starting to believe that bug #396286 might be caused by the kernel and/or udev insisting on loading DRM to get KMS, even on hardware where it's not ported.
<ubot3> Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286
<mjg59> udev will load the drm module even without KMS, yes
<mjg59> But there's no drm for the Geode
<mjg59> So that's not what's happening
<Q-FUNK> mjg59: indeed, there isn't any ported yet AFAIK
<mjg59> So it's not a drm issue
<Q-FUNK> the drm-related modules are the only difference I can spot between what 2.6.30 and 2.6.31 loads whenever dpkg-reconfiguring the kernel
<mjg59> If there's no driver with a PCI ID that'll bind to the Geode then nothing will end up running
<Q-FUNK> aye
<Q-FUNK> I'm just running out of options as to what could cause this kernel crash during bootup.  I've checked every possible issue I could, short of learning how to read kernel core dumps
<Ng> how's 802.11n support in karmic? (I was in a room that had a/b/g/n yesterday and I only seemed to connect to g)
<rtg_> Ng, 4965? I'm using an xps1330 to an 802.11n AP
<Ng> 5300
<rtg_> Ng, I have one of those somewhere....
<Ng> rtg_: it could just be that NetworkManager wasn't trying to use the 11n in preference, I was just idly curious if we'd generally expect it to work
<rtg_> Ng, yes, in general 802.11n _should_ work.
<Ng> groovy
<rtg_> apw, push it
<apw> doh, will push the aufs update ...
<Q-FUNK> heh
<apw> rtg pushed
<apw> rtg that dell rfkill switch thing i guess thats testable on anything with a h/w kill switch 
<apw> Keybuk, just fyi the next kernel update will include a few aufs bug fixes
<Keybuk> ok
<apw> Keybuk, its applied in the kernels here: https://edge.launchpad.net/~apw/+archive/green if you want to play, passed basic testing here
<apw> Keybuk, bah will take  a few mins to sort, PPA copy jut did something mad
<apw> Keybuk, now they are there
<rtg_> apw, do you have anything in the pipe for Karmic? I'm thinking about getting the aufs and dell-laptop changes uploaded.
<apw> no nothing ...
<rtg_> apw, ok, I'll wrap a bow on it in a bit
<apw> rtg_, ack
<apw> rtg the nice thing is that would also test sparc build fixes
<lesshaste> apw, is shm.c: mmap() failed: Cannot allocate memory an  application bug?
<apw> will generally be something that side though nothing is guarenteed in this world
<lesshaste> ok :)
<lesshaste> except death and taxes of course
<lesshaste> people seem to see it all over the place so I doubt its actually a specific app issue
<ivoks> rtg_: you said that you've removed drbd from karmic kernel, but it's still here?
<sbeh> hi, 1. is there an option for debian/rules that does not clean the kernel-build? 2. how do i get linux-headers-2.6.28-14.deb because the file linux-headers-2.6.28-14-generic.deb depends on it?
<rtg_> ivoks, I'm not sure where or when I said that. the git log shows a couple of maintenance touches since your January update.
<ivoks> rtg_: mail sent to ivoks@grad.hr, 24/06/2009
<ivoks> rtg_: anyway, could you remove it or should i report a bug about it?
<rtg_> ivoks, start by reporting the bug. That'll give me time to remember what in hell drbd does.
<ivoks> :)
<ivoks> rtg_: it's network mirror, we moved kernel part to drbd8-source package which uses dkms
<rtg_> sbeh,  there are several meta packages tha you can use to kkep your headers packages up to date; linux-headers-generic, linux-headers-server, etc.
<sbeh> why is building kernels on debian that terrible complicated
<sbeh> on gentoo i unpack the source and make menuconfig && make && cp .. /boot, thats it
<sbeh> rtg_: I build git to boot from nfs
<ivoks> you can do that on debian/ubuntu too
<rtg_> sbeh, install devscripts, then type 'debuild -b'. 
<sbeh> ivoks: but then i loose the ability to use apt for kernel-modules
<ivoks> sbeh: which you had on gentoo? :D
<sbeh> portage
<sbeh> rtg_: this does create deb-packages, i don't know which files linux-headers-2.6.28-14-generic is awaiting in linux-headers-2.6.28-14.deb
<rtg_> sbeh, 'debuild -b' creates everything, including the headers debs
<sbeh> oh reset, i read the KernelCompile-Wikipage and I already got linux-image*.deb and linux-header*.deb, but the linux-header*.deb depends on a deb that did not get build while following the instructions on the wikipage
<sbeh> what do you mean by 'everything'?
<rtg_> sbeh, the linux-headers packages depend on linux-headers-*_all.deb. 'debuild -b' will build that package as well.
<sbeh> does it take hours too?
<sbeh> like debian/rules binary-generic?
<rtg_> sbeh, that depends on your build machine.
<sbeh> like ...
<sbeh> argh, i will just try it
<rtg_> sbeh,  read the man page on debuild first. by default it cleans first
<sbeh> dpkg-checkbuilddeps: Unmet build dependencies: xmlto docbook-utils transfig sharutils
<sbeh> wtf?!
<sbeh> the hole texlive-distribution, wonderful!
<rtg_> sbeh, have you tried satisfying the build dependencies by installing those packages?
<sbeh> i dont want to
<sbeh> linux can be build without texlive *g
<rtg_> sbeh, this ain't linux, this is debian.
<sbeh> hm, ok, I will build 2.6.28-13 than, so I can use the already build packages, thanks
<lerot> hi
<lerot> do most distros such as ubuntu  use the same system calls which UNIX has as mentioned by POSIX?
<praveen> lerot: I think they do
<sbeh> even gentoo with freebsd-kernel does ;)
<Kernel_n00b> Hi
<Kernel_n00b> Anyone here ?
<sbeh> don't ask to ask, just ask!
<Kernel_n00b> Hi,
<Kernel_n00b> I need to measure the time consume by the Page-Fault process.
<Kernel_n00b> I'm trying to measure the software's overhead (no including the HDD overhead).
<Kernel_n00b> I'm using Ubuntu 9.04 running Linux Kernel 2.6.28
<Kernel_n00b> I have a small application which generates Page-Fault and then calculate the time (user mode) it is handled.
<Kernel_n00b> In order to deduce the IO (HDD) Time, I try to wrap the following section:
<Kernel_n00b> file : linux/mm/page_io.c
<Kernel_n00b> function: int swap_readpage()
<Kernel_n00b> bio = get_swap_bio(GFP_KERNEL, page_private(page), page,
<Kernel_n00b> end_swap_bio_read);
<Kernel_n00b> Is this the correct location ?
<Kernel_n00b> In addition, in order to time the process correctly, I couldn't decide whether I should use "gettimeoftheday()" , RDTSC (on Intel's CPU) or maybe the new Intel's HPET.
<Kernel_n00b> Any Suggestion ?
<Kernel_n00b> Thank you for your help.
<Kernel_n00b> No one ?
<Kernel_n00b> sbeh ?
<manjo> Kernel_n00b, have you seen this http://ww2.cs.fsu.edu/~hines/present/timing_linux.pdf
<Kernel_n00b> Nope.. I'll check it out.
<Kernel_n00b> Thanks!
<manjo> Kernel_n00b, looks like that is what you need to do instead of adding kernel code 
<Kernel_n00b> How did you find it ?
<Kernel_n00b> Hmmm....
<Kernel_n00b> I think I'm back to the same question :-(
<Kernel_n00b> getinfo() is using RDTSC
<Kernel_n00b> as in my question....
<Kernel_n00b> the problem is that I still neeed to measure the HDD Access time, and deduce it from the PageFault time.
<Kernel_n00b> Anyone ?
<Kernel_n00b> Someone ?
<Kernel_n00b__> ?
<jjohansen> Kernel_n00b__: all of the timing sources have problems, so its a pick your poison type of thing.
<Kernel_n00b__> I was hopping someone could tell me which function should I measure (in order to deduce the HDD overhead)
<Kernel_n00b__> I know that timing is a tricky issue. it is always tricky if you're running an multitask OS
<jjohansen> Kernel_n00b__: I haven't played in the vm code lately so it would require digging
<jjohansen> Kernel_n00b__: how do plan on accounting for everything else that can happen while your process is waiting for its page fault
<jjohansen> Kernel_n00b__: just because you start a page fault doesn't mean its the only io going on, and there could be other interrupts, cpu use etc
<Kernel_n00b__> I plan to kill all process that I don't need (including network).
<Kernel_n00b__> I though of installing a RAM-drive and swap to it. this is how I can measure the HDD access VS memory access (which is much faster)
<jjohansen> Kernel_n00b__: measuring at swap_readpage (I haven't looked) will probably work for a rough value as long as you get a good sampling get rid of the outliers 
<Kernel_n00b__> I think I'll used RDTSC to measure timing. I need uSec accuracy
<jjohansen> Kernel_n00b__: I would go ask on kernelnewbies and see if anyone more familure with current vm is hanging out
<jjohansen> Kernel_n00b__: make sure to set it so the processor doesn't do any speed changes, or C state changes then, as those will affect your RDTSC
<Kernel_n00b__> I'll also use CPUID in order to ensure no "Out-Of_Order" execution on the measuring section :-)
#ubuntu-kernel 2009-07-28
<billybigrigger> anyone here know where i can start filing a bug against the gpsca/sonixj module thats built into the kernel?
<billybigrigger> i just compiled a kernel from linus's source today, where there were a bunch of fixes to v4l and gspca, apparently fixing some bad sensor issues for this webcam
<billybigrigger> and it's still not working, hasn't worked through the whole 2.6.31 kernel
<Seracht> hi
<Seracht> does anyone here have experience working with setfsuid
<Seracht> it seems to be full of fail
<Seracht> is there some known way to get back the current fsuid
<Seracht> because I need to check it
<Seracht> and if I set it, it seems to set, if my RES UIDs are 0
<Seracht> even when I tried things like setfsuid(-5000);  and then did a setfsuid(0); I got -5000 the second time...so it went through, which is very weird
<Seracht> um actually
<Seracht> anyone know if the setuid invariant bug was fixed
<Seracht> after linux 2.4.XXX?
<Wellark> hi! what's the current situation with xen support?
<Wellark> does jaunty server kernel support xen domu?
<tseliot1> apw, mjg59: if I wanted to get rid of some garbage that shows up when resuming from s3 (and which goes away after resume is complete), where should I look at?
<apw> tseliot1, the messages should be in the dmesg, so you need to identify them and look at why they are coming out
<amitk> jjohansen: a kernel compile leaves behind ubuntu/apparmor/af_names.h and ubuntu/apparmor/capability_names.h. Can they be added to .gitignore?
<apw> they are generated files IIRC, where is it leaving them?
<jjohansen> amitk: as apw said they are generated files, definitely could be added to .gitignore
<amitk> apw: yes, they are generated
<apw> i wonder if they are being made in the right place, should they not be made in the O= directory we use in the build
<jjohansen> yeah they should I thought I had fixed that
<amitk> jjohansen: will you work on this or should I send a patch to add it to .gitignore?
<jjohansen> amitk: I will fix
<amitk> jjohansen: thanks!
<jjohansen> amitk: is this under Karmic? and how are you building?
<amitk> jjohansen: Karmic and building using the in-kernel build system. i.e. use a .config and 'make oldconfig;make'
<jjohansen> amitk: okay so you are building in place
<amitk> yes
<amitk> I use it to quickly test my arm flavours
<jjohansen> amitk: okay, thanks looks like I just need to add them to .gitignore then
<rtg_> tseliot1, have you had reports of the nVidia driver randomly going into power save mode and blanking the screen? It happens to me several times a day.
<tseliot1> rtg_: let me check
<apw> rtg_, have been looking at the karmic delta, and there are a number of commits which add 5 drivers and others which remove two of those, which makes understanding the delta.  i have been playing with rewriting those commits to split them up so that the add and drop can be paired.  this is with a view to simplifying squashing the redundant delta when we move forward.  does that sound sane?
<apw> understanding the delta hard.
<rtg_> apw, I've been thinking about LL in that regard, and the amount of noise we carry in the git repo. I'm inclined to start clean and just copy the ubuntu and debian directories and commit them once.
<apw> yeah i envision us squashing the entire config thread and all debian stuff as one
<tseliot1> rtg_: I can't find anything about that
<rtg_> tseliot1, ok, thanks
<apw> rtg_, i'll put an email together and push it to the list on this
<rtg_> apw, how come 2.6.28-rc1 got rebuilt?
<apw> not rebuilt, but built for the first time
<rtg_> ah
<apw> 2.6.28 was before we started doing them automatically, so we have none for that gap, and smb wanted one for a bisection
<apw> so it got requested
<gnarl> Just updated the bug report with that
<rtg_> amitk, pushed http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=20268b66870d83d86574d22ee32f654d02996599
<amitk> rtg_: sure. ABI and module lists is a don't-care right now.
<rtg_> amitk, should I just push an ABI ignore as well?
<amitk> rtg_: if armel is the only one causing an ABI bump for the next upload, sure.
<rtg_> amitk, I imagine with all of your pending patches, there is bound to be an ARM ABI change
<amitk> probably
<bjf> rtg_, I'm also close to having a huge pile of Marvell patches to submit for Karmic
<rtg_> amitk, bjf - OK, I'll preempt build failures by updating that last push with an ABI ignore
 * amitk pictures apw and rtg running to avoid getting buried like in a bad Roland Emmerich movie 
<bjf> ****************************************************
<bjf> ** What:  Ubuntu Kernel Team Meeting
<bjf> ** When:  Today, 17:00 UTC
<bjf> ** Where: #ubuntu-meeting
<bjf> ** Who:   Everyone is invited
<bjf> >
<bjf> > Ubunt kernel team meeting starting in 5 minutes in #ubuntu-meeting
<bjf> >
<bjf> Ubuntu even
* bjf changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Karmic Kernel Version: 2.6.31 || Ubuntu Kernel Team Meeting - Tuesday, 28th of July - 17:00 UTC"
#ubuntu-kernel 2009-07-29
<Keybuk> apw: when's your next upstream-tree-of-the-day-build due?
<apw> they build about 10am
<Keybuk> 23-Jul was the last?
<Keybuk> oh, no, daily
<Keybuk> sorry, mis-understood your directory structure
<apw> heh :)
<Keybuk> any way to know what the git log/revno of a given build was?
<apw> the last -rc was 23rd
<apw> at the top of the build log
<Keybuk> why the -g ?
<apw> long<v2.6.31-rc4-198-g7d3e91b>
<apw> thats the form git uses for describing a commit
<apw> the short form of the sha1 follows the -g
<Keybuk> ah
<Keybuk> got it
<Keybuk> that has the patches I need to ack
 * Keybuk downloads to test
<apw> though i also report the full commit after the checkout there
<apw> vvv - build head
<Timmy2Tall> Home is where the heart is
<Timmy2Tall> would you agree?
<maks_> hello Keybuk 
<maks_> thanks for your write down, will release current state of i-t to have that out of the way and then soonest pick up.
<Keybuk> maks_: busy atm, will get back to you in a bit
<maks_> no rush needed. Keybuk 
<Keybuk> great! :)
<dk_> hi
<dk_> i have questions
<dk_> i have a Netbook acer aspire one, and i want compile the kernel for the  best performace
<rtg> dk_, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<rtg> apw, we don't have a single example of request-pull in any of the git recipe pages.
<apw> rtg, thats poor, i can fix that
<rtg> apw, the reason I was looking is the I cannot get one of my request-pull examples to work, so I was just making sure i didn't have brain damage
<apw> whats it doing wrong reporting lots and lots of patches?
<rtg> apw, it can't find the repo on zinc.
<apw> wanna paste the line here or in /query that you are using
<rtg> apw, actually, there is an example: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide?highlight=(request\-pull)
<rtg> apw, here is my example: git request-pull HEAD~1 git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<apw> your branch won't be in the ubuntu karmic repo though will it
<apw> ?
<rtg> apw, I tried my repo as well
<apw> normally its in your personal one
<rtg> git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic
<apw> ok so its definatly yours as the last param
<apw> and you have pushded the commit as which branch in your repo?
<rtg> apw, this is just master, and I'm synced.
<rtg> it should be a no-brainer
 * apw looks
<rtg> apw, how about you, can you get a request-pull to work correctly?
<apw> just testing with your repo
<apw> rtg ok a request pull can only be for a commit which is the head of a branch
<apw> so you'd have to have pushed HEAD~1 as a branch tip
<apw> so the one you are trying there f493e5ae7f0799a45f25e6f0595e32e95990c67d is master~2
<apw> so if you want to send a request pull for that you need to do like
<dk_> rtg:  i was compiling my kernel for acer aspire one, but i  need more help::)
<apw> git push zincremote master~2:pullme
<apw> and then the request-pull will work
<rtg> apw, I don't think thats correct. I just updated against the core repo (I guess I wasn't synched). This works fine (notice I can specify a commit prior to HEAD) : git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic
<rtg> dk_, do it the long way first. install devscripts, then 'debuild -b' and follow the bouncing ball.
<apw> rtg ok we are both using it wrong
<apw> or i am understanding you wrong
<apw> git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic
<rtg> apw, my understanding of the SHA1 in request-pull is that is where you'd like the pull to start from.
<apw> does not ask for HEAD~1 to be the thing to pull, that says list from after HEAD~1..HEAD on the  page, and find HEAD in the repo
<apw> ie the HEAD~1 there is the commit before the first one you want mentioned, but it is trying to find your current branch in there
<apw> you can add a commit tip as param 3
<apw> but either way that needs to be in the pushed repo as a head
<apw> git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic
<apw> arrg
<apw> git request-pull rtg/master~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic rtg/master
<apw> so that says ... generate a request to pull the commits from rtg/master~1 to rtg/master
<apw> the  final param must be a the sha1 of a tip in the repo in param 2
<rtg> apw, I think I grok it. I just wasn't properly synced. Its just like forgetting to see if your mixer is plugged in when it won't turn on.
<apw> i happen to be using your branches there
 * apw notes he got its use wrong again and once again had to read the manual.  its not an obvious interface to me
<rtg> apw, true, but at least request-pull tells you when its confused.
<dk_> rtg:  speak spanish?
<rtg> dk_, nope.
<dk_> ok
<apw> rtg it should just say, "look read the manual, trust me its quicker"
<rtg> :)
<apw> Keybuk, how common across distros is the modprobe blacklist stuff?  is it ubuntu specific?
<Keybuk> apw: the blacklist files, or the contents of them?
<apw> the format and support for the functionality
<Keybuk> oh, totally upstream
<Keybuk> we have no patches to module-init-tools
<apw> so if you can find the right place, then a blacklist config can be added, cool
<apw> Keybuk, are we still looking to remove graphics drivers from initramfs?  i was supprised to find i915 in mine
<Keybuk> in the common case, yes
<apw> whats the uncommon case?
<Keybuk> see my mail today ;)
<ogra> phew
 * ogra is relived that Keybuk agrees we *do need it* :)
<apw> Keybuk, thanks ... thats exactly what i needed to know at the moment i needed to know; most fortuitious
<ogra> did anyone ever chack how much ot bloats the kernel if we compile all FB drivers in ?
<Keybuk> ogra: FB drivers are quite closely linked to the X driver
<ogra> or is that breakins
<Keybuk> I don't think we want to compile them in
<ogra> *g
<Keybuk> in fact, in general, I say we should never compile a _driver_ in
<ogra> well, we do so for filesystems
<ogra> and that was actually a noticeable speedup
<Keybuk> only ext4
<Keybuk> ext* sorry
<Keybuk> and those aren't really drivers
<ogra> fuse too
<apw> we tend to compile in commonly used filesystems yes
<apw> drivers we tend to make modules
<ogra> and nfs i think
<Keybuk> again, not a driver
<apw> Keybuk, have you tried switching the initramfs to lzma ?
<Keybuk> driver sits on a bus
<ogra> indeed
<maks_> -rw-r--r-- 1 root root  6314398 2009-07-29 16:48 /boot/initrd.img-2.6.31-rc4-amd64
<maks_> contrast too
<maks_> -rw-r--r-- 1 root root 10655820 2009-07-29 10:10 /boot/initrd.img-2.6.31-rc4-amd64.bak
<rtg> Keybuk,  so you are arguing that we should only be compiling in drivers that are essential to mount the rootfs. udev can do the rest (for the common case).
<ogra> apw, please make that optional, we have massive probs on ARM with lzma 
<Keybuk> apw: I'd like to see the benchmarks of decompress time first
<Keybuk> rtg: that's what we do
<Keybuk> rtg: I think the only driver we compile in, in practice, is the Intel PIIX driver no?
<rtg> Keybuk, thats what I though we were doing, just wanted to confirm.
<Keybuk> things that it makes sense to compile in
<Keybuk>  - modules that we force load for everybody unconditionally
<apw> Keybuk, its slower to decompress, but a lot smaller to load
<Keybuk>  - core kernel functionality that it makes no sense to be an option (unix.ko, printk.ko, etc. :p)
<rtg> Keybuk, actually, we compile in _all_ of the block level drivers that are required for a root fs
<apw> so its a trade off between the two
<Keybuk> apw: I'd like to see the timings for that
<Keybuk> decompress should show up as the populate_rootfs() time
<apw> yeah ... and you should just be able to make the initrd which ever way you prefer
<apw> the kernel should understand both
<ogra> on ARM its like 10x slower to compress/decompress
<apw> i would think on netbooks gzip is faster, on faster boxes i would think lzma probabally is
<apw> ogra, yep, but as the kernel understands both you can choose the faster one
<ogra> in fact we have massive build failures on arm for all packages using lzma because the ddeb compressing times out after 3h
<apw> if your initrd is in flash you may decide not to compress it
<ogra> its on SD
<ogra> or various forms of disks depending on the HW
<ogra> we dont use flash on any of the supported SoCs
<apw> all i am saying is it is an option ... not trying to make one or the other the right one
<apw> was just interested if Keybuk had poked that pile of ants in his review of boot speed
<maks_> smaller initramfs also builds faster, as added bonus :)
<apw> cking, that kernel i was tlaking about is here: http://people.canonical.com/~apw/lp318942-jaunty/
<cking> apw, cheers, will test.
<cking> apw, yep some audio, and crackly reboot sound too
<apw> so the audio is 'working' but the thingy you said was bust is
<cking> apw, yep. Let me do some other tests (headphone, suspend/resume etc) to make sure it's all fine.
<apw> Keybuk, sorry to ask yet again, but where might i find info on the vt7->vt1 switch
<cking> apw, speakers work, headphones plug in works, headphones unplugged => no sound out of speakers.
<apw> crap
<cking> lemme have a poke around.
<cking> apw, you're 95% the way there. It's just that weird hda pin stuff that needs some massaging
<rtg> cking, you mean that 128 bit magic array of bits?
<cking> something that way. It's not too difficult when one has the data sheet. However, I don't have the data sheet :-)
<rtg> cking, thats what makes it magic. how often can you procure the data sheet for a motherboard?
<cking> ..rarely. But there are ways and means...
<apw> cking, it is meant to work in karmic if that helps
<cking> really? I will give that a try and make sure.
<cking> I will pick this up tomorrow. I've got some family deadlines tonight
<apw> just the kernel should be sufficient
<apw> and thanks for that
<cking> I could not apply your 3rd patch onto jaunty, I got:
<cking> Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
<cking> error: sound/pci/hda/Makefile: does not match index
<cking> error: sound/pci/hda/hda_codec.c: does not match index
<cking> error: sound/pci/hda/hda_patch.h: does not match index
<cking> Patch failed at 0001 UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
<cking> ??
<cking> rats, my left hand has gone numb, must be my neck pressing on the nerves
<apw> cking, third patch would be 0003?
<apw> cking,  what base you applying them to?
<cking> top of the jaunty repo.
<apw> thats where they are in my tree
<cking> lemme retry. could be a typo, my left hand is out of action
<apw> d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip i am on
<apw> and remember they apply in numeric order
<cking> 0001, 0002, then 0003 -> probs
<cking> d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip too
<apw> cking, sum those patches
<apw> as i just applied them from my rookery copy
<apw> apw@dm$ git am ~/rookery/lp318942-jaunty/????-*
<apw> Applying: UBUNTU: SAUCE: copy the hda sigmatel codec driver for the HP mini family
<cking> 5a65225dec284daf299a8d6711e99595  0001-UBUNTU-SAUCE-copy-the-hda-sigmatel-codec-driver-for-.patch
<cking> 0a54f072f5a75c199cd866e5be4971f9  0002-ALSA-hda-Rework-on-STAC-IDT-auto-configuration-code.patch
<cking> 0195e12abb7b4ff2d5f2a73a2b86baf2  0003-UBUNTU-SAUCE-select-the-patched-sigmatel-codec-for-H.patch
<apw> Applying: ALSA: hda - Rework on STAC/IDT auto-configuration code
<apw> Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
<apw> sums match
<cking> apw, see my email - got a script of what happens. Most curious.
<apw> cking, oddness, could you ensure you are reset to head correctly
 * apw will push up my branch too ...
<cking_> apw, that fixed it. sorry about that
<apw> cking_, np was confused
 * cking_ is surprised he missed that one. doh
<cking_> I need to go. Family + left hand issues.
<apw> np
<apw> go
<Alaric`> localtime(time()), folks ....   anyone here running 9.04 on an Inspiron 4100?  I have a fan problem I'm seeking a solution for.
<Alaric`> capsule summary:  the fans on the laptop never run, causing it to overheat, unless I load the i8k module.  i8k.ko + i8kmon runs the cooling fans properly, BUT i8k.ko disables the keyboard as soon as it loads, and I can't get the keyboard back except by rebooting without i8k.
<Alaric`> is there a known solution for this?
 * apw hasn't heard of that specific issue
<Alaric`> (right now I'm compiling a new kernel with a modified i8k.c patched to never try to touch fn-key status, to see whether that's where it's blowing away the keyboard)
<Alaric`> also speculating that it may be an ACPI issue
<apw> have you tried later mainline kernels to see if they work?
<Alaric`> last time my wife (it's her laptop) checked for updates, it wasn't showing a newer kernel available as a package
<apw> no i mean a later mainline build, from the mainline builds archive
<Alaric`> mainline builds archive?
<apw> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<apw> those contain builds of later upstream kernels which can be used to see if the issue is fixed later on
<Alaric`> but yeah, once I get the build-kernel-on-ubuntu procedure down, I was thinking of building a 2.6.30.3
<apw> which can help find it
<Alaric`> hm, lemme check that out
<apw> there are prepackaged 2.6.30 kernels on there
<Alaric`> hm.  in this situation, would you go with 1.6.30.3, or 2.6.31.rc3?
<Alaric`> er, s/1.6/2.6/
<Alaric`> oh, there's an rc4
<Alaric`> missed it at first
<apw> i would tend to pick the latest first if that works pick one between the distro and that one and try that
<apw> yeah so i'd try -rc4
<apw> its not intended as a fix, more as a barometer of that feature being fixed
<Alaric`> the linux-source package is equal to the corresponding linux-image plus linux-headers?
<apw> i am suspicious it will not fix things as there does not seem to be much
<apw> nope thats a source package no use generally
<apw> you want the binary and headers and generic headers
<Alaric`> so http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-image-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4_2.6.31-020631rc4_all.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb?
<Alaric`> oops.  forgot those'd get expanded.  :p  sorry.
<apw> looks about right
<apw> is there a bug for this on launchpad?
<Alaric`> haven't found any reference to it except in way old threads dating from 2.6.8
<apw> you should file one then, so it can get tracked
<Alaric`> roger that.  soon as I get this kernel-with-patched-i8k built and tested.
<Alaric`> if it works, I'll have at least a workaround to attach to the report.
<rtg> apw, whats the script you use to rebase master onto a topic branch, e.h., master --> lpia ?
<apw> you mean to rebase the netbook branches onto a tag ... rebase-branch in the branch
<apw> that reminds me i have a netbook push to do for jaunty
<rtg> apw, I guess. where is it located?
<apw> ./debian/scripts/misc/rebase-branch
<apw> normally you rebase to a tag
<rtg> apw,  ah, that script only lives on the netbook branch
<apw> yes, its branch specific right now, am working on removing the last couple of branch specific items
<apw> then we cna commit it to the master
<apw> that reminds me, i have a proposed update to the karmic config system
<apw> which makes it a completely overrides based system
<apw> ie. each level contains only the options which are changed
<rtg> apw, I'd like to use it for the LTS branch, i.e., the hardy branch in the Jaunty tree.
<apw> so you can have a default at the top and only mask it with another value on one flavour or arch
<apw> rtg makes sense for that use for sure
<apw> i will get an email together for this config thing and send it out, prolly in the morning now
<rtg> apw, yeah, isn't it time you were off quaffing beers?
<apw> heh something like that
<]Oscar> does the usb driver send a reset signal to all peripherial while shutting down the pc?
<AnAnt> Hello, I got a directory that has a kernel module how can I avoid a binary blob (.o) file from being deleted by clean target ?
<AnAnt>  when I run make -C $KERNELSRC -M $(CURDIR) clean, the blob gets deleted that is
<AnAnt> isn't there an override that I can add to the makefile ?
#ubuntu-kernel 2009-07-30
<ntrfug> Good evening. Anybody home?
<]Oscar> does the usb driver send a reset signal to peripherial while shutting down the pc?
<alex_joni> :P
<tjaalton> any known issues with virtualbox on .31? there are a lot of crash reports being filed against xorg-server, but the problem is somewhere else
<tjaalton> bug 402800 is the master bug
<ubot3> Malone bug 402800 in virtualbox-ose "Xorg crashed with SIGSEGV in <signal handler called>()" [Medium,Confirmed] https://launchpad.net/bugs/402800
<tjaalton> heh, there are a lot of similar crashes, some have 30 dupes
<tjaalton> quality
<apw> rtg we should probabally ask what the pain point was, my understanding was that the versions being different for the arches was the issue
<apw> that i lead to complex hand holding of the version mappings for d-i
 * amitk nods
<apw> i think if we have to source packages, we should just in the main aim to have them loaded at the same time
 * rtg nods
<apw> though i am thinking that maybe the amitk idea of mushing a merged tree at build time is interesting
<rtg> apw, its worth discussing, but I'm leery...
<apw> i will write them all up for next week so we can think on them
<apw> yeah interesting but ultimatly a bit scarey
<amitk> apw: the rebase script was supposed to be scarey too, but we ship it :-p
<apw> heh yeah its a bit scarey but it occurs in my face and i can see the result
<apw> the other options we never see the real source as seen by the compiler, whihc is scarier
<rtg> amitk, how is 'UBUNTU: ARM: IMX51 ' for a patch subject?
<amitk> rtg: you mean 'UBUNTU: ARM: DOVE' ?
<rtg> amitk, I thought you wanted IMX51?
<rtg> amitk, from your email: 'UBUNTU: ARM: IMX51: <description>'
<amitk> rtg: IMX51 for the _Freescale_ patches. DOVE for _Marvell_ patches.
<rtg> amitk, got it
<amitk> rtg: I was just showing the pattern I used for Freescale
<mjg59> Keybuk: The reason thermal and fan are in the initramfs was so that they're loaded before resume from disk is triggered
<mjg59> Otherwise you'd overheat while doing that
<mjg59> Obviously not a problem with stuff statically built
<Keybuk> but they're loaded by udev *anyway*
<maks_> not if not present?
<mjg59> They weren't when it was originally implemented
<mjg59> acpi didn't have modaliases
<Keybuk> right
<Keybuk> in hindsight, we should have fixed *that* instead
<mjg59> Wel, yes
<mjg59> Though that's true of many things
<mjg59> I mean, rather than usplash I should have written KMS :)
<Keybuk> damned straight
 * mjg59 goes back to hating on USB
<devinheitmueller> Hello all.  I spent the last few months working with Xceive to get their firmware licensed for distribution with Linux distros.  That's been done and it's in dwm2's linux-firmware git tree.  Aside from opening a launchpad ticket, is there anything I can do to facilitate getting this pulled into Karmic?
<devinheitmueller> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/403642
<ubot3> Malone bug 403642 in linux-firmware "Include xc5000 firmware in Karmic (now properly licensed)" [Undecided,New] 
<devinheitmueller> woah, is there an echo in here?  :-)
<rtg> pgraner, ^^ re: linux-firmware
<pgraner> rtg: it will be ready for you next week. I'm running a bit behind 
<rtg> pgraner, just wanted to make sure you noted it.
<pgraner> devinheitmueller: no need for a bug, we will be pulling it in 
<pgraner> rtg: I did will do it at the sprint
<devinheitmueller> Wow, did I happen to walk into the middle of a conversation about my exact bug, or are you guys really that fast?
<apw> they are that fast
<devinheitmueller> pgraner: great.  Thank you very muhc.
<devinheitmueller> s/muhc/much/
<rtg> devinheitmueller, licensing has been a topic of some interest of late.
<devinheitmueller> rtg: understandable.  It took several months to get this one straightened out, so it will be great to finally get it into the distros since it makes a half dozen Hauppauge/PCTV products work "out of the box".
<devinheitmueller> Anyway, thanks for all your help guys.  I will keep my eyes open for the package update.
<rtg> devinheitmueller, should be sometime next week.
<rtg> certainly before Karmic releases
<devinheitmueller> rtg: excellent.
<devinheitmueller> On a separate note, is there an #irc archive for this channel?  I looked around and couldn't find one.  If so, could someone paste a link?
<rtg> devinheitmueller, dunno. you might have to contact a freenode admin
<devinheitmueller> ok, just curious.  thanks.
<devinheitmueller> (I wasn't sure if you guys had a loggging bot setup)
<rtg> apw, you've somehow acquired logs from #ubuntu-meeting. Are all channels logged?
<apw> rtg? you mean i point to them in the meeting notes?
<apw> i am not sure all are logged no
<rtg> apw, ok, you know as much as I do :)
<apw> i think the logger is ubuntulog user
<apw> so if thats not on a channel its not logged, if it is is is
<devinheitmueller> Ah, here we go:  http://irclogs.ubuntu.com/2009/07/30/
<devinheitmueller> Great, thanks for the info.
<awe> apw: ping
<apw> awe hi
<awe> apw: hey, i saw emails between you and stefan recently about wep module name munging in jaunty related to ipw2200
<awe> just wondering if this may be a problem on karmic too
<awe> ?
<awe> just saw a bug report for a user on karmic who's having trouble with ipw2000; repeated disconnects when trying to associate to a wpa-psk AP
<apw> awe karmic is ok as the munging is gone as of recently, rtg removed it cause modprobe is now sorted out and does the right thing in the face of the duplicate modules
<awe> was it a problem at some point in karmic though?
<rtg> awe, not to my knowledge. the last change remember making to ipw2200 was a module parameter default, but I think its upstream now.
<apw> awe i don't remeber it being and issue
<awe> rtg, apw: ok.  i asked for more information, but it looks to me like there still may be an issue with ipw2200 under karmic
<awe> thanks for the 411
<rtg> awe, you going to the wireless mini-summit in Sept?
<awe> rtg: i plan to, but that depends on whether or not my boss(es) have other plans for me in sept
<awe> i responded yes to john's email
<rtg> awe, cool. hope to see you there.
<awe> rtg: me too
<awe> rtg: see you next week!
<gnarl> awe, rtg There was a munging problem in Jaunty but that would prevent the wep crypto module from getting loaded at all
<gnarl> Karmic should be fine with that as there is no munging done
<awe> gnarl: thanks for the info!
<rtg> bjf, just pushed some changes for Karmic arm topic branch which remove support for non-arm arches
<rtg> bjf, there is likely to be one or 2 more once I figure out all of the packaging issues
<bjf> rtg, ack
#ubuntu-kernel 2009-07-31
<stas> hi guys, why this builds contain no support fo btrfs: http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<Darkr> Is there anyway I can disable cpu freq scaling?  You see, my hardware is a tad buggy.  It crashes when scaling occurs.  In Hardy, I simply removed powernowd and that did the trick.  But in Karmic, that no longer exists so I can't do that.  Any advice?
<Darkr> brb, I'm going to try doing this: http://ubuntuforums.org/showthread.php?p=7602572
<Darkr> I just wanted to say nevermind, but thank you for your help.  Someone in another channel (#ubuntu+1) was able to help me.
<NCommander> apw, belated ping, I know the kernel currently FTBFSIng on SPARC, I hope to get you revised patchs soon, but its hard to work on my sparc box whiel I'm at debconf. I should be able to do something once I'm in Ireland tomorrow morning
<johanbr> Darkr, easiest way would be to change the cpufreq governor, for instance using the cpufreq-applet
<gj> anyone using an acer?
<gj> laptop?
<gj> anyone using an acer laptop?
<Athunye> Hello. Since the update to 2.6.28-14 some pages like yahoo.com, scrib.com and some other won't load. In karmic they do load and so with arch linux. 
<Athunye> I think it is not a flash problem because I even purged it. In links I can load those web pages, though.
<Athunye> I tried opera, and epiphany-browser as well.
<reisi> are there any updates on lzma support in perhaps 9.04 kernels? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177634
<ubot3> Malone bug 177634 in linux "squashfs kernel module does not support lzma" [Medium,Won't fix] 
<reisi> it's currently targeted at Milestone "later"...
<amitk> reisi: it is marked as "Wont fix" for 9.04
<reisi> amitk: well hopefully it'll get into 9.10 then.. or is it in the mainline already? squashfs+lzma seems superb backup solution if you need to image a fs with huge number of files..
#ubuntu-kernel 2009-08-01
<bluefoxicy> where's the proper place to discuss disfunctional hardware?
<eeanm> is there a repo with 2.6.31rc4 or greater for Jaunty somewhere? I need it for my eeepc ethernet to work.
<eeanm> and I'm going to get on a plane in a few hours and would rather not compile myself :) :)
<bluefoxicy> I have a friend trying to get wifi working on an acer laptop, it perpetually says no wireless connections, found some bugs referencing such a thing but none of the workarounds work and it's fixed relased.
<dtchen> eeanm: the mainline builds are fairly release-independent
<dtchen> eeanm: see http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/ and http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc5/
<dtchen> eeanm: e.g., i've run both on an intrepid i386
<eeanm> dtchen: yep I'm using that now
<dtchen> bluefoxicy: general triage issues can be kernel-team@
<dtchen> (lists dot ubuntu dot com, that is)
<eeanm> dtchen: I need to use an experimental module that isn't being built... I disabled all the other modules, did make modules, but when I insmod it, it says "no symbol version for module_layout"
<eeanm> using the kernel from the source deb
<eeanm> any idea? I really don't see why this didn't work. maybe because the kernel from the ppa has a weird version that wasn't transfered to the source deb.
<eeanm> 2.6.31-020631rc5-generic vs. 2.6.31-rc5
<eeanm> well fixed that, still same error
<tim_blechmann> hi all, not sure, whether i am right here, but i have a problem, when building a kernel package with make-kpkg. the /lib/modules/../source symlink points to my kernel directory, but i would prefer to have it pointing to the /usr/src/linux-header folder of the linux-header package of the corresponding kernel ... what do i need to do in order to generate kernel packages with changed source and build symlinks?
<DKcross> hello friends
<DKcross> i need help
<DKcross> i am compiling my kernel
<DKcross> but i have 2 problmes
<DKcross> problems"
<DKcross> undefine mode video
<DKcross> and Bar 6 ,device not found
<DKcross> any can help me
<DKcross> os[Linux 2.6.31-rc2-dkcross- i686] distro[Ubuntu "jaunty" 9.04] cpu[2 x Intel(R) Atom(TM) CPU N270   @ 1.60GHz (GenuineIntel) @ 800MHz] mem[Physical: 991.2MB, 71.9% free] disk[Total: 127.8GB, 36.1% free] video[Intel Corporation Mobile 945GME Express Integrated Graphics Controller] sound[HDA-Intel - HDA Intel]
<DKcross> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
<spO> hi
<spO> i did a git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git , git checkout Ubuntu-2.6.28-15.48 , git fetch , but then when i do a make menuconfig  the top of the menu says configuration for Kernel 2.6.28-10  
<spO> i don't undrestand
#ubuntu-kernel 2009-08-02
<spO> anyone know?
#ubuntu-kernel 2010-08-02
<DanaG> Say, why is drm-next kernel-ppa so old? http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/
<lag> Mornin'
<cooloney> lag: morning, man
<lag> Hey Bryan :)
<smb> cooloney, Morning. Any news from Freescale about the brickage?
<cooloney> smb: morning, i am just wanna discussing with you. 
<cooloney> smb: actually, i don't have any update as we got in the email
<cooloney> i saw you post the security kernel in the email
<smb> Ok, I had been looking at the source code on Friday. Right, there were two updates missing from the latest security, but otherwise it was as I would expect it
<smb> And from the things missing its hard to believe that this can destroy things as it did
<smb> Very strange
<smb> The only other variance was that I built on tangerine but you do that too
<cooloney> smb: for fsl-imx51, i built them in *.mills. 
<cooloney> although it is different, i still don't think build machine is a issue.
<cooloney> i have to say ' that's pretty odd'
<cooloney> so what's our next?
<cooloney> i am going to send out an email to ask?
<smb> cooloney, So just to confirm that for myself. When you installed the bad kernel, you once could boot but it crashed. And only then was the board bricked?
<cooloney> smb: oh, IIRC, it never boots any more
<cooloney> we installed the whole system on babbage
<cooloney> and copied your kernel .deb file to the board
<smb> cooloney, So in theory it could be some weird wrongness in the flashing process as well?
<cooloney> and sudo dpkg -i *.deb
<cooloney> smb: yeah, at the end of the installation, it will try to update the kernel in flash
<cooloney> so maybe corrupted sth
<lag> cooloney: How 'bricked' are they?
<lag> cooloney: Have you tried to JTAG them yet?
<smb> Though quite mysterious to do that twice. Anyway, I guess we want to know what _did_ break things. As much as I understood mails. We only know that it was not what fsl thought it was.
<cooloney> lag: cannot even boot from the bootloader
<cooloney> lag: too bad, i don't have it
<cooloney> and we shipped them back to fsl 
<lag> Okay, I assume they'll try to JTAG them back to life then
<cooloney> lag: yeah, i think so
<cooloney> smb: let me send out email to sync up with fsl guys
<ikepanhc> cooloney: you mean you update a can-not-boot kernel to babbage and have to send the board back to fsl?
<smb> ikepanhc, We found out about the cannot-boot after flashing. :)
<cooloney> ikepanhc: we tried to test smb's security kernel
<cooloney> after we installed that kernel, the board cannot boot anymore
<cooloney> bricked the board 
<cooloney> smb: yeah
<cooloney> update the kernel image in on board flash or somehow
<ikepanhc> IIRC babbage board can boot from SD card...
<simon___> bump to anybody: i have found a bug and don't know where to report it - i have a packard-bell laptop and the kernel loads asus_laptop driver by default (it's enabled in the stup process). it's a driver that's causing some problems (e.g. wifi) and the workaround is to blacklist it. where should i report it?
<ikepanhc> simon___: please report it
<smb> simon___, Launchpad against linux package
<cooloney> ikepanhc: yes, but it needs it's on-chip bootrom supports that.
<ikepanhc> simon___: you mean you have a dell laptop and asus-laptop loaded?
<cooloney> ikepanhc: it does not boot from anywhere after that.
<ikepanhc> cooloney: oh, too bad
<ikepanhc> cooloney: ah? on-chip bootrom erased? *faint*
<smb> ikepanhc, Hm, was it asus-laptop which got the handling for the lenove because they had the asustek acpi id?
<ikepanhc> smb: asus-laptop.ko will look for ACPI HID ATK0101 or ATK0100
<ikepanhc> but they shall not be there on dell laptops
<smb> ikepanhc, So it might be the dell also has that
<smb> ikepanhc, Its said to be packard-bell
<ikepanhc> smb: that will be bad news
<smb> not dell
<ikepanhc> smb: ohoh, sorry for my poor eyes
<smb> ikepanhc, I got that problem too often. :)
<simon___> ikepanhc:smb is right, it's packard-bell
<ikepanhc> simon___: if you filed the bug, please let me know the bug id
<ikepanhc> simon___: I think I can try to help you
<smb> simon___, The best way would be to use "ubuntu-bug linux"
<simon___> ikepanhc:i'll file the bug right away.. tnx
<simon___> smb:should i use "ubuntu-bug linux" with asus_laptop loaded?
<ikepanhc> <---- has a laptop with asus-laptop
<smb> simon___, If it is usable to reach the network yes.
<ikepanhc> simon___: with or without is ok
<smb> At least with the driver loaded it might show some of the problems in the logs
<ikepanhc> yes
<simon___> smb:wifi doesn't work, but the cable is ok
<smb> simon___, Ok, then do it with it loaded. Sounds a bit like rfkill might be messed up in that case
<simon___> smb:i agree..at first i thought it was a wifi driver issue so i filled a bug there:
<simon___> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2128
<ubot2> bugzilla.intellinuxwireless.org bug 2128 in others "Intel 3945ABG sees networks but can't connect" [Normal,Resolved: tested_patch_exists]
<cooloney> smb:  i am going to point fsl guys out where is the kernel source code.
 * abogani waves all
<cooloney> smb: do you know where is the source of your secuity kernel and our updates kernel
<smb> cooloney, That is not yet released
<akgraner> crimsun, in answer to your question about the mac air - nope :-( sorry not yet - I've been a bit busy :-/  I'll see what I can do after next week
<smb> cooloney, I normally wait till the security releases are really out
<smb> cooloney, The updates kernel is just the one in the topic branch
<cooloney> smb: ok, got it. man
<cooloney> smb: is this one? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/fsl-imx51
<smb> cooloney, Sort of. If you take the additional stuff off after 608-15
<cooloney> smb: got it. @tags/Ubuntu-2.6.31-608.15
<smb> cooloney, yup
<smb> cooloney, I hope the security release is going out soon, then I can push all of the code
<cooloney> smb: ok, no problem. 
<simon___> ikepanhc; it took me a while.. :)
<simon___> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/612454
<ubot2> Ubuntu bug 612454 in linux (Ubuntu) "[Packard-Bell EasyNote] asus_laptop problem: wifi (affects: 1) (heat: 6)" [Undecided,New]
 * ikepanhc looking
<simon___> ikepanhc: i just detected another bug - numlock is not working as expected (it's also an asus_laptop issue). should i add my findings to this bug?
<ikepanhc> simon___: please do so.
<ikepanhc> simon___: but numlock shall be nothing related to ACPI extra driver..
<simon___> ikepanhc: i am quite sure it's related to asus_laptop - blacklisting it solves the problem
<ikepanhc> simon___: I have some comment on the bug, I need the acpidump and dmi modalias. please help me dump those info
<simon___> ikepanhc: sure, but how do i do that?
<ikepanhc> simon___: I write how to do it on the bug comment :)
<simon___> ikepanhc; the command "sudo iasl ..." is not found. is it a misspell?
<ikepanhc> simon___: no, please "sudo apt-get install iasl", but you can skip that, using acpidump please
<proppy> will 2.6.35 (retail) be build for lucid on ppa ?
<proppy> is it 2.6.35-14 ?
<simon___> ikepanhc: do i have to install acpidump as well?
<ikepanhc> simon___: yes please
<simon___> ikepanhc: done
 * ikepanhc looking
<apw> proppy, do you mean the final v2.6.35 version?  yes that will be built for lucid once its done for maverick
<proppy> apw: yes, I meant the one which went out yesterday
<proppy> apw: thanks for the confirmation
<proppy> will it be -14 ?
<apw> proppy, normally the abi number is the same in lucid yes
<proppy> thanks
<proppy> it seems like it will be built in 2 days :) https://launchpad.net/~kernel-ppa/+archive/ppa/+build/1900054
<proppy> can I dget && debuild an ubuntu kernel .dsc, or are there additional steps needed ?
<apw> proppy, in theory yes, not something i do regularly but the buildd's can build it that way
<proppy> apw: thanks I'll give it a try
<ikepanhc> simon___: I am tracing what ACPI method is executed, if some news, I will update as bug comment :)
<simon___> ikepanhc: thanks a lot
<ikepanhc> simon___: thanks you too for reporting :)
<Corona> hi everybody
<Corona> i'm trying to build a kernel in order to test a patch
<Corona> i'm following these instructions https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<Corona> but apparently they only work for linus's tree and I need to apply a patch to drm-intel-next
<Corona> does anybody know where i can find instructions on how to do this?
<apw> https://wiki.ubuntu.com/Kernel/Dev/QuickBuildLocal
<apw> Corona, that one perhaps ^^
<Corona> thanks apw, but that's not really what i'm looking for. can i just clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git and then apply the patches or do i need to merge the drm-intel-next branch with linus's tree?
<apw> Corona, as the drm-intel branch is just a derivative tree from linus' tree you should be able to do the same thing to it you can the linus tree
<apw> though i'd have thought you really want an ubuntu tree and cherry-pick the patch you need onto it
<Corona> the patch is in mailbox format so that's why i was told to use git
<Corona> here's the patch, but i can't get the kernel to compile when i apply it
<Corona> https://bugs.freedesktop.org/attachment.cgi?id=36959
<apw> how does it fail
<Corona> it doesnt say much, the compilation process stops with "error 2"
<Corona> [debian/stamp/build/kernel] Error 2
<Corona> i just started over with a clean tree so i'm going to have lunch while it compiles
<Corona> and see if it works this time
<jjohansen> gah sometimes /me can't stand C++
<soren> jjohansen: Only sometimes?
<jjohansen> soren: I can blissfully ignore it when I'm not doing something with it
<soren> jjohansen: True.
<soren> still... It's always lurking somewhere. *shudder*
 * cking is glad ACPI AML code is not like C++
<jjohansen> hehe, but are they really any more sane?
<cking> both make me feel insane
 * smb tries to imagine object oriented BIOS code and shudders
<JFo> well that was a bit odd
<smb> JFo, Odder than the usual oddness?
<JFo> indeed
<JFo> my machine went dark and wouldn't respond at all
<smb> Thats odd
<JFo> never done that before
<JFo> heh
<smb> Hm, were you still on Lucid or Maverick?
<JFo> this is Lucid\
<cking> JFo, run out of power? ;-)
<JFo> no cking I checked that ;)
<smb> Went black means just screen black but some parts still running or shutdown?
<cking> can you ping it?
 * smb imagines JFo sitting in front of his laptop with a triangle: "Yep, that works!" :-P
<cking> gosh, we're being very literal today
<smb> Yeah, must be something in my coffee today
<JFo> heh
<JFo> smb, looked like there was HDD activity
<JFo> but no ping, ssh, etc
<JFo> the backlight was still on
<smb> Ok, so rather hang than thermal shutdown
<JFo> just nothing displayed
<smb> Really sounds like some stuff that apw had seen. But that was rather on boot
<smb> Like the drm driver locked down hard while not refreshing or so
<jjohansen> JFo: did it happen on resume, perchance?  I've seen the screen come back from resume briefly and then go dark.
<JFo> no, this was a fresh startup
<smb> during startup?
<JFo> jjohansen, I did have that happen though at the sprint
<JFo> smb, after
<smb> ok
<JFo> it came up, I logged in, started things
<JFo> and then went for coffee
<JFo> and when I came back it was like that
<smb> So could be power save mode
<smb> for the screen
<JFo> could have been
<JFo> but the backlight was still on
<JFo> so the screen was on
<cking> and maybe GPU lock up
<JFo> and I have no screensaver configured
<smb> I believe that DMPS thing sill kicks in
<JFo> brb, i need more coffee :)
<diwic> A bug is sitting on my screen.
<smb> Hm, on it has the advantage that you can squash it more simply
<diwic> smb, it's likely to turn into SAUCE then ;-)
<smb> heh :)
<JFo> don't look at me. I'm all for smashing bugs ;-)
<apw> ogasawara, kernel has been NEW'd other than arm
<JFo> Live NEW'd kernels?
 * tgardner thinks jfo is a sick puppy
<JFo> heh
<diwic> What is your favorite C debugger?
<diwic> ie GDB frontend
<cnd> morning everyone :)
<diwic> morning cnd
<cnd> anyone know how linaro stuff flows to the ubuntu kernel
<cnd> things like Dave Martin's perf patches that he posted about on the kernel-team mailing list?
<cnd> apw, tgardner, ogasawara? ^^
<apw> cnd, they have their own master tree
<cnd> apw, so does that mean that if we want Dave's cool patches, we need to have them submitted specifically for the maverick kernel?
<amitk> cnd: isn't that why he posted it to the k-t list? Do they not apply?
<jwest-> hi
<jwest-> is the 2.6.35 kernel released today
<diwic> cnd, I look through the canonical-kernel-team list but can't find anything from Dave Martin...?
<ogra> cnd, depends on the kernel
<ogra> cnd, for omap4 we still have the separate branch, omap3 gets built from the ubuntu source package, i guess you will find linaro patches only in the linaro branch and binaries
<cnd> diwic, the kernel-team@lists.ubuntu.com mailng list
<jwest-> do you guys think i should update to the 2.6.35 kernel?
<jwest-> or wait?
<cnd> ogra, I'm interested in Dave's perf patches
<cnd> which aren't arch specific
<JFo> jwest-, depends on what the machine you are upgrading is used for
<diwic> jwest-, we always need more testers :-)
<amitk> cnd: you didn't answer me, do they not apply?
<JFo> I don't recommend updates to dev unless it is a test machine
<JFo> yeah, what diwic said :)
<cnd> amitk, sorry, didn't see your msg
<cnd> I don't know if they apply, because I haven't had time to really take a good look
<cnd> amitk, so I was wondering if I needed to take a look, or if they would be pulled automagically into ubuntu
<amitk> cnd: in general, I've been urging everything going into the linaro kernel to be made available for ubuntu (post to k-t). Then it is upto the k-t to decide if they want to them
<amitk> s/for/to
<jwest-> diwic: i could try:D
<amitk> s/want to/want to apply/
<amitk> *sigh*
<tgardner> amitk, y'all could have your very own linux-linaro kernel if I could get the packaged accepted. I sent slangasek and email about it.
<tgardner> s/and/an/
<amitk> tgardner: sure, in this case though, the changes are general enough for other flavours too, I believe
<cnd> sorry for going awol, I'm otp :(
<tgardner> amitk, the perf bits? If they get accepted upstream then we'll likely be able to get 'em via stable (eventually)
<amitk> cnd: understand, you're probably contorting at weird angles to get reception on the iPhone 4 :-p
<JFo> just his hand though
<JFo> he'll be great at gang signs after this
<JFo> Snoop Dogg would be so proud
 * JFo brings the bad humor out
<amitk> lol
<jjohansen> diwic: hrmm, lots of different gdb frontends, ddd is the generic fallback but its kindof slow, Insight and KDbg are worth looking at, I would avoid eclipse unless you want to setup a project just so you can debug
<jjohansen> http://en.wikipedia.org/wiki/Debugger_front_end
<jjohansen> diwic: that is assuming your doing userspace debugging
<cnd> amitk, tgardner, the perf bits aren't really something I would expect to get through -stable
<diwic> jjohansen, I've tried ddd and kdevelop's built-in and haven't really fallen in love with either of them
<cnd> so I think we should just pull them
<jjohansen> diwic: yeah, none of them are great
<tgardner> cnd, once they are actually upstream perhaps
<cnd> tgardner, they are already upstream
<cnd> at least, they are in Arnaldo's tree
<tgardner> cnd, in Linus' tree?
<cnd> tgardner, not yet, but I would assume as soon as he pulls from arnaldo
<cnd> I will try to take a look at the patches myself and test them out
<cnd> and then send the patches on to kernel-team
<slangasek> tgardner, amitk: I've looked at the package in NEW and my archive admin hat is presenting me with concerns, which I will try to get an email back to you about today
<slangasek> (high latency on this stuff since I'm at DebConf this week)
<tgardner> slangasek, ack
<tgardner> smb, is Lucid mvl-dove subject to SRU ?
<smb> tgardner, Only sort of SRU-light
<smb> But you should still have bugs for things to change
<smb> or reports that is
<smb> tgardner, But if you ask about the mvl pull request 
<smb> tgardner, If there is no tracking lp report there should be one. SRU team is looking over those things and it seems to complicate their process when this is missing.
<smb> tgardner, I/we can mass-add the buglinks before applying, but need to know the number
<tgardner> smb, why are you telling me all of this? you should be telling ericm
<smb> tgardner, because you asked
<tgardner> smb, I only asked if mvl-dove was subject to SRU.
<smb> tgardner, Ok, ok, the rest you don't care. :) I'll post a reply
<smb> bjf, Were you usually quick reading ARM pull requests
<bjf> smb, not exactly sure what your question is but I did see eric's pull request, want me to review it?
<tgardner> smb, bjfwhy bother? About all we can actually change is packaging, so the rest is just a waste of time.
<smb> bjf, I just vaguely remembered you once going over some patches from Bryan for fsl. On their topic branches its not really required as they are ok to do what they want
<tgardner> bjf^^
<smb> bjf, The question was more were you planning
<smb> But otherwise I'd agree not to bother too much
<bjf> smb, yes I did look at some earlier mvl patches, was thinking about looking these new ones over, but there's not much we can do other than suck them in
<smb> exactly
<smb> sconklin, Was it you that had used some helper to quickly create man pages from text files?
<octo777>  is the intellegacy driver, the same driver that was the intel driver in older kernels? If so, it should work the same as before once KMS is turned off right ?
<ogasawara> tgardner: seems I don't have the permissions to upload lbm. I've got the package built in my home dir on zinc.  Could you sign it for me and upload in the mean time.
<ogasawara> tgardner: I assume I just need to get cjwatson to add it to the list of packages for the ubuntu-kernel-uploaders team
<smb> ogasawara, Yes, the joy of the name containing the version
<ogasawara> smb: yep, figured that was it
<tgardner> ogasawara, ack
<sconklin> smb: there's a tool that is part of the debian packaging utilities which generates a man page template from the output of "command --help"
<sconklin> smb: stand by and I'll figure out what it is
<smb> sconklin, Hm that might be nice though a bit sparse in this special case
<tgardner> ogasawara, done
<ogasawara> tgardner: thanks
<tgardner> ogasawara, arm finished?
<smb> Hm, debhelper created an .ex maybe I just use that. Annoyingly high effort for such a small package
<ogasawara> tgardner: not yet, I think it has 1 more hr to finish building
<ogasawara> tgardner: once that's done, I'll upload linux-meta
<tgardner> ogasawara, you cuold probably upload the -meta package now. the armel guys can just deal....
<ogasawara> tgardner: true
 * ogasawara uploads
<manjo> JFo, is there a bug review now ?
<JFo> yep
<smb> Damn this time of day already!
<JFo> heh
<JFo> apw, are you joining us?
<manjo> JFo, which list are we looking at now ?
<manjo> JFo, http://qa.ubuntu.com/reports/jfo/kernel-buglist.html ?
<JFo> the kernel-candidate
<JFo> list
<bjf> manjo, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&f
<bjf> ield.subscriber=&field.tag=kernel-candidate&field.tags_combinator=ALL&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_no_branches.used=&search=Search
<manjo> thanks got it 
<bjf> manjo, there is a link off of https://wiki.ubuntu.com/Kernel/Tagging
<manjo> bjf, yep I know... was not sure which list jfo was looking at 1st 
 * ogasawara wonders if anyone can hear me
<ogasawara> or if I've been talking to myself
<bjf> ogasawara, no
<ogasawara> awesome
<JFo> heh
<JFo> talk louder! >:-)
<ogasawara> dammit!
<JFo> :)
<ogasawara> heh
<ogasawara> bjf: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<komputes> Hello kernel folks, I was wondering if there is a way to tell if KMS is currently enabled.
<tgardner> smb, bjf, sconklin, would one of you guys take care of the patch in bug #576066 ? I know I sent it out for review at least once.
<ubot2> Launchpad bug 576066 in linux (Ubuntu Maverick) (and 3 other projects) "ums_cypress missing from lucid server cd (affects: 1) (heat: 46)" [Medium,Fix released] https://launchpad.net/bugs/576066
 * smb thinks he saw it but hasn't looked
<smb> bjf, sconklin Feel free to grab
<sconklin> I'll take it
<bjf> tgardner, reading through the description for bug 611474, he tried a 2.6.35 kernel already
<ubot2> Launchpad bug 611474 in linux (Ubuntu) "Boot fails with busybox prompt using LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS [1000:0058] (rev 08) SAS Disk Controller (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/611474
<tgardner> bjf, hmm, what did he boot in order to get the SAS disk address ?
<tgardner> CurrentDmesg.txt is only a fragment, so I can't tell what kernel it is
<bjf> tgardner, don't know
<bjf> tgardner, the apport-collect was done on 2.6.32
<tgardner> bjf, he says 'Booting from a SATA drive seems to works'. I wonder if he means that the SAS drivers work when booting from SATA.
<tgardner> SAS drives*
<tgardner> in which case that inmplies its an initrd problem
<smb> tgardner, The question would be whether those need additional handling beside of the diver being loaded
<tgardner> smb, well, like what?
<smb> Heck if I knew. But in those dmesg the drive came up quite late after the SATA drive and network stuff
<smb> Do those things need special fw loaded?
<tgardner> smb, yes IIRC
<tgardner> it looks like he able to install to a SAS drive, so that means the boot kernel did the right thing
<smb> Well the boot kernel had a different medium for the root fs
<smb> ie the cd
<tgardner> smb, thats beside the point. the boot kernel _did_ see the SAS drives.
<smb> We are talking about the boot dmesg in the report, which was booted from SATA
<smb> ?
<tgardner> smb, I think so, but its hard to tell
<smb> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
<smb> [    3.772592] ata3.00: ATA-6: ST3120026AS, 8.05, max UDMA/133
<smb> [    3.772596] ata3.00: 234375000 sectors, multi 0: LBA48 
<tgardner> smb, [   34.819922] scsi6 : ioc0: LSISAS1068E B3, FwRev=00192f00h, Ports=1, MaxQ=266, IRQ=16
<tgardner> [   34.856342] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x5000c500237abaf1
<tgardner> [   34.857592] scsi 6:0:0:0: Direct-Access     SEAGATE  ST3300657SS      ES62 PQ: 0 ANSI: 5
<tgardner> [   34.859752] sd 6:0:0:0: Attached scsi generic sg2 type 0
<tgardner> in CurrentDmg.txt
<smb> That is later on in the current dmesg
<smb> yep
<tgardner> huh? Its right at the top
<tgardner> oh well, I'm gonna ask for some clarifications in the bug
<smb> Like you need the root fs (or stuff from there), then it takes a bit to initialize and then the drive come up
 * manjo getting lunch will be back soon
<smb> I am not sure, but I thought boot.dmesg ends when switched from initrd root to real root fs. But I might be wrong
<komputes> smb: ping
 * smb is only available for really simple stuff
<komputes> smb: Do you know a way to tell if KMS is currently enabled.
<komputes> ^ simple?
<smb> Not sure there is a single bit somewhere. apw do you know that. Otherwise usually you would see special drmfb devices...
<tgardner> komputes, as far as the kernel team is concerned, the first step towards debugging desktop issues (like KMS) is to try a recent release.
<komputes> tgardner: right, in mode cases that would do however I simply want to know if there is a way to tell if, in the current session, xorg or the kernel is doing mode switching
<smb> Most drivers seem to emit stuff like
<smb> [   15.602350] [drm] radeon defaulting to kernel modesetting.
<smb> Hm, not intel as it seems
<komputes> smb: interesting, dmesg...eh?
<smb> komputes, Yep
<komputes> tgardner: would explain why I can't see it for my intel card
<smb> But there you would see inteldrmfb being used which iirc indicates kms
<komputes> ok, well thanks guys, that helps - would be nice to see it on i915 driver as well, but this is good enough as an indication :)
<komputes> and tgardner, thanks for following up on Bug #611474, much appreciated
<ubot2> Launchpad bug 611474 in linux (Ubuntu) "Boot fails with busybox prompt using LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS [1000:0058] (rev 08) SAS Disk Controller (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/611474
<tgardner> komputes, that bug is so old the original reported has probably given up
<komputes> tgardner: bug is 3 days old
<tgardner> hmm, I thought I saw Jan, 2010. oh well...
<komputes> tgardner: probably one of the dupes
<JFo> too many bugs, not enough brain cells
<komputes> tgardner: feel free to mark the dupes in the description as actual dupes of this bug
<JFo> brb, gone to take meds and lunch
<JFo> komputes, we hatesss the duplicatessssss
<JFo> :)
<komputes> JFo: stuff happens
 * tgardner lunches
 * smb goes away
<proppy> Hi, it seems kernel 2.6.35 headers package are broken
<proppy>   linux-headers-2.6.35-14-generic: Depends: linux-headers-2.6.35-14 but it is not installable
<proppy> E: Broken packages
<proppy> does someone have a clue ?
<proppy> (from kernel-ppa)
<tgardner> proppy, i386 ?
<proppy> amd64
<proppy> just installed .../linux-image-2.6.35-14-generic_2.6.35-14.19~lucid1_amd64.deb
<tgardner> proppy, you gotta wait until i386 finishes.
<jjohansen> ->Lunch
<proppy> oh ok, 
<proppy> the package seems there thought linux-headers-2.6.35-14-generic_2.6.35-14.19~lucid1_amd64.deb
<proppy> only one of its dependencies is missing
<tgardner> proppy, all of the linux-headers packages depend on a package that is only built for i386, so it'll be awhile yet
<proppy> oh ok, tgardner thanks for this information
<proppy> so I should wait until https://launchpad.net/~kernel-ppa/+archive/ppa/+build/1900054 is done right ?
<proppy> 05/08 ;0
<proppy> :)
<tgardner> proppy, I don't know whats taking so long, but I wanted to advertise the amd64 binaries so folks could do some testing
<proppy> tgardner: do you want me to do any test in specific ?
<tgardner> nothing particular other then just using the kernel
<proppy> was looking for this patch http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commit;h=a1e80fafc9f0742a1776a0490258cb64912411b0
<proppy> obviously it is included in 2.6.35-14
<proppy> tgardner: do you know if I could me the missing package myself ?
<proppy> apt-get source linux-headers && debuild ?
<tgardner> yeah, if you know a bit about building the kernel. https://wiki.ubuntu.com/Kernel/Dev
<proppy> tgardner: thanks for the pointer
<proppy> 'fakeroot debian/rules binary-indep' was what I was looking for
 * ogasawara lunch
<proppy> tgardner: asciidoc is also needed for building indep
<proppy> https://wiki.ubuntu.com/Kernel/Dev/QuickBuildLocal#Packages%20required%20on%20a%20build%20system
<tgardner> proppy, 'sudo apt-get build-dep linux'
<proppy> oh ok, should we updated the wiki page ?
<tgardner> proppy, I need to experiment a bit. I think build-dep doesn't work as well on older releases.
<proppy> dpkg-deb: building package `linux-headers-2.6.35-14' in `../linux-headers-2.6.35-14_2.6.35-14.19~lucid1_all.deb'.
<proppy> \o/
<octo777> anyone having problems with the kms enabled intel driver locking up intermittently ?\
<JFo> octo777, in Lucid?
<Sarvatt> komputes: grep -E '(nouveau|drm)fb' /proc/fb
 * manjo out for now 
#ubuntu-kernel 2010-08-03
<komputes> Sarvatt: awesome, thanks
<komputes> Sarvatt: ATI will show 'drm'?
<Sarvatt> ati/intel have drmfb's nouveau only has KMS
<komputes> ah yes - [drm] radeon defaulting to kernel modesetting.
<Sarvatt> its looking for nouveaufb or drmfb
<komputes> Sarvatt: sorry, confused. again from the beginning.
<komputes> /proc/fb contains a list of frame buffer devices, with the frame buffer device number and the driver that controls it
<Sarvatt> yeah if nouveaufb or any of the drmfb's are in there it's using KMS
<komputes> Sarvatt: and just to be clear those drmfb's are inteldrmfb, nouveaufb, radeonfb
<Sarvatt> nouveaufb radeondrmfb or inteldrmfb
<komputes> cool, thanks Sarvatt 
<Sarvatt> no problem, also I forgot but vmwgfx is svgadrmfb as well
<komputes> Sarvatt: which are?
<ripps> Can someone please mentor me with l-b-m? I want to add an updated wacom module fix problems with new wacom bamboo tablets. I've already discussed this and submitted a proposal on the mailing list, but nobody has responded. See bugs #568064 and #606278
<ubot2> Launchpad bug 568064 in linux (Ubuntu) "Wacom new bamboo models are not recognized in Lucid (affects: 19) (heat: 101)" [Undecided,Confirmed] https://launchpad.net/bugs/568064
<ubot2> Launchpad bug 606278 in linux-backports-modules-2.6.35 (Ubuntu) "Add linux-backports-modules-input (affects: 6) (dups: 1) (heat: 42)" [Undecided,New] https://launchpad.net/bugs/606278
<ripps> Since I can see any sign of anybody working on this, I wanted to know if somebody can help me write a patch instead. I've taken a look at the l-b-m source, but it's so complicated I can't really make much sense of it.
<ripps> *don't see any sign
<ion> It might be nice to have CONFIG_COMPACTION on.
<ripps> I'm not some noob with packaging, I was just hoping somebody give me some hints or guidance on how to start adding a new component to l-b-m
<Sarvatt> ripps: does l-b-m make sense for something thats not a backport? what's wrong with your dkms package?
<ripps> Sarvatt: nobody would accept it. MOTU's said to try and get it into Debian, and Debian said that it was just working around a problem with the kernel. Problem is, the linuxwacom project isn't updating their wacom kernel source because apparently their refactoring it or something.
<ripps> After discussing it here, I was advised to propose an addition to linux-backport-modules. But apparently, nobody wants to help me get in there, either.
<tjaalton> any known regressions in the current lucid kernel? I 
<tjaalton> hrm
<tjaalton> I'm unable to do a full install (~2500 packages) anymore, since dpkg sees some packages are corrupt (same size, different md5sum as on the archive)
<tjaalton> or when unpacking some config stubs in /tmp are missing etc
<tjaalton> maybe I should try with ext3 to rule it out
<tjaalton> ah, actually.. the installer image is the release one :)
<tjaalton> the one that worked was from March
<tjaalton> though the corruptness happens on an installed system as well, and that has the latest kernel
<apw> /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
<era> hi ogasawara, is anything being done to implement this? https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/590090/comments/7
<ubot2> Ubuntu bug 590090 in ndiswrapper (Ubuntu) (and 1 other project) "package ndiswrapper-dkms 1.56-1 failed to install/upgrade: ndiswrapper kernel module failed to build (affects: 40) (dups: 3) (heat: 206)" [Medium,Confirmed]
<apw> if ! git remote | grep FOO >/dev/null; then echo NO; fi
<tumbleweed> can anyone suggest things to try and get useful debug information? Got a user who's USB controller seems to hang ~once a day (leaving him without working keyboard and mouse). Nothing interesting in kernel/X logs, and lsusb hangs on open("/dev/bus/usb/002/005")
<tumbleweed> nm that, after a while, starteg tetting task blocked messages in kernel logs
<Ejdesgaard_> hi, is there any chance that https://bugzilla.kernel.org/show_bug.cgi?id=16315 will be backported to 10.04 LTS?
<ubot2> bugzilla.kernel.org bug 16315 in i386 "icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine" [Normal,New]
<smb> Ejdesgaard_, If the patch goes upstream as a stable patch it will come back as soon as upstream stable picks it up
<JFo> lag, the picture is up on my Facebook
<JFo> sent to you in e-mail
<lag> JFo: That's awesome!
<JFo> :)
<lag> JFo: http://people.canonical.com/~ljones/lastsupper/
<JFo> nice!
<JFo> not a bad approximation
<lag> It's there or there abouts 
<lag> Someone is facing completely the wrong way and I'm a few degrees off
<lag> Overall I think we did okay :)
<vanhoof> lol!
<vanhoof> you guys werent kidding around :D
<Ejdesgaard_> smb, it was included in .35-rc4
<bjf> ##
<bjf> ## Kernel team meeting in two hours
<bjf> ##
<ogasawara> era: it seems that bug was recently resolved in the last few hours by the package maintainer
<ogasawara> era: I'm not opposed to going with their plan B in the future and completely dropping ndiswrapper from the kernel but that's a discussion that needs to probably take place on the kernel-team mailing list
<Riddell> jcrigby: has the binary package names in the linux-linaro upload been OKed by the kernel team?
<tgardner> Riddell, its been uploaded, but is awaiting acceptance by an archive admin
<jcrigby> Riddell: I don't know.  What constitutes approval.
<Riddell> tgardner: why do you think I'm asking :)
<Riddell> jcrigby: tgardner's blessing? :)
<tgardner> Riddell, random curiosity?
<tgardner> Riddell, slangasek said he had some concerns, but he's at debconf
<Riddell> why do some of the binary packages have "linaro" in the name and some go for the -1000 suffix?
<tgardner> Riddell, um, not supposed to. I guess I'd better look closer. I only looked at the control file
<jcrigby> I tried to follow the abstracted debian model.  May have messed up.
<Riddell> well it looks deliberate I presume there's a reason why that's the best way to do it
<jcrigby> tgardner:  I removed a bunch of entries from the control file yesterday.  It now looks like the ti-omap4 control file.
<Riddell> e.g. linux-headers-2.6.35-1000
<tgardner> Riddell, whats the URL for looking at the generated packagesd?
<Riddell> tgardner: there are no generated packages, I'm reviewing the source
<jcrigby> I think you will see the same convention in the ubuntu kernel
<jcrigby> without the 1000
<tgardner> Riddell, according to debian/control I think the package names are correct. it follows the same model as other kernel topic branches
<Riddell> yeah that's the ABI number
<Riddell> but it seems curious to namespace some packages with "linaro" and some with <mega big ABI number>
<smb> Ejdesgaard_, Is that definitely needed for 2.6.32 (10.04 LTS) as the patch seems to have been sent for 2.6.33.y specifically
<tgardner> Riddell, oh, you mean the 'linaro' part? I guess he's using it to distinguish these kernel binaries from the omap4 packages that are already in the archive.
<Riddell> tgardner: yeah that makes sense.  bumping the ABI to 1000 is what seems strange to me
<tgardner> jcrigby, so, do you want to respin with new binary package names?
<tgardner> Riddell, we use the ABI number to distinguish between kernel topic branches
<tgardner> otherwise we'd have binary package name collision
<jcrigby> tgardner:would be glad to if someone tells me what to change them to
<Riddell> I'd have thought e.g. linux-linaro-headers-2.6.35-1 would make more sense
<tgardner> Riddell, its a restriction of the installer, which insists on the linux-header* pattern
<jcrigby> ahh
<tgardner> similarly for linux-image*
<Riddell> tgardner: ah, I knew there'd be a perfectly rational explanation
<tgardner> well, rational is a stretch :)
<jcrigby> on a different matter, I changed the control yesterday and removed some stuff and made Architecture: armel for everything
<jcrigby> so the build system only tries to build on armel
<Riddell> jcrigby: in that case should I reject the current upload and save the non-arm buildds the hassle of building something they don't want?
<tgardner> jcrigby, I'm not sure you can do that. Some of the packages have to be constructed on the default arch (i386), e.g., the headers _all.deb
<jcrigby> tgardner:I made it look like the ti-omap4 control
<jcrigby> is that known good?
<tgardner> Riddell, why don't you go ahead and reject this upload. I
<tgardner> I'll work with jcrigby to fix the control file issues
<jcrigby> tgardner:thanks
<Riddell> ok rejected, ping me when you reupload if you want a quick review
<tgardner> Riddell, later today I think. Thanks for your help.
<jcrigby> tgardner:what is best for you.  Do you want to just send me a patch?
<tgardner> jcrigby, send a pull request with your current bits
<jcrigby> with the ti-omap4 changes?
<jcrigby> style changes that is
<tgardner> jcrigby, yep
<jcrigby> ok, I notice one thing that your comment above sheds some light on:
<jcrigby> Package: linux-headers-2.6.35-1000
<jcrigby> Architecture: armel
<jcrigby> Section: devel
<jcrigby> Priority: optional
<jcrigby> Depends: ${misc:Depends}, coreutils | fileutils (>= 4.0)
<jcrigby> #Provides: linux-linaro-headers, linux-linaro-headers-2.6
<jcrigby> Description: Header files related to Linux kernel version 2.6.35
<jcrigby>  This package provides kernel header files for version 2.6.35, for sites
<jcrigby>  that want the latest kernel headers. Please read
<jcrigby>  /usr/share/doc/linux-linaro-headers-2.6.35-1000/debian.README.gz for details
<jcrigby> explains the commented out Provides:
<tgardner> jcrigby, correct
<apw> bjf, is there a meeting today?
<bjf> apw, yes
<apw> ahh i see your 2 hour warning now
<smb> sconklin, bjf Seems there is no need to start a new release on Lucid, that was already done
<sconklin> smb: yes, I'm just applying the patches. I'll start with the things we wanted on the short list
<smb> sconklin, ok
<smb> sconklin, We should sync on the writeback patches. I got the feeling there is a patchset you got and one I have done
<sconklin> smb let me check what I have and see if they're in my public repo
<smb> bug 643617
<ubot2> smb: Error: Bug #643617 not found.
<smb> hm
<smb> bug 543617
<ubot2> Launchpad bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 11) (dups: 2) (heat: 101)" [Unknown,Unknown] https://launchpad.net/bugs/543617
<smb> same as bug 585092
<ubot2> Launchpad bug 585092 in linux (Ubuntu) "giant IO delays (affects: 1) (heat: 22)" [Medium,In progress] https://launchpad.net/bugs/585092
<sconklin> smb: yes, there's already a branch "bug bug543617" in my public repo that I used to build the test kernel for that bug
<sconklin> oops, branch name is simply bug543617
<smb> sconklin, Let me check what is there. Cause I have been working on that and probably got a different set
<smb> sconklin, My set is there (http://kernel.ubuntu.com/git?p=smb/linux-2.6.32.y.git;a=shortlog;h=refs/heads/writeback) and looks like being a superset of yours. I am currently trying to get Jens Axboe look at those to get them backported to stable upstream. There is a set for 2.6.34.y as well
<smb> sconklin, Have you sent your patches for review already. I cannot remember having seen that
<sconklin> as I recall, they were sent for review weeks ago, and I just picked them up. Let me check
<sconklin> smb: [1/2] writeback: fix WB_SYNC_NONE writeback from umount
<smb> I was holding back because I at least wanted to have some feedback on them before. These series has been taking a lot of time to mature upstream
<sconklin> [2/2] writeback: ensure that WB_SYNC_NONE writeback with sb pinned is sync
<smb> Ok, maybe my bad not deleting those
<sconklin> smb: OK, I just grabbed them and built a test while you were out sick because rtg asked about them
<smb> sconklin, Please don't pick them for applying now
<sconklin> smb: they were still active in patchwork also
<sconklin> ok, I won't pick them
<smb> Right, I should have marked them as superseeded 
<smb> Thanks. Unfortunately there was a time in between when I knew the ones we had were not good but upstream was not fixed yet. And not to forget I did not set them as rejected
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<smb> sconklin, The set now seems to be ok, but as you can see in that tree its a huge set.
<smb> sconklin, The only thing we need to remember is to revert the workaround when we apply the writeback set
<sconklin> smb: I'll apply the graphics fixes for the two issues we have patches for, then the writeback patches, then the stable update, OK?
<smb> sconklin, Leave out the writeback patches completely. I want to get feedback on the backport first and then do another round of sending those to the kt-mailing list
<sconklin> smb: ok
<vanhoof> sconklin: i assume you need that sru sooner than later for the x201 display bug?
<sconklin> vanhoof: yes, I'd hate for it to end up being the gating factor
<vanhoof> manjo: ^^ :D
<manjo> yes building kernel with patch now 
<manjo> I will send it to SRU as soon as I am done 
<vanhoof> manjo: ok, i can re-test if you'd like
<manjo> yep that will be great!
<sconklin> vanhoof, manjo: also, people have been ignoring the SRU requests or not completing them properly. We've been fixing them up without complaining, but I'm going to start bouncing them until they are correct.
<smb> sconklin, I removed the writeback parts from patchwork for now so there won't be confusion on that part
<sconklin> smb: ok, but I think I acked them on the mailing list, so you'll want to follow up on that
<smb> sconklin, There is another one to disable CONFIG_LGUEST for hardy lpia which went in as part of the security update to fix the build failure
<smb> sconklin, I probably should post a message there, too
<manjo> Is there an issue with tangerine ?
<manjo> manjo@tangerine:~$ dchroot -c lucid-amd64
<manjo> W: Group âsbuildâ not found
<manjo> E: Access not authorised
<manjo> I: You do not have permission to access the schroot service.
<manjo> I: This failure will be reported.
<manjo> manjo@tangerine:~$ 
<manjo> I was able to dchroot just couple of hrs ago
<JFo> <-starving... headed to lunch
<manjo> tgardner, ^^ any idea ?
<tgardner> manjo, I guess you're not special.
<manjo> ?
<bjf> tgardner, i think it's because he *is* "special"
<tgardner> manjo, just kidding. lemme check
<manjo> bjf, thanks
<tgardner> apw, smbgot some oops on tangerine.
 * manjo brb
<tgardner> smb, ^^ need to reboot.
<smb> Hm, just for compiling six kernels in paralell
<smb> ok
<apw> tgardner, stuck in writeback ... smb could that be your writeback issue you had patches for ?
<tgardner> shall we try the 2.6.35 kernel?
<bjf> ogasawara, you want me to leave "delta-review" on the agenda?
<smb> tgardner, apw Let me have a quick look
<ogasawara> bjf: I'd say take it off
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-10 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ogasawara> bjf: the last big item is to review if any of our ubuntu drivers need updating (which I suspect they won't)
<bjf> ogasawara, it's gone
<sconklin> smb: do we put the buglink for the stable update bug in every patch that's part of a stable pile?
<smb> sconklin, yes. maint-modify-patch
<sconklin> ok, doing that now
<smb> tgardner, apw Seems the process that was stuck first was returning later. So it might well be the slow writeback problem
<bjf> apw, you still have two agenda items do you want to keep them?
<tgardner> smb, lets try the LTS backport kernel for awhile.
<simar> I want to triage bugs for kernel at first. So I'm going to read documents of Ubuntu Kernel Bug triaging ..
<apw> bjf, the misc one is likely redundant
<smb> tgardner, as long as we can switch back to the lts kernel later, ok. Cause that machine is good for running stress io tests
<smb> tgardner, I am off it again, so you can reboot if you like
 * smb is gone
<manjo> tgardner, please let me know when tangerine is back
<apw> simar, sounds great for us ...
<manjo> simar, talk to JFo he should be able to help you as well 
<manjo> simar, he leads the bug triaging effort 
<manjo> tgardner, looks like tangerine is back... can I use it ?
<manjo> ah same issue cannot dchroot ...  
 * manjo getting lunch will be back soon 
<tgardner> manjo, should be OK now. you'll need to logout first.
 * ogasawara lunch
 * jjohansen lunch too
<sconklin> manjo, vanhoof: The graphics patches you wanted are now in the lucid repo
 * manjo sconklin beer++
<bjf> ogasawara, sconklin just pushed some patches to the lucid repo is there anything that will automatically build that (some kind of pre-proposed / stable crack of the day)?
<ogasawara> bjf: hrm, I can't remember if smb's pre-proposed in the kernel-ppa builds automatically
<tgardner> ogasawara, bjfAFAIK it does
<ogasawara> bjf: it certainly should be easy enough to make it do so automatically as apw does the same for the latest maverick tip
<bjf> ogasawara, that's what i thought, was just wondering if we already did it
<bjf> tgardner, i guess we'll know in a bit then
<manjo> latest maverick iso i386 from cdimage current does not seem to boot ... 
<manjo> I recall apw posted something in this regard wrt to usb keys .. anyone recall ? 
<ogasawara> manjo: bug 608382 ?
<vanhoof> sconklin: awesome!
<ubot2> Launchpad bug 608382 in usb-creator (Ubuntu) (and 1 other project) "USB images of Maverick CDs fail to boot with -- Error: Unkown keyword in configuration file (affects: 13) (dups: 1) (heat: 70)" [High,New] https://launchpad.net/bugs/608382
<manjo> looking 
<manjo> ogasawara, thanks a ton 
<tgardner> bjf, kernel-ppa@zinc:~$ crontab -l
<tgardner> # m h  dom mon dow   command
<tgardner> 0 *    *   *   *   $HOME/buildscripts/mainline-build/kernel-version-map >$HOME/public_html/info/kernel-version-map.html.new && mv $HOME/public_html/info/kernel-version-map.html.new $HOME/public_html/info/kernel-version-map.html
<tgardner> 0 09    *   *   *   USER=kernel-ppa $HOME/kteam-tools/mainline-build/mainline-trigger >>$HOME/logs/mainline-trigger 2>&1
<tgardner> 5  *    *   *   *   USER=kernel-ppa $HOME/kteam-tools/mainline-build/cod-execute >>$HOME/logs/cod-execute 2>&1
<tgardner> @hourly /srv/kernel.ubuntu.com/www/scripts/gitfind > /dev/null 2>&1
<manjo> ogasawara, if you are channel operator can you add "10.10 USB boot issues see https://launchpad.net/bugs/608382 for workaround" ? 
<ubot2> Ubuntu bug 608382 in usb-creator (Ubuntu) (and 1 other project) "USB images of Maverick CDs fail to boot with -- Error: Unkown keyword in configuration file (affects: 13) (dups: 1) (heat: 70)" [High,New]
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-10 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! || 10.10 USB boot issues see https://launchpad.net/bugs/608382 for workaround
<apw> ogasawara, bjf, sconklin-gone, the pre-proposed engine builds all of the releases, assuming they have non-ignored commits following a release
<bjf> apw, yes, i was looking at the scripts and sort of decided that
<bjf> apw, if i understand it, they should kick off 0900 UTC
<apw> bjf yes indeedy
<apw> bjf with the new queuing ability we could reschedule the pre-proposed to a better time independantly if needed
<apw> night
<bjf> g'night
#ubuntu-kernel 2010-08-04
<johanbr> hi... on the first suspend after a cold boot, my laptop suspends immediately after the hard drive is parked
<johanbr> but on subsequent suspends, there's about a five-second delay after the hard drive is parked... does anyone know why this might happen?
 * manjo out 
<amitk> morning
<smb> morning
<amitk> hey smb 
<ikepanhc> good morning .eu :)
<cooloney> morning guys
<cooloney> amitk: one short question for you, need i use external powered usb hub for beagleboard, right?
<amitk> cooloney: yes
<amitk> hi ikepanhc 
<cooloney> i got an external powered usb hub to my BB's usb host port.
<cooloney> amitk: but doesn't work. so weird.
<amitk> cooloney: which port did you connect it to? the ehci (standard) port or the OTG port?
<cooloney> amitk: the standard EHCI port
<amitk> cooloney: nothing is detected?
<cooloney> amitk: i am trying to install the system from SD card, so no chance to get the dmesg
<cooloney> amitk: but i can change the bootargs to see from serial maybe
<amitk> cooloney: ohh, you have C3 right?
 * ikepanhc updating maverick and praying
<cooloney> amitk: yeah C3
<amitk> cooloney: Hardware issue on rev C3 - the EHCI port on some rev C3 boards is unstable and will disconnect hubs/devices. Symptoms are: devices are disconnected from the port and cannot be reconnected without a reboot. It appears the shared 1.8V rail between the OMAP3530 and the power chip was getting noisy. Suggested solution (works on many boards) is adding a 22 uF 0805 package SMT capacitor atop the existing cap on C97. If SMT parts 
<amitk> cooloney: http://elinux.org/BeagleBoard#EHCI
<amitk> cooloney: time to get out the soldering iron ;)
<jk-> heh
<cooloney> amitk: oh yeah. i need 22uF 0805
 * ikepanhc updated, looks great :)
<amitk> ikepanhc: you updated yourself?
<ikepanhc> amitk: ahah, update my machine, not my brain :)
 * apw has to shift locations
<tgardner> apw, have you run into 'Cannot make directory '/var/run/screen': Permission denied' ? Seems that the /var/run/screen directory isn't correctly created at boot time.
<apw> tgardner, no ... is that something to do with you using screen as your default on login ?
<tgardner> apw, nope, just running jobs on remote servers. I rebooted tangerine this AM and found screen no longer worked.
<tgardner> there must be a service startup rule somewhere.
<apw> ahh ... not a bit screen user so i'd probabally not hit it
<tgardner> apw, really? I thought everyone was seduced by the wonders of screen
<apw> tgardner, i am a little supprised it uses /var/run/ ...
<apw> tgardner, i use it on zinc, thats about it
<apw> /etc/init/screen-cleanup.conf <-- tgardner 
<JFo> I <3 screen
<apw> JFo, yeah its great other than not being able to access scrollback, so i use it for things where i have to, otherwise i tend to run and log locally to a file and tail the file remotely style
<JFo> same here
<JFo> I tail from a non-screened term
<apw> don't get me wrong it rocks for those where you need it
<JFo> oh yes
<apw> tgardner, so thats an upstart job ... so ask upstart if its started
<tgardner> All of my build scripts log locally so I don't have to deal with the lack of scroll back
<JFo> especially for things that run forever and would suffer from unexpected failure
<tgardner> apw, I just ran it by hand. I'd actually already tries it with 'restart', but its not well coded and did nothing
<apw> tgardner, hrm ... sounds like a bug ... cirtianlyu it exists on my maverick boxes ok
<tgardner> now I can't remember what the hell I started out to do
<apw> tgardner, now that i can relate to
<tgardner> oh, updating maverick schroots
<tgardner> apw, ok grubmaster, tell me why emerald boots 2.6.32-21.32-server ? /boot/grub/grub.cfg looks right. nothing in /etc/default/grub, etc
<apw> tgardner, looking#
<smb> saved_entry?
<tgardner> apw, I think it should be booting linux-image-2.6.35-14-server
<apw> tgardner, the config does say 'default = 10' and if i count from 0 that is the 32-21 kernel
<apw> so i think its doing what the config says ... now why thats not default=0 i am not sure
<tgardner> huh
<apw> on my other machines the default = 0
<tgardner> apw, well then, I shall set the default to 0
<apw> tgardner, it seems that the default is set in /etc/default/grub and to 10
<apw> which to my mind is oddness indeed
<smb> apw, Maybe someone tried to set a timeout and hit the wrong line...
<apw> smb, or maybe they wanted to move to an older one, and it tracks it somehow
<tgardner> apw, I'm betting smb is right, someone (perhaps pgraner) wanted a grub menu timeout
<smb> Could be, too. I am also not sure how the save default feature would work
<apw> yeah something mad
<pgraner> tgardner, yea that way me, when emerald was wedged I wanted to throw up grub for 10 sec
<pgraner> tgardner, looks like I got the wrong entry
<pgraner> tgardner, just flip it back
<tgardner> pgraner, you used the wrong option
<apw> and until you get to 10 in the menu it suddenly means something
<pgraner> tgardner, no duh
<tgardner> pgraner, well, she's bouncing.
<pgraner> tgardner, thanks
<tgardner> pgraner, ah, much better
<apw> lag its as likely my end
<tgardner> apw, you're_rally_ quiet
<tgardner> really*
<apw> tgardner, thanks
<lag> apw: Connection failed. Error: (336151568) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
<apw> lag, lovely helpful error message
<lag> Quite
<lag> apw: If I disable SSL I get "Connected. Now logging in..." then nothing
<lag> How does bip know which channels to save logs for?
<apw> heh proper handy
<apw> lag, all open ones i think
<apw> it tracks where you open in your client
<lag> Arh okay
<lag> So you don't need to tell it
<lag> That's good at least
<apw> lag, i think you can give it a list to open by default when it reconnects, otherwise it tracks (or in addition) it tracks places your clients ask for
<apw> note that more than one client can be connected
<lag> apw: I can't even get one to connect :(
<apw> lag, there must be a simpletons quide out there somwhere
<lag> Seemingly not
<lag> apw: http://www.mindforge.org/index.php?option=com_content&task=view&id=70&Itemid=45
<lag> I've done all this
<lag> apw: Sorted!
<ikepanhc> JFo: I am interested in bug 612454, shall I change the status myself or you perfer you triage first?
<ubot2> Launchpad bug 612454 in linux (Ubuntu) "[Packard-Bell EasyNote] asus_laptop problem: wifi (affects: 1) (heat: 3411)" [Undecided,New] https://launchpad.net/bugs/612454
<JFo> ikepanhc, I am fine with you changing it as you see fit
<JFo> :)
<ikepanhc> JFo: thanks :)
<JFo> no problem. you guys are the only ones I don't second guess if I can help it :)
<ikepanhc> JFo: change done, just want to make sure I wont let you hard to track those bugs
<JFo> no, it isn't a problem
<ikepanhc> :)
<manjo> drm-intel-next kernels (2.6.35-997 and 999) also give me a blank screen on boot under lucid,
<manjo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561802
<ubot2> Ubuntu bug 561802 in linux (Ubuntu Lucid) (and 1 other project) "[lucid] [i915] blank screen on Latitude E6410 (affects: 27) (heat: 166)" [Medium,In progress]
<smb> bjf, git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
<bjf> smb ack
<ogasawara> apw: bug 589439 is linked to our config blueprint and I've reviewed it and commented on the config options we have changed as requested.  There is no way I'm going to change the whole lot of them without proper justification.
<ubot2> Launchpad bug 589439 in linux (Ubuntu) "configuration gotchas with Maverick 2.6.35 kernel... (affects: 1) (heat: 63)" [Medium,Triaged] https://launchpad.net/bugs/589439
<ogasawara> apw: is there a way for the bug to remain open and linked to the blueprint but not show up as an open action item on our release page?
<ogasawara> apw: maybe if I set the milestone to ubuntu-later?
<apw> ogasawara, i don't think there is right now, if you put it ubuntu-later i think it'll just show up
<ogasawara> apw: maybe I'll unlink it from the blueprint and then write it down as an actual work item that I can mark DONE
<apw> ogasawara, yeah i've been known to do that too ... its not ideal
 * apw waves to balbir 
<apw> ogasawara, essentially you are saying that the work item is smaller than the bug open life, so actually a manual work item is appropriate in that context
 * balbir waves back
<manjo> apw, is this correct ? git checkout lucid debian 
<manjo> apw, is this correct ? git checkout lucid debian.master 
<apw> ogasawara, and on the original point ... you are sane to not change the ones which you don't need
<apw> manjo, if lucid is your remote then likely its
<manjo> apw, yes.. thanks
<apw> git checkout lucid/master debian debian.master
<bjf> smn, when reviewing your new combined tree we are reviewing everything after 2.6.32.16.6, correct?
<manjo> git remote add lucid1 git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<manjo> manjo@tangerine:~/linux-2.6.34.y.561802$ git checkout lucid1/master debian debian.master
<manjo> error: pathspec 'lucid1/master' did not match any file(s) known to git.
<manjo> error: pathspec 'debian' did not match any file(s) known to git.
<manjo> error: pathspec 'debian.master' did not match any file(s) known to git.
<manjo> manjo@tangerine:~/linux-2.6.34.y.561802$ 
<manjo> apw, ^^
<bjf> smb, when reviewing your new combined tree we are reviewing everything after 2.6.32.16.6, correct?
<apw> manjo, did you fetch your remote ?
<smb> bjf, yes correct
<manjo> no :)
<apw> spanner
 * manjo is wondering if stefan is building on tangerine :) 
<apw> manjo, he has a tendancy to make the load hit about 90 ... most annoying
<manjo> apw, absolutely!
<tgardner> manjo,  16:51:39 up  3:01,  6 users,  load average: 0.58, 0.58, 1.51
<manjo> tgardner, hmm... so my connection has a lag possibly ... should have done top before blaming smb :)
<smb> I am innocent this time
<manjo> apw, do I have to do something special for FAIL: value CONFIG_DEFAULT_SECURITY_APPARMOR Y ?? 
<apw> manjo, zap the enforce configuration
<JFo> I really wish chromium would quit crapping its pants
<vanhoof> JFo: seems to be worse lately
<JFo> it does indeed
<JFo> nigh unusable on my netbook
<JFo> I just opened it and it was up all of 10 seconds
<JFo> segfaulting it seems
<JFo> chromium-browse[29554]: segfault at 0 ip 08619d0f sp bfde07a0 error 4 in chromium-browser[8048000+2214000]
<JFo> looks like it has been reported to google though
<JFo> did you and I ever come to some satisfactory decision on the QA bugs vanhoof?
<JFo> my brain is still fuzzy from sickness
<pgraner> JFo: is that what they are calling hangovers these days?
<JFo> heh
<JFo> nope, but I wonder if that would help at all
<JFo> not the hangover, more the drinking
<JFo> :-)
<JFo> pgraner, someone has requested we re-enact the dogs playing poker next time we do photos
<JFo> I'm up for it
<lag_> Any ideas: http://paste.ubuntu.com/473148/
<lag_> apw: --^
<apw> lag_, nope
<lag_> apw: :(
<vanhoof> JFo: we did, do you have some?
<vanhoof> JFo: from you -> project
<lag_> apw: It's weird how the complicated one works and the "just works", "open" one doesn't!
<JFo> no, just trying to follow up on our chat and my notes
<JFo> ah yes, I remember that now
<vanhoof> ultimately, if QA can make that call, then from QA -> project
<apw> lag_, perhaps some config options are leaking over
<JFo> sweet
<vanhoof> JFo: getting my bits in place, should have it setup soon
<JFo> just wanted to make sure my notes were complete
<JFo> ok cool
<JFo> I'll do some quick and dirty write up for my notes then
<JFo> since I remember now
<JFo> thanks for the reminder vanhoof :)
<lag_> apw: What's to leak?
<lag_> network {
<lag_>         name = "freenode";
<lag_>         server { host = "irc.freenode.net"; port = 8001; };
<lag_> };
<vanhoof> JFo: cool
<apw> 8001 ?
<apw> lag_, ^^
<manjo> lag_, server { host = "irc.freenode.net"; port = 8001; };
<lag_> yep
<manjo> that is what I have too
<lag_> It' what I've always used
<lag_> So shouldn't be an issue
<lag_> It's so annoying!
<manjo> lag_, you are setting up bip ?
<lag_> I've been through the conf 100 times
<lag_> manjo: Yes
<apw> lag_, so i have 6667 in mine
<lag_> I've tried that too
<manjo> lag_, I can send you mine try to compate ? 
<lag_> pgraner is email me his
<JFo> sconklin, I just blew soda all over my laptop
<JFo> thx
<JFo> :)
<vanhoof> lag_: try irc.us.freenode.net
<apw> lag_, perhaps you could put your config as is somewhere
<vanhoof> lag_: see if its a problem where you're being sent to
<lag_> vanhoof: Sure - 1 mo
<manjo> apw, zapping enfore causes other errors ... 
<manjo> apw check-config: /home/manjo/linux-2.6.34.y.561802/debian.master/config/enforce: open failed -- No such file or directory -- aborting
<apw> zap the contents not the file
<manjo> fuck!
<apw> ie make the file empty
<manjo> :)
<JFo> heh
<manjo> apw, finally getting it to build 
<manjo> apw, thanks beer++
<smb> error overflow
<apw> smb, no asuch thing, its a 256 bit integer
<smb> apw, That is, if he gives you enough beer tokens you end up to give him beers
<smb> Thats bad
<JFo> oh no, I took the beer++ as multiple beers rather than coding addition
<JFo> :)
<cking> is beer a unsigned int or signed int? I'd hate it to wrap to -ve
<JFo> cking, it is a Long
<cking> unsigned or signed long?
<JFo> either way, it is big ;)
<cking> a big negative is bad for the beer gut
<JFo> probably unsigned
<JFo> given memory during its use
<cking> struct lame_beer { unsigned int beer:1; };  knowing my luck
<apw> cking, thats all you can take anyhow
<cking> yep
<manjo> apw, processor LNXCPU:00: registered as cooling_device0
<JFo> cking, http://www.youtube.com/watch?v=WESUiQ07ibY
<cking> JFo, that's an old TV ad
<JFo> indeed
<rsalveti> guys, I have some patches I got from TI in my tree and I wanted to publish it somewhere, and kernel.ubuntu.com seems to be the best place to go
<rsalveti> is there an easy way to get access to it?
<rsalveti> otherwise I can just push it elsewhere
<JFo> <-lunch
<manjo> rsalveti, you could send a request pull to the mailing list
 * tgardner lunches
 * manjo getting lunch will be back soon 
<rsalveti> manjo: I know, but is not only the kernel team would take use from it, it's useful to send to the TI guys also, and our team if anybody wants to test them
<rsalveti> it's just a working branch, before sending to review and etc
<manjo> rsalveti, you could also try asking in #linaro
<manjo> I assume they might be the right people to deal with it
<rsalveti> well, it's just a bunch of patches for arm
<ogasawara> rsalveti: I believe tgardner (who just went to lunch) is the gatekeeper for adding accounts to kernel.ubuntu.com/git
<rsalveti>  ogasawara: thanks, will try to ping him later then :-)
<vanhoof> apw: ping
<apw> pong
<apw> vanhoof, ^^
<vanhoof> apw: did that bug match what you were after?
<apw> vanhoof, yeah i think so
<vanhoof> apw: what grapevine did this come through :)
 * apw calls it a day
<cking> it's a wrap
<JFo> pgraner, http://failblog.files.wordpress.com/2010/08/098d342c-a365-44f7-a35f-aa398398404f.jpg
<JFo> :)
<jjohansen> hehe
<pgraner> JFo, rofl
<JFo> :-)
 * jjohansen lunch
<vanhoof> JFo: http://sfbay.craigslist.org/eby/cto/1879395238.html
 * manjo out for the moment 
#ubuntu-kernel 2010-08-05
<KE1HA> All, this isn't a bug, but more of a feature request. I had a fella need more that 4x Serial ports on his base install the other day. The Kenel is set to Max 4x ttyS, and passing a kernel command ixed it: 8250_nr=6 .. where would we make the request for this to be built into the Kernel?
<pgraner> KE1HA, what kernel version did you do this on?
<KE1HA> Oh, boy, it was a couple days ago, but it was the latest 10.04 base install w/Upgrades.
<KE1HA> Let me look at mine real quick.
<KE1HA> Im not sure to be hones, was 32 to 35 somwhere in there. I need to catch the guy in ubuntu IRC again and ask to be certain.
<pgraner> KE1HA, I'm not finding that param in the kernel source, also check the spelling
<KE1HA> It was a Debian solution to pass the kernel param, will go find it.
<pgraner> KE1HA, ok thanks
<KE1HA> pgraner, Here's what led me to the solution, but Im still looking for the Deb document page.
<KE1HA> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440807
<ubot2> Debian bug 440807 in linux-2.6 "increase CONFIG_SERIAL_8250_NR_UARTS (number of serial ports)" [Wishlist,Fixed]
<KE1HA> pgraner, basically, addign this to the boot image in grub solved it for him, he needed 6 ports: 8250.nr_uarts=5
<pgraner> KE1HA, the best way to do it is via the /etc/modprobe.d system and add an "options" line with that param
<pgraner> KE1HA, we keep it at a low number due it consuming memory, since most people have 1-2 ports on average
<KE1HA> pgraner, rr. yes, I didn't understand why he needed that many either, but he did, so we came up with a work around for not ahving to re-compile the kernel. I need to read up on the /etc/modprobe.d method. Still can't fid the flippen Debian page, errr
<KE1HA> cut off the first part of the. I dont knwo whay he needed that many, but he did .. .. ..
<KE1HA> pgraner, where can I read about the mode proble method ?
<KE1HA> modprobe*
<pgraner> KE1HA, here is a decent tutorial that should work
<pgraner> http://atlanticlinux.ie/blog/?p=134
<KE1HA> TNX
<bjf[afk]> pgraner, i just whacked two folks off of the plumbers attendance page
<bjf[afk]> pgraner, (with their permission)
<pgraner> bjf[afk], huh?
<pgraner> bjf[afk], ok, I guess
<stenten> So, my cursor disappeared somewhere between 2.6.35-rc6 and 2.6.35 (final). Would it be more helpful to run a git bisect on the mainline kernel or the Ubuntu kernels?
<jjohansen> rebooting
<RAOF> stenten: If you're using the Ubuntu kernels then bisecting the Ubuntu kernel will likely be more useful - it might some of our sauce.
<stenten> I tested with the two mainline kernels from the mainline PPA, and rc6 works but the final doesn't. 
<stenten> (That's because I just installed A3 for iso-testing, so I only have the -14 (2.6.35 final) kernel installed, and don't know where I could install the older ones from).
<stenten> Trying to find a good tutorial for git-bisect right now, since I've never done it before....
<jk-> stenten: it's fairly straighforward:
<jk-> git bisect good v2.6.35-rc5, then git bisect bad v2.6.35
<jk-> then it'll put you on a commit to test
<jk-> those version numbers would be suitable for testing upstream; you'll need to change them if you're testing the ubuntu kernel
<stenten> Am I supposed to 'git clone' one of the git repositories from kernel.org before I git bisect? I'm *really* confused right now "(
<ion> You need a local repository, so if you donât have one, you need to clone it from somewhere.
<stenten> And that contains all the commits that I'm going to bisect, right?
<ion> Yes
<stenten> OK, I'm git clone-ing the 2.6.35 git repository right now, I'll be back if I get terribly confused again. Thanks.
<jcrigby> cooloney:are you working on bug #588243
<ubot2> Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243
<jcrigby> if not I may take a look at it
<lag_> Morning
<ikepanhc> lag_: its too early for you..
<lag_> Yes, it's fairly early for me (just gone 6)
<lag_> cooloney: ping
<lag_> Morning smb
<smb> lag_, morning
<lag_> cooloney: You there yet?
<lag_> smb: What's the flag to forward SSH keys?
<smb> -A I believe
<apw> smb, -A indeed
<apw> though it doesn't forward your keys per-se rather forwards the connection to your authentication agent
<lag_> How do you use it?
<apw> ssh -A destination
<cooloney_> lag_: yeah
<apw> then that machine can ssh or indeed ssh -A somewhere else, but can talk to the original local key manager to get permission to login
<cooloney_> -A 
<cooloney_> Openfree`: hi
<lag_> It doesn't work :(
<Openfree`> cooloney, hi~
<cooloney_> lag_: -A doesn't work?
<lag_> Yeah
<lag_> ssh -A build-one
<lag_> ssh build-two
<lag_> Password: 
<lag_> :(
<cooloney_> lag_: no idea
<cooloney_> it works for me
<jk-> lag: does build-two have your ssh key in authorized_keys ?
<cooloney_> jk-: yeah, that might be the root cause
<lag_> jk-: Yep
<lag_> I can ssh build-two from dev-one
<lag_> Do the *.pub files need to be there?
<lag_> Or just authorized_keys?
<jk-> just authorized_keys
<lag_> That's what I have
<jk-> so you can ssh without a password from dev-one?
<lag_> ssh build-two from dev-one works
<lag_> Yes
<lag_> To build-one and build-two
<lag_> ----------^
<lag_> OMG - bip took 1.5hrs to log into FreeNode
<jk-> maybe try ssh -vvv build-two, see why it's failing to use public key auth
<lag_> kk
<lag_> apw: If you issue "/etc/init.d/bip restart" how log does it take to connect to FreeNode?
<apw> lag no idea, don't do it ever to be honest
<apw> not hours though
<lag_> :(
<lag_> bip -v ?
<apw> and cirtainly not going to try it now in case t does take hours
<apw> invalid option
<lag_> Really?
<lag_> lag@bip-server:~$ bip -v
<lag_> Bip IRC Proxy - 0.7.4
<lag_> Copyright Â© Arnaud Cornet and LoÃ¯c Gomez (2004 - 2008)
<lag_> Distributed under the GNU Public License Version 2
<lag_> Current version is 0.8.3
<lag_> Correction 0.8.4
<apw> lag_, must be as old as hell :)
<lag_> Yeah
<lag_> Just issued ... safe-upgrade
<smb> upgrade and safe does not compute
 * amitk looks up safe-upgrade
<amitk> is this apt-get ?
<lag_> schroot -q -cmaverick-armel
<lag_> E: Failed to execute â/bin/bashâ: Exec format error
<era> ogasawara, i don't think the ndiswrapper problems are over. my drivers are set up properly and scan for ssids on any kernel i throw at it, but it won't be able to connect on any kernel newer than 2.6.34-5.14
<era> doesn't matter if there is security on the router or not
<tseliot> apw: are your patches for drm (not to make plymouth believe that drm is ready when it's not) ready?
<apw> tseliot, the patches are applied to the uploaded maverick kernel
<tseliot> apw: great, I'll pull them from git
<andreoli> Hi, I just saw that linux-image-2.6.32-24.39 is out, but I can't seem to find it in git. I made a git pull and the last tag seems to be Ubuntu-2.6.32-24.38. How can I update my git in order to work on it?
<andreoli> sorry, I meant linux-image-2.6.34-24-generic, version 2.6.32-24.39Ã¹
<apw> andreoli, yep, the repo is behind as that was a security release
<apw> i'll hastle the culprit and get it up as soon as possible
<andreoli> no problem, apw :) I thought it was my fault somehow (git newbie, trying to learn...)
<andreoli> is it sensible to host several kernel ubuntu packages (with different names) in the same PPA?
<apw> andreoli, no just the rules on exposing security before the binaries are released, prevents us pushing, and its another team which pushes security
<andreoli> ok, thx for the clarification
<smb> apw, I hear ya. Being on that
<cooloney> amitk: i tried enable SMP in omap3_defconfig to built a single kernel for omap2/3/4.
<cooloney> amitk: after fixed some compiling issue, i've built the kernel.
<cooloney> but it doesn't work on my omap3 beagle board.
<amitk> cooloney: I talked to TI engineers and they feel it will take some low-level arch work in arch/arm to get SMP arm kernels to work on UP
<cooloney> it looks like it's not easy to enable SMP in such single kernel
<cooloney> amitk: yeah, i think so
<amitk> so ARM needs to go through the same pain the x86 and other archs did to get SMP kernels working on UP
<cooloney> in SMP code, there some instruction can't be built in gcc as armv6
 * amitk is not surprised
<smb> tgardner, While working there I just noticed an arm branch in the Karmic repo which you have been committing to long time ago. Would you think we need anything from that anymore?
<tgardner> smb, if its not in the archive, then I suspect no
<smb> tgardner, Its at least heavily neglected. The last commit was a year ago.... So I guess, no. Well I tag it before removing the branch
<tgardner> smb, wfm
<lag_> tgardner: Build server orange is broken 
<lag_> schroot -q -cmaverick-armel
<lag_> E: Failed to execute â/bin/bashâ: Exec format error
<tgardner> apw, wasn't that an mmap issue?
<lag_> apw: Tried to fix, but doesn't have perms
<smb> tgardner, The direct issue is binfmt-misc not loaded / set up
<tgardner> lag_, tried to fix how?
<smb> Not sure this was because of an mmap thing
<lag_> Restarting binfmt-misc 
<lag_> Apparently it wasn't started by the init scripts 
<lag_> smb thinks it may be a race
<smb> Or maybe its as simple as needing to add binfmt-misc to /etc/modules...
<tgardner> lag_, restarted, try again
<smb> Hm no, don't have that on my build box and it gets loaded
<lag_> tgardner: That's the badger!
<dnielsen> Any chance of getting  KOSAKI Motohiro's low latency synchrounous lumpy reclaim patch set applied to Maverick?  http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/02107.html
<smb> Is the discussion really finished?
<apw> from the description its still an RFC
<smb> That was my feeling. Mel was also involved and it did sound incomplete. Though, as it showed up on my stable watchlist, it might come that way when done.
<dnielsen> it would be nice to get some more data somehow though, it is attempting to address a bug that has been plaguing the desktop for years so the sooner it dies the sooner we can drink beer
<smb> Sure it would be nice to fix it. But taking patches under discussion from a mailing list for a essential core functionality is like tuning your car according to some information found somewhere. It is crazy enough to it on yourself but you certainly don't want to resell that.
<JFo> or in this case 'regift' ;)
<tgardner> apw, do you plan to add the DEB_STAGE=stage1 patch to debian commonization?
<bjf> moin all
<smb> morning bjf 
<cking> bjf, morning!
<cking> bjf, where do those kernel team iso images appear - are they downloadable from a webby URL?
<bjf> cking, http://kernel.ubuntu.com/~kernel-ppa/testing/
<cking> bjf, you probably can expect what my next question is going to be...
<cking> ..any chance of hooking up my USB stick image generating hacks?
<bjf> cking I thought you were going to get back to me on that
<cking> I believe I sent you an email. lemme see if it got stuck somewhere :-(
<bjf> cking, nope, I just missed it
<cking> 03 2010, ~17:57:35
<bjf> cking, don't know about checking in a vm to kteam-tools
<cking> it's rather big ;-)
<cking> dang, that's one thing that version control cannot handle well
<pgraner>  /query dendrobetes
<tgardner> pgraner, dendrobates isn't it?
<pgraner> tgardner, yea misspelled, thx
<tgardner> a large green frog IIRC
<pgraner> tgardner, that I didn't know
<apw> tgardner, i am assuming all things which get accepted into maverick should also get applied to the common debian
<cking> a poisonous dart frog at that
<tgardner> apw, I'm cnosidering the ripple effect. We still need to get Karmic updated.
<apw> tgardner, its an issue indeed
<apw> tgardner, i don't think i have a good plan if we are not going to commonise en'toto
<apw> ie, all those using the common debian, remain up to date
<tgardner> apw, we need cjwatson to finish his policy update
<cking> bjf, so is this image generator hack a no-goer, or just we need to make sure we keep that vm image somewhere safe?
<apw> tgardner, yeo
<apw> cking, might be worth asking cjwatson when he is back ... as this is something they must have as an issue too for the isos
<bjf> cking, i have no problem adding it to the process, it's just you might have to recreated it if necessary
<cking> apw, what's the issue?
<cking> bjf, I will back it up onto a couple of devices
<apw> cking, the VM is needed to install grub yes?
<cking> yep
<cking> the issue is that grub-install does some over-zealous sanity checks which cannot be spoofed around using loopback or device mapper tricks
<cking> one can modify grub-install, but I cannot be bothered - it's easier to do it in a 15 lines script inside a vm
<tseliot> apw: are you going to backport your 2 kernel patches for drm and fbcon to Lucid. If not, shall I?
<apw> tseliot, do we have those issues on lucid ?
<apw> i've only ever seen the behaviour on maverick
<tseliot> apw: I think I've seen the drm problem but I'll test again, just to be sure
<apw> tseliot, ok thanks ... good to know
<JFo> pgraner, what was the name of the place where you bought our travel case?
<cking> JFo, I think pgraner buys it in bulk 'cos they go missing so frequently at the airports
<JFo> but that would be me since I lost the most this last time :)
<JFo> 3 bags
<JFo> he only had one lost
<cking> JFo, I hadn't realised that. That's really bad news.
<JFo> well, they are back now, but it took 3 days after we landed to get them
<cking> If it's any consolation, I think I found a security cable from UDS that may be yours
<JFo> I'm just looking at getting us a bigger box
<JFo> could be indeed
<cking> JFo, next time fedex your luggage
<JFo> heh
<JFo> <-lunch
<apw_> Test
<bjf> cking, i've added the img creation steps to the dail-iso-builder script and i'm running a test
<smb> apw, Works
<apw> smb, indeed so
<cking> bjf, fantastic. thanks
<cking> much appreciated
 * smb is out
<robbiew> ogasawara: incoming!....https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/554172  (boom!)
<robbiew> :P
<ubot2> Ubuntu bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed]
<ogasawara> robbiew: ack
<ogasawara> 237 comments!
<robbiew> ogasawara: yeah...you can ignore 236 of them
<robbiew> just read Scott's
<robbiew> #237
<vanhoof> prolly a dumb q ... how long does it take for a kernel to move from pre-proposed to proposed?
<tgardner> vanhoof, its somewhat arbitrary for a released kernel, but generally every couple of weeks.
<apw> bug #554172
<ubot2> Launchpad bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed] https://launchpad.net/bugs/554172
<vanhoof> tgardner: cool, thanks
<lag>  /msg NickServ identify nelsons
<pgraner> lag, change it NOW
<Guest46722> Done
<Guest46722> :)
<apw> Keybuk, this EIO thingy on open ... which kernel are you testing
<Keybuk> reports are on both Lucid and Maverick
<Keybuk> I read the source of GIT HEAD
<Keybuk> though the code was last touched in 09
<apw> Keybuk, and indeed the comments at the time say that returning EIO on a 'tty' which has been closed, but not yet completed closing should return EIO
<apw> the implication is that this behaviour is reasonable, and supported by POSIX
<apw> s/reasonable/expected
<Keybuk> I'm not sure POSIX says anything about ttys
<Keybuk> or indeed about the ability to half-close something
<Keybuk> can you point me at the comments?
<apw> do a git log on the file containing tty_reopen
<apw> Keybuk, it is documented as a possible return in the open manual page
<apw>        EIO    The  path  argument  names  a STREAMS file and a hangup or error
<apw>               occurred during the open().
<apw> the implication is that last close being inprogress is a hangup on a tty
<Keybuk> that implication sounds more like an SMP-unaware race condition to me ;-)
<apw> Keybuk, cirtainly the behaviour makes more sense for slow closing things like modems, where there is an external interlock to wait on
<Keybuk> yes, but not /dev/console ;-)
<apw> but it cirtainly seems possible that there is a period during which a closing device is unopenable, for ttys
<apw> and /dev/console is a tty like any other no
<Keybuk> it's not supposed to be
<apw> what makes you say that
<Keybuk> because it's supposed to be a virtual device
<Keybuk> stop trying to kill my pony
<apw> that doesn't stop it being a tty
<Keybuk> it also doesn't stop this being wrong behaviour
<apw> indeed, but it also may well be reasonable behaviour, and if it is then we arn't likely to get a fix past alan
<Keybuk> breaking init doesn't seem reasonable though? :)
<Keybuk> nothing about this is upstart specific, after all
<apw> if init breaks cause it doesn't handle documented return codes, he isn't going to have any sympathy is he
<Keybuk> it's not documented anywhere
<apw> i assume you have to handle EAGAIN and EINTR already
 * Keybuk is reading tty(4)
<apw>        EIO    The  path  argument  names  a STREAMS file and a hangup or error
<apw>               occurred during the open().
<apw> it documented as a valid return from open
<Keybuk> yes, but not any explanation as to why it would occur
<Keybuk> and
<Keybuk> err
<Keybuk> no it isn't
<Keybuk> open(2) does not document EIO
<apw> indeed not, but that a tty is a stream as you can push line diciplines
<apw> (thats for your tty ocmment)
<apw> open 2 is libc right?
<Keybuk> manpages-dev
<apw> 3 is the system call
<apw> (isn't it ?)
<Keybuk> it's not POSIX either FWIW :p
<Guest46722> It was wrong anyway! :)
<apw> its documented in the 3 an page, which calls itself the POSIX one
<Guest46722> Doh
<Keybuk> assuming you're looking at SUS, STREAMS only refers to the XSI STREAMS extension
<lag> It was wrong anyway :)
<apw> i am reading man 3 open on my linux box
<lag> Which is why it keeps logging me in as guest :)
<Keybuk> I don't have an open(3)
<Keybuk> what package does that come from?
<apw> how do i find out
<Keybuk> it could be the snarf'd copy of SUS
<Keybuk> it says STREAMS in capitals like that, it matches SUS
<Keybuk> which means it's XSI STREAMS, not "tty"
<apw> a tty is a steeams device though, as you can stack streams modules onto it, like line diciplines ?  no?
<Keybuk> no, STREAMS is a very specific standard
<Keybuk> you can't randomly apply one standard to something else to suit your purposes ;-)
<mjg59> STREAMS is something you don't want to know about
<Keybuk> so
<mjg59> It's the System V networking failure
<Keybuk> this behaviour is not documented
<Keybuk> this *return code* is not documented
<Keybuk> so it's completely reasonable for me to not handle it
<apw> Keybuk, do you handle EINTR ?
<Keybuk> what's more, it only broke in Sep 2009 as a result of a kernel change
<Keybuk> apw: yes.
<apw> manpages-posix-dev: /usr/share/man/man3/open.3posix.gz
<Keybuk> apw: right, that's SUS - so STREAMS refers to XSI STREAMS which is not relevant (and deeply scary)
<apw> well i suggest you handle it now, regardless of whether its reasonable
<Keybuk> no, I suggest you fix the kernel
<Keybuk> since this is a regression
<apw> cause even if we can fix it, its likely to take months to get it accepted
<Keybuk> it's affecting a small number of people
<apw> the reality is if we bodge it in upstart it'll fix everyone esle as it'll stay open forever and avoid the issue for ever
<apw> giving us time to persue a fix
<apw> manpages-posix-dev: /usr/share/man/man3/open.3posix.gz
<Keybuk> it's possible that we'd turn this into an infinite loop, etc.
<Keybuk> I'd rather keep the known bug
<apw> ok works for me
<Keybuk> while you work on fixing the kernel regression
<apw> how often is it occuring ... so i can prioritise it with the other issues we have
<Keybuk> (plus I know full well if I bodge it, the bodge will become *the* fix, and the kernel fix will never appear)
<Keybuk> apw: some people (including support customers) claim most boots
<Keybuk> others say intermittently
<Keybuk> others say they've seen it once
<Keybuk> support have given it P3
 * tgardner lunches
 * apw finds it .. maybe
<joshhunt> hi, i've got some patches which were accepted in the upstream kernel for 2.6.36, but would like to see them get into Maverick. I think they're candidates for 35 stable, but haven't submitted them yet. I was wondering what the ubuntu kernel release schedule was like and if you are going to sync up with stable before Maverick is released?
<apw> joshhunt, we normally start following the stable branch once the kernel releases at our chosen level
<apw> so we're likely to have time to take the first few stable updates for 2.6.35 for maverick before release
<joshhunt> ok great. so if i can get them into one of the first few releases of 35 stable then that would probably be the best way to get them into maverick, right?
<apw> joshhunt, yep
<joshhunt> apw, thanks for your help.
<sconklin> ls
<JFo> bin   cdrom  etc   initrd.img      lib         media  opt   root  selinux  sys  usr  vmlinuz
<JFo> boot  dev    home  initrd.img.old  lost+found  mnt    proc  sbin  srv      tmp  var  vmlinuz.old
<JFo> :)
<JFo> <- smartypants
 * jjohansen lunch
 * ogasawara lunch
<Keybuk> apw: I just realised something
<Keybuk> you the commit that "fixes" the Input/output error
<Keybuk> if you look at the patch, it doesn't cover all tty drivers
<Keybuk> just serial ones
<JFo> pgraner, tgardner so we aren't attending this before plumbers? http://events.linuxfoundation.org/events/linux-kernel-summit
<jjohansen> JFo: if your invited, sure
<JFo> ah, I just got to the invitation bit :)
<JFo> thanks jjohansen 
<apw> Keybuk, will take a closer look tommorrow on an awake head.  have some theorys to look over
 * tgardner checks out
 * cking calls it a day
#ubuntu-kernel 2010-08-06
<Kenny_Duehit> anyone have time to help me with a Kernel Panic I am having? it's grub related and occurs on boot up.
<stenten> If I'm git-bisecting, is this how I'm supposed to compile the kernel after getting a commit to test? https://wiki.ubuntu.com/Kernel/Dev/QuickBuildLocal
<stenten> I tried using the directions here: http://ubuntuforums.org/showthread.php?t=311158 but it failed after compiling for 3+ hours: http://paste.ubuntu.com/473800/
<lamont> where's my ppc kernel guy
<jk-> lamont: i don't think that's me, but I can try to help :)
<lamont> root     31624  0.0  0.1   5624  2196 ?        D    Aug02   0:00          \_ /usr/lib/apt/methods/http
<lamont> jk-: it's more one of "want me to look at anything before I stab the poor Xserve?"
<lamont> last thing in dmesg is the RAID check starting almost 2 days before the timestamp on the build log
<lamont> I'm of a mind to just reboot it and see when it gets mad next
<lamont> or maybe even just trigger a check of the array to see if it crashes again faster
<lamont> yeah - that'll let it get started again before I sleep
<lamont> and off to bed with me
<jjohansen> rebooting
<MTecknology> apparmor is in the mainline kernel... isn't it?
<MTecknology> I'm not able to find that little guy
<MTecknology>  /SECURITY_APPARMOR = :(
<MTecknology> Is that not until 2.6.36?
<starkraving> The last few kernel releases have disabled my wireless card, Dell Inspiron 6400. With the new kernel release today the last one that worked has now rolled off of grub. Any idea how to get it back?
<starkraving> The wireless card shows up in LSPCI but it doesn't show up in my list of interfaces
<cybrocop> Hi, I wonder if I can ask a Linux kernel/system question. I don't have a bug necessarily, but I have a question about performance of certain activities.
<cybrocop> Does the "cp" command make any special performance optimizations to make it run faster than a custom written C code (read a block from source and copy a block to destination). I realize the source of cp is available but I was hoping someone could give me a quick answer. I have a software that I'm writing that will need to (among other things do file copies), and I wanted to implement the copying myself in order to keep track of bandwidth. (Don't
<cybrocop> want to copy too fast and use up IO for other procs.)
<lapion> anyone from ubuntu-kernel-lucid-ppa in here ?
<lapion> Has support been removed for /dev/dsp ?
<apw> lapion, not sure what PPA that is, got a url ?
<lapion> ppa,launchpad.net/kernel-ppa/ppa/ubuntu
<apw> lapion, so do you mean the maverick kernel in there?
<lapion> apw yes..
<lapion> the latest versions the i915 xserver/kms doesn't crash
<apw> yes the maverick kernel has OSS support turned off, as maverick supplies OSS compatibility via pulseaudio
<lapion> as often
<lapion> yes but there is a version n there for lucid as well...
<apw> lapion, yep, understood, but the version compiled for lucid is the same config as for maverick
<apw> so i can believe that OSS support is missing on lucid if you are using that kernel
<apw> or better put, using that kernel on lucid
<lapion> slight problem, mythtv doesn't work well with alsa or pulse, and the tvcard has it's own dsp running at 32k the only way to get it to work is by using dsp in mythtv
<apw> lapion, a problem indeed, not sure what to say, currently there is no suoport for that kernel on non-server, and worse currently no mechanism for it to have a different configuration from that in maverick -- even if we wanted to fix it
<apw> tis not even possible to file a bug against the package as the package is not yet in the official archive
<apw> lapion, i suspect your best bet is to report this on the kernel-team@ email list ... and we can think about it
<lapion> any info on how to add dsp-emulation on pulse ?
<lapion> *to
<apw> lapion, that i have no idea about sorry ... drop an email to the list and we can start the discussion
<cking-afk> http://launchpadlibrarian.net/53159327/buildlog_ubuntu-maverick-i386.fwts_0.17.5_CHROOTWAIT.txt.gz
<lapion> apw, list of the ppa ?
<apw> i mean email to kernel-team@lists.ubuntu.com ... thats the team list
<cking1> apw, is your mumble working?!
<lapion> apw will send the mail laters, thanks
<cking1> apw, http://smackerelofopinion.blogspot.com/2009/06/looking-at-intel-x-hangs.html
<gnomefreak> has the nvidia+2.6.35.13 been fixed. (getting black screen and cant do anything)
<tseliot> apw, cking1: are we going to get this patch in maverick (as a backport)? http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
<tseliot> gnomefreak: what bug report would that be?
<gnomefreak> tseliot: not sure if there was one. but as i understand it nvidia hasnt yet supported the new kernel i remember someone saying that. i will file a bug now igf you need one :)
<gnomefreak> oh wait
<gnomefreak> tseliot: i did file one. bug 613458
<ubot2> Launchpad bug 613458 in nvidia-graphics-drivers (Ubuntu) "After upgrading to lates kernel i get a black screena nd cant do anything except ctrl+alt+delete to reboot (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/613458
<tseliot> gnomefreak: ok, Nvidia should reply in that report
<tseliot> I've just subscribed them
<gnomefreak> tseliot: thanks
<tseliot> np
<cking1> apw, http://kerneltrap.org/Linux/Removing_The_Big_Kernel_Lock2
<amitk> cking1: if you want to talk to arnd about details, pop into #linaro. He is working in Linaro Kernel consolidation WG
<apw> amitk-afk, thanks
<lamont> [856361.776368] Warning: dev (tty7) tty->count(4) != #fd's(3) in tty_release_dev
<lamont> ew
<apw> lamont, heh thats the bug i am chasing
<lamont> well then, I'll go back to other things
<apw> (well one symptom thereof anyhow
<lamont> 'twas logcheck spam
<lamont> well, maybe not _spam_, per se
<lamont> though that does remind me that I need to reboot for the shiny new kernel
<apw> nice new shiney crashes
<tgardner> apw, https://pastebin.canonical.com/35537/
<bjf> moin
<JFo> moin bjf 
<tgardner> apw, how about https://pastebin.canonical.com/35546/ ?
<apw> tgardner, other than putting filling in the close time at the the point that we put CLOSING in i think that could work
<tgardner> apw, isn't the tty structure released after closing?
 * apw reboots to test the EAGAIN thing
<apw> tgardner, yeah i mean the time needs to be set correctly at the same instant we put in TTY_CLOSING
<apw> into the flags ... as its that we use to detect closing and when we start checking the times
<tgardner> apw, well, its done under tty_mutex
<apw> tgardner, yeah its more stylistic, in case someone split them later, as they are needed to be together the intent is better served by putting them together
<tgardner> apw, then we need a separate function to consolidate the set_bit(TTY_CLOSING, &tty->flags) statements
<apw> and i suspect that that is the right thing for an upstream patch, for somethig we want to not collide to much not so much
<tgardner> apw, like upstream is gonna take this anyways
<apw> well indeed
<tseliot> apw: shall I take it as a no on this? http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
<tgardner> smb, do you think this LVM snapshot regression fix will have an impact no how bad system response sucks when doing qemu/armel builds? I assume its related since bind mounts are being torn down.
<apw> tseliot, the patch isn't very big and quite self contained
<apw> so its not a flat NO on first viewing
<apw> are the patches 'finished' yet though?
<smb> tgardner, Only if fs freeze/unfreeze calls would be involved. The other thing is our still pending writeback suckiness
<tgardner> smb, my desktop would freeze for 20-30 seconds at a time during the build. 
<smb> tgardner, The snapshot freezes were actual hangs. Not to be recovered without force reboot
<smb> tgardner, I would think you see the "we do sync syncronous" issue
<apw> smb, where are we with the write back stuff ?
<smb> apw, The patches seem to be ok from testing, but feedback from Jens is 0 of 4
<apw> 0 of 4 ?
<smb> I wonder if I should just send them to Greg with him on cc
<smb> apw, Tried 4 times got 0 response
<smb> apw, The unfortunate thing is that the set is 14 patches or so
<smb> apw, And not the shortest too
<apw> smb, nasty ...
<smb> And then there seem to be even more issues (like the other thing that an active writer can starve other things) or potentially fs specific slowness in other cases...
<smb> tgardner, is that on boxes that run Maverick, too?
<apw> tgardner, the changes tseliot is pointing to are interesting as they help with intereactive performance under heavy IO load
<apw> smb ^^
 * tseliot nods
<tgardner> smb, no, I'm running the lucid -proposed kernel
<tgardner> 2.6.32-24-generic
<tgardner> dunno about maverick
<smb> tseliot, apw, Is that about lumpy reclaim again?
<apw> smb, indeed lumpy
<smb> Which is the one we discussed yesterday which seems unfinished in discussion
<smb> apw, You can try in Maverick. If it does not explode I might think again. :)
<apw> may well be, hense my question on its completedness, but its very small
<smb> tgardner, Ok, potentially you could try the writeback test kernel
<smb> If I find the place...
<tseliot> smb: I'm not sure about what patch you're referring to but it might be the same
<smb> tseliot, I saw some lines with lumpy reclaim and I have been seeing a discussion upstream about that. Which seemed to go on still. So my impression was this is still in progress
<smb> tgardner, bug 585092 has a reference to the test kernels
<ubot2> Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 1) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/585092
<tseliot> smb: this discussion? http://lkml.org/lkml/2010/8/1/40
<smb> I think yes
<tseliot> ok
<tseliot> let's see how it goes then
<tseliot> the discussion, that is
<smb> Assumed so. :)
<tseliot> good
<smb> It just seemed to hot at least to jump on it from Lucid
<tgardner> smb, http://people.canonical.com/~smb/lp585092/linux-image-2.6.32-23-generic_2.6.32-23.38~lp585092v4_amd64.deb ?
<smb> tgardner, there should be a -24 as well...
<tgardner> ah, no should be 24
<tgardner> right
<smb> tgardner, The comments from someone in the bug seem to indicate even more slackness. So the issue you see might still be there. But if it survives a build box too it at least should not regress.
<tgardner> smb, rebooting for your test kernel
<smagoun> smb: Hi, I noticed that the lpia flavor of linux-ubuntu-modules-2.6.24 (2.6.24-28.46) in hardy-security FTBFS. Is that a known issue? (I pinged you since your name is on the upload)
<smagoun> smb: https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24
<smb> smagoun, Let me check the versions. The latest security should have fixed the FTBS but the real lpia flavour is build through OEM anyway.
<smb> Oh wait its. modules
<tgardner> lum
<smb> yeah. Though there was no lum upload this time. So this would be old
<smagoun> smb: yeah, it's old (April). I'm auditing a tool we use to track security updates, I noticed that distro's lpia l-u-m wasn't what I expected
<smb> smagoun, I cannot find the reason for the FTBS on LP but likely it was because the kernel itself FTBSed. Then probably doing a retry should fix it
 * smb wonders whether he can click on retry...
<smb> Seems to work. Now lets see
<smb> smagoun, Seems to have failed again, but as long as it does not tell me why, I have a hard time to say whether or how to fix it.
<smagoun> smb: alright, I'll talk to a LOSA
<smb> smagoun, ok, let me know what you find out. 
<apw> http://people.csail.mit.edu/albert/bluez-intro/x232.html
<vanhoof> pgraner: ping
<apw> cking1, i can still _see_ you
<apw> not-really-here-, don't make me kick you
 * not-really-here- leaves
<bjf> JFo, apw,  i've just created  https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat , I don't know where it's _supposed_ to go but there it is
<JFo> cool
 * JFo looks
<apw> bjf, i like it, not sure thats 'Stable' related at all ...
<apw> bjf, perhaps PatchCommentryFormat
<apw> (but spelt correctly)
<smb> Though some of the musts or more applying to SRU than the general patch submission
<bjf> apw, the stable team requires the subject line format and the buglink which is just "nice to have" in dev kernel patches
<apw> bjf, i don't think it should be nice to have in dev patches ... i think we should be consistant
<bjf> apw, also the double ack
<apw> the only difference should be the number of acks
<apw> so two ack* 
<apw> * stable only
<apw> should be the only difference to my mind
<bjf> and having two ack's for dev wouldn't be a really bad thing
<ogasawara> we do enforce the two ack's after kernel freeze for the dev kernel
<apw> and the rest of the page is mostly about formatting, and that should be consistant both sides of the line
<apw> how to say where it came from, how to form the front of the title etc etc applied to dev too
<smb> apw, Well I guess if you and ogasawara look at it and agree then it is fine. I looked over that more from the SRU point of view
<ogasawara> I agree with apw we should be consistent with both the dev and stable releases in terms of patch submission
<pgraner> vanhoof, pong
 * apw s done
 * ogasawara lunch
<alex_joni> is there a better place than this to ask a LiveCD question?
<virtuald> alex_joni: yes #ubuntu
<alex_joni> not the type of question I had in mind, but thanks anyways
#ubuntu-kernel 2010-08-07
<cooloney> do you guys know how to find out which version of kernel are in our Ubuntu release image?
<cooloney> ikepanhc: ^^^
<cooloney> do you you know that?
<ikepanhc> cooloney: you mean in the iso?
<cooloney> for example, for lucid 10.04 ubuntu release image, how can i know the exactly version of our kernel in it.
<cooloney> ikepanhc: i am looking for fsl-imx51 image
<ikepanhc> ikepanhc@Natasha:~$ cat /proc/version_signature 
<ikepanhc> Ubuntu 2.6.32-24.38-generic 2.6.32.15+drm33.5
<cooloney> oh, i don't have a running system
<cooloney> that's bad
<ikepanhc> cooloney: you have a iso or img, you can mount, but can not run?
<ikepanhc> cooloney: how about going to find the build log of the iso?
<cooloney> ikepanhc: cool, where can i find the build log of the image
<ikepanhc> cooloney: for oem images, I know, for distro images, I dont know
<cooloney> ikepanhc: https://launchpad.net/ubuntu/+source/linux-fsl-imx51
<cooloney> from the URL above, can we tell the release version is 2.6.31-607.13
<cooloney> ikepanhc: and since 2.6.31-608.14, it is for updates and security
<ikepanhc> cooloney: its in stock, not in iso
<ikepanhc> cooloney: I need to afk a while
<proppy> Hi
<proppy> It seems that http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-maverick/linux-source-2.6.35_2.6.35-020635_all.deb is empty
<proppy> is it available somewhere else ?
<proppy> I was wondering what was the difference between http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-maverick/linux-headers-2.6.35-020635-generic_2.6.35-020635_amd64.deb
<proppy> and 2.6.35-14 in ppa http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/pool/main/l/linux-maverick/linux-image-2.6.35-14-generic_2.6.35-14.19~lucid1_amd64.deb
<proppy> I was told that it is the same kernel, without the ubuntu patches
<proppy> how could I list them ?
<proppy> maybe I should just diff http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=2fef797a0bb72dd1d11dd1eb3624e9bdb8591719 with the official release
<penguin42> Can someone please look at the patch I've attached to bug 606081, upstream (fdo/radeon) seems happy with it, and it clears an oops with google earth - it would be nice to get it into the +1 kernel packages
<ubot2> Launchpad bug 606081 in linux (Ubuntu) (and 1 other project) "radeon_info_ioctl: [340700.513619] BUG: unable to handle kernel paging request at fffffffff0ea1e74 (affects: 2) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/606081
<mozmck> Is there a simple way to make a custom livecd not download and install the pae kernel on a machine with more than 3g ram?
<randoms7> Hi guys, I'm running Ubuntu 10.04 2.6.32-24-generic-pae-phc trying to compile my custom Ubuntu-lts-2.6.34-5.14 kernel from git, im following this guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but at the point where I run debian/rules editconfigs the custom flavor config (core2) is not opened for editing, its just skipped, and nothing in debian/rules 
<randoms7> updateconfigs output shows that it is being processed. Appreciate any help here, thanks
#ubuntu-kernel 2010-08-08
<anon^_^> Hi, question for devs. Recently a few patches were submitted to LKML to try and address a long standing issue with desktop responsiveness under heavy i/o disk activity
<anon^_^> any possibility that these patches will be backported for the next Ubuntu release?
<anon^_^> references
<anon^_^> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094
<ubot2> Ubuntu bug 131094 in linux-source-2.6.22 (Ubuntu) (and 2 other projects) "Heavy Disk I/O harms desktop responsiveness (affects: 99) (dups: 6) (heat: 787)" [High,Won't fix]
<anon^_^> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
<anon^_^> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3Mw
<penguin42> hmm that could explain particularly grim behaviour I've got on systems running off live writable USB disks
<kx> I have compiled a kernel obtaining the source with git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git MyDirectory. Now I want to update the files to the latest 2.6.32-24.39 additions. Is there a git command to do that?
<kx> I think the git user's manual has my answer
<Guest39869> I used my old .config for the 2.6.32-21 kernel to compile the 2.6.32-17 kernel and it installed a lot of new modules. I don't think they were necessary, so is there any way to change this so it won't happen in the future?
<squarebracket> has there been any progress on an lbm-wacom package?
#ubuntu-kernel 2011-08-01
<apw> df
<diwic> apw, /dev/brain, cells:2, used:2, available:0, Use: 100%, Mounted on: /dev/head
<apw> diwic, sounds about right
<apw> /dev/head, capacity:10, populated:0
<diwic> eh
<apw> i refer you to your first answer :)
<diwic> refer? by a symlink or a hardlink? or a recursive loop device? :-)
<apw> mount -o bind /dev/answer1 /dev/answer
 * diwic realises he's out on deep water and quickly gets back to work ;-)
 * smb strolls in
<apw> bug 753994
<ubot2> Launchpad bug 753994 in linux "[arrandale] Display is slanted when using 1360x768 resolution" [Medium,Confirmed] https://launchpad.net/bugs/753994
<jussi> crioes, thats a strange looking bug
<apw> stupid integer mistake in stride width
<apw> RAOF, you any idea why this diagonal thingy fix is only applied to the fixes branch ?  seems odd behaviour
<RAOF> I don't know; were I to guess, it would be because there will be a merge from -fixes to -next at some point in the future.
<apw> hhmmmm
<ilmari> what are the odds of the oneiric 3.0 drm-intel-next kernel packages working on natty?
<Tommeh> ilmari: pretty high
<Tommeh> I'm using mainline 3.0 from the kernel team PPA
<Tommeh> At the end of the day it's only a few .deb packages, so if they don't work you've not lost much time. :)
 * ilmari gives it a go
<apw> RAOF, so i guess are you happy to have it in natty when its not yet upstream
<hx_> Hello, I've got an Asus P53E and I installed Ubuntu 11.04, the problem i have is that my touchpad is recognized as a "PS/2 Logitech Wheel Mouse" and therefore the multitouch functionality doesn't work. I found out that this is could be a bug in the Kernel, so I installed the newest one (3.0 rc7) but still the problem is the same.. Is there a patch for this issue?
<apw> hx_, what make of touchpad is it
<hx_> apw, i think its an "elantech" type, but i cant find its name or anything in the manual
<davmor2> ogasawara: just to confirm that after a fresh install of oneiric at the weekend the Ralink 5390 driver was working out of the box thanks :)
<ogasawara> davmor2: cool, good to know
<sforshee> hx_, I have a machine with an elantech touchpad that behaves the same. I'm planning to look into it but just haven't gotten around to it yet.
<apw> hx_, i've heard of issues with new ALPS touchpads, but not with elantech.
<apw> sforshee, must be a new device.  you'd think they could be compatible, its not like its complex
<hx_> sforshee, ive done some research and a lot people are having this issue :(
<sforshee> apw, it might just be a problem in detecting that it's an elantech device. Note that it's identified as a Logitech.
<hx_> apw, how do i be sure which one i got?
<apw> sforshee, yeah point
<apw> hx_, a good question.  i hate h/w for a reason
<apw> hx_, but i'd say its a bug yes
<sforshee> hx_, is there a launchpad bug already open for this?
<apw> hx_, did it every work on any older version ?
<hx_> apw, it didnt work on an older kernel, but it worked on windows 7, with the native synaptics drivers
<hx_> sforshee, im pretty sure there is already one open
<apw> yeah windows isn't interesting in the sense that that just tells us they can detect their own h/w in their driver
<hx_> yeah right, but i even tried several other distributions
<hx_> fedora and opensuse
<apw> and i assume they don't work either
<hx_> no they dont same result
<sforshee> detecting what's attached to PS/2 is just a bunch of black magic, there's no standard scheme for hw identification
<sforshee> my guess is we mostly just need to determine the correct way to probe the device
<sforshee> that's my hope anyway :)
<apw> sforshee, yep, but thats only broke cause they changed it from their previous h/w, stupid stupid stupid
<sforshee> apw, that pretty much sums up what I've been dealing with the past couple of weeks
<apw> particularly the stupid, stupid, stupid part
<hx_> im on that for a several days of googling before i decided to ask here
<hx_> but cant i "just" assign the synaptics driver to the (wrongly detected) PS/2 Device?
<sforshee> hx_, the elantech driver is probably refusing to work with it because it doesn't look like the things it knows about
<apw> hx_, no cause unless you incant the right bytes at the deveice it behaves like a mouse
<apw> hx_, the act of asking it if it is a touchpad (in the correct way) makes it into a touchpad, before that it fakes mouseness
<apw> as i say .... STUPID
<apw> all in the name of compatibility with dos 3.0 no doubt
<hx_> oh okay, but can't the act of asking if it is a touchpad be patched?
<sforshee> hx_, it can be patched but we have to find the right way to ask first
<apw> hx_, yes, we could change how we ask it if it is a touchpad.. but .. what am i meant to say to it
<apw> oh we don't know cause the vendor don't tell us
<hx_> that looks like a hopeless situation..
<apw> difficult at least yes
<sforshee> hx_, there are ways to reverse engineer such things, it just takes time
<apw> means someone has to watch windows doing it, and figure it out normally, which isn't easy
<apw> and when its all said an done the vendors should just write it down and tell us
<sforshee> that would be nice
<sforshee> I'm not holding my breath though
<hx_> what exact information would we need about the touchpad?
<hx_> in order to detect it
<hx_> apw, or is there a posibility of just using the windows drivers as with wireless cards?
<apw> hx_, that is a black-art which i am not up on, i have not heard of any way to use the windows drivers no
<hx_> apw, okay i hope this will be fixed in a new kernel version if possible, as a lot of people are having this issue
<apw> hx_, well at least it works as a mouse
<hx_> apw, yes but without multitouch i cant scroll which makes it rather useless
<apw> hx_, not as useless as it not working as a mouse would be
<apw> i understand your pain, but we are somewhat at the mercy of vendors
<hx_> apw, thats true.. do you think i should ask for support at asus?
 * apw looks pointedly at his stupid SD card slot which will likely never work cause of the vendors attitude
<apw> hx_, i always feel its worth the vendors knowing people care
<apw> whether it will help is another quesiotn
<hx_> yes i will see, thanks for your support though
<sforshee> hx_, please go ahead and look for a bug that matches your issue and click the link to indicate that you are also affected, or open a new bug if there isn't one already. Let me know the bug number. I hope to start looking into it with the hardware I have within the next couple of weeks.
<hx_> sforshee, i think i found a patch for our problem
<tgardner> apw, ogasawara: so far Oneiric is only building perf as a tool. do you suppose we should start building and packaging turbostat and x86_energy_perf_policy ?
<apw> tgardner, i have been thinking i need to overhaul the tools as it doesn't package half of the stuff in perf
<apw> tgardner, should i look at it or will you
<tgardner> apw, you should since I'm gonna be gone for a few days later this week
<apw> (and i suspect we should be including those other tools
<apw> tgardner, ack
<tgardner> well, I guess I have time though.
<tgardner> I wtill have 3 days
<tgardner> apw, are you swamped with other stuff ?
<apw> there is always more stuff to do
<sforshee> hx_, can you point me to the patch?
<apw> i think its important, so i am happy to do it t
<apw> though as i know the perf support files are missing
<tgardner> apw: put it low on your list. I'll see if I can get it done before you get to it.
<apw> tgardner, ok let me know when you are sure you arn't doing 
<hx_> well i found a post with the link of a patch but im not sure if it is what where looking for
<hx_> anyway: https://bbs.archlinux.org/viewtopic.php?id=115810
<hx_> sforshee
 * ogasawara back in 20
<sforshee> hx_, I thought I tried that, but let me try again
<hx_> look at the end of his post
<mahmoh> how can I change the interrupt frequency via kernel command line?  Let's say I want to imitate the 100Hz server timing  vs. desktop 250?
<sforshee> hx_, oh, okay, didn't see that before, let me take a look
<hx_> sforshee, okay but i dont know how to use it
<apw> sforshee, the patch is like 500 lines of doom :)
<apw> and looks to do all sorts of bad things ... dimitri has asked for it to be split up
<apw> though he asks them to do that on linux-imput, so it may be going on over there too
<sforshee> yep
<sforshee> ugh, I think I've seen touchscreens with problems similar to these touchpads
<apw> first foray into MT
<sforshee> apw, I'm pretty sure the nexus one touchscreen has the same problem -- it can't do real MT, and sometimes gets confused about where the fingers really are
<sforshee> but getting that right isn't necessary for simple gestures, like two-fingered scrolling
<apw> sforshee, yeah it doesn't support the spin in google maps for that reason
<sforshee> apw, I worked on a device that used the same touchscreen :)
<apw> heh ... no comment :)
<sforshee> anyway, I guess my point is that a stripped-down version of the patch might work as a starting point and still support the gestures that are needed
<hx_> im listening :)
<sforshee> hx_, do you have a bug yet? It's going to be easier to track all this information in the context of a bug than in an irc discussion.
<sforshee> hx_, it's still going to take some work. Like I said it's on my list, I just haven't been able to get to it yet.
<hx_> sforshee, no i havent yet, should i create one?
<sforshee> hx_, first you should check for an existing bug report, but if you can't find one then yes you should create one
<hx_> sforshee, there already are bug reports, like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/694222
<ubot2> Ubuntu bug 694222 in linux "Synaptics touchpad incorrectly recognized as PS/2 Logitech mouse on a Samsung SF310 laptop (dup-of: 681904)" [Undecided,New]
<ubot2> Ubuntu bug 681904 in linux "[arrandale] Samsung QX310/QX410/QX510/SF310/SF410/SF510/NF210/RF410/RF510/RF511/RF710 trackpad/touchpad not recognized" [Medium,Confirmed]
<sforshee> hx_, that one's marked a duplicate of bug 681904
<ubot2> Launchpad bug 681904 in linux "[arrandale] Samsung QX310/QX410/QX510/SF310/SF410/SF510/NF210/RF410/RF510/RF511/RF710 trackpad/touchpad not recognized" [Medium,Confirmed] https://launchpad.net/bugs/681904
<sforshee> hx_, that looks like it's probably the same thing though. The machine I have with the elantech touchpad is a samsung.
<hx_> sforshee, okay, well i have an asus but i think that doesnt matter if its an elantech
<sforshee> and it's already tracking the upstream bug, so that's useful
<sforshee> hx_, we'll just have to see if the same thing fixes your machine too
<hx_> sforshee, yes what i would really appreciate
<sforshee> hx_, subscribe to the bug and you'll get emails when I start posting stuff there
<hx_> sforshee, okay wonderful thanks in advance
<hx_> to that one right? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681904
<ubot2> Ubuntu bug 681904 in linux "[arrandale] Samsung QX310/QX410/QX510/SF310/SF410/SF510/NF210/RF410/RF510/RF511/RF710 trackpad/touchpad not recognized" [Medium,Confirmed]
<sforshee> hx_, yes, that's the one I'll be using
<hx_> sforshee, alright let me know if i can help in anyway (testing,..)
<sforshee> hx_, will do, thanks!
<hx_> sforshee, looking forward to it, thanks
<ogasawara> anyone know who this julian wiedmann is?  he's doing some pretty good bug triage for us lately.
<sforshee> ogasawara, don't know who he is, but I've noticed that he's been doing some good work
<mahmoh> anyone?
<apw> mahmoh, ?
<mahmoh> apw: how can I change the interrupt frequency via kernel command line?  Let's say I want to imitate the 100Hz server timing  vs. desktop 250?
<apw> no thats not tunable via the command line
<mahmoh> I was afraid of that
<apw> ogasawara, did we decide to harmonise on a value in the end
<mahmoh> apw: thx :(
<ogasawara> apw: i can't recall if we did actually
<apw> ogasawara, jj may remember .. he has an ear for detail
<ogasawara> apw: I think we agreed we should, but left it at that
<apw> ogasawara, i think i remmber someone (maybe him) was going to go do some measurements
<ogasawara> apw: I think I also vaguely remember needing to get our IPV6 configs sorted as well
 * ogasawara puts it on the todo list
<marcoceppi> Hello
<apw> yeah harmonising them iirc
<marcoceppi> I've got a question about building the Ubuntu Kernel. I've checked out ubuntu-lucid.git applied my patches and merges. I'm trying to build a src package to I can place in a PPA - I've built the control file but I need a change log. How can I get the current changelog for the ubuntu-lucid kernel?
<apw> marcoceppi, if you clean the package first (fakeroot debian/rules clean), it'll appear.  the master is in debian.master/changelog
<marcoceppi> apw: Thank you
<marcoceppi> So, what's the best way for me to enter my changes to the log? Other than the obvious of "edit the changelog file generate"
<sconklin> marcoceppi: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel may help a bit
<marcoceppi> I've been loosely following https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<sconklin> edit the changelog and commit it to your local repo if you want to save it, otherwise, just build from the uncommitted tree
<apw> (the master one)
<sconklin> We have three or four wiki pages on how to build a kernel, unfortunately.
<marcoceppi> sconklin: heh, I've noticed. They all have about the same information - just variations it seems apw Thanks, I'll do so
<skaet> sconklin,  I haven't been able to move the SRU meeting to Tuesday,  you able to meet now?
<sconklin> skaet: sure
<sconklin> #ubuntu-meeting?
 * tgardner bounces tangerine to make it'll boot without a CDROM.
 * tgardner notes tangerine is back up
<marcoceppi> So, I'm about to build with debuild -S -sa and i'm getting This package has a Debian revision number but there does not seem to be
<marcoceppi> an appropriate original tar file or .orig directory in the parent directory;
<marcoceppi> (expected one of linux_2.6.32-33.72.orig.tar.gz, linux_2.6.32-33.72.orig.tar.bz2,
<marcoceppi> linux_2.6.32-33.72.orig.tar.lzma,  linux_2.6.32-33.72.orig.tar.xz or ubuntu-lucid.orig)
<marcoceppi> continue anyway? (y/n)
<marcoceppi> Is it safe to just continue?
<apw> marcoceppi, the upload will be much bigger without it, but safe i beleive
<skaet> bjf, sconklin - are you sure you want me to move lucid kernel to proposed?   Looking at bug 811745 comments from over the weekend looks like its not fixed quite yet.
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745
<skaet> or they were running the wrong kernel (ie. -71) and we need to move -72 in place for them to pick it up.
<ohsix> i have a panic related to removing drives in the natty kernel, and in the ones where it's "fixed" by some stuff, i get acpi wakeup panics
<herton> skaet: yes, 2.6.32-33.72 is the one that should fix the issue
<bjf> skaet, yes, please copy 32-33.72
<skaet> bjf,  thanks will do.
<skaet> herton,  thanks
<skaet> herton, bjf,  ok, have copied it in.   Could one of you update the status of 811745 bug to reflect fix committed and the correct importance.  
<bjf> skaet, just fyi, i'm on rotation to QA this cycle, though i do still dabble in kernel team issues
<skaet> thank for clarification bjf.
<herton> bjf, skaet: I set it to fix commited and importance: high. Let me know if importance should be different. If a nomination is needed, I don't have permissions to approve, so someone must do it.
<herton> *someone else
<bjf> herton, which bug #?
<herton> bug 811745
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [Undecided,Confirmed] https://launchpad.net/bugs/811745
<herton> bjf: ^
<bjf> herton, thanks, looks like skaet got to it
<skaet> herton,  ok,  have gone in and marked it for lucid.  
<ohsix> you might be interested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793796 as well, it's the panic i reported w/the natty kernel, removing an external drive
<ubot2> Ubuntu bug 793796 in linux "2.6.38-10 panic after ejecting drive" [Undecided,In progress]
<herton> ohsix: ? that one should be ok already, since 2.6.38-10.46. There is no upstream fix, so the patches that caused it are reverted since then
<ohsix> it might be related with the freeze they're investigating, even if remotely :]
<ohsix> btw, with tha tkernel i get acpi stuff in the stack for a panic after wakeup
<skaet> herton,  linux-backports-modules-2.6.32 has been copied to proposed.
<herton> skaet: ok thanks. If everything is on proposed, you must set the 'Promoted-to-proposed' task to 'Fix Released' on the tracking bug
<skaet> herton,  was going in and doing that now.
<herton> ah ok
<herton> lunch, back in some minutes
<skaet> going through the bugs for the natty move to proposed, and bug 791019 and bug 751681 don't have the right state,  can someone confirm it should be in and clean up the status of the bug.   also bug 731706 is not targetted to Natty - oversite?
<ubot2> Launchpad bug 791019 in linux "yama_ptracer_del lockdep warning" [Undecided,Fix released] https://launchpad.net/bugs/791019
<ubot2> Launchpad bug 751681 in linux "Lenovo Ideapad U350: Internal mic stopped working with natty kernel" [Undecided,Incomplete] https://launchpad.net/bugs/751681
<ubot2> Launchpad bug 731706 in linux "[Dell Studio 1558] Driver advertises extra internal Microphone Input which does not work" [Undecided,Fix committed] https://launchpad.net/bugs/731706
<bjf> skaet, that has often been the case in the past, not all bugs fixed in a upload necessarily have the correct status or have been nominated for a series
<herton> ohsix: is the acpi stuff you mentioned a crash? (so resume from suspend fails?)
<ohsix> herton: yes it's a panic, with stuff like "acpi_idle_enter_c1" (paraphrasing) in the stack
<herton> ohsix: did it happen before, or a recent update triggers it?
<skaet> bjf,  one of the steps of the process on the release side is walking through all the bugs and checking that they are have complete description, justification, have a stable release task, conformant to SRU rules, etc., so basically haven't been inadvertently included.   By setting the state of the bug to Fix Committed, it makes things more efficient for everyone - ie.  we know that it is intended to be released witho
<skaet> ut having to ask.  ;)
<ohsix> herton: well i was running the package with those eject fixes in them, but then i ended up with the acpi problem
<bjf> skaet, interesting, since this is first anyone has asked
<skaet> bjf,  ah well,  this is what happens when you get a backup trying to follow an existing process,  documentation gets read.  ;)  https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools
<herton> ohsix: are you able to get dmesg/kernel log after the crash?
<ohsix> herton: i can get a picture next time i boot that kernel; it's been 2 sets of new kernels i've had problems with so i've sort of decided to cut my losses
<herton> ohsix: it helps know when the problem start, you can check if you had this problem with first natty kernel (8.42). In any case, open a bug about it.
<herton> *started
<bjf> skaet, heh, agreed
<ohsix> i only had a problem with that patched version, i did not get to use the unpatched update for long cuz of the panic thing with the drive ejecting
<ohsix> herton: so it is after 2.6.38-9-generic but as far as i know only as soon as 2.6.38-11-generic
<herton> ohsix: did suspend/resume worked before on the same machine at some point?
<ohsix> herton: aside from when i installed cgroup-bin (unrelated to anything, but tends to break suspend!) i've never had any problems with any version of anything i've ran on this laptop
<herton> ohsix: which was the last kernel version you got suspend/resume working on this laptop?
<ohsix> the last one i know for sure is 2.6.38-9-generic
<ohsix> since i couldn't run -10 due to the eject thing; when i finally could, i encountered the problem for the first time, with 2.6.38-11.47
<herton> ohsix: ok, that clears up things. let me know the bug number you open, we may do a bisect again just for this issue. Also if you can get the picture of the crash and attach on the bug, would be great.
<ogasawara> anyone else you able to connect to tyler?
<ohsix> herton: i'll try, i don't know when though; i use this laptop for "work" 99% of the day, rebooting even is a pain :]
<tgardner> ogasawara, hmm, its lost tis love for me
<ogasawara> tgardner: damn, it's probably lost my build that was in progress as well
<tgardner> ogasawara, yantok seems to be down
<tgardner> ogasawara, use gomeisa
<ogasawara> ack
<jmburges> I think bug 565543 can be marked as triaged...correct? I'm new to kernel bug triaging
<ubot2> Launchpad bug 565543 in linux "Alps touchpad detected as ImPS/2 Generic Wheel Mouse(in VAIO E series) after the kernel upgrade" [Medium,Confirmed] https://launchpad.net/bugs/565543
 * tgardner --> lunch
 * apw calls its quits
 * jjohansen -> lunch
<pgraner> rtg:
<pgraner> [   75.457505] pcieport 0000:00:01.0: AER: Multiple Corrected error received: id=0008
<pgraner> [   75.457535] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0008(Receiver ID)
<pgraner> [   75.457541] pcieport 0000:00:01.0:   device [8086:3c02] error status/mask=00000040/00002000
<pgraner> [   75.457546] pcieport 0000:00:01.0:    [ 6] Bad TLP               
<pgraner> [   75.457549] pcieport 0000:00:01.0:   Error of this Agent(0008) is reported first
<pgraner> [   75.457556] pcieport 0000:01:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0100(Transmitter ID)
<pgraner> [   75.457560] pcieport 0000:01:00.0:   device [8086:1d74] error status/mask=000031c1/0000e000
<pgraner> [   75.457564] pcieport 0000:01:00.0:    [ 0] Receiver Error         (First)
<pgraner> [   75.457568] pcieport 0000:01:00.0:    [ 6] Bad TLP               
<pgraner> [   75.457571] pcieport 0000:01:00.0:    [ 7] Bad DLLP              
<pgraner> [   75.457574] pcieport 0000:01:00.0:    [ 8] RELAY_NUM Rollover    
<pgraner> [   75.457578] pcieport 0000:01:00.0:    [12] Replay Timer Timeout  
<pgraner> [   90.240075] pcieport 0000:00:01.0: AER: Multiple Corrected error received: id=0008
<pgraner> [   90.240105] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0008(Receiver ID)
<jjohansen> reboot
<marcoceppi> Do I need to do anything special in order to create a deb source that LP can build?
 * tgardner --> EOD
 * herton -> eod
#ubuntu-kernel 2011-08-02
<kees> apw: I've finished the 3-phase old kernel bug tracker sync stuff now. I've done a bunch of status and description updates as well.
<kees> apw: there are a few more corner cases I ran into, but I've been documenting it in the uct README file. of most note is how to add and remove SHAs from the bug descriptions.
 * smb -> BOD
 * apw yawns
 * smb waves
 * abogani waves back to all
<tjaalton> were there some scripts to aid debugging when suspend fails to work?
<tjaalton> my snb desktop hangs while trying that on oneiric
<smb> Not sure how much Colin built into fwts, but he also had some system tap scripts somewhere
<smb> But there also was some bug (I fail to remember atm) that system tap in oneiric was broken..
<tjaalton> ah
<tjaalton> i'll try fwts
<smb> bug 815944
<ubot2> Launchpad bug 815944 in systemtap "systemtap on Oneiric breaks because of kernel commit 449a66fd1fa75d36dca917704827c40c8f416bca" [High,Confirmed] https://launchpad.net/bugs/815944
<tjaalton> thanks
<apw> smb, i suspect that systemtap needs to change to follow, it is its lot (to break ceaslesly)
<smb> apw, Yeah, I don't think we want to follow a road of changing back the kernel, when the upstream path is to have it removed.
<marcoceppi> Do I need to do anything special in order to create a deb source of the kernel that LP can build?
<marcoceppi> Maybe a magic wiki article that I missed?
<smb> !kernel
<ubot2> The core of Ubuntu is the Linux kernel: see https://help.ubuntu.com/community/Kernel - You shouldn't have to compile your own, and if you need to troubleshoot issues, you can try a !Mainline kernel instead, but if you insist, see https://help.ubuntu.com/community/Kernel/Compile (see also !Stages)
<smb> marcoceppi, Something like that?
<smb> !kernel-faq
<ubot2> A list of common questions about the Ubuntu Kernel can be found in http://wiki.ubuntu.com/Kernel/FAQ
<apw> marcoceppi, how did it fail ?  we covered clean yesterday i think
<marcoceppi> Yeah, here is the last line from the build line
<marcoceppi> enable deprecated sysfs features which may confuse old userspace tools (SYSFS_DEPRECATED_V2) [Y/?] y
<marcoceppi> make deprecated sysfs layout dynamically (SYSFS_DEPRECATED_DYN) [Y/n/?] (NEW) aborted!
<marcoceppi> Console input/output is redirected. Run 'make oldconfig' to update configuration.
<marcoceppi> make[5]: *** [silentoldconfig] Error 1
<marcoceppi> make[4]: *** [silentoldconfig] Error 2
<marcoceppi> make[3]: *** [sub-make] Error 2
<marcoceppi> make[2]: *** [silentoldconfig] Error 2
<marcoceppi> make[1]: *** [sub-make] Error 2
<marcoceppi> make[1]: Leaving directory `/build/buildd/linux-2.6.32-33.72'
<marcoceppi> make: *** [/build/buildd/linux-2.6.32-33.72/debian/stamps/stamp-prepare-tree-generic] Error 2
<marcoceppi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<marcoceppi> The source was built properly, lp build spit this back. I ran make oldconfig in my source tree and it built the .config without an issue. So I wonder if it's not getting my saved config somehow
<apw> you seem to have an out of date config
<apw> fakeroot debian/rules updateconfigs
<marcoceppi> So running that seems to produce check-config errors. I assume that I'll need to do something about that.
<marcoceppi> ls
<smb> herton, That new lucid kernel upload, I guess that means I should prepare an ec2 tree. Though I cannot remember having seen any bot or person bugging me about that...
<herton> smb: the new lucid kernel was just a respin to revert 2 changes for bug 811745. We should be creating new tracking bugs for you, but this isn't ready yet
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [High,Fix committed] https://launchpad.net/bugs/811745
<herton> smb: not a respin, but a new update I mean just for that bug
<smb> herton, Ah, ok. So I better wait until you are ready. I was just wondering whether I missed something there
<smb> Unplugging an external usb drive in the cloud is difficult anyways...
<herton> hehe
<apw> smb, does it not have usb emulation ?
<smb> apw, Not the normal usage. There could be ide or scsi emulation but actually only the virtual block devices are used as the are quicker
<marcoceppi> Thanks for your help thus far. I'm getting closer. The build servers are telling me that the source isn't clean and that I need to make mrproper - however, when I run that in my local source it removes a lot of the debian control items.
<apw> marcoceppi, you need to "rmdir include/config" normally to fix that
<marcoceppi> Ah, I'll give that a try. Thank you
 * ogasawara back in 20
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<ogasawara> bjf: I noticed bug 819632 from the daily bug report
<ubot2> Launchpad bug 819632 in linux "WARNING: at /build/buildd/linux-2.6.31/net/sched/sch_generic.c:246 dev_watchdog 0x1f6/0x210()" [Undecided,New] https://launchpad.net/bugs/819632
<ogasawara> bjf: it's against a karmic kernel (which your scripts correctly detected)
<ogasawara> bjf: just curious if you'd want to auto close it rather than have it appear on the report?
<bjf> ogasawara, yes, but it didn't get the right tag (and it's an unsupported series)
<bjf> ogasawara, i'll look into it
<ohsix> herton: i just got an unrelated panic (in the wifi stack) on wakeup with -9, so i'm running -11 now and i'll get a screen asap
<herton> ohsix: ok
<marcoceppi> Hum, so I removed include/config and I'm still getting mrproper error during the build. Is there anything else I might need to do?
<BenC> marcoceppi: make mrproper
<apw> marcoceppi, well the tree should be made clean, so checkin anything you have changed
<apw> then git clean -f -x -d, note this will DELETE any files not tracked by git
<apw> then fakeroot debian/rules clean, then package it
<marcoceppi> mrproper removes all the debian/ files - so I won't be able to run debuild
<BenC> marcoceppi: mv debian ../debian.orig; make mrproper; mv ../debian.orig debian
<marcoceppi> Ah, makes sense. Let me try that
<marcoceppi> Shuould I rape mrproper in fakeroot?
<marcoceppi> WRAP*
<apw> don't think so
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<apw> bdmurray, i'd be interested in more details of the changes if you able to send them out
<bdmurray> apw: the changes already made or what I think should happen now?
<apw> bdmurray, right, but of what we might find different
<alfmatos> hi
<alfmatos> just reported bug #819925
<ubot2> Launchpad bug 819925 in linux "iwlwifi driver exports all packets through netlink" [Undecided,New] https://launchpad.net/bugs/819925
<apw> ogasawara, ^^ that sounds like something to put on your config-review list
 * ogasawara looks
 * ogasawara adds a work item
<alfmatos> :)
<alfmatos> that should default to N i would assume =)
<bjf> apw, hah! you beat the script
<apw> bjf, yeah stop the spam
<alfmatos> well, that's all i got, thanks guys =)
<ogasawara> alfmatos: I'll get it flipped to N and it'll be in the next upload after Alpha3
<alfmatos> cool
<cprofitt> hell all...
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/776999
<ubot2> Ubuntu bug 776999 in linux "[Lenovo W520] laptop freezes on ACPI-related actions" [Undecided,Confirmed]
<cprofitt> was looking for a little bit of advice on how to move this from confirmed to triage
<cprofitt> I have a W520 and could assist gather some information
<marcoceppi> I seem to be getting a lot closer to it actually compiling. The seemingly last hurdle is that 7 configuration values fail check-config. Should I just remove those? Is it maybe they no longer exist in this version of the kernel and are just old?
<apw> marcoceppi, what version of the kernel is the config from and what is the version of the kerenl
<marcoceppi> apw I have the latest from ubuntu-lucid.git -33.72 I copied the config from a lucid VM with the latest installed from the repo
<apw> marcoceppi, then no i would not exect the config to change at all
<ogasawara> bjf: pastebin me the minutes, I'll shove em to voices
<apw> bjf, i say don't bother to publish them
<apw> its not a high priority for us apparently
<marcoceppi> apw: The build fails at these 7 entries: http://paste.ubuntu.com/657368/
<apw> marcoceppi, but the config for a lucid kernle would have those set
<bjf> apw, ogasawara i've been assured that this will be fixed today, if not i will send email to pgraner that we will no longer be blogging our meeting minutes
<apw> and set correctly else the same failure would have prevented the kernel you have from building in the first place
<ogasawara> bjf: ack
<marcoceppi> apw: Makes sense. I'll try to figure out where I went wrong. I may try re-copying the configurations over and running updateconfig again
<bjf> ogasawara, http://pastebin.ubuntu.com/657372/ (thanks)
<apw> why not use the config which is in the tree?  given it is for the same kernel
<marcoceppi> I was just following the instructions from https://wiki.ubuntu.com/KernelTeam/GitKernelBuild I may have gotten confused and copied when I shouldn't have.
<marcoceppi> So should I just checkout the configuration files from the last clean commit in the ubuntu-lucid.git? I assume it's in debian/build/ directory?
<bjf> marcoceppi, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a good, basic starting point
<marcoceppi> bjf: Thanks, I was linked to it yesterday - I'll probably just start from their this time
<jjohansen> marcoceppi: ping me if you run into problems
<marcoceppi> I'm trying to avoid starting from scratch. It took me about 5 hours to patch the kernel. Soo, let me see if I can back up until right after I patched
<marcoceppi> Okay, I think I've gotten to a point where I can try to perform a clean build. Would it be beneficial to build the kernel locally before trying to get LP to build it? 
<apw> marcoceppi, depends how fast your local build is
<marcoceppi> It's still failing at those configurations. I wonder if it's because I patched v2.6.32 in the git line, then merged down the changes up to 2.6.32-33.72
 * tgardner --> lunch
 * smb -Y eod
<marcoceppi> If I remove those values, I assume it would make me re-enter them if it really needed it, right?
<apw> marcoceppi, nope, it will then not have things set you need in order to boot most likely
<apw> if you mean removing them from the config check
<marcoceppi> I mean removing them from the build's .config
<apw> it will ask you to set thme yes on updateconfigs
<marcoceppi> Then what would be causing check-config to throw the error? Could it be expecting a different value?
<apw> what values do the config options have in your config ... git grep FOO debian.master/config
<marcoceppi> When I search the debian/build/build-generic/.config file those keys don't exist
<apw> if you got the configs and the enforcer file from the same or nearly the same version of the kernel then they should match
<apw> marcoceppi, thats generated during the build and not interesting as much as the master for them
<marcoceppi> Let me check the master
<marcoceppi> All of these keys and values exist in config/enforce config/config.common.ubunut and config/config.common.ports
<marcoceppi> So, I should run debian/control updateconfigs then try again?
<marcoceppi> rules*
<apw> if you do a fakeroot debian/rules prepare-generic (or whatver falvour you care about)
<apw> you can see if the built cdonfig has what you need in it
<marcoceppi> It built, but failed with the same 7 check-config errors like before
<apw> you said they were present and correct in the config master files yes ?
<apw> so then the question is what patches have you applied
<marcoceppi> I applied the OpenVZ patch
<marcoceppi> for 2.6.32
<apw> so perhaps they prevent those options being set, and you are in a world of hurt
<apw> does the openvz patch set include any configuration (Kconfig) file updates, add any additional depends ?
<marcoceppi> It changes a few kconfigs. It doesn't add any external dependencies that I know of
<apw> well if an option is in the master configs and not in the resultant built .config in debian/build
<apw> then there must be a configuration dependancy that is stopping them
<apw> so you need to pick one and validate its pre-requisites
<apw> and find out why its now off/difffernet
 * apw eyes the beer on his desk ... you are mine
<marcoceppi> I see, so it's it's time to chase down "why"?
<apw> yep sadly so
<marcoceppi> Well the majority is related to SELINUX and APPARMOR which I know does not work with OpenVZ
<apw> then that would explain why they go missing
<apw> if they are incompatible
<marcoceppi> So, updating the enforce file would be...the solution?
<apw> then you need to remove the enforcement for them, as they can never be set
<apw> and pay the consequences if userspace needs them
<marcoceppi> Well, I'll chase down the others to make sure it's something that is supposed to be missing. Thanks for your help apw enjoy your beer :)
<apw> *glug&
<marcoceppi> Awesome, OpenVZ doesn't support DEVTMPFS as well. This is going to be a pain now that I look at it.
<apw> now that is going to be a tricky one
<apw> upstart may cope
<marcoceppi> I hope so
<marcoceppi> I mean, if people are able to use the linus 2.6.32 kernel on 10.04 I *should* be able to use 2.6.32-33.72 with the patch? right?
<marcoceppi> well _maybe_
<apw> except that that supports devtmpfs
<marcoceppi> what I mean was 2.6.32 with the OpenVZ patch (which it was created for)
<apw> if the openvz patch is known to work on ubuntu then yours should, is what i think you are saying
<kees> apw: how did yesterday's bug status sync look to you?
<marcoceppi> apw: Yes, only I didn't articulate it very well.
<apw> kees, didn't see anything out of order
<kees> apw: excellent
<apw> wil keep a weather eye
<kees> herton: do you know who is doing the publication of the maverick linux package? it seems to have only hit -updates...
<herton> kees: no idea
<kees> herton: okay, thanks
<herton> kees: sconklin is looking into it, he was told slangasek did the publishing
<sconklin> kees: it's being worked
<marcoceppi> bjf apw:  Thanks for your help. I'm able to get past the configuration issues from earlier - now I just need to fix the code errors!
<kees> sconklin: thanks!
 * tgardner -> EOD
 * jjohansen -> lunch
<kees> apw, sconklin: do either of you know the status of ti-omap4 for maverick?
<sconklin> kees: no
<kees> sconklin: what's needed to make it show up on http://people.canonical.com/~kernel/reports/sru-report.html ? just open bugs?
<sconklin> a tracking bug that's in process
<kees> sconklin: hm, okay. I guess I don't know what takes stuff from http://people.canonical.com/~apw/cve/pkg/ALL-linux.html in "pending" to showing up on http://people.canonical.com/~kernel/reports/sru-report.html
<kees> I'll ping apw tomorrow
<sconklin> kees: is this helpful? http://people.canonical.com/~kernel/reports/versions.html
<sconklin> probably not
<kees> sconklin: I think that just shows me that there isn't something in the PPA waiting for workflow progress
<sconklin> that's right, and nothing in -proposed
<kees> sconklin: oh, what about linux-lts-backport-maverick? it seems to be missing a tracking bug?
<sconklin> kees: looking
<herton> sconklin, kees: for linux-lts-backport-maverick it's bug 811215, but it doesn't show on sru-report
<ubot2> Launchpad bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/811215
<kees> herton: ah, thanks.
<sconklin> herton: thanks, I was waiting for git to fetch
<sconklin> we'll figure out why that's not in the report
<bjf> sconklin, i'm looking at the kernel-sru-worflow and the tracking bug shows there, heading to the sru-report
<sconklin> bjf: thanks!
<herton> yep, the sru-report is the one which misses it
<medberry> cnd, the recent 10.04.3 kernel update "broke" my clickpad in Lucid. I've got an HP ProBook 4320s and stayed on Lucid as Maverick forward don't work properly with the clickpad.
<medberry> now that forward problem has come back to haunt me.
<medberry> Any suggestions?
<cnd> medberry, can you provide more details on what's wrong?
<medberry> the left center right areas are treated as one area cnd.
<medberry> and it's also really "touchy". Making it much more difficult to click and drag now.
<medberry> I suspect the 10.04.3 kernel SRU pulled in some mouse/input changes (similar to what were in Mav and Nat all along.)
<cnd> medberry, can you describe the layout of your trackpad? what do you mean by left center right areas?
<medberry> sure: the clickpad has a "T" shape overlay on the bottom 20% where the middle of the T is in center bottom.
<medberry> representing "left" and "right" mouse buttons. Moreover, the bar of the "T" functioned as a middle click.
<medberry> Now, I'm back to the whole area representing a left click (irrespective of the markings.)
<cnd> medberry, I'm guessing there was a kernel patch that was in lucid that was not upstream to handle these trackpads
<medberry> so "left" is more less the bottom 20-25% and the left 40%, center is the bottom 20-25% and the middle 20% and right is the right most 40% of the bottom 20-25%. I can send a picture if it helps.
<cnd> based on a vague memory of what's happened in this area
<cnd> sconklin, do you remember any changes in drivers/input/mouse/synaptics.c that went into the latest lucid kernel updates?
<sconklin> cnd: no but it's really easy for me to check
<cnd> medberry, I'll add that upstream still doesn't have a great solution for this, IIRC
<medberry> cnd, to clarify, afaict, this is still broken/crippled in M/N/O-alpha as well.
<cnd> yeah
<medberry> cnd, yes, I think that's the issue.
<cnd> the kernel should provide the raw coordinates, which is what occurs in M/N/O/etc.
<medberry> did lucid release with a kernel that didn't have the pointer stuff "in kernel". That's my understanding (or misunderstanding)
<cnd> but xserver-xorg-input-synaptics needs to handle clickpads properly
<cnd> which it doesn't right now
<medberry> okay.
<sconklin> cnd: I don't see any recent changes to that at all
<sconklin> i.e. last patch was in April 2010
<medberry> I'm going to double check my assumption that it was a kernel change that made the difference. Please disregard until I've completely verified that is the delta.
<cnd> medberry, can you check to see what events are emitted by the kernel in the good and bad kernels?
<cnd> you can use evtest to see the events
<medberry> sure.
<medberry> I'll do that and get back to you. Thanks.
<cnd> the "good" kernel probably is emitting BTN_LEFT, BTN_RIGHT, and BTN_MIDDLE
<cnd> whereas the "bad" kernel is probably only emitting BTN_LEFT
<medberry> nod.
<sconklin> cnd: I may have found what happened with input
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.32/+bug/814186
<ubot2> Ubuntu bug 814186 in linux-backports-modules-2.6.32 "linux-backports-modules-wwan and -input packaged incorrectly" [Medium,Fix committed]
<sconklin> previously the input driver from lbm wasn't getting loaded, and apparently now it is
<cnd> medberry, do you have linux-backports-modules-synaptics installed?
<cnd> sconklin, I'm not sure that works out though
<cnd> so if lbm is installed, the synaptics module may be the server version
<cnd> and so it would fail to load
<cnd> but then you'd end up without any input modules loaded
<sconklin> yeah, it only applies if lbm is installed
<cnd> actually, that might work out
<cnd> I dunno :)
<sconklin> well, the kernel also has some input drivers without lbm, so I believe you would just get a different driver
<cnd> yeah
<cnd> it could be picking up a static standard PS2 driver instead
<cnd> and I wouldn't be too surprised if these clickpads worked better in PS2 mode than in full synaptics mode :)
<sconklin> cnd: a bug with collected info would be helpful. And is this from -proposed? because that change hasn't been released yet
<sconklin> medberry: are you running -proposed?
<cnd> sconklin, meet medberry :)
<sconklin> medberry: the most helpful thing now is to run 'ubuntu-bug linux' and get all your info into a bug
<medberry> sconklin, cnd, nod.
<medberry> sconklin, dpkg -l linux-backport\* reports nothing 
<jwi> note that several touchpad "regressions" have been reported after the update to -33.70; 811420, 811753, 811962, 815357
<bjf> jwi, bug 811753 is against .32-32.62 where the other three are .32-33.70
<ubot2> Launchpad bug 811753 in linux "Synaptics Touchpad keys stoped working" [Undecided,Confirmed] https://launchpad.net/bugs/811753
<medberry> sconklin, my experience is similar to 811753. cnd: evtest reported  can't get version: Inappropriate ioctl for device (no matter which mouse dev I chose.)
<cnd> gah, the stupid evdev protocol version issue
<cnd> medberry, get the oneiric evtest package and install it
<bjf> jwi, how do you happen to be tracking those bugs, are you watching input bugs or lucid regressions or ... ?
<cnd> it should work just fine
<medberry> nod, will do.
<bjf> ogasawara, ping (just if you happen to be around right now)
<medberry> cnd, oneiric evtest behaved the same: Inappropriate ioctl for device
<medberry> I then ran "xinput test ##" with my device on both
<medberry> the new kernel reports only button 1 events (and they occur anywhere on the clickpad). The old kernel reports all three buttons but only in the lower 20-25% of the screen.
<medberry> Both report movement but the old kernel only reports mouse motion in the top 75-80% of the clickpad. The new kernel reports all over. So it's just one giant button/mouse in its behavior.
<medberry> (which as I understand accurately reflects the hardware--software heuristics are required to get the B1, B2, B3 and to distinguish between the "mouse" and "button" areas.)
<medberry> my work around for now is to use the 2.6.32-32 kernel
<jwi> bjf: incoming regressions, mostly. re 811753: note the user's description, I guess it was reported from the old/working kernel
<bjf> jwi, i was looking at the bootdmesg
<medberry> jwi, bjf : if you need a guinea pig for these issues let me know. My issue most closely resembles 811753.
<bjf> medberry, i have nothing to offer right now
<medberry> no worries. Thanks guys.
<cnd> sconklin, bjf: where's the code for the workflow mgr bot?
<bjf> cnd kteam-tools
<cnd> ok
<bjf> cnd, it's kind of complicated because it's trying to manage a specific workflow, but it wouldn't be bad to start with, gut it and do your own
<cnd> yeah
<cnd> bjf, how do you develop? what's your testbed?
<bjf> cnd, unfortunately the best thing to use is the qastaging server
<bjf> cnd, if you look at the code, there is a --staging command line flag that you can use
<cnd> what's the qastaging server?
<cnd> is it some semi-permanent instance?
<bjf> cnd, you can create any bugs over on that server/service (a testing LP instance)
<bjf> cnd, it's got a snapshot of the DB, so any changes you make there are not seen on the production server
<cnd> ahh, cool
<bjf> cnd, the problem with it is that it isn't real stable
<cnd> oh..
 * cnd just hit an error
<cnd> bjf, I assume things are wiped every so often?
<bjf> cnd, yes, something like weekly
<cnd> ok
<bjf> cnd, https://bugs.qastaging.launchpad.net/ubuntu/+source/evolution/+bug/777777
<ubot2> Ubuntu bug 777777 in evolution "Mark read / unread only works once in message window" [Low,New]
<bjf> cnd that worked for me
<cnd> bjf, where's the documentation for the launchpad api?
<bjf> https://edge.launchpad.net/+apidoc/
<bjf> cnd the bot uses the LPLTK which is a slick on top of the LP api
<cnd> ok
<bjf> cnd bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/
<bjf> cnd https://launchpad.net/~arsenal-devel/+archive/ppa
#ubuntu-kernel 2011-08-03
<cnd> bjf:     from lpltk.service                   import LaunchpadService
<cnd> ImportError: No module named service
<cnd> any ideas?
<bjf> cnd, yes, you want "from lpltk.LaunchpadService import LaunchpadService"
<cnd> ok
<cnd> bjf, I'm getting really antsy cause I can't figure this out :)
<cnd> I see setters in lpltk
<cnd> but not everything I need has one
<cnd> so I looked at the setter code and I see things being set and a function called lp_save() being called
<cnd> but I can't find where lp_save is defined
<bjf> cnd, that could be the case, it's mostly implemented what we've wanted for working on bugs
<cnd> in lpltk and python-launchpadlib
<bjf> cnd, ok, one sec
<cnd> in fact, the whole launchpadlib source code doesn't make sense to me :)
<bjf> cnd, if you look at the "status" setter for a BugTask, it is calling self.lp_bug_task.lp_save()  that lp_save() is part of the lp api, not the lpltk, it is using the raw LP object
<cnd> yeah, and that raw LP object is from launchpadlib I assume?
<bjf> cnd, yes
<cnd> so I went over to launchpadlib to see if I could find out where lp_save is and what else I can set
<cnd> but it doesn't make a lot of sense to me
<bjf> cnd, not everything is documented
<bjf> cnd, even for the launchpad library
<cnd> yeah
<cnd> ok, I might be starting to understand it
<cnd> it's just heavily abstracted
<jk-> ... and heavily dynamic
<jk-> cnd: `print bug.lp_attributes` is handy
<cnd> ok
<bjf> jk-, are you using the lpltk or the straight lp api?
<jk-> or <any lp object>.{lp_attributes,lp_collections,lp_entries}
<jk-> bjf: ah, just straight lp api
<bjf> jk-, right, that doesn't work with the lpltk unless you get to the raw lp object in the wrapper
<cnd> jk-, how do I manipulate an lp object?
<cnd> lets say I want to create a project
<cnd> I may have figured it out
<jk-> cnd: I've only queried LP myself :/
<cnd> ok
<jk-> seen https://help.launchpad.net/API ?
<jk-> particularly https://help.launchpad.net/API/launchpadlib
<jk->     me = people['my-user-name']
<jk->     me.display_name = 'A user who edits through the Launchpad web service.'
<jk->     me.lp_save()
<jk-> but again, this is all launchpadlib objects, not lpltk.
<cnd> yeah, I'm trying to figure out how to create new objects
<cnd> to set up a test env
<cnd> on qastaging
<cnd> it doesn't appear that many people have wanted to do this before :)
<cnd> I see that there's a method new_project
<cnd> but I don't know what its signature is
<cnd> it's rather opaque, and there's no docs that I can find...
<bjf> cnd, looks like you need the lp projects collection
<cnd> I may have figured it out by finding a snippet through google :)
<cnd> http://webcache.googleusercontent.com/search?q=cache:TepAzI2pmu0J:people.canonical.com/~bryce/arsenal_lib.py+launchpadlib+%22new_bug%22&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com
<cnd> grep for new_bug
<jk-> cnd: print new_project.__doc__ ?
<bjf> cnd, you may be better off sticking with the straight LP api, you could look at "close-eol-nominations" in kteam-tools/bugs for an example
<cnd> yeah
<rokr1> Hello there !
<rokr1> I am trying to install Mainline 3.0 in Linux kernel from ubuntu repository
<rokr1> current version seems 3.0-oneiric
<rokr1> I am running natty 64bit
<rokr1> desktop
<rokr1> I would like to know if the new mainline version of kernel 3.0 supports XEN dom0 natively ?
<rokr1> I hope the .deb packages are generic
<rokr1> lamot u there ?
<rokr1> sorry lamont*
<rokr1> does kernel 3.0-oneiric support XEN dom0 
<rokr1> ?
<rokr1> Just installed 3.0 about restart please advise
<rokr1> I am about to restart the machine !
<rokr1> bye
<jk-> CONFIG_XEN_DOM0=y
<jk-> -ETIMEDOUT
<rokr1> back after a reboot now on 3.0-oneiric
<rokr1> kernel
<jk-> <jk-> CONFIG_XEN_DOM0=y
<jk-> ^ rokr1
<rokr1> is it enabled by default ?
<jk-> that's the default config
<jk-> so yes
<rokr1> Oh okay
<rokr1> thanks jk
 * jk- has no idea what else is required
<rokr1> will be back once if I have a question bye for now!
 * apw yawns
<jk-> hey apw
<apw> jk- heya
 * smb crawls in
 * apw waves to smb
<smb> apw, mornin
<cooloney> morning apw and smb 
<apw> cooloney, moin
<smb> cooloney, morning
<cooloney> apw and smb, did you guys try the onieric for MAC?
<cooloney> which is the same kernel as amd64?
<smb> cooloney, What makes you think we even got a MAC
<cooloney> smb: oh, i found a special ISO for mac on cdimage.ubuntu.com
<cooloney> http://cdimage.ubuntu.com/daily-live/current/
<smb> cooloney, For which you would want to use the right hardware, no? ;)
<cooloney> smb: you know, i had a macbook pro and maybe test the iso on my mac
<apw> cooloney, yep you need a special iso cause mac efi is sooooo broken
<smb> cooloney, You are free to do, but I have not a single piece ow hardware with an apple on it
<apw> does anyone know if it is possible that a machine with wireless is not capable of doing wpa ?
<smb> apw, Think that is possible
<apw> is it a hardware feature
<cooloney> apw: ming lei or ikepanhc might know that, heh
<apw> oh dear
<smb> With old wireless chipsets...
<apw> poor t30
 * ikepanhc ah?
<smb> apw, But I thought wpa_supplicant worked around that to some degree..
<cooloney> apw: are you still using t30?
<ohsix> it depends on the drivers too
<apw> cooloney, i have one lying about as its tooo crap to run unity, so it defaults to unity-2d
<ohsix> mac80211 drivers generally can do "anything", barring bizarre hw edge cases
<ikepanhc> it must be a very old wifi chips, since 802.11i has announced for at least 5y
 * smb wonders that a t30 should be able to do wpa... His t21 could...
<ikepanhc> t30 should, I once have a x31, it works fine with wpa, I think they are about the same year
<apw> ikepanhc, hmmm ok ... it has a prism chipset
<apw> and is only offering me password options for non-wpa levels oddly
<ikepanhc> apw: which machine?
<ikepanhc> and with ubuntu?
<apw> ikepanhc, it is a t30 and with natty yes
 * ikepanhc checking
<apw> only the SO is allowed to have windows, and only then cause screaming and crying didn't persuade them otherwise
<apw> well i plugged in some external thing that rtg gave me, and that just selects wpa correctly for my network
<apw> i suspect the prism can't do it, i guess it might be cause i have selected tkip
<smb> apw, Yeah, I think prism was "special"...
<apw> you mean that it was and is a POS ?
<smb> apw, My memory may be wrong, but I think it had a special driver (not softmac) which did not do that and probably is not maintained much anymore...
<apw> yay, fun, joy, BAH
<ikepanhc> apw: for you reference: http://lists.shmoo.com/pipermail/hostap/2010-April/021329.html seems there are several drivers for Intersil prism 2.5 and not all of them supported wpa
<apw> yay
<apw> ikepanhc, thanks, i suspect it is too shite to believe, i will therefore assume it cannot do it
<apw> anyone owned one of those 
<apw> nano USB adapters that actually worked ok ?
<smb> I had one small but its currently on rental and I do not remember what chipset...
<smb> but it worked ok
<apw> you mean you have loaned it to someone ?
<ikepanhc> I am glad that I can help
<smb> apw, Yeah, to my brother in exchange to his seemingly broken (in Linux) one
<apw> they always do that, you end up with piles of junk which don't work for you and all the good stuff is gone
<smb> apw, Though it turned out its only broken in the sense that it lies about connection speed
<apw> oh so its working fine, just saying 0mb all the time
<smb> Yeah, 1Mbit but exactly
<smb> Still runs at higher speed but you only can see that deeply hidden in debugfs
<smb> apw, Though I may fix that when I have nothing else to do... Well clearly that is about to happen ... not soon
<apw> right two random nano wireless thingies which claim to support linux purchased
<tgardner> apw, I notice Mario has uploaded dkms.
<lilstevie> just wondering if security_yama and security_smack are required
<ogra_> did you guys rework the enforcer parts of the packages ?
<ogra_> (if so, is there a wikipage or some other doc that lists why something is needed, so we know if we need to patch third party kernels because userspace requires a feature patch)
<tgardner> ogra_, what config option is bothering you?
<ogra_> tgardner, well, lilstevie is just rolling a galaxy tab kernel for an ubuntu image and the enforcer wants things like aufs, security_yama and security_smack
<ogra_> as you can guess he uses the ubuntu package infrastructure
<tgardner> well, we tune these config options for the distro and not necessarily for an embedded system
<ogra_> its not "embedded"
<ogra_> :)
<ogra_> its not different to the pandaboard 
<ogra_> which is rather atom class 
<tgardner> ogra_, ok, then what is the issue? you want to disable them ?
<ogra_> and he rolls a normal unity-2d ubuntu desktop image for it 
<ogra_> tgardner, i wonder if we have documentation anywhere why what is needed so i can go through the enforcer file and drop things for non ubuntu maintained kernels (missing aufs for a non live system wont do harm for example, but people need to know that its only for this)
<tgardner> ogra_, there is probably a rationale somewhere. ogasawara, do you have this in our config review spec ?
<ogra_> ... if no userspace makes any use of security_yama and security_smack i wouldnt want to patch a 2.6.29 BSP kernel i package for universe to have it (and having to maintain that patch)
<ogasawara> tgardner, ogra_: nope, I don't recall we've documented the config enforcer in any or our wikis or specs
<lilstevie> Well I just want to know what are the absolute required patches
<ogasawara> tgardner, ogra_: I think some of the configs being enforced have a comment in the file itself for why it's there, otherwise one would likely have to parse the git history
<ogra_> lilstevie, my ac100 works fine without security_yama and security_smack on oneiric 
<tgardner> lilstevie, I think anything in the ubuntu directory is optional since its not part of mainline. aufs, yama, etc...
<lilstevie> yeah I am working fine without yama and smack
<lilstevie> I am just wondering if there is any reason that I may not be seeing
<ogra_> ubuntu should generally be able to run with mainline kernels
<ogra_> the ubuntu patches are usually fo special features (i.e. aufs -> livecd)
<tgardner> ogra_, apparmor will complain a little, but things will still work
<lilstevie> and we don't have a live cd on arm do we?
<lilstevie> tgardner: well I have apparmor
<ogra_> hmm, it doesnt complain here on an up to date oneiric
<kees> ogra_, lilstevie: running without Yama will open a system up to a few classes of security vulnerabilities, so I would recommend keeping it.
<lilstevie> kees: it isn't available in my kernel
<lilstevie> this is why I am wondering
<ogra_> kees, "keeping" isnt the discussion point ;)
<kees> ogra_: oh, I have misunderstood, then. :)
<lilstevie> Yama and Smack are not available in my kernel
<ogra_> its an older kernel version (as BSP kernels usually are) that misses such features
<ogra_> to be packaged in universe for a certain device 
<kees> nothing in the default ubuntu userspace uses smack, so that's fine.
 * ogasawara back in 20
<ogra_> great :)
<kees> there are a few regression tests that will fail if Yama is missing, and while a few things are tuned to work with Yama, they will operate fine without it.
<lilstevie> ok that is good to know
<ogra_> lilstevie, so i would look how much effort adding yama is :) 
<lilstevie> yeah
<lilstevie> kees: is this all there is to yama http://codereview.chromium.org/6677065
<lilstevie> if so that isn't too bad
<kees> lilstevie: it's small, yeah. the "current" set of patches is as mentioned from that url, in my git tree: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads/yama
<jmburgess> Hey kernel team. I have two bugs that I think are ready to be marked as triaged. Can anybody look them over for me? I'm new
<jmburgess> Bug 565543 and 814426
<ubot2> Launchpad bug 565543 in linux "Alps touchpad detected as ImPS/2 Generic Wheel Mouse(in VAIO E series) after the kernel upgrade" [Medium,Confirmed] https://launchpad.net/bugs/565543
<ubot2> Launchpad bug 814426 in linux "Natty Narwhal Crackling Sound" [Medium,In progress] https://launchpad.net/bugs/814426
<lilstevie> actually smack seems pretty easy to implement too
<charlie-tca> jmburgess: looking
<jmburgess> Thanks charlie-tca
<kees> lilstevie: smack should just be a CONFIG_* option, iirc.
<charlie-tca> jmburgess: Done; very nice work on those
<charlie-tca> Thanks for helping with those bugs.
<lilstevie> kees: heh yeah, smack is implemented in kernel, just not refered to in the makefile or Kconfig
<lilstevie> I just didn't notice before
<jmburgess> charlie-tca, :) glad I can help
<charlie-tca> kernel bugs are difficult to work. It is good to have some help with them
<Q-FUNK> Greetings!  It seems that I have a serious regression in Oneiric since kernel 3.0 that has forced me to revert to 2.6.38. 
<Q-FUNK> I'd love to report it, except that 'ubuntu-bug linux-image-3.0.0-7-generic' would obviously attach the wrong boot logs. Any ideas on how to work around that?
<apw> Q-FUNK, i think it doesn't attach the running ones if you use a binary like that
 * smb -> away
 * herton -> lunch
<Q-FUNK> apw: could be.  any other way to get the log from the previous boot, to shot what crashed?
<apw> nothing in syslog?  and it crashes hard ?
<Q-FUNK> it freezes half-way thru the boot.   it already started misbehaving during the 2.6.39, but it was fairly random at that time.  mostly odd segfaults whenever running dpkg.  with 3.0, it's nearly systematic.
<apw> Q-FUNK, and booting without splash vthandoff and adding debug wahts that look like
<Q-FUNK> apw: I'm probably missing half of your sentence?
<apw> i am trying to work out what level of kernel loggin is visible when you are booting
<apw> therefore i am asking if you have disabled splash etc and turned on debug
<apw> Q-FUNK, ^^
<Q-FUNK> apw: if your have cmdline recipe I could input into grub, I'd welcome that.
<apw> when at the boot menu, edit the entry and change the set gfxmenu=$xxx to =text
<apw> then drop "splash" and "vt.handoff=N" from the command line and add "debug"
<apw> then boot that
<cnd> bjf[afk], sconklin: how is the sru bug tracking page generated?
<bjf> cnd, look in kteam-tools/web the makefile shows all
<cnd> bjf, ok, thanks
<Q-FUNK> apw: thanks.  where will that drop the log ad how do I grab it when I reboot into my backup kernel to attach to the bug?
<dupondje> For a gps device, a /dev/gpsX should be created or ?
<sforshee> dupondje, no /dev/gps that I'm aware of. What kind of device is it?
<ohsix> sforshee: they're usually serial ports, barring devices that don't talk NMEA
<sforshee> ohsix, depends, a lot of consumer models just have a USB mass storage interface
<ohsix> (so they're on the serial ports, not gpsX)
<ohsix> my only experience is garmin devices where it's a proprietary protocol or nmea
<ohsix> i presume he actually meant to get gps information, not something like a tomtom situation where you copy maps or whatever to it over usb
<sforshee> ohsix, that's why it depends on the model :)
<dupondje> iInterface             18 Dell Wireless 5540 HSPA Mini-Card GPS Port
<ohsix> yup, i was more speaking to getting nmea and it showing up as a serial port; he'd probably notice a disk :P
<dupondje> would be cool if it worked :P
<sforshee> dupondje, my first guess would a serial port then, but I don't know anything about that device
<dupondje> Bus 002 Device 004: ID 413c:8184 Dell Computer Corp. F3607gw v2 Mobile Broadband Module
<dupondje> its 3G & (A)GPS in one
<dupondje> usb-_ADell_Wireless_5540_Dell_Wireless_5540_3563970331281170-if0X
<dupondje> mmm :) serial it seems indeed
<dupondje> got 3 of them
<sforshee> dupondje, from there it depends if it used NMEA or some proprietary protocol
<JanC> that's an Ericsson I guess?  âº
<dupondje> any idea how I can find out what one of the 3 it is ?
<JanC> dupondje: try pointing gpsd to all 3 of them and see which one it gets data from?
<ohsix> try "cat" on all of them, one at a time :>
<ohsix> one of them will probably be the modem baseband, dunno what the third will be
<dupondje> none of them gives output :P
<sforshee> dupondje, you could also try looking at the data from 'udevadm info --export-db' for the ttyUSB devices, see if there are descriptive names associated with them
<ohsix> those cards tend to need firmware and special knocks too
<JanC> not sure if this has useful info: http://sourceforge.net/apps/mediawiki/mbm/index.php?title=MBM
<dupondje> NetworkManager does see the modem, so thats fine
<dupondje> JanC: seems nice
<dupondje> lets read
<dupondje> mmm, the tool depends on HAL :(
<apw> bjf, ok finally remembered to fix those two reports ... should be ok now
<bjf> apw, it would seem so
<apw> bjf, i've also moved your update jobs a couple minutes earlier to miss the matrix update
<bjf> apw, wfm
<dupondje> JanC: http://www.thinkwiki.org/wiki/Ericsson_F3507g_Mobile_Broadband_Module
<dupondje> seems like it can be enabled manually also :D
<JanC> right, that's at least based on the same Ericsson card, it seems
<JanC> or a similar one?
<JanC> 3507 vs. 3607
<dupondje> $GPGGA,,,,,,0,00,0.5,,M,-0.142099,M,0.0000199,0130*54
<dupondje> $GPRMC,000151.86,V,,,,,,,060180,,,N*79
<dupondje> $GPGSA,A,1,,,,,,,,,,,,,1.1,0.5,1.0*34
<dupondje> hehe :D
<dupondje> waiting for a fix :)
 * JanC only has a 12 â¬ "GPS mouse"  âº
<JanC> (which gets a fix within seconds)
<dupondje> still no fix btw
<dupondje> sad :(
<robbiew> any known issues with power management in Oneiric?  my x220 is getting sucked dry:
<robbiew> Power usage (ACPI estimate): 19.8W (2.3 hours)
<robbiew> Top causes for wakeups:
<robbiew> 33.9% (526.4)   [Rescheduling interrupts] <kernel IPI>
<robbiew> 23.1% (358.6)   SignalSender
<Sarvatt> robbiew: thats chromium sucking your power dry
<robbiew> all hell
<Sarvatt> robbiew: supposedly fixed by 14.0.835.0 according to the bug report
<Sarvatt> http://code.google.com/p/chromium/issues/detail?id=77625
 * robbiew is running chrome browser...but I guess it's there too
<robbiew> amazing...thanks!
<manjo> Sarvatt, u genius
 * robbiew switches to the unstable package...maybe the fix is there...damn sure ain't in stable
<Sarvatt> 14.0.835 should be dev channel
<robbiew> yep...fixed in unstable Chrome browser
#ubuntu-kernel 2011-08-04
<vanhoof> Sarvatt: /me is going to test as well
<kees> did tangerine changes its host key?
<broder> kees...are you asking that...from blackhat? :-P
<kees> broder: haha, yes, but I see the same host key change from home too :)
<broder> "you just think you're seeing the same host key change from home"
<kees> if so, I'm a certainly doomed :)
<kees> s/ a/
<diwic> is it really kees asking that? :-)
<kees> hehe
<smb> Morning
<smb> kees, In case still interested, yes it did change. And for your convenience we erased all you data in /home
 * ogasawara back in 20
<kees> smb: where can I find the new host key?
<apw> kees, i emailed you the fingerprints
<apw> (and even signed them)
 * smb is much more careless and trusts the key to be right knowing the machine had been reinstalled...
<kees> apw: ah, heh, just saw that now :)
<kees> <sysadmin>why not keep the host keys when reinstalling?</sysadmin>
<apw> kees, heh
<_ruben> and use the same keys on all hosts just to be on the "safe" side
<apw> kees, of course you'll be phoneing me to confirm _my_ fingerprint
<smb> and set it to 123456 so one can remember
<_ruben> apw: but how will you know it's kees calling?
<apw> luckily i'd be giving out public information so if its the wrong person it doesn't matter
<_ruben> true
<mfilipe> sforshee, man, you rox! lol
<skaet> ogasawara, apw - could one of you take a pass at https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview and update the linux kernel info?
<ogasawara> skaet: yep
<skaet> thanks ogasawara !
<mfilipe> I will try the lucid backport 
<mfilipe> I only need more time here :)
<ogasawara> skaet: should I add an "Ubuntu Kernel" section to the "New features in Oneiric" area? or would you prefer I put our info under a different section?
<skaet> ogasawara, please do.
<skaet> heh
<sforshee> mfilipe, thanks, but all I did was backport :)
<skaet> ogasawara,  put it in the new features section.
<ogasawara> skaet: ack
<mfilipe> sforshee, I know but it is 2.6.32
<mfilipe> backport of natty need be 2.6.38, no?
<sforshee> mfilipe, did you test it? is it working for you?
<sforshee> mfilipe, yep, natty is 2.6.38
<mfilipe> not yet
<mfilipe> I need get free time in work 
<mfilipe> tonight I will test it
<sforshee> mfilipe, cool. I'm a little uncertain of the lucid backport since that code has changed quite a bit, so I'm interested to hear if it works.
<mfilipe> ok, certainly I will talk with you about the results
<sforshee> mfilipe, thanks!
<ogasawara> skaet: https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#Ubuntu_Kernel
<skaet> ogasawara, looks good.  Thanks!  :)
<ara> Hello!
<ara> maybe sconklin, or bjf can help a bit
<bjf> ara, ?
<apw> ara, ask, you never know who might answer
<ara> we had a Lucid kernel SRU released  just last week and another one is now in the testing phase
<ara> are we losing the three week cadence?
<ara> (this would be less than 3 weeks)
<bjf> ara, no 
<bjf> ara, give me a sec to find out what is going on
<bjf> herton, it looks like you've uploaded a new lucid kernel to fix a single regression, is that correct?
<herton> bjf: yep, was about to tell this
<herton> it was just a new release for 811745
<herton> *bug 811745
<ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [High,Fix committed] https://launchpad.net/bugs/811745
<apw> bug #811745
<apw> did the previous one make it out to -updates already ?
<herton> yes
<bjf> herton, so I think a little more communication should have been done, we probably should have put that information into the tracking bug and given qa/cert a heads up
 * apw wonders if its worth handling that single fix as an upload given the regresion made it into -updates
<herton> bjf: indeed
<bjf> herton, we decided that since a regression went out in -updates, we wanted to do a quick turn to "fix" that regression and get that into -updates as quickly as possible, correct?
<bjf> herton, do you know who this was discussed with?
<herton> exactly. Also worth to note that we are in the regression testing week, and thus lucid syncs again with calendar if testing is done this week I think. bjf, sconklin did the packaging
<herton> I told to him about the regression, and he pushed the update
 * herton -> lunch
<bjf> ara, ^
<bjf> herton, the lucid that went to -updates last week, was that from this cycle or the previous cycle?
<ara> bjf, the problem is that it is very difficult to plan this. We hadn't planned to test this week (nor in the next two weeks)
<ara> bjf, is it necessary to do a full testing if it was only 1 fix?
<bjf> ara, isn't this the week for cert. testing in the current cycle?
<bjf> ara, i've not looked at what was done to fix this regression, so i don't know how much testing is required
<ara> bjf, with all the changes that we have been doing to adapt to the different uploads, really, we lose track
<bjf> ara, not sure i'm following that, you are saying that there have been a number of unanticipated uploads (of kernels)?
<ara> bjf, there must be. If not, how we could have tested last week and also this one?
<ara> (or 2 weeks ago)
<ara> the kernel calendar only shows "one path" where, actually, every series follow their own cadence
<bjf> ara, that is true to a point, we try to keep them all in sync and as part of the same cadence
<sconklin> ara: I should have communicated this better. The intention was that with a single fix, this could receive light testing, and we could turn it quickly.
<sconklin> The next update will be large, and I didn't want to hold this fix for it.
<sconklin> I'm pretty sure I discussed this with someone, but I didn't put it out to your team, as I should have.
<herton> bjf: previous cycle
<ara> sconklin, could you send to the mailing list the testing that you would be happy with?
<sconklin> yep
<ara> sconklin, awesome, thanks
 * ara needs to log off now
 * bjf -> quick errand
 * smb -> gone
 * bjf -> back
 * apw performs extensive keyboard surgery
<ricotz> apw, hello, what happened to the lucid kernel repos? it looks like there are only a few new commits, but pulling it results in  a massive download like after multiple rebases
<apw> can you pastebin the output of the pull please
<apw> and when did you last pull?  as there may well have been some rebases
<apw> for the derivative branches
<ricotz> i pulled yesterday and it already downloaded 170mb at 40%
<ricotz> so it is still loading
<ricotz> apw, http://paste.debian.net/125127/
<ricotz> the hash is from master branch
<apw> when did this pull start
<ricotz> like 15min ago
<apw> i think the natty lts backport may have been rebased today, but that seems like a lot of objects none the less
<apw> if you are happy to let it finish i'd like to see which refs changed and from and to what
<ricotz> yeah will do
<ricotz> apw, http://paste.debian.net/plain/125130
<apw> ricotz, what do you use as transport?  git:// or http:// ?
<apw> the odd thing about that output is all of the updates are fast-forward updates, much as i would expect
<apw> a few commits on any one branch.  why you got all those other objects is a mystery
<ricotz> using git://
<apw> then that is just bizarre, as i suspect if you got log --oneline | wc -l  on each of those xxx..yyy it won't add up to more than 3 or 4 commits
<ricotz> weird, i need to check the repo config
<apw> ricotz, its not at all obvious how it could be your fault
<ricotz> i use to define references to save download
<apw> ricotz, there are three commits in those ..'s, so why you didn't get those three and only those three i have no idea
<ricotz> apw, i have no idea, after a rebase it seems normal to a larger diff, but that seems not normal
<ricotz> anyway thanks for looking at it
#ubuntu-kernel 2011-08-05
<lifeless> apw: hi; I'm curious if you think bug 729338 will have a fix before oneiric is released, or should we look for alternative workarounds ?
<ubot2> Launchpad bug 729338 in linux "yama hardlink restriction misbehaves under aufs" [Medium,Triaged] https://launchpad.net/bugs/729338
 * apw yawns
 * smb waves (a coffee)
 * apw reposts with a cup of english breakfast
<RAOF> Capitol!
<apw> A
<smb> B
<RAOF> No, capital is where the government lives.  Capitol is the accepted response for english breakfast tea.
 * smb was hoping to score 7 for doing a cab... :-P
<apw> RAOF, i have have heard the sound of "capital" used in the context of "capital idea" i didn't think it spelt differently though
<RAOF> My version is!
<apw> heh, well i assumed a miss-spelling and worked with that.  but indeed it is a capit[oa]l idea, so much so i need another
<tjaalton> RAOF: just to confuse some more, Capitol Hill is where the US government lives ;)
<apw> tjaalton, ahh but that really is a differnt spelling (with an o)
<tjaalton> apw: yeah, just a reply to the "capital is where.."
 * smb thought it was capital hill... well until they nearly went out of it now... :-P
<jk--> hey RAOF, tjaalton, smb, and apw.
 * apw waves to jk-- -----
<smb> hi jk-- 
<tjaalton> jk--: o/
 * jk-- makes use of the Oxford Comma while it still exists
<smb> jk++ ? ;)
<jk-> :D
<jk-> smb: too similar to c++
<smb> jk-, Oh, you did not accidentally type code when setting the nick then... ;-)
<jk->  /nick intmain(void)
<jk->  /nick intmain(void){return0;}
<jk-> :)
 * apw calls you initmain from now on
<apw> intmain even
<jk-> only if I can call you EXIT_FAILURE
<jk-> or maybe EXIT_SUCCESS, less bad connotations
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/821157
<ubot2> Ubuntu bug 821157 in linux "intel 5300agn in Oneric leads w722v to reboot" [Undecided,New]
<apw> if i am reading this right oneiric causes their wireless router to reboot ... 
<jk-> nice
<lilstevie> apw: how odd
<apw> indeed.  and i am unsure how i am meant to help with it ... your router is clearly broken if a client can crash it
<lilstevie> yeah
<lilstevie> I mean like what, if an ATM went out of order when you put your card in, there is something wrong with the atm not your card
<apw> when my car drove over the bridge it collapsed, your car is clearly faulty please fix it
<lilstevie> heh
<jk-> "but it worked with my previous car!"
<lilstevie> some people have a hard time with cause and effect
<apw> jk-, on the nail
<lilstevie> got anymore info
<bullgard6> Natty writes at startup in a virtual console: "[1.581365] mmc0: no vmc regulator found". I suppose that this message originates from the MMC kernel subsystem. What kernel routine or program does cause this message?
<apw> bullgard6, what h/w is that from
<apw> bullgard6, and is that verbatim copy?  ie could it be vmmc in the middle ?
<bullgard6> apw: The hardware is a Thinkpad T61. Yes, I made a mistake. It should read "vmmc". I beg your pardon.
<bullgard6> apw: In the mean time I found out that /usr/src/linux-source-2.6.38/drivers/mmc/host/sdhci.c includes a printk line of this text.
<apw> bullgard6, i am trying to understand if there is an issue associated with this, or if you just are querying the error
<bullgard6> apw: Once I tested this computer using an SD card, and it worked. I would like to know what this warning means to me.
<apw> bullgard6, from what i am reading your mmc slot can have an option power regulator, if that is found we enable it else we emit that message
 * ogasawara back in 20
<sforshee> cnd, I have a question for you about input multitouch protocol when you have a minute
<cnd> sforshee, sure
<sforshee> cnd, I'm working with a touchpad driver, 2-finger touch seems to be working fine but 3-finger events aren't
<sforshee> comparing the output from this driver to that from synaptics, the only thing I see different is that this driver only reports 1 MT position whereas synaptics reports 2
<cnd> which touchpad?
<sforshee> elantech
<sforshee> the tripletap event is reported, but the device only gives a single position for 3 touches
<sforshee> cnd, in ubuntu a 3-finger tap just acts like a 1-finger tap
<sforshee> and a 3-finger drag like a 1-finger drag
<cnd> sforshee, this is typical for multifinger touchpads
<cnd> are you sure it's actually multitouch?>
<apw> yeah multi-finger is not the same
<sforshee> cnd, it reports the number of contacts (up to 3) and with 2 fingers it reports 2 positions
<cnd> sforshee, oh, and then it drops down to one position for three touches?
<sforshee> yep
<sforshee> cnd, would it help to see a dump of the events?
<cnd> hmm
<cnd> it wouldn't hurt
<cnd> so what questions do you have?
<sforshee> cnd, http://pastebin.ubuntu.com/659348/
<sforshee> cnd, I guess my question is what events the driver needs to spit out to have 3 contact gestures properly supported
<cnd> ok
<apw> sforshee, do you know that it can even do three touch
<sforshee> cnd, that dump is for dragging on the touchpad with 3 fingers
<apw> just cause it can tell you that there are three fingers touching doesn't mean i knows where they are
<sforshee> apw, it reports that there are 3 contacts, but only reports one position
<sforshee> right
<cnd> sforshee, can you provide me the full dump that includes the transitions from 1 to 2 to 3 touches
<apw> that as they say tells you nothing
<sforshee> but isn't that enough for a 3-finger tap or drag?
<cnd> sforshee, multifinger mode, which this looks to be, would be enough
<apw> now that is a different thing, and likely it should be
<cnd> except we don't actually have the support for it
<sforshee> cnd, let me get that dump for you
<apw> c
<cnd> we gave it a shot about a year ago, and it broke devices
<apw> cnd we gett
<apw> cnd we getting anything new for this cycle?
<cnd> and we never tried again
<cnd> apw, kernel patches or?
<apw> functionality in touch
<apw> from a user perspective
<cnd> yes
<cnd> so we're still working on eog and evince to get smooth scrolling and rotate and pinch to zoom
<sforshee> cnd, with a synaptics touchpad I'm getting 3-finger taps == middle click and 3-finger drag moves the window around
<cnd> hopefully those land before FF next week
<cnd> we just published utouch-qml to universe
<cnd> that will make writing new qml applications with touch really easy
<cnd> sforshee, yeah, that's with sem-multitouch
<cnd> which is a step up from multifinger
<cnd> apw, that's also something new this cycle
<cnd> semi-multitouch synaptics trackpads have some gesture support
<sforshee> cnd, http://pastebin.ubuntu.com/659355/
<sforshee> let me know if that isn't what you meant
<cnd> sforshee, in this event stream, did you go from 0->1->2->3 or from 0->1->0->2->0->3?
<apw> sforshee, is that ... heh waht he said
<sforshee> cnd, the latter
<sforshee> I guess you want the former?
<cnd> yep :)
<sforshee> okay, just a sec
<cnd> but this does help too :)
<sforshee> cnd, http://pastebin.ubuntu.com/659356/
<sforshee> now you should have plenty of data :)
<cnd> indeed :)
<cnd> sforshee, is this really 0->1->2->3?
<cnd> cause the data is still the other way
<apw> sforshee, its the exact same data including timestamps
<sforshee> rats, let me try again...
<cnd> heh
<sforshee> cnd, apw: http://pastebin.ubuntu.com/659357/
<sforshee> I just got the wrong file
<cnd> ok
<cnd> sforshee, is this the upstream elantech driver, or from somewhere else?
<davmor2> sforshee: Hey dude, you know the fix that you put into the proposed kernel that made the atheros driver work, the latest natty kernel seems to of removed it again I think
<sforshee> cnd, it's upstream plus some work I've been doing to support a new model
<cnd> sforshee, does the hardware cease to give two points when you put three fingers down?
<sforshee> davmor2, do you have a bug number that I can refer too?
<sforshee> cnd, yes
<cnd> or is it something in the driver that is causing that to happen
<cnd> hmmm
<davmor2> sforshee: just tracking it down
<sforshee> cnd, the v2 support in the upstream driver is pretty similar to what I have, the difference largely being how 2-touch coordinates are reported
<sforshee> by the hardware that is
<cnd> sforshee, if the hardware ceases to give two coordinates when there are three touches, then I suppose this is the best you can do
<cnd> I don't know what our stack would do in this case, but I'm guessing it won't see three finger gestures
<davmor2> sforshee: https://bugs.launchpad.net/bugs/710738
<ubot2> Ubuntu bug 710738 in linux "Regression latest kernel breaks my Atheros AR5001 wifi" [High,Fix released]
<cnd> you can run geistest (in utouch-geis-tools) to see what gestures are emitted
<sforshee> cnd, okay, that's what I wanted to know -- whether I needed to do something different in the driver
<cnd> sforshee, if it's something you are interested in, you could also add support to our stack for it :)
<sforshee> cnd, thanks -- that answers another question I have, what tools to use to test multitouch :)
<cnd> there are multiple tools, but that's the easiest to use and read
<sforshee> cnd, thanks a lot!
<cnd> sure, np
<davmor2> sforshee: nevermind I've just fired it up again and now it's working so meh
<cnd> ok, time to actually get up for the day
<sforshee> davmor2, I just checked and the patches are definitely still in natty
<sforshee> hopefully it keeps working for you :-/
<davmor2> sforshee: yeah I think there might just of been a glitch after the initial install, seems fine now :)
 * apw takes a risk and updates one of his machines
<apw> if you don't see me again you know why
<jjohansen> ogasawara, apw: sorry about the ipv6 patch, it was done Friday at the sprint and somehow I dropped it.  /me swears it was sent then :/
<ogasawara> jjohansen: no worries.  I had it on my todo list to review, so thanks for doing the work!
<ogasawara> jjohansen: I'll get applied for the upload I'm preparing
<jjohansen> ogasawara: I am going to drop an apparmor patch next week, would you prefer revert patches for current stuff, or do you plan to just rebase?
<ogasawara> jjohansen: probably easier for me if you revert patches for current stuff
<jjohansen> ogasawara: okay, then that is what I will do
<manjo> pgraner, do you have root on tangerine? can you install unzip ?
<sforshee> anyone around that can approve my nominations on bug 583760 ?
<ubot2> Launchpad bug 583760 in gentoo "[PATCH] Mouse cursor dissappears with nouveau" [High,Confirmed] https://launchpad.net/bugs/583760
<ogasawara> sforshee: done
<sforshee> ogasawara, thanks!
 * ogasawara lunch
<pgraner> manjo, nope I sure don;t
<manjo> cool np 
<cnd> sforshee, I remembered one other thing that you need to be sure to do with the elantech driver
<cnd> be sure to set the maximum slot value at 1 so that it matches what the device gives, and set the INPUT_PROP_SEMI_MT property for the device
<sforshee> cnd, thanks for the tips
<sforshee> testing with geistest didn't go so well
<cnd> no?
<sforshee> most gestures were just detected as drags
<sforshee> cnd, the driver already does both of those
<cnd> sforshee, ahh, great :)
<cnd> sforshee, what did you expect for gestures?
<cnd> you should only be able to get two touch drags and pinchs
<sforshee> cnd, oh, really? then it didn't do so bad
<sforshee> cnd, I saw this page and tried to run through those tests: http://testcases.qa.ubuntu.com/Hardware/Touchscreen/Multitouch
<cnd> sforshee, SEMI_MT alone limits you so you can't do rotate
<sforshee> cnd, that explains it then :)
<cnd> SEMI_MT means you have a bounding box, but you don't actually know where the touches are
<cnd> the actual touches could be at (x1, y1) (x2, y2) or (x1, y2) (x2, y1)
<cnd> and if you don't know where they are, then you can't do rotation
<cnd> but you can do pinch by watching if the bounding box's area is changing
<sforshee> cnd, that makes sense, and seems entirely appropriate for this device
<cnd> sforshee, can you get three touch drags?
<cnd> you may not see them in geistest
<cnd> because unity may be grabbing them
<cnd> but if you run geistest in gnome 2 then you could get them
<sforshee> cnd, no
<cnd> ok
<sforshee> it's behaving like a one touch drag
<cnd> there's some logic in utouch-frame that emits the number of touches based on BTN_TOOL_*TAP events for SEMI_MT devices
<cnd> if you are interested, you could poke at it to generate the correct number of touches for these devices
<cnd> and then three finger drags may work
<sforshee> cnd, it's sending the tripletap event
<sforshee> but only one touch point
<cnd> yeah, that would be enough for drags, but not pinches of course
<cnd> there's probably a bit of logic in utouch-frame that needs to be tweaked
<sforshee> cnd, in the pastebin from earlier you can see the events: http://pastebin.ubuntu.com/659357/
<sforshee> but no triple touch drag
<cnd> sforshee, the driver is working properly
<cnd> it's a matter of "fixing" utouch-frame to make it emit three touches when the driver emits BTN_TOOL_TRIPLETAP
<cnd> utouch-frame does this already for synaptics, but synaptics emits 2 slots from the driver when there are more than 2 fingers
<cnd> elantech emits 1 slot from the driver when there are more than 2 fingers
<sforshee> cnd, okay, I get you now
<cnd> something about that is throwing off utouch-frame
<cnd> you don't have to look into utouch-frame if you're busy, I'm not trying to push work on you :)
<cnd> but if it interests you, that's where you would look
<sforshee> cnd, I probably won't have time to anytime soon, but I might take a look later on
<cnd> ok
<cnd> sforshee, I'm just happy to have one more person who speaks the language of the input subsystem :)
<sforshee> cnd, I've got more touchpad work queued up for next week too :)
<cnd> you better watch out though, you could get slurped into the multitouch team :)
 * sforshee shudders
<cnd> that's an appropriate response
<cnd> :)
<bjf> cnd, i know where you live
<cnd> bjf, I need to be careful too, cause my only get-away vehicle is a bike...
#ubuntu-kernel 2011-08-07
<melkor> I have been using the mainline kernels, the 3.0 and the 2.39.  Neither of these kernels handles my hdmi audio out correctly.  I think it is a regression becaues the .39 used to work.  Is there somewhere I should report this?
<apw> melkor, if you have tested it out with oneiric kernel then report against that
<promithius> Hi! Does anyone know about the configuration file for init process in Ubuntu or Debian systems? Is it inittab like all the systems? Cause I don't see it in the /etc directory. Any idea?
#ubuntu-kernel 2012-07-30
<smb> morning
<ppisati> moin
 * ppisati is in 'email catchup mode'
<ikepanhc> ppisati: you mean deadlock or infinite loop?
<diget> ls
<diget> ohh sorry - definately wrong window ;)
<Daviey> Hai.. can bug 1030600 be included in the next precise sru, and 12.10 next kernel please?
<ubot2> Launchpad bug 1030600 in linux "please build/install highbank dtb file" [Undecided,Confirmed] https://launchpad.net/bugs/1030600
<apw> Daviey, shark ?
<smb> Daviey, Where is the shark?
<lifeless> in midair.
<Daviey> apw: shark?
<dileks> hai means German shark
<ppisati> is monday morning even for tangerine?!?!
<ppisati> ppisati  62325 99.2  0.0 4135820 2516 pts/0    R+   09:37  37:15 /usr/bin/qemu-arm-static /bin/gzip --no-name --rsyncable -9
<cking> bah, now on 3G, ISP failure
 * Eimann is on 3G for >3 Months, T-Mobile works good :)
 * henrix is having DNS issues as well...
 * ppisati -> back in 10mins
<apw> Daviey, what do we need the dtb file for?  we clearly arn't using it right now :)
<Daviey> apw: And that is the problem.. :)... highbank qemu emulator requires device tree, the dtb file.
<apw> we have real machines?
<Daviey> we have some
<apw> Daviey, is this file different in each kernel?  is it really kernel specific?  how large is it?  do we make CDs for highbank and will they still fit with this extra on them
<apw> Daviey, and ... this patch is not even against a branch that exists any more, its not flavour specific, so i'll have to rework it completely ... sigh
<Daviey> apw: no cd is created... it's really small.. I have a panda one to hand.. # ls -alh board.dtb
<Daviey> -rw-r--r-- 1 linaro linaro 340 May 18 19:14 board.dtb
<Daviey> I believe it to be hardware specific, and as each hardware seems to have it's own kernel, it's therefore kernel specific 
<Daviey> But.. i could be wrong.
<apw> Daviey, its definatly h/w specific, i was more wondering if you have one installed for every kernle you have installed will they differ
<Daviey> apw: i suspect not, but i don't know
<apw> ./boot/highbank.dtb-3.5.0-7-highbank
<apw> Daviey, this seems like a silly name to me
<Daviey> apw: but in any case, it's going to be ~3.5K
<apw> Daviey, can you see any reason to have highbank in the name more than once ?
<Daviey> apw: I believe real highbank kernel doesn't need it, only qemu emulated.
<Daviey> apw: twice is twice the awesome.
<apw> i suppose there might be more than one machine supported by a flavour in a perfect world
<Daviey> NFI ;)
<apw> hmmm, that does not inspire me with confidence to apply the change
<Daviey> apw: wise.
<Daviey> apw: I don't care if it is called mickeymouse.dtb TBH :)
<apw> Daviey, do we really care about this in P, surely everyone in development is on Q now?
<infinity> apw: Customers being able to test/prototype in qemu is pretty important.
<infinity> apw: And their target is generally the LTS.
<ikepanhc> apw: where you get the highbank.dtb? it shall not be with linux-image
<apw> ikepanhc, its in the kernel sources isn't it?
<apw> ikepanhc, though i assume thats because someone included it
<ikepanhc> apw: yes, but device tree should be something bootloader hands to kernel in memory
<apw> ikepanhc, oh yeah i understand it is useless on the filesystem for booting, as we need it before we start running
<apw> ikepanhc, this is for the qemu users, i can also see in the future that you might have one on filesystem for a variant of flash-kernel to use when installing kernels to boot
<ikepanhc> apw: right, it is ok, but not necessary to be put into filesystem
<apw> ikepanhc, specifically here the only reason to include it is so qemu has somewhere to find it
<ikepanhc> apw: that's also right, for qemu user, they need the dtb in the filesystem
<apw> ikepanhc, so the requst was to include it for highbank in the kernel package, and i am happy for it to be in /boot as that is where we might want it for the conceptual flash my kernel with this generic arm kernel in the distant future
<ikepanhc> that raise another question, shall we support for qemu user?
<apw> ikepanhc, i don't see any formal support being requested for it
<ikepanhc> apw: sounds like I can close my eyes
<apw> Daviey, i assume there is no support for this its for testing
<ikepanhc> Daviey: you need the dtb in /boot for supporting qemu env?
<ikepanhc> what I know is that there is gap between qemu env and real hardware
<infinity> ikepanhc: It could be distributed on floppies mailed to the user, it doesn't need to be in /boot, but the general rule for DTBs should be to put them in /boot, so why deviate here just because it's not technically needed on the hardware?
 * apw is assuming the DTB here is for the real hardware rather than qemu, as its the one in the kernel
<ikepanhc> infinity: I just see the discussing about dtb in /boot.
<ikepanhc> what I am sure is that on real hardware, dtb is not something comes from kernel
<infinity> No, on real hardware, the dtb is burned into ROM.
<infinity> Though it's basically the same as the one shipped from the kernel sources.
<infinity> Which is kinda the point.
<infinity> ikepanhc: flash-kernel on real highbank hardware is mostly a no-op anyway, so yeah, the dtb doesn't get used, but that's not a big deal.  Do you actually have a concern with it being shipped?
<apw> ikepanhc, right for highbank its not that useful as its in the firware and we don't supply it with the kernel, but if we did here is the right place for it i recon
<ikepanhc> infinity: I think it shall not be shipped with linux-image
<apw> and this change needs to be approximatly right for the future too, its not a highbank change, its an ARM DTB change
<ogra_> shoultnt it be in the u-boot package ?
<infinity> ikepanhc: That's not an argument, or a concern, it's a statement.
<infinity> ogra_: God no.
<ogra_> but it is something th ebootloader should supply to the kernel, no ?
<apw> ogra_, the kernel is something the boot loader supplies to the machine and we don't include that in the bootloader
<infinity> ogra_: That's like saying u-boot should ship initrds.
<apw> heh thats a better way of putitng it
<ikepanhc> ogra_: dtb may different based on hardware, its hardware description
<apw> if the dtb comes from the kernel sources, then the kernel is not a dumb place to supply it
<Daviey> sorry, went AFK
<Daviey> Real hardware no longer requires it, i believe it's provided by the kernel dynamically 
<Daviey> Qemu, splits kernel from filesystem.. meaning it needs to be provided separately 
<apw> Daviey, to the kernel dynamically by the bootloader indeed
<apw> Daviey, we are now arguming about location for it
<Daviey> apw: Right, but i mean.. real hardware doesn't need this mod
<infinity> Daviey: Yes, we know.
<apw> Daviey, so by your own argument you should supply the dtb with qemu as its part of the hardware, and qemu is your hardware
<ogra_> who cares about real HW anyway ... its not what the intersted admin will have there first if he determines if highbank is for him
<infinity> Still, we'll need to ship DTBs for a ton of other devices Real Soon Now, so this is as much about setting a sane policy for how to ship those as it is about highbank on qemu.
<ogra_> ++
<Daviey> apw: Is that what you want?  Really?
<ogra_> i think omap and tegra switch to it in their next kernel iteration too
<apw> Daviey, no i want a sane discussion on where it should go, and you seemed to be arguing we shouldn't ship it with the kernel; having just sent me a patch to do just that
<Daviey> not my patch, but yes.
<Daviey> So what is to discuss ?
<ogra_> and in the longterm there wont be SoC specific kernels at all anymore you will just install the -arm flavour
<ogra_> how does ppc deal with it btw ?
<ogra_> iirc it uses DT much longer already
<apw> ogra_, all PPC machines have firmware which holds the dtb
<infinity> ogra_: PPC device trees are all in firmware.
<ogra_> and qemu ?
<infinity> (Though patchable at the kernel level)
<ogra_> ships a fake firmware ?
<infinity> openbios-ppc has a device tree in it.
<ogra_> ah
<apw> so the question is really, is this a one off, and highbank qemu is an aberation, or will other cheap arms need a DTB somewhere
<apw> i guess one other option would be to add them to the firmware package
<ogra_> all arms will 
<ogra_> at some point 
<ogra_> at least all that linaro ever touched
<apw> ogra_, all arms will have a DT, but will it come with the board, be on the board, or will it be something we need to know about
<ogra_> DT planning for arm in ubuntu is even older than linaro
<apw> ogra_, on ppc you don't need to know about them as they are never something you handle
<infinity> apw: Having them in linux-firmware wouldn't hurt my feelings.
<ogra_> apw, by design it cant come with the board on omap (no flash)
<infinity> apw: As for where it lives, that depends on if the board HAS firmware. ;)
<apw> infinity, well it all depends if they are kernel specific at all, ie version specific
<infinity> apw: They can't be kernel specific, or the burned-in ones would fail to work with kernel upgrades.
<infinity> apw: Which would be a pretty nasty design flaw. :P
<apw> though i suppose having an /lib/firmware/dtb/arm-highbank.dtb-version is no worse
<Daviey> well, they are kernel flavour specific ... whilst each SoC requires a different kernel flavour, until thye converge 
<apw> infinity, that would seem a reasonable statement, it implies the DT semantics are very stable
<infinity> Daviey: They'll never converge, that's the point of a device tree.
<apw> Daviey, that makes them system specific
<Daviey> this discussion seems circular 
<ogra_> the kernel will converge 
<Daviey> infinity: i mean kernel will converge 
<ogra_> the HW wont :)
<apw> though this implies that DT might grow over time but still be 'per system'
<infinity> Daviey: Yes, but you seemed to imply the device trees would as well, which clearly they won't. :P
<infinity> Daviey: The device trees are the reason the kernel will be able to converge.
<Daviey> infinity: sorry, i wasn't implying that.. I was stating that kernel flavour is a reasonable separator for system, UNTIL the kernel converges the systems. 
<apw> if anything they will grow new nodes as more things become parameterised, so they will be enlarging so changing over time, but one assumes backwards compatible
<apw> Daviey, right but that means right now we should not use flavours, as they are wrong 'soon'
<Daviey> apw: agreed
<Daviey> but soon could be years away.
<infinity> apw: linux-firmware seems like a good fit for them.
 * ogra_ still thinks it being a firmware it should live in the HW initialization (i.e. SPL or bootloader)
<Daviey> And it's easy enough to change the path.. we can spend all year predicting what will happen.
<infinity> apw: Maybe we should look into making linux-firmware not be arch:all, so we can trim fat on some arches. :P
<ogra_> but seems i'm alone with that opinion :)
<ogra_> rsalveti, ^^^
<ogra_> what does linaro plan here ?
<infinity> ogra_: Burning it into u-boot means a different u-boot build for every platform, which is also something DT may well get rid of some day.
<apw> Daviey, well as they are h/w specific they really feel more like firmware, so linux-firmware might make more sense
<ogra_> yes, u-boot will use the DT tables
<infinity> ogra_: The whole point is that you take a kernel, slap on a device tree, feed it to u-boot, and it all works.
<infinity> Three distinct parts.
<ogra_> thats why i think they should be shipped in there
<Daviey> apw: linux-firmware seems good nuff to me :)
<ogra_> and we will *always* need board specific SLP
<ogra_> *SPL
<apw> ogra_, what if they have redboot instead
<apw> ogra_, we don't want to put them all in there as well
<Daviey> they can go to hell.
<infinity> ogra_: Not always.  Not on all platforms.
<ogra_> no idea, i dont know redboot will ever support DT 
<ogra_> (i dont think its being developed since 5 years)
<apw> they feel like a bootloader independant thing
<ogra_> (or even 10)
<apw> they feel like a kernel independant thing
<ogra_> u-boot will fully depend on DT in the future
<apw> they feel like a hardware you have specific thing
<apw> which i think means to me they are firmware-esque
<ogra_> so you *have* to have the DT data available before you have a kernel or rootfs
<Daviey> why not just put it in -firmware for now, and we can switcheroo later if needed.
<Daviey> it's a reasonable starting block.
 * ogra_ would really like to hear from linaro, they have it planned through and will implement it
<ogra_> we can discuss it til death but after all we will have to use what linaro makes out of it
<infinity> Eh?
<infinity> ogra_: Linaro has nothing to do with it.
<ogra_> then their main objective changed recently
<infinity> ogra_: What package we ship it in, and where we put it on the filesystem, is, well, meaningless bikeshedding, and there's no reason any two distros have to match.
<ogra_> unified kernel and bootloader was one 
<infinity> ogra_: Yes, unified kernel is happening, that has nothing to do with this discussion.
<ogra_> infinity, what i mean is that the filesystem is the totally wrong place
<infinity> This is pure bikeshedding about where to put some files.
<apw> right we concur that linaro will drive all arm kernels to need and use a DT
<infinity> ogra_: It's going to be on the filesystem SOMEWHERE.
<ogra_> your SPL wont have any access to it 
<apw> so we can have one kernel, but how we get those together and where we put them is surley something 'we' are best quantified to grok
<infinity> ogra_: Cause you have to "cat vmlinux dtb > newblob" to feed it to u-boot.
<ogra_> oh, sure, but it wont be used from there during boot
<apw> SPL ?
<ogra_> first stage bootloader
<infinity> The SPL has no access to it at all in the current world order.
<ogra_> well, actually the S stands confusingly for "second" ... since the ROM is the first stage
<infinity> Also not changing this month.
<ogra_> surely not, indeed
<apw> please never :)
<infinity> So, again, not relevant.
<ogra_> relevant if they change it in a month though
<ogra_> thats why i think we need linaro input, they do the upstream work 
<infinity> If they change how everything on the platform works, we get to sort it out then.
<infinity> Right now, we need to sort out how to boot with the current kernel/dtb/u-boot trio.
<infinity> Which we know how to do.
<infinity> We're just arguing about WHERE TO PUT FILES.
<infinity> No knowledge of the future changes that.
<infinity> At all.
<apw> i would say even if it needs to be in /gableblotchet to make something like u-boot work
<ogra_> right, but they know what the plan for the near future 
<apw> its still a firmwary thing and sound come out of the firmware packages
<infinity> ogra_: But that doesn't matter!
<ogra_> and we could already work towards this instead of having to change it massively again
<infinity> ogra_: We need a plan for today.  The plan can't be "do nothing until it changes".
<ogra_> th eplan should be "ask the implementor first" imho
<infinity> ogra_: And whatever they plan to do, it has no relevance AT ALL to where we ship files.
<infinity> They're not implementing an OS, they're implementing a boot method.
<infinity> It's up to us to make it work with our OS.
<ogra_> they implement something where bootloader and kernel use the same file ... while the bootloader doesnt have any access to this file
<infinity> It's glued to the kernel.
<Daviey> ---â------â------â------â------âTRIM BIKESHED ---â------â------â------â---
<Daviey> Sorry, just a marker for my logs.
<ohsix> wouldn't ### have sufficed
<Daviey> ohsix: no.
<ohsix> has it occured in the discussion already?!
 * ppisati likes the scissors... :)
 * smb tries to see through the pillars of smoke...
 * cking now sees why earlyprintk=dbgp is flaky on his H/W
<rtg> cking, is it a generic issue, or just on your HW ?
<cking> rtg, i'm comparing a bunch of machines to see if it is machine specific
<cking> the fix is trivial, but i need to sanity check it first on a broad range of machines
<rtg> cking, ack
<rsalveti> infinity: ogra_: apw: currently we have the "reference" dtb file at the kernel tree itslef
<rsalveti> which is produced during the kernel build
<rsalveti> in our case we're installing it together with the linux package and at /boot/, so flash-kernel can copy it over while installing uImage and uInitrd
<ogra_> rsalveti, right, but what will you do wrt SPL and u-boot ?
<rsalveti> that's complicated, as it's hardware dependent
<rsalveti> as we don't yet have a "final" dtb that would ideally be provided by the hardware, we're shipping the latest one provided by the kernel build
<rsalveti> which would be loaded by u-boot 
<ogra_> k
<rsalveti> so having it at linux-firmware is ok, but if you're planning on updating it over the time, that can be dependent to the kernel used by the system
<rsalveti> until there's a single dtb file that can be used as reference
<rsalveti> the same that would be provided by the hardware itself 
<rsalveti> the problem is that we could even have hardwares that doesn't support a valid u-boot and needs dtb to work :-)
<rsalveti> which would need the distro to merge both dtb and the kernel into one single file
<rsalveti> but I don't think we need to cover that specific use case at ubuntu now
<ogra_> k
<rsalveti> so unfortunately this logic would still be part of flash-kernel
<ogra_> thats not the prob :)
<apw> rsalveti, i assume the dtb would be backward compatible conceptually is not kernel specific
<rsalveti> it should, and the drivers should only use the dtb if it's actually provided by the boot
<rsalveti> as the dtb files can also be produced by the kernel, as a reference one, I don't see why we shouldn't just provide them as part of the kernel package itself
<rsalveti> even if we copy them over to linux-firmware, it'd still be just a reference of the latest one integrated from the latest kernel tree
<infinity> rsalveti: Sure, that was understood.
<infinity> rsalveti: Though the kernel tree one certainly doesn't change that often.
<ogra_> having them in a non kernel package will make quemu stuff more tricky though
<rsalveti> currently people are changing them quite frequently 
<infinity> rsalveti: And, of course, shipping them from the kernel build is "wrong" when the linux-image can support more than one hardware platform.
<ogra_> as users will need to get two packages 
<rsalveti> because the port is on going
<rsalveti> sure, but would still be just a reference 
 * infinity nods.
<ogra_> not a biggie indeed, but documentation issue and likely causeing support requests
<rsalveti> the problem would be once we get to the situation where the dtb is needed just to boot the device
<infinity> Anyhow, shipping it from linux-image in /boot was our first gut reaction anyway.
<infinity> linux-firmware just seemed like a more elegant ongoing solution.
<rsalveti> so we'd need some sort of dtb available at the system for flash-kernel to use
<ogra_> it surely is, but might be unexpected for users
<rsalveti> it'd say it's unexpected because you can produce them from the kernel build itself :-)
<infinity> Though, the part where you can technically have linux-image without firmware makes it make more sense to put it in linux-image.
<Daviey> I really couldn't give a monkeys where it is btw :)
<rsalveti> so if it's produced from the kernel build, why it sholdn't be part of the kernel package? :-)
 * infinity waffles.
<Daviey> infinity: well, you can technically use linux-image without dtb :)
<infinity> rsalveti: Yeah, perhaps it should just be in linux-image, and as we get platform convergence, linux-image can just ship multiple DTs.
<infinity> Daviey: We're not talking about highbank.
<infinity> Daviey: We're talking about the whole concept.
<Daviey> Yeah, i gave up all my monkeys 3 hours ago on the concept.
<infinity> Daviey: Some kernels won't boot without DTs on some hardware, in the future.  That's a consideration we need to think about.
<infinity> apw: Given that, it probably makes more sense to ship it in linux-image, and when we end up with platform convergence, we'll just ship multiple DTs in linux-image-arm-generic.
<infinity> Though, filesystem-wise, boot then feels ugly, cause you could have dozens of them.
<infinity> So, linux-image, the package, but /lib/firmware, the filesystem namespace?
<apw> infinity, well i presume i could put them in /lib/firmware/device-tree still ?
<infinity> apw: Absolutely.
<infinity> apw: And that feels sane to me.
<infinity> apw: Just ship them from linux-image-$(abi), though.
<Daviey> Can we start bikeshedding over path now?
<apw> infinity, ok that works for me i guess...
 * apw /kickbans Daviey
<infinity> apw: I'd have no issues with /boot either, except for this theoretical future where /boot would end up littered with 50 dtbs for all the platforms the generic kernel supports.
<infinity> (And I can't wait for that to be a reality)
<infinity> apw: Anyhow, if we fuck it up, it's not like it's hard to move things around later. :P
<Daviey> Okay, package name.. â ... path... â  .. now we need to discuss filename.
<infinity> No we don't.
 * apw uses the filename the kernel produces for the hardware
 * Daviey blinks.
<apw> as someone else has bikeshedded about the filename upstream and made sure it is unique
<Daviey> Hmm, i ws thinking we could make this discussion go on all day?
 * smb thinks Daviey needs some real work assigned...
<infinity> bjf: Say, does the bot hande "prepare package" bug tasks based on scanning the PPA, or is that a manual thing?
<bjf> herton: ^ i can never remember all the things the bot does automagically
<infinity> bjf: Mostly curious if Ike should be updating https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1030308 manually, or if the bot will get to it.
<ubot2> Ubuntu bug 1030308 in linux-armadaxp "linux-armadaxp: 3.2.0-1606.9 -proposed tracker" [Medium,In progress]
<infinity> bjf: I also assume, though, that if impatient people jump the gun on automated tasks, the bot won't have a hissy fit?
<bjf> infinity: yes, the bot is happy to let humans play along
<herton> infinity, bjf: yes, the bot looks in the build status in the ppa
<infinity> Check.  Maybe I'll just jump the gun so I can get to my copying and overriding. :)
<infinity> herton: Okay, good to know.
<infinity> ikepanhc: ^-- The bot would have updated it "eventually", but I'm going to short the process and JFDI.
 * ikepanhc reads
<ikepanhc> infinity: you are going to copy it? thanks
<herton> infinity, but in the case of armadaxp, the prepare-package must be fix-released, and upload-to-ppa in progress.
<infinity> ikepanhc: Like I said, I have to fix it after it's copied anyway, so I may as well.
<infinity> herton: Ahh, so Ike messed up his tasks so the bot won't look. :P
<infinity> ikepanhc: ^
<herton> for these derivative packages it was intended that we would do the upload, so there is this extra upload-to-ppa task
<ikepanhc> probably the bot does not like me
<herton> may be for armadaxp we should remove it, since ike is doing the uploads
<ikepanhc> herton: nono, we just kidding here
<bjf> ikepanhc: after uploading the package you need to set the "prepare-package" to "fix-released"
<ikepanhc> herton: oh, you mean the upload-to-ppa?
<ikepanhc> herton: how about set to invalid?
<ikepanhc> bjf: ACK
<bjf> ikepanhc: you should be setting the "upload-to-ppa" as well
<infinity> Anyhow.  Tasks all fixed up, and packages copied.  I'll fix overrides in half an hour.
<herton> the idea was, for example, the derivative maintainer sets the prepare-package to fix released. the bot would set the upload-to-ppa task to confirmed, to notify us. then we would upload the package and set the upload-to-ppa to in progress
<herton> but things ended up being different for armadaxp
<ikepanhc> bjf: eh, its done, anyone did it? or bot?
<infinity> ikepanhc: I did.
<infinity> ikepanhc: It was "New" when I got there.
<ikepanhc> infinity: thanks
<infinity> herton: Do the wiki step-by-step docs point out which tasks the bot manipulates, and under what conditions?
<herton> ikepanhc, so for your case for now, just set prepare-package to fix released and upload-to-ppa to in progress
<infinity> (I haven't read that doc for a while...)
<herton> ikepanhc, when doing the upload
<ikepanhc> herton: ACK
<ikepanhc> herton: keep the status correct.. understood
<herton> infinity, yes, there is some description on what the bot does, may be not ideal, https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
<infinity> herton: Oh, see, I'd never before read that with s/Worflow Mgr./The Bot/
<infinity> herton: Makes a bit more sense if I do. ;)
<infinity> Workflow, even.
<herton> infinity, bjf, I updated that wiki page (kernel-sru-workflow). I noted there was some missing pieces/outdated info.
 * ogasawara back in 20
<bjf> herton, thanks
 * herton -> lunch
<rtg> ogasawara, cracked the ubuntu-r repo. builds for amd64, and am working on the rest of the arches. updated dropped.txt, etc. we should -cr1 by weeks end I think.
<rtg> -rc1 even
<ogasawara> rtg: sweet
<ogasawara> rtg, apw: I was going to plan on a quantal upload today too if you guys had anything you haven't pushed yet that you want in
<apw> ogasawara, have a highbank change i'd like to see in, its a passive file
<rtg> ogasawara, I'll be pushing firmware patches for the kernel throughout the week, but I see no reason not to upload soon.
<ogasawara> apw: ack
<apw> ogasawara, ok pushed
<ogasawara> apw: cool, thanks
<apw> ogasawara, i have also shoved an abi bump underneath
<cking> ubuntu-r already? is it that time of the year again?!
<apw> cking, always
<cking> apw, seems shorter each time, argh, time must be speeding up
<apw> cking, you are getting slower :)
<cking> noooooo
<ogasawara> apw: available to mumble?
 * cking --> EOD (early for once)
 * ppisati -> gym
 * henrix -> EOD
<herton> smb, when running maint-startnewrelease I'm still getting some errors related to SIGPIPE (stdout: broken pipe)
<herton> from this on getabis script:
<herton>                                 # Prevent exposing some errors when called by python scripts. SIGPIPE seems to get
<herton>                                 # exposed when using the `find ...` form of the command.
<herton>                                 ko=$(find lib/modules/$verabi-$sub/kernel \
<herton>                                         -name '*.ko' | head -1)
<herton> smb, this fix I'm testing on kteam-tools seems to do the trick, avoiding the problem: http://pastebin.ubuntu.com/1120029/
<smb> herton, Hm, would be a better explanation than the change of shell script. Though it seemed to work for me
<herton> smb, seems because head finishes earlier, then find tries to write again and then there is an error, since how python setup sigpipe
<smb> herton, Heh, guess it depends then whether you use a netbook or a real computer... :)
<herton> yep, sometimes if head finishes "later", there wouldn't be an error. that's why probably when reordering that line introduced a time change that made it work sometimes
<herton> *finishes later than the last find write
<herton> smb, I found this which has a good example, gzip being affected as well: http://blog.nelhage.com/2010/02/a-very-subtle-bug/
<apw> rtg, did you tag the sync point to R in the quantal repo ?
<rtg> apw, not yet
<rtg> it should be agaist -6.6 
<rtg> against*
<rtg> apw, besides, I don't think a sync point tag does much good as long as we're rebasing 
<rtg> rebasing quantal, I mean
<apw> rtg, well at least you can see the top commit, the title should remain the same, but yes till the rebase stops its not a simple git log 
<rtg> though I suppose a tag, even though not lineraly accurate, would at least tell you to begin in the stack of UBUNTU patches
<rtg> linearly*
<rtg> where to begin*
<apw> rtg,  right
<rtg> apw, pushed Ubuntu-R-sync
 * ppisati just had a huge kebab
<ppisati> *burp*
<bjf> jjohansen: bug 1029937 (just so it's on your radar)
<ubot2> Launchpad bug 1029937 in qa-regression-testing "test-kernel-security failures on Precise with 3.5.0-6 kernel" [Undecided,New] https://launchpad.net/bugs/1029937
<jjohansen> bjf: ack
<jjohansen> apw: btw your kernel that rolled out fixed my S/R issue even though the testing kernel didn't :/
<apw> jjohansen, wibble, good in some sense, but
<jjohansen> apw: yeah, I don't understand and haven't looked at it more yet, just noticed it on the weekend, when I slept my machine by accident
<apw> well at least it is in the positive
<autojack> hi. I was following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel trying to customize a Lucid kernel for my i386 ec2 instance. I've built kernels from scratch before, though not since the LILO days :)  when I run 'fakeroot debian/rules binary-headers binary-generic' it eventually errors, saying there is no target named binary-generic. what am I doing wrong?
<autojack> Google didn't lead me to a solution.
<cheako> bug 1007089
<ubot2> Launchpad bug 1007089 in linux "overlayfs alters /proc/self/exe link(s), making result a dead link." [Medium,Confirmed] https://launchpad.net/bugs/1007089
<cheako> This bug is causing several other packages to have issues.
<cheako> It's importance should be set at High (2.7 points) or Critical (1 point), I've mentioned this in #ubuntu-bugs.
<cheako> Err, I can't count.  That's 3.3 points for High.
 * rtg -> EOD
#ubuntu-kernel 2012-07-31
<ppisati> moin
<smb> morning
<ppisati> smb: ciao Stefan! :)
<smb> ppisati, -ETOOHAPPYINMORNING :-P
<ppisati> smb: i love when i wake up at 6:$something so @ 9 i'm already fully awake :)
 * smb grumbles something about detestably cheerful people in the morning...
<ppisati> :)
<apw> ppisati, as you are in such a good mood :)  could you render an oppinion on the 1GHz patch dropped onto: bug #771537
<ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress] https://launchpad.net/bugs/771537
<cooloney> cking: i've got an panda ES board setup with ceph, do you know how to make it talk with the ceph server on my VM
<cking> cooloney, not sure off the top of my head
<cooloney> cking: ha, maybe you guys are focusing on Olympic game right now, heh
<cking> cooloney, somehow you need to bridge it
<cooloney> cking: yeah, i'm board and my host desktop machine are in same subnet
<smb> One of the places I described the transparent bridge setup https://wiki.ubuntu.com/Kernel/Reference/Orchestra
<cking> cooloney, you could make life easier for yourself and install the ceph server on real metal
<smb> You would need to set the VM to use a "shared device" and then tell it the name of the bridge you defined
<cooloney> cking: indeed, since i've got your ceph server image, i just wanna reuse it
<cking> cooloney, lemme send you my ceph notes
<cooloney> cking: great, thanks a lot
<cking> cooloney, its fairly easy to get it running on bare metal, and saves messing around with the bridge, email coming your way soon
<ppisati> apw: i'll give the patch a look after lunch
 * ppisati needs an irssi notificator...
<apw> ppisati, doesn't irrsi have that top window with all your highlights in it ?
<cooloney> cking: yeah, thx, i will try to setup one on my host. 
<cooloney> ppisati: you need this http://pastebin.ubuntu.com/1121145/
<cooloney> cking: i got your notes. 
<ppisati> cooloney: ah Perl! i love it! :) i'll give it a try later
<ppisati> apw: dunno what you mean but i'm using it under screen so until i switch to the correct shell i don't see anything (and i usually switch when i'm compiling&c)
<apw> ppisati, ahh ... fail :)
 * ppisati -> lunch
<cking> apw, I use:
<cking> override_dh_auto_configure:
<cking>         autoreconf -ivf
<cking>         dh_auto_configure
<cking> apw, http://paste.ubuntu.com/1121196/
<cooloney> cking: i got failed when i try to run 'mkcephfs'
<cooloney> cking: http://pastebin.ubuntu.com/1121205/
<apw> mk-build
<cking> more like mk-fail
<apw> jodh, cking, (for your logs) sudo mk-build-deps --install  update-notifier
<apw> is the incantation
 * cking slaps it into his book of knowledge
<jodh> apw: thanks!
<cking> cooloney, so once you've set up the ssh, you may need to wipe out the contents of the /var/lib/ceph/osd/ceph-*/  and /var/lib/ceph/mon/ceph-*/ and /var/lib/ceph/mds/ceph-*/ directories before re-running the mkcephfs command
<cooloney> cking: ok, np, thx
<apw> cking, ok when testing properly your auto thing seems to work
<ppisati> apw: portions of that patch were upstreamed in some pm trees, another chunk was not
<cking> apw, that's a relief
<ppisati> apw: i sent an email to the author to get more info
 * cking --> lunch, back in 25
<apw> ppisati, ok thanks
<ppisati> cooloney: i'll try you irssi perl thing now :)
 * ppisati quit for a second...
 * henrix --> lunch
<ppisati> cooloney: it seems there's a new version of that script
<ppisati> cooloney: http://code.google.com/p/irssi-libnotify/source/browse/notify.pl
<cooloney> ppisati: thanks, man. i will upgrade. heh
<ppisati> cooloney: btw, i'm on a dual screen setup, i need to tell it to use the first screen only
<ppisati> uhm
<ppisati> why it doesn't autoload?!?! grrr...
<cooloney> ppisati: put it in ~/.irssi/scripts/autorun/
<ppisati> cooloney: doesn't work
<ppisati> cooloney: already tried that
<ppisati> :(
<cooloney> ppisati: no idea,
<ppisati>  /script list
<ppisati> says
<ppisati> 14:15 Loaded scripts:
<ppisati> 14:15 scriptassist    /home/flag/.irssi/scripts/scriptassist.pl
<ppisati> and scriptassist is another script i installed (and manually loaded)
<ppisati> truth be told
<ppisati> my .irssi dir is a symlink
<ppisati> since i mantain all my config giles
<ppisati> files
<ppisati> in git
<ppisati> in another directory
<apw>  -/b 5
<ppisati> .irssi, .gitconfig, .bashrc, etcet
<rtg> ogasawara, bouncing gomeisa for kernel update
<ogasawara> rtg: ack, go ahead
<rtg> ogasawara, gotta fix my VPN connection before I do tangerine. it never reboots without a power cycle.
<henrix> smb: i was trying to reproduce bug #999755 to verify the fix
<ubot2> Launchpad bug 999755 in linux "Kernel crash in rb_next doing ohai loops" [Undecided,In progress] https://launchpad.net/bugs/999755
<henrix> smb: but so far... no luck
<henrix> smb: i am using vbox for that. do you remember how long you need to run the test case in order to trigger the issue?
<smb> henrix, I am doing the same. For precise it does work
<smb> but oneiric no luck
<henrix> smb: ah, i was trying oneiric actually :-/
<smb> henrix, It is extremely timing sensitive. 2 CPUs seemed best
<smb> But also it seems something is slightly different in oneiric, making it not happen with the current setup
<henrix> smb: later today i'll probably try oneiric on bare metal. i'll install it on a 2-cores laptop
<henrix> smb: were you able to reproduce it on oneiric before? or was it just on precise?
<smb> I was only reproducing it on precise. Just the scheduler code is the same back in O (or farther)
<henrix> ack. how long does it take (roughly) to hit the bug?
<henrix> minutes? hours? days?
<smb> Unfortunately I have not found a reall good way to cause the scheduler to migrate a task at the same time as it moves task groups
<smb> Sometimes 1hr, sometimes 4hrs... sometimes it happened just before I really got fed up...
<henrix> heh
<henrix> ok, thanks
<smb> henrix, Though for Oneiric I left the VM running the whole night without luck
<rtg> henrix, ppisati, Daviey: rebooting tangerine for kernel and openssl update
<henrix> rtg: ack
<henrix> smb: yeah, tricky bug.
<smb> henrix, Yeah, iirc people in production environments saw it happen every 1-2 days... :/
<rtg> ogasawara, magic -> "[timg-tpi] Review set of Ubuntu patches: DONE"
<ogasawara> rtg: heh, I was cleaning up WI's and saw it so just did it since it was only a few patches to look at
<rtg> ogasawara, I should take another pass just to be sure.
<ogasawara> rtg: I threw my notes under your section at https://wiki.ubuntu.com/KernelTeam/Specs/QKernelDeltaReview
 * ogasawara back in 20
 * cking grabs a 10 min break
<jsalisbury> smb, If you have a chance, can you take a look at bug 1031090
<ubot2> Launchpad bug 1031090 in linux "kvm_intel not loadable in a quantal guest" [High,Confirmed] https://launchpad.net/bugs/1031090
<smb> jsalisbury, I just got a chance as Daviey asked about it on the server-team meeting
<jsalisbury> smb, cool, thanks
<apw> smb, i'd check we haven't dropped anything config wise in our resync
<smb> apw, Yeah, first I want to locally confirm it. Not trusting anybody else more than I can throw them, and that is not far
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<autojack> hi. I was following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel trying to customize a Lucid kernel for my i386 ec2 instance. I've built kernels from scratch before, though not since the LILO days :)  when I run 'fakeroot debian/rules binary-headers binary-generic' it eventually errors, saying there is no target named binary-generic. what am I doing wrong?
<jsalisbury> sconklin, are you reporting the CVE's in today's meeting or is it bjf ?
<apw> autojack, if its an ec2 kernel from the ec2 branch then its binary-ec2
<sconklin> jsalisbury: it's me, and will be until further notice
<jsalisbury> sconklin, got it, thanks
<sconklin> bradf was covering while I was on vacation
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 8th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> herton, do we make bugs for lowlatency rebases ?
<apw> (for P ?)
<herton> apw, no
<herton> apw, if someone is working, or starting to work on it, we could
<apw> herton, noone is working on it cyrrently indeed
<dileks> august 8th is a wednesday
<jsalisbury> dileks, thanks
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 7th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * henrix --> EOD
<autojack> apw: thanks, I'll give that a try.
 * cking -> EOD
 * smb -> EOD
<josepht> bug #1029547 has been bisected
<ubot2> Launchpad bug 1029547 in linux "8086:0091 WARNING: at /home/apw/COD/linux/drivers/net/wireless/iwlwifi/iwl-trans.h:565 iwlagn_mac_flush+0x1a3/0x1b0 [iwlwifi]()" [Low,Triaged] https://launchpad.net/bugs/1029547
<cheako> I just closed #381896 after testing and I'll start working on two more.
<cheako> Down to 15.  How come there are so many CVE bugs marked as new?
<apw> jsalisbury, there is a candidate for you above ^^
<apw> bug #381896
<ubot2> Launchpad bug 381896 in linux "bad router advertisement lead to disabilitation of ipv6 privacy extension" [Medium,Fix released] https://launchpad.net/bugs/381896
<jsalisbury> apw, looks like that bug was just closed
<apw> jsalisbury, the one above not below :)
<apw> jsalisbury, the one with my nick in the title
<jsalisbury> apw, ah, got it :-)
<jsalisbury> josepht, Thanks for bisecting.  It looks like that commit was introduced in v3.5-rc1.  I'll build a quantal test kernel with that commit reverted and post a link in the bug.
<apw> jsalisbury, thanks
 * rtg -> EOD
<jMCg> Do you people parse your logfiles for how long you've worked?
<Daviey> I'm currently hammering tangerine.. if it hurts anyone, please feel free to kill me
<Daviey> err, kill my job
<stgraber> Daviey: there are some many ways to misinterpret that ;)
<Daviey> stgraber: Friday night is the real life tangerine show.
#ubuntu-kernel 2012-08-01
<h00k> If I am trying to load a module on boot by adding it to /etc/modules (netconsole, troubleshooting a panic on 12.04), and it fails to load, is that an issue with that module or with the kernel?
<h00k> However, if I load it manually (sudo modprobe netconsole), it ignores the /etc/modprobe.d/netconsole options I have, so I'd have to load all options with the 'sudo modprobe netconsole...etc' line.
<h00k> I don't know enough to know whether it's with the kernel itself, or with the module :(
<infinity> h00k: Try /etc/modprobe.d/netconsole.conf
<infinity> h00k: If I recall, modprobe ignores certain filenames.
<infinity> h00k: (It might tell you that with -v)
<ppisati> back in 20mins
<smb> Daviey, If your hammering had any outcome I should know about, let it be known to me... ;)
 * ppisati needs a boatload of coffee...
 * smb looks for a suitable vessel
<apw> yawn
<smb> Seems that needs to be a cruise around Europe...
<apw> kernel coffee yaught sounds like a plan to me
<Daviey> smb: wilco
<cooloney> morning guys
<cooloney> cking: i've start ceph on my local host now. thanks for your help
<cking> cooloney, yay \o/
<cooloney> cking: one thing is weird. i need to run 'sudo service ceph -a start' to start ceph
<cooloney> w/o '-a' it won't start ceph
<cking> cooloney, hrm, thats unexpected
<cooloney> i think -a == --allhost
<cooloney> and $ ceph health
<cking> I've not had to do that, it just worked for me on multi-hosted and single hosted configs
<cooloney> HEALTH_WARN 2 near full osd(s)
<cooloney> and i got 2 WARNs, heh
<cking> well, I suspect the default location for the OSD data is filling up - the default locations are a not sane IMHO
<cooloney> i got an 1G jounal file in osd directory
<cking> cooloney, that sounds sane to me
<cooloney> cking: wow, so clever, my rootfs is about out-of-space
<cking> cooloney, :-/
<henrix> smb: from your last comment in bug #999755 i see you were not able to reproduce it in oneiric
<ubot2> Launchpad bug 999755 in linux "Kernel crash in rb_next doing ohai loops" [Undecided,In progress] https://launchpad.net/bugs/999755
<henrix> smb: i spend some time trying to trigger it (both in VM and bare metal), without any luck
<smb> henrix, correct, still running without a crash
<henrix> smb: ok
<smb> henrix, What I'd probably do is to upgrade the kernel and make sure it runs as long with the new one
<henrix> smb: ack
<henrix> but what if we fail to reproduce it? would you be comfortable to tag it as verified (as the patch has been accepted upstreams already)? or would you rather revert it on oneiric?
<smb> henrix, As I tried to say in the bug comment. For Oneiric go on and accept it verified. For natty, stop worrying ...
<henrix> smb: yep, that's what i understood from your comment. just wanted to make sure :)
<henrix> smb: thanks Stefan
<smb> :)
<smb> apw, There would be the question for Quantal. There will not be a crash but (probably a very theoretical) race. I am not sure about it ever make it into a stable later than 3.2 for that reason. Should we still bother to get it in there or just move on and pretend we did not see anything (which is actually true)
<apw> smb, thats a tricky one without knowing the nature of the race.  i will trust you :)
<smb> apw, Actually its even tricky when knowing it. But I believe the worst case is that a task is moved over and placed into the wrong run queue for some time. I guess we can live with that every now and then (which may be as often as any leap seconds). 
<apw> yeah as long as smoke isn't coming out when it happens
 * ppisati -> lunch
 * apw goes splish
<rtg> ogra_, apw, can you remember who was doing the ac100 kernel ?
<cooloney> rtg: i think jani is working on ac100 kernel.
<rtg> cooloney, ack, thanks
<ppisati> rtg: he is just packaging it
<ppisati> rtg: the guy porting patches&c is marvin24
<ppisati> rtg: a guy from community
<rtg> ppisati, well, wrt to the mailing list query, redirecting to Jani is sufficient.
<josepht> jsalisbury: the test kernel for bug #1029547 works for me, commented in the bug.
<ubot2> Launchpad bug 1029547 in linux "8086:0091 WARNING: at /home/apw/COD/linux/drivers/net/wireless/iwlwifi/iwl-trans.h:565 iwlagn_mac_flush+0x1a3/0x1b0 [iwlwifi]()" [Medium,In progress] https://launchpad.net/bugs/1029547
<jsalisbury> josepht, thanks for the update.  I'll take a look at that commit and see what the next step should be
<ppisati> cool, i received an ssd for my desktop: is there a way to install P on it without requiring to boot an entire box with it attached?
<ppisati> e.g. can i attach it to my running desktop, launch an "installer", select the ssd and let it install P on it?
<smb> ppisati, Use kvm? 
<ppisati> smb: uhm... qemu is an option indeed
<ppisati> smb: but axctually the install is an application that runs on top of a live system
<ppisati> smb: so i guess it's doable even on my desktop without any system emulation
<smb> ppisati, Maybe. Though I thought you were asking about a simple solution. :)
<ppisati> doh!
<ppisati> ubiquity requires all the qt libs!
<ppisati> and even some kde packages...
<ppisati> kille me, now...
<ppisati> ok, qemu...
<apw> ppisati, can't you debootstrap the disk ?
<ppisati> apw: i wonder if there're some particular steps (like /etc files&c) that are handled only via the installer
<ppisati> but yes, deboostrap is another option
<apw> i'd just attach it to a test box and install on it as a usb disk
<apw> then switch it in when its done
<bjf> apw, bug 1021174. can you add the appropriate verification?
<ubot2> Launchpad bug 1021174 in linux "include all binary packages in module checks" [Medium,Fix committed] https://launchpad.net/bugs/1021174
<rtg> ppisati, in the Linaro nano image, how do you get the dhcp client to run on boot ?
<rtg> hack it into /etc/rc.local ?
<ppisati> rtg: never used Linaro images, but i guess rc.local is an option
<apw> bjf ack
<ppisati> rtg: playing with the guru plug?
<smb> Sounds a bit dodgy...
<ogra_> rtg, pointing /etc/network/interfaces to dhcp doesnt work ?
<rtg> ppisati, no, still the sabrelite stuff
<ogra_> oh, nano ... thats likely special since tons of stuff get hacked out of the system to make it small
<rtg> ogra_, ah, tahts likely it. doh!
<ogra_> so it might or might not work the usual way
<ogra_> but /e/n/i would be my first thing to try
<rtg> ogra_, it should. the nano image comes with the ISC client installed
<ogra_> yeah, then it should
<apw> bjf, done
<bjf> apw, thanks
 * ogasawara back in 20
 * herton -> lunch
 * smb -> gone
<Daviey> dammit.
 * cking notes Daviey is not having a fun day
<cking> rtg, i meant "Natty" instead of "Oneiric" on that eCryptfs patch, can you apply it to Natty?
<rtg> cking, yep
<cking> bit stupid of me, especially 'cos I tested it on Natty to make sure it worked OK
<infinity> cking: Oh hey, I suck at bug mail.  Feel free to ping me on IRC if you do things like spin test kernels for me. ;)
<infinity> cking: (re: 871891)
<cking> infinity, yep, if you could try that kernel out, I'd appreciate it, I'm not sure if one of those testers has a sane set-up
<ogra_> why do you assume infinity has one ?
<cking> ogra_, 'cos it appears he filed the bug
<cking> unless I'm totally mad
<cking> which is possible
<ppisati> "[PATCH 00/24] Introduce Xen support on ARM"
<ppisati> "this patch series implements Xen support for ARMv7 with virtualization
<ppisati> extensions."
<ppisati> still A15 only i guess
<infinity> cking: I did indeed file the original bug, yes.  Though, I think it's suffered bug bloat since, as someone else said that nohpet didn't work for them (and it does for me).
<infinity> cking: Which, I assume, means two different S10-3s, internally, and two different bugs.
<brendand> jsalisbury, how would i load samsung-firmware?
<brendand> sorry, samsung-laptop
<cking> infinity, does the kernel I provided w/o the nohpet work?
<infinity> cking: I'll spin it up in a bit over here and let you know.
<cking> ok, no rush
<infinity> cking: Well, I'll be scientific and make sure that the current precise still sucks too.  I haven't run without the cmdline option since I filed the bug. :P
 * cking notes infinity has an Atari logo on his LP page. perhaps cking should put the commodore chickenhead on his
<infinity> cking: See, I used to own a lot more C= hardware than Atari, but I went with the less ugly logo. :P
<infinity> cking: (I used to run a lot of both, mind you, when I was deeply involved in 68k porting)
<cking> infinity, yep, I had a C64 and Atari 1040ST
<brendand> jsalisbury, modprobe -l samsung-laptop shows something underneath kernel/drivers/platform/x86
<jsalisbury> brendand, I believe it is samsung_laptop
 * jsalisbury checks
<brendand> jsalisbury, it's listed in /proc/modules. does that means it's loaded?
<dileks> yupp, samsung_laptop
<jsalisbury> brendand, you can run lsmod | grep samsung
<jsalisbury> brendand, If not loaded, you can run: sudo modprobe samsung_laptop
<brendand> jsalisbury, it's definitely loaded
<brendand> jsalisbury, always has been
<jsalisbury> brendand, did you have this bug in precise or earlier releases?
<brendand> jsalisbury, i can check
<jsalisbury> brendand, ok
<brendand> jsalisbury, let's do this in the bug. put a comment asking me to test precise
<jsalisbury> brendand, will do
<smoser> ok. its that time again.
<smoser> smoser's noob questions
<smoser> i'm just curious. if i kexec from one kernel to another, does memory get zero'd ?
<smoser> i know that in the kdump use case it clearly does not, but kdump explicitly has the second kernel only "knowing" about a small portion of the memory.
<infinity> cking: So... I can't tell you if your fix fixes anything, because current precise (-27-) seems to work fine without nohpet.
<cking> infinity, 'current' as in the one I gave you to test?
<infinity> cking: No, you gave me a -29-
<infinity> cking: I'm saying that I'm testing the -27- from updates, and it's fine.
<infinity> cking: (Like I said, I haven't booted without nohpet since oneiric, so this could have magically been fixed ages ago)
<cking> infinity, OK, well thanks for testing, this info makes it just a little more mysterious
<infinity> cking: Okay, switching from unity-2d to 3d, on resume with the old kernel, my root window didn't get painted, so I couldn't log in.
<infinity> cking: But that could have just been a random bug.
<infinity> cking: (Rebooting into your test kernel, I didn't have that issue, though)
<infinity> cking: Okay, just reproduced the root window painting bug with your kernel too, so that's unrelated, and probably just unity being crap.
<cking> infinity, surely not!
<infinity> cking: So, conclusion is that (for my hardware), your kernel changed nothing.
<cking> infinity, OK - thanks for testing
<infinity> The upshot is that my hardware seems to have been fixed somewhere between 3.0 and 3.2.whatever. :P
<cking> looks like another random S3 bug to me
 * ppisati -> gym
<infinity> cking: I'd just close the bug, if it wasn't for the metooing on it.
 * cking nods, well I will look at that other users bug and see what's busted and maybe then ask them to file a new bug
 * infinity nods.
<infinity> Another 10 resume cycles on the old kernel, and I'm satisfied this all works correctly now.
<infinity> So, I dunno what fixed it, or when, but thanks? :P
<cking> thanks to upstream
<infinity> It's harder to buy upstream beer.
<infinity> I guess that's a cost savings for me.
<cking> heh
<dileks> infinity: you know thorsten (mira)?
<infinity> dileks: Nein.
<dileks> as you were talking about m68k porting - mira did a happy revival for debian
<dileks> ...or still doing
<infinity> dileks: Oh, yeah, wouter and I were talking about that at Debconf.
<infinity> dileks: I've moved on by now, to a different set of slow hardware that actually has a future (ARM).
<dileks> hehe
 * dileks had a500 a2000 and 2x a3000
 * infinity had a 2000 and an unholy collection of 4000s.
<infinity> Well, and a 1200 that I used to use to write music, but it never ran Debian.
<dileks> 4000 was not stylish, come on :-) 4000t(ower) was
<infinity> They were Ts, I was too lazy to add the character. :P
<dileks> good choice
 * rtg -> lunch
 * cking saunters off
 * ogasawara lunch
<balloons> bjf, jsalisbury how's things going with the community kernel testing on your end?
<balloons> from my perspective it seems like you are having some good interactions and feedback from everyone
<bjf> balloons: is community kernel testing happening?
<balloons> sorry, I mean the 12.10 on 12.04 userspace testing
<balloons> I shouldn't confuse :-0
<bjf> balloons: i don't really pay any attention to it
<balloons> bjf, ahh, perhaps I'm mistaken then.. I thought it was mainly you and joe responding to the bugs raised
<bjf> balloons: you confuse me with a bot that runs as my lp user :-)
<balloons> bjf, ahaha
<balloons> yes yes of course!
<balloons> Well jsalisbury interactions might have some "bot" in them as well, but I know he's personally sent some messages
<balloons> any feedback you have would be great.. positive or negative. I want to make sure things are going well from your perspective
 * rtg -> EOD
<pbuckley> how is 12.10 doing?
<joshhunt_> I see that 3.2.0-29.46 is listed as proposed as of July 28. I was wondering if there is a release schedule for this?
<joshhunt_> i believe it has all of the leap second fixes which i'd like to work into my current release
<ogasawara> joshhunt_: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock
<ogasawara> joshhunt_: by that it should move to -updates next week
<ogasawara> joshhunt_: but I've been told they might try to have it available earlier so that it can land in the 12.04.1 point release
<bjf> joshhunt_: we are shooting for the .1 point release
<bjf> joshhunt_: those commits are part of the reason i want it as the point release kernel
<joshhunt_> ogasawara, bjf: thanks. i stepped away for a bit.
<cheako> How come there are so many CVE bugs marked as new?
<cheako> bug 1007089
<ubot2> Launchpad bug 1007089 in linux "overlayfs alters /proc/self/exe link(s), making result a dead link." [Medium,Confirmed] https://launchpad.net/bugs/1007089
<cheako> How can I re-open a bug that I closed? bug 381896
<ubot2> Launchpad bug 381896 in linux "bad router advertisement lead to disabilitation of ipv6 privacy extension" [Medium,Fix released] https://launchpad.net/bugs/381896
#ubuntu-kernel 2012-08-02
<h00k> infinity: I do currently have it at /etc/modprobe.d/netconsole.conf
<h00k> infinity: today it seems to be playing nicely. odd. modprobe -c | grep netconsole shows what I'd expect.
<ppisati> moin
 * smb yawns
 * ppisati while reinstalling P on a brand new ssd found a couple of bugs (one about the ATI driver card and another with ia32-lits and skype)...
<ppisati> and when i start skype, if i tick "start minimised in tray" nothing shows up... ARGHHH!!!!
 * ppisati realizes he's complaining&swearing like a well-known English... :)
<ppisati> now mumble...
<dileks> http://www.heise.de/imgs/18/8/9/8/5/7/4/nvidiaex-5000f4c3eb4e5d15.png
<dileks> recent nvidia exploit demonstrated
<ppisati> smb: can you hear me?
<smb> ppisati, No, maybe a good thing... ? :)
<ppisati> ok, i think i'm done... fingers crossed...
<ppisati> forgot empathy...
<ppisati> and weather indicator doesn't update
 * ppisati clicks nervously Refresh
<ppisati> ok so, if you are part of a group that has some rules in sudoers
<ppisati> no mnatter what you specify for your user, it'll be overwritten by your group rules
<ppisati> e.g.
<ppisati> flag ALL=(ALL)  NOPASSWD:   ALL
<ppisati> %sudo  ALL=(ALL:ALL) ALL
<ppisati> since i'm part of the sudo group, it'll keep asking me for my password
<ppisati> now /me goes complaining about Skype in #devel
 * ppisati notes NO ONE cares about skype... bah...
 * smb turns on the OPP field
<ppisati> tseliot: yesterday i reinstalled my P/amd64 desktop and found two oddities with the ATI/AMD driver
<ppisati> tseliot: first, jockey proposed me two differents drivers (one was marked as - post release update or something like that, the other had no particular notes)
<ppisati> tseliot: so first i tried the "post release updates", but it failed to compile/install
<ppisati> tseliot: while the "normal one" succeded
<ppisati> tseliot: second oddities - to properly handle a dual screen setup i had to manually tweak my X conf file
<ppisati> tseliot: and add a Display subsection
<ppisati> tseliot: with a virtual option equal to the sum of the two screens resolution
<tseliot> ppisati: there isn't much I can do without a log about the module which failed to build
<ppisati> tseliot: i think i've it
<ppisati> tseliot: or i can try to reinstall it
<tseliot> ppisati: the second oddity is really about their implementation of Randr in the driver which doesn't allow front buffer reallocation
<tseliot> ppisati: also, what kernel are you using?
<ppisati> 3.2.0-23-generic #36-Ubuntu
<ppisati> x86_64
<ppisati> brand new P/amd64 desktop installation
<ppisati> ok, it failed again
<tseliot> please collect the log
<ppisati> tseliot: http://people.canonical.com/~ppisati/jockey.log
<ppisati> tseliot: does it make any sense to you?
<tseliot> ppisati: so, the driver built successfully but somehow it couldn't be enabled. What's the output of update-alternatives --display x86_64-linux-gnu_gl_conf ?
<ppisati> tseliot: http://people.canonical.com/~ppisati/upd-alt.x86_64-linux-gnu_gl_conf
<tseliot> ppisati: it looks fine. It could be a bug in Jockey
<ppisati> tseliot: can i install it manually?
<tseliot> ppisati: it seems to be already installed correctly
<ppisati> tseliot: ah
<ppisati> tseliot: http://paste.ubuntu.com/1124965/
<ppisati> brb
<tseliot> ppisati: yes, it looks good. You might want to reboot now
<ppisati> tseliot: weird
 * ppisati -> reboot
<ppisati> tseliot: ok, did two reboots just to be sure
<tseliot> ppisati: and?
<ppisati> tseliot: and the second display (the right one) is garbled
<ppisati> tseliot: if i mirro the display, and then go back to this config, it fixes it
<tseliot> ppisati: are talking about indipendent heads?
<tseliot> *are we
<ppisati> tseliot: but after every reboot the screen is "full of crap"
<ppisati> tseliot: yep
<ppisati> tseliot: with the previius driver it was ok
<ppisati> tseliot: i mean, before the reboot
<apw> tseliot, i assume you are aware of the nvidia exploit ?
<tseliot> ppisati: what version works for you and what doesn't?
<tseliot> apw: yes but there are some many vulnerabilities you'd be surprised...
<ppisati> tseliot: the version that doesn't is the one that had problem installing via jockey
<ppisati> tseliot: let me get the rev
<apw> tseliot, actually i suspect i wouldn't be supprised, just supprised this is the first i have heard of
<ppisati> tseliot: 2:8.960-0ubuntu1
 * ppisati reboots again
<ppisati> tseliot: still crap... ahhhhhh...
<tseliot> ppisati: so you get the corruption with both releases
<ppisati> tseliot: yes
<ppisati> tseliot: previously was http://paste.ubuntu.com/1124965/
<ppisati> tseliot: now i'm like this http://paste.ubuntu.com/1125017/
<ppisati> tseliot: still garbled right head
<tseliot> ppisati: please file a bug report and I'll forward it to AMD
 * ppisati considers going with the open source driver
<tseliot> it's the same driver, BTW
<ppisati> tseliot: one says "fglrx" the otehr says "fglrx-updates"
<ppisati> tseliot: and according to jockeys are different
<ppisati> tseliot: anyway, i'll file a bug
<tseliot> ppisati: they will be different as soon as I update fglrx-updates with a newer release ;)
<ppisati> tseliot: my life sucks...
<tseliot> ppisati: you can uninstall the current driver, download the latest driver from AMD's website and run the installer with "--buildpkg Ubuntu/precise" and install the deb packages that it generates
<tseliot> apw: heh, they were private reports ;)
 * henrix -> out for lunch
<ppisati> tseliot: i can live with that for now
<ppisati> tseliot: when do you plan to update it?
<tseliot> ppisati: they have to accept my SRU for the LTS first, then I can think of updating the driver. You should probably try AMD's latest driver to see if at least it fixes the issue
<ppisati> tseliot: want to do some work this afternoon, i'll try this evening
<ppisati> tseliot: btw, is there a changelog somewhere?
<tseliot> ppisati: no, I don't think they have such things ;)
 * ppisati assumes a fetal position and cries...
<tseliot> at least not publicly available
<tseliot> :D
<ppisati> tseliot: and is there any mention of screen corruption in that non-existant changelog?
<tseliot> ppisati: I don't think so, but you never know ;)
<ppisati> tseliot: ok :)
<ppisati> ah, and now i see why weather-indicator doesn't work
<ppisati> it lookups another site for sunset and sunrise data
<ppisati> and if it's down, it craps out
<ppisati> [Fetcher] 2012-08-02 14:23:15,994 - ERROR - Weather: error reaching url 'http://www.earthtools.org/timezone-1.1/45.464269381/9.18950557709'
 * ppisati goes back in the curly position and cries again...
<smb> Weeelcome to the world of tomorrow (which is as crap as yesterdays but requires twice the resources to do so)... ;-P
<ppisati> smb: ogra calls it progress
<infinity> He's been around longer that all of us, I guess he'd know progress when he sees it.
<infinity> s/that/than/
<smb> If everything is failing around you, positive thinking is the only thing left to do
<smb> You know, yesterday we were standing before the chasm, today we are one step ahead...
<infinity> smb: Freefall is fun.  Plenty of people pay every day to do it.
<smb> infinity, Yeah, though I hear they insist on some strings attached
<infinity> People are also whiney.
<infinity> If we covered the entire planet in giant trampolines, we'd be set.
<smb> Which brings us back to the start of the discussion. :)
 * infinity thinks apw might have died, while I was reviewing something for him.
 * infinity pokes apw with a stick.
<smb> maybe we nee more rubber trees
 * infinity tries not to spit on his monitor.
<infinity> A German, of all people, should know what "black rubber trees" refers to.
<smb> infinity, If he is sensible he is in the pool now... any pool...
<smb> infinity, Should he?
<smb> err me
 * smb looks blank
<infinity> Think of the general shape of an evergreen.  Say, a fir or a pine tree.
<infinity> And then a certain family of sexual aids that come in varying sizes, but almost always the same shape and color.
<infinity> I've said too much.
 * smb wonders why he should know when infinity obviously knows much more... :-P
<infinity> smb: I blame the part where I dated a German.
<smb> infinity, You probably should asked before about the bdsm background
 * apw loves sticks
 * smb takes a step further away from apw
<ppisati> infinity: dude, you are kinky
<rtg> apw, frobbing my laptop with kmod.
<apw> rtg great
<smb> *** this channel is being closed for overly sexual content ***
<infinity> ppisati: Am I?  You knew what I was talking about.
<infinity> rtg: That's the dirtiest thing anyone's said this morning.
<rtg> infinity, :)
 * smb tries to shut up those internal voices...
 * infinity whispers "rubber trees" in smb's ear.
<smb> yellow! :-P
<infinity> Yellow?  I'm not sure I like where this is going.
<infinity> You're a disturbing man.
<smb> infinity, Hey, you started. ;)
<infinity> I beg to differ.
<infinity> 06:39 < smb> maybe we nee more rubber trees
<infinity> ^-- Evidence.
<smb> infinity, I just meant real normal ones instead of trampolines. Everything else was your imagination.
<infinity> smb: Real... Normal... Rubber... Trees?  Kay.
<infinity> smb: We'll get you one of those "normal" black ski masks with zippers, too.  You know, for skiing.  Like a normal person.  Who likes zippers.
<smb> infinity, I seriously doubt your skiing experience...
<ogra_> geez... whats going on here !
<smb> infinity, Next thing comes the table tennis ball on a string, for people who tend to loose them
 * ogra_ wonders if there is a beer shortage or so ...
<smb> ogra_, Rather an over supply on temperature outside...
<ogra_> heh
<smb> But those tend to go together
<ogra_> yeah, here too (boston)
<ogra_> rather tropical weather
<smb> At least buildings there tend to have ac
<rtg> apw, kmod still produces map files ?
<smb> infinity, Just to "cool" down the discussion, I was actually thinking of this: http://www.youtube.com/watch?v=1-_-QxerYno
<apw> rtg, kmod has no code to do so
<apw> the older map files, it still makes binary accelerator files
<infinity> smb: Yeah, Monkey Island gets me going too.
<rtg> apw, seems to be working. I've installed a new kernel and nothing has caught on fire
<apw> rtg, nice ... i had it on my box through 3 updates without remembering i'd install it
 * cooloney just realize overlayfs is not in mainline yet
<cooloney> apw: will overlayfs be merged into mainline recently?
<apw> cooloney, its not making much progress
<cooloney> apw: ha, got it. just sent an email about the lxc issue with overlayfs to maintainer, but i also copied it to lkml.
<apw> cooloney, can you forward me a copy pls
<cooloney> apw: oh, i think i copied it to our public mail list
<cooloney> apw: you should receive it
<apw> ok
<rtg> cking, can you test tip of Quantal master-next for IVB graphics? I've pushed some patches for dynamic parity detection.
<cking> rtg, OK will do
<rtg> cking, thanks
<cking> rtg, booted on an IVB SDP laptop and desktop - I can't see any i915 issues, and I'm thrashing it with some 2D and 3D rendering apps too
<cking> so, it seems good to me
<rtg> cking, cool, thanks.
<cking> rtg, not sure what else to do to test these patches
<rtg> cking, dunno, I was just making sure the parity patches didn't cause regressions.
 * cking can't see any immediate issues
<cking> even passes my S3 soak tests too
 * ogasawara back in 20
<ppisati> mumble failure?
<apw> ppisati, global
<ppisati> uhm is back
<arges> ppisati, apw : mumble is crashing when i load it.. is there a bug associated with this?
<apw> arges, mine seems to have settled, i think it was a server side issue for us
<smb> Though crashing is probably not the epected reaction
<arges> well even moved my .conf file to see if it was that. time to file a bug
<arges> apw, ah its because i had selected jack audio as the output, if I select another output it works fine
<apw> arges, la la la jack is wonderful
<arges> it acutally looks like a pulseaudio bug 
<arges> at least that's where the crash is in the backtrace
 * smb bails early
 * cking reboots
<rtg> apw, I have a git foo question. I would expect this to work: 'git format-patch v3.5..HEAD -- drivers/net/ethernet/intel/ixgbevf; git reset --hard v3.5; git am 0*'
<bkerensa> If someone on the Kernel Team might have a look at Bug #972063 and help determine if its Kernel related that would be great? :)
<ubot2> Launchpad bug 972063 in bluez "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Confirmed] https://launchpad.net/bugs/972063
 * cking calls it a wrap, back much later
 * rtg -> out early
 * henrix -> EOD
 * apw calls it a day
<bjf> slacker
<shadeslayer> hi
<shadeslayer> I'm trying to use make-kpkg to compile my own kernel with a custom config
<shadeslayer> but I get this 
<shadeslayer> dpkg-gencontrol: error: illegal package name 'linux-image-3.5.0-powersave-ARCH': character 'A' not allowed
<shadeslayer> I've looked at the wiki and the documentation there seems to be a bit .. convoluted, and make-kpkg seems a bit easier
<apw> shadeslayer, no idea where that -powersave- is coming from ...
<shadeslayer> apw: that's me
<shadeslayer> fakeroot make-kpkg --append-to-version="-powersave" kernel_image --initrd binary -j6                                                                         
<shadeslayer> a bit of clarification, the primary reason I'm compiling my own kernel is because I want to get the I915 module compiled into the kernel
<shadeslayer> and not as a module
<shadeslayer> that would allow me to switch off my discrete graphics card
<shadeslayer> ( currently I can't because if I switch off my discrete card via grub the kernel can't find *any* graphics card and the screen goes black )
<apw> how are you turning it off via grub when it fails
<shadeslayer> oh, grub boots fine, then you can use 'out' to send bits over the wire
<shadeslayer> and turn off the graphics card 
<apw> so why would building in 915 help ?
<shadeslayer> because the I915 code initializes the intel graphics card?
<shadeslayer> Did I mention I have 2 graphic cards?
<apw> the same code is run whether its a module or builtin ?
<shadeslayer> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
<shadeslayer> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Seymour XT/PRO [Radeon HD 7400M Series]
<shadeslayer> apw: afaik you need to build in the code so that the card gets initialized and you have one working graphics card
<apw> that to me doesn't make sense as builtin or not the driver will get loaded if you have the device in your PCI listing
<shadeslayer> I've already tried switching off the graphics without the module built in and the screen doesn't show anything
 * apw suspects it won't make a differnece
<shadeslayer> sec
 * shadeslayer pulls up docs
<shadeslayer> oh .. maybe this is it
<shadeslayer> "If you have blackscreen on boot, it may be because you've built both Framebuffer Console support and the i915 driver (with KMS enabled) as modules. The blackscreen is a result of the i945 driver probing for displays before the fbcon module is loaded. As it can't find any console display(because the fbcon driver isn't loaded yet) it simply turns it off."
<apw> that implies you want fbcon builtin and i915 not
<shadeslayer> true, I've just found that
<shadeslayer> or 
<shadeslayer> http://en.gentoo-wiki.com/wiki/Intel_GMA
<shadeslayer> I just add modules="fbcon" to /etc/conf.d/modules as suggested by that wiki
<apw> shadeslayer, i think fbcon is builtin in ubuntu
<shadeslayer> can you tell me the key for fbcon?
<apw> shadeslayer, indeed its builtin
<apw> key?
<apw> grep fbcon /lib/modules/3.5.0-6-generic/modules.builtin
<apw> kernel/drivers/video/console/fbcon.ko
<shadeslayer> oh .. I was looking at /boot/config-3.5.0-6-generic
<shadeslayer> interestingly : CONFIG_DRM_I915_KMS=y
<shadeslayer> so the I915 driver is built as a module
<shadeslayer> but KMS is built in
<apw> no that is just a toggle, enabling kms support
<apw> in tghe module
<shadeslayer> oh ... I thought 'y' meant that it was built in
<shadeslayer> and m, like in this one : CONFIG_DRM_I915=m
<shadeslayer> meant it was a module
<apw> depends if it is bool or tristate
<apw> and indeed what it i use for
<shadeslayer> oh .. interesting ...
<shadeslayer> apw: so according to you, it *should* work?
<shadeslayer> with the default config
<apw> according to the limitations you are saying are required, i think you are already meeting them
<shadeslayer> hmm ... I'll try again, and lets see what happens this time
<shadeslayer> apw: http://dentifrice.poivron.org/laptops/macbookpro8,2/ < if you go down to the place where the article talks about GRUB menuentries, you'll see what I was talking about :)
<apw> of course it is a macbook
<shadeslayer> haha :D
<apw> damn apple
<shadeslayer> as a matter of fact, I have a very simple mechanism to get a ubuntu ISO boot from a USB drive in EFI mode
<shadeslayer> bbiab, trying out the outb commands
<apw> the i915 driver requires a patch activating dual LVDS channels, otherwise it will show nothing but a black screen;
<apw> from the doc you pasted ^^
<bjf> jjohansen: have you had a change to look at bug 1028837 ?
<jjohansen> bjf: do you mean 1029937?
<jjohansen> bjf: I have started but haven't gotten very far
<bjf> probably
<bjf> jjohansen: yes i do
<shadeslayer> apw: I thought the dual LVDS channels patches were incorporated with the 3.5 kernel ....
<apw> shadeslayer, dunno maybe
 * apw sleeps
<shadeslayer> I should probably sleep as well :P
<shadeslayer> right after I check if the patch was applied or not
<shadeslayer> seems not
<shadeslayer> so I'll have to compile it afterall
<shadeslayer> bah, I was looking at the wrong patch, applying the lvds patch fails
<shadeslayer> need to look at the code
#ubuntu-kernel 2012-08-03
<dileks> hi. good its called arch/arm64 :-)
<dileks> http://thread.gmane.org/gmane.linux.kernel/1324121/focus%3D1333603
 * smb decides that having a cup of coffee standing in front of him probably is not enough...
<apw> infinity, what was the arch name in debian for arm64 in the end
<smb> aaaarch64?
<apw> smb, dunno, dileks was just pointing out the kernel looks to be changing to arm64
<smb> just being more than an hour ago but yeah
<smb> they probably got too many puns for the other name
<apw> indeed almost exactly two apparenly ...
 * apw bets this means we end up with the same issues with name
<apw> between debian and the kernel again ... sigh
<smb> Why should they deserve a better fate than amd64/x86_64
 * smb still feels more tired than before going to sleep...
<infinity> apw: arm64.
<infinity> apw: aarch64 is just the GNU triplet, the dpkg arch is arm64.
<infinity> apw: You can thank me for that sanity. :P
<apw> heh so we managed to get them inconsistenat anyhow
<apw> thanks :)
<infinity> apw: Yeah, people whined about the triplet/dpkg inconsistency, and I don't care.
<infinity> apw: Making the triplet something that isn't arm* means that the tons of tools out there that assume arm* = aarch32 won't explode.
<apw> having most of an arch name be arch is pretty uselss as its effectivly a64
<apw> which is pretty greedy namespace wise
<infinity> apw: Yeahp, but whatever.  Not my concern.  Anything !arm* is fine by me. :P
<infinity> apw: Maybe someone will talk ARM into renaming the GNU triplet, but I'm kinda hoping not, as it will mean redoing all their toolchain patches, plus any bootstrap porting they've done.
<infinity> apw: (Plus the above conflict, which means having to go over every single build system with a fine-toothed comb)
<apw> infinity, its not sounding perfect indeed
<dileks> I looked (quickly) over a bit that arm64/aarch64 patchset, so its a bit inconsistent in usage. in terms of "port" they mostly use "arm64", in case of arch(itecture) aarch64 is used. so there should be a clear usage of terms. for linux/arch/arm64/ that is what kernel people have expected
 * dileks looked into ia32 below arch/ and naming of files, hmm, yes, what shall I say :-(
<henrix> smb: fyi, i'm tagging bug #999755 as verified in oneiric
<ubot2> Launchpad bug 999755 in linux "Kernel crash in rb_next doing ohai loops" [Undecided,In progress] https://launchpad.net/bugs/999755
<smb> henrix, Ok, cool. Yeah, it is as verified as it will get. Thanks
<henrix> smb: :)
<apw> warning warning will robinson ... X seems to be in quantal-proposed
<smb> Friday sounds like the perfect day for that.
<dileks> as Linux v3.6-rc1 is released... <http://www.h-online.com/open/features/Kernel-Log-Development-of-Linux-3-6-under-way-1657742.html>
<dileks> apw: you read that "secret announce" about unionmounts in vfs pile #1?
<dileks> preliminary support*
<dileks> I am surprised noone asked when that will be ready2use
<dileks> https://lkml.org/lkml/2012/7/22/17
<dileks> to quote: "* preparatory bits from unionmount series (from dhowells)."
<apw> oh great more transisions in my future
<dileks> apw: just as a note "VFS: Split inode_permission()" (commit by dhowells)
<dileks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0bdaea9017b9d2b9996e153a71ee03555969b80e
<dileks> remembering your work... an export is missing for "fs built as module"?
<apw> yeah
<smb> apw (and maybe bryceh is interested): bug 1032622
<ubot2> Launchpad bug 1032622 in xorg "ctrl+alt+l fail to start screenserver" [Undecided,New] https://launchpad.net/bugs/1032622
<smb> (this seems to be related to pulling in the new X stack)
<smb> or q-proposed in general
<apw> yeah
<apw> you should say that if you didn't
<smb> I did
<apw> great
<arges> apw, hello. was it you or cking that was the resident acpi expert?
<apw> arges, that'd be cking, but he is off for a bit, whats up
<rtg> arges, cking, but he's out for 2 weeks
<arges> rtg, apw : ah that's what i thought.   just looking at a report regarding apci,  pad.lv/1016617     looks like it works in centos but not in ubuntu. so was wondering if getting /proc/cmdline from the other distro would make sense to compare or if I need to look at something else
<apw> bug #1016617
<ubot2> Launchpad bug 1016617 in acpi "Dell c6220 Unable to Reboot" [Medium,Confirmed] https://launchpad.net/bugs/1016617
<apw> I have found that by rebooting the server via the DRAC web interface will reboot the server correctly.
<apw> arges, ^^ any idea what that even means ?
<arges> apw, I'm guessing its the dell server management console, but i was going to verify
<arges> Dell Remote Access Controller
<arges> yes
<apw> that may involve poweing the machine off then which we know also fixes the issue
<apw> arges, the most likely difference between centos and us is kernel version
<arges> apw, yea i'll get the kernel version and ask to try the similar ubuntu version
<apw> as there is an indication that nolapic works for them you might look see if there is a quirk for htat, i suspect there is
<arges> apw, well looks like it helps with the reboot part, but not the boot up part after software reboot
<arges> apw, yea they got it to work using 2.6.18 ... so pretty ancient
 * ogasawara back in 20
<apw> yeah a million years old
<arges> wow it was released march 2012
<henrix> fwiw, they use "2.6.18", not 2.6.18 -- its a *really* heavily patched version.
<arges> yup
<henrix> i had to use centos 2 years ago, and their kernel is very different from the mainline version
<mjg59> If it's the standard Dell BIOS issue it'll also go away if you disable x2apic support
<apw> mjg59, as in nox2apic on the kernel command line ?
<arges> mjg59, ah. is this done via the bios?
<henrix> i guess he meant the kernel param nox2apic
<henrix> oh, apw had already suggested that :)
<ohsix> what's an irq injection attack
<arges> henrix, well they tried nolacpi, but i'll suggest nox2apic
<arges> mjg59, thanks
<mjg59> If that works then it's a BIOS bug
<mjg59> And it's not easy for Linux to work around it
<rtg> apw, ogasawara: pushed 3.6-rc1 for ubuntu-r. it builds for x86en. have not boot tested yet.
<ogasawara> rtg: ack, thanks
<rtg> back to firmware patches...
 * apw was looking at what was in -rc1 it looks like a huge upheaval especially in VFS we should be wary about moving there as i suspect aufs and overlyafs are going to break hideously
<rtg> apw, aufs, overlayfs, and raid4-5 are all disabled for now
<apw> rtg, thought they might have to be, there is some union-mounts basis going in there which will collide hideously
<apw> ogasawara, ok pushed -- pulled all the commits together so we can squish them next time round
<ogasawara> apw: ack
<rtg> apw, quantal ?
<apw> rtg yep quantal, refreshed aufs and pulled the commits together so we can clean them up and drop them easy depending
<jwi> jsalisbury: for bug 1028151, testing on 3.3 is a red herring - 3.3 doesn't have the relaxed dmi check that was cherry-picked to precise. so you're back to a situation where samsung_laptop.ko isn't loaded and can't cause havoc.
<ubot2> Launchpad bug 1028151 in linux "Samsung Series 900 Laptop brightness control issue" [High,In progress] https://launchpad.net/bugs/1028151
<jsalisbury> jwi, ahh right.  makes sense 
<jwi> but f34cd9ca932087 upstream sounds like it could help
<jsalisbury> jwi, cool, I'll take a look.  Thanks!
<jwi> jsalisbury: and for bug 1021086, e19ebcab01cc130fa is trickling down through 3.5-stable
<ubot2> Launchpad bug 1021086 in linux "Kernel Panic when re-enabling wifi via Fn+F2 on Dell XPS 15z" [High,In progress] https://launchpad.net/bugs/1021086
<jsalisbury> jwi, great, thanks!
 * henrix -> EOD
<herton> jjohansen, are you maintaining qrt? I just filled a bug for a minor issue I noticed here (bug 1032743)
<ubot2> Launchpad bug 1032743 in qa-regression-testing "ptrace-restrictions.sh will fail if LC_MESSAGES or LC_ALL is set to something undesired (non english error messages)" [Undecided,New] https://launchpad.net/bugs/1032743
<herton> jjohansen, by qrt, I mean the security tests on it
<jjohansen> herton: okay I'll take a look
<herton> jjohansen, thanks
 * smb -> EOD
 * rtg -> lunch
 * apw -> beer
 * ogasawara lunch
<rtg> ogasawara, we've accumulated quite a stack of patches in quantal master-next. are you thinking about uploading today ?
 * rtg -> EOW
<ogasawara> rtg: I wasn't planning one for today, but it should be trivial to do.  let me kick off some test builds and then I'll upload.
<rtg> ogasawara, ack, I'll watch for build failures over the weekend.
#ubuntu-kernel 2012-08-04
<Maiz_en_Heces> anybody here?
#ubuntu-kernel 2012-08-05
<wzssyqa> pbuilder failed after I modified something in config, it seems that I need to bump abi
<wzssyqa> how to bump abi?
<Martiini> anyone care to help with compiling custom kernel for a netbook on Ubuntu ?
#ubuntu-kernel 2013-07-29
<ppisati> moin
<smb> ciao
<ppisati> brb
<ppisati> the push to talk button doesn't work... :(
<ppisati> i can crackling hear you
<ppisati> but can't talk
<ppisati> :(
<smb> bah
<ppisati> i just dist-upgraded
<ppisati> let's see if it helps...
 * ppisati -> reboot
<ppisati> i can hear you, but my push-to-talk button doesn't work
<ppisati> and changing it, doesn't actually make any difference
<ppisati> :(
<smb> ppisati, One of those mysteries about mumble to me is that even if you tell it to not use speech for status messages, it still causes the speech-dispatcher to start. Which is one more needless complication.
<ppisati> smb: eh...
<ppisati> ppisati: it usually works for me
<ppisati> smb: ^
<ppisati> smb: but today it's completely broken... :(
<smb> ppisati, Not saying it does not work (usually) but sometimes when one has to kill things to unbreak it, I also have to make sure to kill speech
<smb> But I don't use it, so I would not need it to run
<ppisati> smb: i rebooted after a dist-upgrade, hoping it would fix it
<smb> ppisati, You should be more *experienced* by now... :-P
<ppisati> smb: and i had this problem before this dist-upgrade, so it was something from last week
<smb> ppisati, Unfortunately for you it seems something bad very much restricted to your hda codec
<ppisati> smb: i don't know, it's like the input channel is completely broken
<ppisati> smb: lips don't turn red if i press the push-to-talk button
<ppisati> smb: and even switching from ptt to continous or voice recognition, doesn't make any difference
<ppisati> bah
<smb> ppisati, Not sure this helps, but did you try to go into config and change input to samething different and back
<ppisati> life sucks, and then you mumble
<smb> somthing
<ppisati> smb: i could try wiping the entire config
<ppisati> smb: lemme try
<ppisati> uhm, first problem
<ppisati> where does mumble store its config?
<smb> ppisati, I believe to remember that sometimes you had to fiddle around with the config to make it use what you wanted it to use.
<smb> .mumble ?
<smb> no .Mumble
<ppisati> [flag@luxor ~]$ ls -la .mumble*
<ppisati> ls: cannot access .mumble*: No such file or directory
<ppisati> [flag@luxor ~]$ ls -la .Mumble
<ppisati> ls: cannot access .Mumble: No such file or directory
<smb> Sorry
<smb> Had some sockets there... actually .congig/Mumble
<smb> .config! 
<smb> Gah
<apw> ppisati, when i get that i find going into the 'audio wizard' and clicking forward a few times
<apw> will either hang mumble completely (then killall mumble; killall pulseaudio; sleep 10; mumble -- is needed)
<apw> or it fixes it magically ... and you are good
<ppisati> can't set any shortcut for PTT now
<ppisati> ok, i give up
<rbasak> If a driver works on an old release when a linux-backports-modules* package is installed, does that mean there should be support in the latest upstream kernel? ie. is linux-backports-modules fed from the upstream kernel, the Ubuntu kernel, or somewhere else?
<apw> rbasak, it is fed from the wireless backports tree, but yes in principle it means that it is supprted in mainline
<apw> (compat wireless is the right name)
<rbasak> Great - thanks!
<apw> rbasak, though testing kernels from later releases should be as simple as installing the newer kernel and testing
<rbasak> I need a USB wireless dongle because I'm working with the latest upstream kernel on my ARM Chromebook to experiment with ARM KVM, and the upstream kernel doesn't have support for the Chromebook's wireless yet. Trying to figure out what to buy.
<apw> something old :)
<rbasak> linuxemporium.co.uk said that 10.04 worked with linux-backports-modules-... installed, so I figured I'd get that one. But they're sold out :(
<rbasak> There are various people selling cheap stuff on eBay with "Linux" support but I don't know if that means mainline or some binary driver built for !arm.
<rbasak> This is when I wish the Linux trademark were used more. If they said "Linux first-class" means mainline support only, then it'd be easier for me to shop for hardware that declares that.
<rbasak> (since "Linux" support can mean anything)
<apw> yeah indeed, it is a minefield, buy something older, and you'll likely be ok, maybe
<infinity> rbasak: USB ethernet tends to be less headache than USB wireless, FWIW.
<infinity> rbasak: And dirt cheap.
<infinity> rbasak: I've got one similar to this http://www.amazon.com/Cisco-USB300M-Cisco-Linksys-Ethernet-Adapter/dp/B001NLV4TQ
<infinity> rbasak: (And those dongles have had mainline support forever, and I use 'em on all sorts of ARM boards when they lack ethernet or their own is buggered)
<ogra_> just dont use to many of them at the same time :)
<ogra_> (at least on teh same bus) 
 * henrix -> lunch
 * henrix -> EOD
#ubuntu-kernel 2013-07-30
 * ppisati -> reboot
<ppisati> smb: guess what? it doesn't work...
<ppisati> smb: i can hear you, but can't answer...
<smb> I realized soon agter I tried to talk to you...
<smb> after
<apw> smb, so it is possible.  boot to grub, edit the kernel command line, fix root= to the new dm mapper name for root and add break=mount
<apw> smb, at that point lvm vgrename the group and let the boot continue, update-grub, grub-install and reboot again
<smb> apw, Ok, at least one method working. Not sure a rename reboot and change root= and then update-grub again would not work as well. And not sure either the install-grub thing is needed there at all...
<apw> smb, if you rename then reboot you have to incant at grub-rescue to get to to the grub prompt
<apw> it is easier to incant at the normal menu thing :)
<smb> Yeah I think
 * smb reboots
<ppisati> brb
 * henrix -> lunch
<amitk> cking: you used to have a script to exercise suspend/resume a bazillion times, did you have something for hibernate?
<cking> amitk, it's in fwts, e.g. use fwts s4 --s4-multiple=10000
<amitk> cking: urghhh... tied to x86?
<cking> more like pm-utils
<amitk> cking: the s4 worries me, I wanted to point to it for ARM platforms
<apw> amitk, how does one ask for hib on arm
<apw> echo disk >/proc/thingy ?
<amitk> apw: we're fixing that :)
<amitk> apw: by adding the required hooks
<apw> what i mean is pmutils uses ech
<apw> echo mem or echo disk into /proc, if you respond to those then i suspect things will work
<amitk> apw: right, that is the only interface i want to depend on, I'll have a look at what fwts expects. I'm hoping it isn't too tied to x86'isms
<amitk> cking: fwts git tree?
<cking> amitk, git://kernel.ubuntu.com/hwe/fwts
<amitk> apw: echo mem > /sys/power/state interface, that is
<cking> amitk, you may get away with faking a pm-hibernate script, that's all it uses
<amitk> cking: we pushed some patches to migrate workqueues and other irqs away from idle cores in 3.10 and 3.11, you might find them useful
<cking> amitk, for ARM specifically, or generic arch changes?
<amitk> cking: most of our work is core frameworks, the only ARM-specific stuff is driver consolidation
<cking> amitk, so I could theoretically be able to measure this on x86 if I enable CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
 * cking pops it on the TODO list
<amitk> cking: depends on your idle profile (drivers using wqs), we only converted 3-4 subsytems to use POWER_EFFICIENT WQs by default. There might be more subystem in use on x86
<amitk> cking: driver writers who don't have to worry about performance (cache) are starting to convert their drivers to use this now
<amitk> cking: so yes, we see improvements
<amitk> idle states are deeper and longer
<cking> ack
<amitk> cking: will try to dump info and exchange notes with you guys as time permits, gtg. Bye
<cking> amitk, ok, I'm always around to help
<amitk> cking: thanks
<tyrant> i have a kernel 3.2.0-49 installed and i want to rebuild a module for that kernel, where do i get the source code for that particular version (same vermagic)? the sources apt gives me  has this vermagic 
<tyrant> 3.2.46 SMP mod_unload 686
<lfaraone> If you're running the raring kernel on 12.04 LTS and upgrade to 12.10, what happens to your kernel version?
<apw> lfaraone, from P+R kernel to real R ?  the kernel would be near identicle, so you would upgrade to the replacement kernel
<apw> which would be basically the same bits
<lfaraone> apw: P+R kernel to Q.
<apw> oh, you will end up with both kernel still i expect
<apw> so you would probabally continue to use the R kernel, which isn't going to update
<lfaraone> apw: Is the R kernel offered as a package in Q? 
<apw> hmmm not idea
<apw> nope
<apw> though that seems like an odd upgrade
<apw> cirtainly odd to move from P+R to Q and not then on to R
<lfaraone> So if you install 12.04.3 or whatever with the HWE raring kernel and then want to upgrade to the (still supported) 12.10 but not 13.04, because lets say there's some incompatability with your frobnicator. 
<lfaraone> You end up in a situation without updates :/ 
<lfaraone> I'm trying to figure out if I need to backport the 3.8-enablement patches for OpenAFS to PQ or just P.
<apw> lfaraone, that does sound like an accurate statement, not idea
<apw> ideal indeed
<apw> i wonder if we can force the lts backports off on upgrade
<lfaraone> apw: that would be unfortunate if I actually need the R kernel for my hardware, though, right?
<apw> if you arn't supported on Q in theory you cannnot upgrade from P+R though Q anyho
<apw> as you should have never been able to install Q in the first place, but would have been forced to R
<apw> but this is all far from ideal in either direction
 * apw makes sure it is on our next team agenda
 * apw calls it a day
<kentb> do we typically update pciutils with a new set of pci.ids in a stable release?  for example, 12.04.3?  There are some new Ivy Bridge servers on the horizon that'll need the id bump so they're recognized properly in 'lspci'.  Or is the answer to run 'update-pciids' (which seems to work)?
<kentb> 'they're' meaning memory controllers and the like
<mojo706> hello wonderful people on the Kernel Team 
<mojo706> please assist this user http://ubuntuforums.org/showthread.php?t=2164127
<mjg59> mojo706: It's not a kernel bug - the panic is because it can't start init
<mjg59> And it can't start init because your hard drive is dead
<mojo706> mjg59, but I have read somewhere else that it got fixed after a reinstall of Ubuntu but in this case there are important files.
<ShapeShifter499> hi
<ShapeShifter499> I have a nook hd tablet that as far as I know is OMAP4. Do I have to do any edits to ubuntu arm to get it to boot and run off my system?
#ubuntu-kernel 2013-07-31
<mojo706> crickets
<RAOF> Woot! There we go! btrfs force remount ro.
<rtg> RAOF, brave soul
<smb> rtg, Early rising and already bored? (/me assuming you guys rather relax today)
<rtg> smb, jet lag is all over me
<rtg> we _do_ have some craft brewers to research this afternoon
<smb> It always a battle (the jet lag)... Sounds tempting. I will join rather late today, probably 9ish
<rtg> smb, I'll likely be face planted by then
<smb> rtg, Yeah, according to previous experience (not you though) it could be likely
 * rtg wonders wtf a unity webapp plugin is, and why does it think it needs to run all the time ?
<smb> UbuntuOne (or similar things)?
<rtg> dunno. it seems new with saucy
<smb> unity-webapps-service <- got that on R
<rtg> well, is it just soaking up RAM for no good reason ?
<RAOF> smb: Its for webpages to pop up in various unity things
<smb> Hm, not particularly (thunderbird and firefox rather be top)
<RAOF> Although quite why it's not dbus-acivated...
<smb> RAOF, Ah well. Might be some S re-baddening
<rtg> RAOF, I need more popups like I need a new orifice.
<smb> rtg, You just have not realized that you need any of that
 * smb will be back in a second after rebooting his FW (famous last words)...
<smb> done
<apw> rtg, if that orifice was for beer consumption it might be ok
<apw> smb, firewall reboot successful, well that never happes
<rtg> apw, should we add that pstate patch to master-next ? I'm thinking there might be one more v3.10 based upload before we switch over to 3.11
<apw> rtg, i think it should already be on there
<apw> rtg, i have pushed a new patch for mem control to all of the phablet kernels, but not uploaded them, know of anytying else pending for phablet kernels at the moment ?
<rtg> apw, there is a bug open against one of the N kernels for blue-tooth, but I can pursue it later this week.
#ubuntu-kernel 2013-08-01
<rbasak> apw: morning! Are you aware of any races in overlayfs that might be observable from userspace? I have a tar complaining "Directory renamed before its status could be extracted" but it seems to affect overlayfs only.
<rbasak> 3.8.0-19-generic
<rbasak> (raring)
<apw> rbasak, there are any number of semantic issues with overlayfs, though it could be a bad assumption by the creating app as likely as anything
<rbasak> apw: AFAICT, it's tar. Just unpacking a fairly big tarball (from a pipe, being delivered from a different filesystem)
<apw> rbasak, is there a bug filed?  if you get me the number i can have a look when i get to the office, in transit right now
<rbasak> apw: unfortunately it's really hard to reproduce. I can do it reliably, but it requires an autopkgtest run of about three hours. I haven't filed a bug because I'm not sure it is a bug in the first place (or if so where it is), but I'd appreciate if you could take a look with me when you get in.
<rbasak> apw: oh, you're sprinting this week, aren't you? I don't want to take your time away from that, actually.
<apw> rbasak, heh, if we have time we have time :)  still good to chat about it
<rbasak> So I'll start explaining the problem, and you'll see it when you're ready :)
<rbasak> I'm writing an adt-virt-lxc. It seems to work, and AFAICT, without any bugs, at least not that are relevant to this problem. I can get it to run in clone mode, or ephemeral mode. With clone mode it uses lxc-clone and overlayfs isn't involved. With ephemeral mode, it uses lxc-start-ephemeral which sets up an overlayfs against the template container's rootfs. In this case I'm using --keep-data, so the upper backing store is on a normal fs.
<rbasak> After the container is started, the system uses lxc-attach to run commands inside the container (which has its root fs as the overlayfs in the failure case).
<rbasak> adt-run transfers files in and out of the container using tar (so it's generic and can work with other virt mechanisms)
<rbasak> When running in clone mode, this seems to work fine. But when in ephemeral mode (which uses the overlayfs), I get tar bombing out with many "Directory renamed before its status could be extracted" errors.
<rbasak> tar's stdin is connected to another tar's stdout. The latter tar is running outside the container. The former is extracting inside the container. So this is transferring files into the container.
<rbasak> I have a suspicion (but am not sure) that the problem occurs when the tar running outside the container has finished all I/O, so the only thing going on is that the pipe is being flushed out.
<rbasak> This is inside a VM that I'm evidently sharing with I/O hungry users. Disk I/O seems to be extremely slow on this VM. So perhaps tar is extracting entirely into buffers in this case?
<rbasak> The code path inside adt-virt-lxc is exactly the same in both modes. The only difference is the way the containers were created. Once they are up, both situations do exactly the same thing. The only difference is the underlying configuration of the container (native fs vs. overlayfs).
<rbasak> So AFAICT, it's a problem affecting tar extractions on overlayfs only.
<apw> rbasak, sounds compelling, and overlayfs does have some awkward semantics when copy up occurs
<rbasak> I've just looked up the tar source to see exactly what it's complaining about
<rbasak> Looks like it doesn't like it if st_ino or st_dev have changed.
<rbasak> Against the known path/filename and an fstatat against the previously open fd, perhaps? SOmething like that.
<zequence> apw: Are you going to DebConf by any chance?
<apw> zequence, sadly no
<smb> apw, morning
<apw> smb, moin ... 
<apw> smb, having fun yet?  overloaded and broken the coffee machine?
<smb> apw, not much yet... reminds me
<smb> coooffeee machiiine
<zequence> apw: Maybe some other time then :). You want to do another upload of the saucy kernel before handing it over?
<apw> zequence, yeah indeed, then we can sort out the sponsorship process for that, and we should work towards getting you upload for it
<zequence> apw: That would be great. I've been meaning to get some more documented packaging experience beyond the kernel, but it's a bit slim so far.
<apw> zequence, well getting a package upload is a good start on the path
<rbasak> apw: over to you then I guess?
<rbasak> apw: if the conclusion is "yeah, it does that" with no hope for a fix, that's fair enough. adt-virt-lxc defaults to clone mode - I was just hoping to make it faster for development purposes by adding --ephemeral. We can still use that with the caveat that if it breaks then the developer should switch to clone mode :)
<rbasak> I don't think we'll use this in production, but if we do, then we'll use clone mode.
<apw> rbasak, ack
#ubuntu-kernel 2013-08-02
<alkisg> Hi, at what date is linux-hwe-generic (precise) going to depend on the raring kernel?
<alkisg> Btw, I just tried the raring kernel + xorg, they work fine here, thanks :)
<Mirv> hi. I've been unable to find some information on the wiki (BuildYourOwnKernel, KernelGitGuide, FAQ). I'd like to offer a PPA build of the kernel with a proposed patch for users before hailing the kernel team with the patch.
<Mirv> so I've git clone:d the raring kernel, have modified a patch to apply with git am and then wondering what should I do to achieve essentially debuild -S for dputing
<arges> apw: hello
<apw> arges, yo
<apw> hello
<apw> arges, ya
<apw> arges, ya
<xnox> So i've been discussing with Darren Hart possibility to support the new Intel MinnowBoards over at g+ https://plus.google.com/109160032876474505377/posts/35eAHQfYMbQ
<xnox> the support is in/for 3.12, but there are patch series & config changes that could be pulled into 3.11.
<xnox> Will saucy be 3.11? it's at rc3 at the moment =/
<ogasawara> xnox: yep, we're gonna push for v3.11
<xnox> ogasawara: do you know the story with EMGD intel drivers in ubuntu? (v1.18 or better) as that's what that board requires. I see some community PPAs with it, but not much else.
<xnox> there is also android drivers, which means that potentially ubuntu touch can also be brought up on MinnowBoard.
<ogasawara> xnox: I'm not up to speed about the EMGD drivers
<xnox> ok. thanks =)
<apw> ?b !^
<ppisati> apw: #$%^
<apw> commit 6d3bfc7be6f80d0c6ee6800d58d573343bf6e260
<apw> Author: Krzysztof Mazur <krzysiek@podlesie.net>
<apw> Date:   Wed Mar 27 13:51:14 2013 +0100
<apw>     [libata] Fix HDIO_DRIVE_* ioctl() Linux 3.9 regression
<apw>     
<apw> !kernel compile
<ubot2`> Factoid 'kernel compile' not found
<apw> !compile
<ubot2`> Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first). Also read !checkinstall
<jibel> rtg, results of dkms tests on 3.11.0-0.1 http://10.98.0.1:8080/view/DKMS/view/Saucy%20Release%20Kernel-Team-PPA%20-generic/
<rtg> jibel, cool, thanks
<jibel> rtg, there is no view on the public jenkins for this kernel yet, you'll need a vpn access
<rtg> jibel, right, gotta turn that on
<smb> apw, !kernelcompile
<joshhunt> i know the non-LTS kernels are only support for 9 months now, i was wondering if there's a pay service ubuntu provides to continue getting USN updates after that 9 months?
<mcs-seattle> Hi. Trying to find the right place to get plugged and get my hands dirty to support new laptops on the market (starting with mine). I am a developer.
<mcs-seattle> \QUIT
#ubuntu-kernel 2013-08-03
<ogra_> ppisati, whats that about dropping arm board support ?
<ogra_> (why dont you just leave them idle ... so people can potentially use them)
<ppisati> ogra_: because we don't need them
<ogra_> well, users might use them :)
<ppisati> ogra_: if we find someone actually using them, they can send a req to turn them on again
<ogra_> that would save them from having to roll their own
<ppisati> ogra_: we already have enough dead crap in it
<ogra_> heh, ok
<rtg> ppisati, aren't these for platforms that don't support LPAE ?
<ppisati> rtg: both of them
<rtg> ah
<ppisati> rtg: in the lpae case we just support calxeda and vexpress a15
<ppisati> rtg: for the non-lpae case, we support omap3/4, imx, calxeda and vexpress
<ppisati> if anyone is willing to support (aka test) exynos5, st, omap5, etcetc i'm happy to turn them on
 * ogra_ thinks am43xx (beaglebone) would be more intresting than omap3
<ogra_> omap5 devices are rare and hard to find
<ogra_> (was born dead after omap4 was discontinued)
<ppisati> ogra_: don;t you have an exynos5 laptop?
<ppisati> ogra_: are you willing to test a kernel?
<ogra_> yes as my main work machine with a highly hacked up GLES setup
<ppisati> ah, right
<ogra_> dont really want to risk that 
<ppisati> the GL bound...
<ogra_> yeah
<ppisati> :(
<ogra_> i would have said ask hrw, but he is all fedora now 
<ppisati> fedora?
<ogra_> EH hired him
<ogra_> *RH
 * ppisati thinks should ask to expense one and add exynos5 support to out generic multiplatform kernel
<ogra_> ++
<ogra_> you should really have a chromebook 
<ppisati> well, problem is that they were talking about a refreshment soon, so i was waiting for that to happen
<ogra_> enoxys5 + USB 3.0  + 2GB = priceless
<ppisati> ah, and i would go for a GL-less kernel :)
<ogra_> my last refreshment paid for 3 ac100s and the chromebook :)
<ogra_> (well, technically i got one ac100 for free)
<ppisati> ogra_: i mean refreshment of the chromebook line
<ogra_> ah
<ogra_> not sure if they will do an arm one again
<ppisati> http://gigaom.com/2013/05/31/new-samsung-chromebook-may-use-8-core-chip-for-power-and-performance-boost/
<ppisati> it was all over the internet
<ogra_> oh, then it must be true :)
<ppisati> LOL :)
 * ogra_ goes reading
<anon^_^> Hi, I'm sure this topic has been discussed or covered before, I can't seem to find an answer.  Has the kernel team considered including BFQ in a kernel package? possibly in linux-lowlatency?
<infinity> anon^_^: We build in all the mainline schedulers.  There's not much interested in pulling in out-of-tree ones, AFAIK.
<anon^_^> inifinity, the main reason I brought it up is there are still some desktop responsiveness issues with deadline and multi-tasking
<anon^_^> specifically when initiating and maintaining sustained file transfers
<anon^_^> BFQ seems to handle those scenarios well and could be more suitable for desktop use
<anon^_^> including BFQ (but not set as default), would at least allow users to switch schedulers and still maintain the use of ubuntu kernel in repo
<infinity> Convincing zequence to pull it into lowlatency might be an easier sell.  Still, maintaining out-of-tree patches can be a pain, especially if we want to move befre BFQ upstream does (he doesn't seem to release patches against RC kernels, for instance)
<infinity> Honestly, the best answer for everyone is, instead of evangelizing how awesome it is for years, and asking distros to carry it as a patch, get it cleaned up and in mainline.
<anon^_^> Unfortunately, my magic wand can't make that happen, but I can petition the ubuntu kernel team
<infinity> You could also petition upstream.  Just sayin'.
#ubuntu-kernel 2013-08-04
<penguin42> where does the debian/scripts/misc/kernelconfig file come from - or more specifically where to report a trivial bug in it?    It's Usage: info is wrong
<penguin42> there's a lot of ARM device drivers built on the x86 kernel builds
#ubuntu-kernel 2014-07-28
<Joe_CoT> So unless I'm missing something, the TSC Zen bug that was fixed in 12.04 got reintroduced somehow in 14.04. I'm having dmesg time jumps of 7000000 seconds. How would I go about getting that fixed?
<Joe_CoT> Forum post here: http://ubuntuforums.org/showthread.php?t=2236742
<bjf> Joe_CoT, please file a bug on the problem and then come back here and tell us what the bug# is. if it asks you for logs, just ignore it.
<Joe_CoT> So my question is that it looks like it falls under this bug, which is "fix released": https://bugs.launchpad.net/ubuntu/+source/linux/+bug/727459 Do I open a new one?
<ubot5> Launchpad bug 727459 in linux (Ubuntu Lucid) "TSC is not reliable under Xen on some Intel CPUs" [Medium,Triaged]
<bjf> Joe_CoT, it *does* seem like the same bug
<Joe_CoT> yeah. So I'm not sure if that bug should be reopened somehow, or if I should post a new one, or what. Or how I'd check whether the code change is already in this version of the kernel
<bjf> Joe_CoT, let me "reopen" it ... one sec.
<bjf> Joe_CoT, i've added a "trusty" task for it. can you please add a comment to the bug that indicates the problem is back?
<bjf> Joe_CoT, subscribe to it and if you get asked to test a kernel with a possible fix, try to test. that helps a lot.
<bjf> smb, bug 727459
<ubot5> bug 727459 in linux (Ubuntu Lucid) "TSC is not reliable under Xen on some Intel CPUs" [Medium,Triaged] https://launchpad.net/bugs/727459
<Joe_CoT> Thanks very much for the help!
<bjf> Joe_CoT, np
<bjf> Joe_CoT, we'll need to know what version of trusty you are running. a full dmesg might be nice, otherwise a uname -a
<Joe_CoT> OK, I've attached the full dmesg
<bjf> Joe_CoT, that kernel is an older one. can you try a newer kernel? 
<bjf> Joe_CoT, 3.13.0-32.57 is in -updates
<Joe_CoT> heh. The problem is that if I restart the server, it'll be a crap shoot as to whether it happens again
<Joe_CoT> I'll try it and post if it happens. If it doesn't I guess I'll rebase my AMI to the new kernel so I'll see it next time
<bjf> Joe_CoT, well, there's a chance that it's been fixed. if you don't test, we'll never know.
<Joe_CoT> well hopefully it happens immediately again. If not it might be a while before I know if it worked
<bjf> ack
<bjf> "hopefully" it never happens again :-)
<Joe_CoT> bjf, happens on the new kernel too. Updated
<bjf> Joe_CoT, cool, thanks for the test
<Joe_CoT> This also brings up another fun topic: the reason I was running the old kernel is that, apparently in 14.04, it asks you if you want to use the package maintainers menu.lst. The difference between the local one and the package maintainer's one? Loading the kernel that just got installed. So if you choose the default, keep the current installed one, the new kernels are just never loaded.
<bjf> Joe_CoT, that seems non-intuitive
<Joe_CoT> I'm aware. So I haven't been loading kernel security updates for a while it seems
#ubuntu-kernel 2014-07-29
<pwaller> Hi Folks, I just hit this kernel bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
<ubot5> Launchpad bug 1349711 in linux (Ubuntu) "Machine lockup in btrfs-transaction" [Undecided,Incomplete]
<pwaller> The advise of the BTRFS developers is to update to 3.15 or above
<pwaller> s/advise/advice/
<pwaller> I tried adding https://launchpad.net/~kernel-ppa/ppa and/or https://launchpad.net/~kernel-ppa/pre-proposed to my trusty system, but both resulted in 404 when doing `apt-get update`
<pwaller> What is a good way to get a more recent kernel on 14.04?
<apw> pwaller, that isn't exactly the most helpful advice
<pwaller> apw: ah. Any better suggestions?
<apw> well they could suggest a fix instead of a blanket upgrade to a newer kernel
<apw> when utopic releases tehre will be a 3.16 kernel available in 14.04 but that is not yet ready for production use, nor available in 14.04
<pwaller> hm, OK.
<pwaller> apw: It was advice from a random on IRC, and I suppose they were trying to help me hit the ground running again.
<pwaller> apw: can you think of any ways I can help the bug along or is it best to sit on my hands for now?
<apw> pwaller, are you seeing any ill effects or only these warnings
<pwaller> apw: I've determined that these are warnings
<pwaller> apw: they all appear to be relating to caches which can be discarded
<pwaller> (according to notes found on mailing lists and the advice from #btrfs)
<apw> yeah that appears to match my understanding, i don't expect any of these to stop things working
<apw> the soft lockups all clear before 46s or whatever the second check is
<pwaller> apw: a cursory check suggests things are working
<pwaller> apw: I can't parse your last statement
<pwaller> apw: the soft lockups are happening after >48h running
<apw> the softlockup warnings all say 22/23s which indicates they did not continue to be locked up, they resolved each individual lockup
<pwaller> ah! I misread that.
<apw> those are serious when they say like 23s, 46s, 90s, 200s, ...
<pwaller> gotcha.
<pwaller> Except that it is preventing the machine from being useful
<pwaller> but I get what you mean.
<apw> ok so there are ill effects, whci are ?
<pwaller> apw: http and ssh stop responding
<pwaller> apw: my interim "fix" was going to be to configure a watchdog which rebooted the system, but maybe that wouldn't work
<xnox> depends on the workload and how full the fs is. Do you rebalance regularly?
<pwaller> apw: I guess the BTRFS FS wasn't accepting writes.
<pwaller> xnox: stupid question from me: do I need to rebalance if it just on one block device?
<pwaller> xnox: FS is 87% full
<apw> hmmm, i don't think those warnings are necessarily even related.  but anyhow, you should cirtainly file a bug against linux if its getting hung up
<apw> and we can suggest some debug kernels to try etc and see if we can figure out if it is fixed in later versions
<pwaller> apw: on the kernel tracker?
<apw> on launchpad, run "ubuntu-bug linux"
<pwaller> apw: the link above is on launchpad
<pwaller> Oops, no it isn't!
<pwaller> Oh, yes - the link I sent is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
<ubot5> Launchpad bug 1349711 in linux (Ubuntu) "Machine lockup in btrfs-transaction" [Undecided,Incomplete]
<pwaller> apw: so I did already file one there
<apw> ok as btrfs upstream are suggesting v3.15 I would first suggest you test with a v3.15 mainline kernel;
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<apw> though these are manual installs and do not upgrade automatically; so they are only useful for testing
<pwaller> ah, I missed the /mainline of ~kernel-ppa
<apw> if that works try v3.14, if it does not try v3.16-rc7
<apw> and report that back to the bug, if that shows it is fixed somewhere already we can start a bisect for the fix
<pwaller> apw: it's a bit difficult to bisect if it isn't triggerable, isn't it?
<apw> very much so, sadly
<apw> but if we have a bracket, we could at least look at the btrfs changes and see if anything "sticks out"
<pwaller> okay
<pwaller> apw: we reached more than 12 days uptime before the last problem I think
<pwaller> so it is going to be difficult to observe
<pwaller> apw: woah. Just looked in the nginx log
<pwaller> apw: which is not on the BTRFS drive - it's full of null characters at the point of the fault
<pwaller> There are ~2280 null characters
<pwaller> apw: and indeed there were no HTTP requests serviced for the duration of the fault (whilst the kernel was reporting 20s soft lockups)
<pwaller> afk for lunch, back in <1h.
<pwaller> back
<pwaller> Does anyone how I can run apport-collect but check that the output doesn't contain company secrets?
<pwaller> Does anyone know where /dev/watchdog comes from? My reading is that it should be there by standard, but I can't find it
<pwaller> Ah, have to load softdog
<bjf> smb, did you see that bug 727459 seems to have come back for a user?
<ubot5> bug 727459 in linux (Ubuntu Lucid) "TSC is not reliable under Xen on some Intel CPUs" [Medium,Triaged] https://launchpad.net/bugs/727459
<smb> bjf, I saw some updates to the bug but have not gotten to that, yet
<smb> bjf, I am very doubtful this is just the same bug, so I asked to open a new report
<bjf> smb, ack
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<Joe_CoT> bjf, unless I'm missing something, think your automated script might be faulty https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349883 It asked me to run apport to collect logs because logs were missing, but the logs apport attached were the same as ubuntu-bug attached in the first place. Is there some log that apport didn't pick up it should've?
<ubot5> Launchpad bug 1349883 in linux (Ubuntu) "dmesg time wildly incorrect on paravirtual EC2 instances." [Undecided,Confirmed]
<pwaller> How do I specify that a kernel module should be loaded? Is it via /etc/modules? Is there a /etc/modules.d equivalent or do I have to edit that one file?
<smb> Joe_CoT, Maybe the bot acts too quickly. Seems like status changed by apport right after
<pwaller> (I want to make a salt state which causes a module to be updated on boot so I don't particularly want to mess with /etc/modules)
<smb> Its now confirmed so it should be ok.
<Joe_CoT> smb, I think the issue is probably that ubuntu-bug collects the same logs, but doesn't set the tag apport-collected, which the bot cues off of
<smb> Joe_CoT, That tag seemed to be there by the time I looked. 
<Joe_CoT> 10:53 I put the bug in with ubuntu-bug, which had all the logs attached. 11:00 the bot replied, saying the logs were missing, and to run apport-collect. 11:10 I ran apport-collect, which attached the same logs, but added the tag apport-collected
<Joe_CoT> apport-bug was already there, apport-collected was not
<smb> Hm, ok. bjf, so I am not sure why this happened ^. 
<smb> Joe_CoT, Anyway I am looking into it
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 12th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<_`_> wait that was it, jsalisbury ?
<ppisati> rtg: git://kernel.ubuntu.com/ppisati/ubuntu-embedded.git
<ppisati> rtg: i'm still working on it, so it's pretty rought right now
<ppisati> rtg: but it works
<ppisati> rtg: for your mirabox board run as:
<ppisati> rtg: sudo ./make_img.sh -b mirabox -d 14.10
<ppisati> rtg: dd the .img file that it creates to an sd, pop in in your mirabox and follow the instruction in "mirabox-uboot-env.txt"
<rtg> ppisati, I'll give it a run
<hallyn> 3.13 most certainly did not resolve the btrfs sync performance issues :)
<hallyn> uh, :(
<cantstanya> lol
<dannf> kamal: i'm seeing a build regression w/ trusty master-next that i've bisected to a 3.13.11.5 patch
<dannf> kamal: is there a 3.13.11.y git tree i could use to demonstrate whether or not it is a problem outside of ubuntu?
<kamal> dannf, http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
<kamal> dannf, what's the problem patch?
<dannf> kamal: a ptrace patch - see my e-mail to kernel-team@
<dannf> kamal: not at all an obvious problem (at least to me), i haven't debugged it yet
<dannf> macro fun no doubt
<kamal> dannf, yeah, its not clear why that patch would cause that build failure
<kamal> dannf, so yeah, if you can (or can't) reproduce the failure with that 3.13.y stable repo, that would be interesting to know
<kamal> dannf, and/or I can try to reproduce it -- what config are you using? -- fwiw, I didn't see any build failure with the few ARM configs I test (tegra, omap2plus, imx_v6_v7).
<dannf> yeah, weird, can't reproduce with pristine
<dannf> but bisecting definitely led to that one, then going back to top of trusty master-next and reverting continued to show that it was the breaker
#ubuntu-kernel 2014-07-30
<kamal> dannf, remind me about this tomorrow and I'll help poke it if you like
<Joe_CoT> smb, were you able to replicate  #1349883 ?
<apw> bug #1349883
<ubot5> bug 1349883 in linux (Ubuntu) "dmesg time wildly incorrect on paravirtual EC2 instances." [Medium,Confirmed] https://launchpad.net/bugs/1349883
<smb> Joe_CoT, No, not locally and not on the few ec2 m1.small I started up. One of those ended up on an AMD, the other on some Intel but even with a few reboots the times in dmesg were ok
<Joe_CoT> ok. would it be helpful if I reproduced it on a clean instance and gave you ssh access to it?
<smb> Hm, maybe... give me a sec (or a few minutes) Thenn I try to see whether I can do what I am thinking of on a local instance
<Joe_CoT> ok
<smb> hrm, could be some minutes more... only getting around 300K/s for the ddebs... 
<smb> Joe_CoT, So I am not really sure it would help. Though I can have peeks at the vpcu time info, I suspect it would only show a high system time (which we already know) and the general progress of time. From what I get from the data we have, this is a one time badness only. Meaning from that point at boot when it jumps, it increments normally
<Joe_CoT> yes
<Joe_CoT> but once it boots once badly, it consistently reboots badly
<Joe_CoT> again, I think it's the specific hardware it runs on.
<Joe_CoT> if I give you a bad one, when you reboot it it'll still be bad
<smb> That could be one additional part of circumstances, yes
<Joe_CoT> I'm busy deploying a new code release, but after that I'll see if I can give you a clean instance where it's happening
<smb> Ok, yeah. I need a bit more time to get my head around the code anyway. 
<slangasek> jsalisbury: so I'm having a terrible time with my KVM host box all of a sudden becoming very unstable, and kernel panicking left and right.  I'm concerned that it might be hardware flakiness, because the panics don't seem to all be in the same place.  Do you have any advice for me before I start hand-transcribing kernel oopses into LP?
<jsalisbury> slangasek, I guess the first thing to check, did anything change?  Did you apply any updates or upgrade the kernel?
<jsalisbury> slangasek, It might be good to try an older kernel, that was known to work and see if the panic persists or goes away, that might indicate if a software change caused this.
<slangasek> jsalisbury: I previously had 3.11.0-26 installed, which is when I first saw a crash; then I upgraded the host to trusty in response to this, and am now running 3.13.0-32 which is definitely crashy
<slangasek> jsalisbury: prior to that I was running on the saucy kernel for a long long time
<jsalisbury> Can you test a Saucy kernel to see if the panic stops?  I can post a link to one, if you don't have one installed already.
<jsalisbury> slangasek, If the panic persists, then it might indicate hardware.  If it goes away, we should did deeper.
<jsalisbury> s/did/dig/
<kirkland> howdy!  the 3.13.0-32-generic update is rendering my Intel NUCs unbootable
<jsalisbury> kirkland, uh oh.  Do you get a panic, or blank screen, or something else?
<kirkland> jsalisbury: hung on the ubuntu splash screen;  never makes it into the desktop
<kirkland> jsalisbury: note that this only happens on a cold boot (warm reboots seem to work fine)
<kirkland> jsalisbury: and downgrading back to the -24-generic kernel also seems to work fine
<slangasek> jsalisbury: I still have the saucy kernel to hand, I'll reboot and see
<jsalisbury> kirkland, can you turn on the screen to get further debugging?  I think you just need to remove quiet and splash from GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub
<jsalisbury> kirkland, and see if anything is printed.
<kirkland> jsalisbury: done;  powering down then booting again
<jsalisbury> kirkland, just don't forget to run update-grub too
<kirkland> jsalisbury: okay, I have call traces now
<kirkland> jsalisbury: pictures from my phone
<kirkland> jsalisbury: looks like its http://support.sundtek.com/index.php/topic,1600.0.html
<jsalisbury> kirkland, cool, that should help.
<jsalisbury> kirkland, looks like the bug is upstream as well.   I'm reading through the forum posts and upstream bug report.  
<jsalisbury> kirkland, We probably pulled in the offending commit as part or upstream updates.
<kirkland> jsalisbury: okay -- is there a fix upstream yet for the offending commit?
<jsalisbury> kirkland, I see a test patch in the upstream bug report.  I guess it might be worth while to test the latest mainline kernel, in case it's being worked from someone else too.  It can be downloaded from: 
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc7-utopic/
<jsalisbury> kirkland, The -24-generic kernel was based off of upstream 3.13.9, so we can also bisect from that version on, if mainline still exhibits the bug.
<kirkland> jsalisbury: seems I do not trigger the bug, if I unplug my usb keyboard when booting
<jsalisbury> kirkland, It appears to be xhci related and there were a few changes I can look at closer.  
<jsalisbury> kirkland, I'll build a test kernel with some of the xhci changes reverted to see if we can narrow down the cause and not have to bisect.  I'll post a link in a bit.
<jsalisbury> kirkland, just to confirm, the mainline kernel still has the bug, if you leave the keyboard connected while booting?
<slangasek> jsalisbury: so, the saucy kernel just crashed for me again.  Interestingly, while on trusty the crashes seem to be more varied, this saucy crash is the same or similar to the last saucy crash I saw, which is ksm-related
<jsalisbury> slangasek, Hmm, and you used a kernel that never paniced before?  It might be worth while to run a memory test real quick on the machine.  Any type of HW related errors in the syslog?
<slangasek> nothing hw-y in the syslog, no; and it never panicked before earlier this month, around the time the weather turned hot ;P
<jsalisbury> slangasek, heh, blame the weather
<slangasek> jsalisbury: the problem has persisted when the weather got better :)
<jsalisbury> slangasek, speaking of weather, does the syslog have any mention of temp readings?
<jsalisbury> slangasek, Just shut the window, lol
<slangasek> wat
<slangasek> shutting the window is what makes the room hot! :)
<jsalisbury> slangasek, whoops, figured keeping the rain off might help :-)
<slangasek> jsalisbury: what would I search for to find temp readings? 'temp' doesn't find anything useful
<jsalisbury> slangasek, you would find something like this: " Core temperature above threshold"
<jsalisbury> or "Core temperature/speed normal"
<slangasek> jsalisbury: nada
<jsalisbury> slangasek, maybe the logs rolled and the temps been ok.  Maybe grep the /sys/log directory
<slangasek> jsalisbury: did that already
<TJ-> slangasek: I've found lm-sensors and the 'sensors' util good for monitoring, or simply "cat /sys/class/thermal/thermal_zone*/temp"
<jsalisbury> slangasek, Hard to know if it is HW releated if there are no errors.  Can you post a picture of the crashes
<slangasek> jsalisbury: the fact that the backtraces are varied makes that more difficult.  If I get the same ksm crash on saucy again, perhaps I'll take a picture - but saucy is EOL so that hardly helps for getting it fixed
<slangasek> and in trusty the backtraces are all over the map
<kirkland> jsalisbury: do we have a Launchpad bug for this yet?
<kirkland> jsalisbury: do you want me to file one?
<jsalisbury> kirkland, That would be great
<slangasek> jsalisbury: memory test> I don't think we have a memtest that works on UEFI-only systems, do we
<jsalisbury> slangasek, hmm, I don't know off hand.  Can you not selecet it from the GRUB menu?
<slangasek> nope
<slangasek> memtest86+ has grub code that specifically says it doesn't work on UEFI
<jsalisbury> slangasek, Ahh, ok.
<slangasek> /etc/grub.d/20_memtest86+: 
<slangasek> # We need 16-bit boot, which isn't available on EFI.
<slangasek> if [ -d /sys/firmware/efi ]; then
<slangasek>   exit 0
<slangasek> fi
<jsalisbury> slangasek, It makes it difficult that the backtraces are not consistent.  Do you have to put some load on the machine, or does just booting and waiting trigger it?
<mjg59> memtest is difficult with UEFI
<mjg59> Because the firmware is using so much more of the memory
<slangasek> jsalisbury: the "load" appears to be nothing more than having VMs configured to start at boot
<mjg59> You'd probably need something that did ExitBootServices() and then ignored the runtime regions
<mjg59> And hoped that there was no periodic SMM code using them
 * slangasek nods to mjg59
<slangasek> and writing that is out of scope for my current problem ;)
<jsalisbury> slangasek, to see if it is HW releated, can you try to boot a LiveCD and see if you can get a crash again.  That would rule out anything configuration wise.
<slangasek> jsalisbury: not conveniently, but I'll put that on my list of things to try
<jsalisbury> slangasek, ok
<jsalisbury> kirkland, Can you try the test kernel here: http://kernel.ubuntu.com/~jsalisbury/kirkland/
<kirkland> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350480
<ubot5> Launchpad bug 1350480 in linux (Ubuntu) "[REGRESSION] Kernel update renders Intel NUC (i5-3427) unbootable with USB devices plugged in" [Undecided,New]
<jsalisbury> kirkland, That has four out of the five xhci commits added after 3.13.9 reverted.
<jsalisbury> kirkland, The fifth didn't revert without a backport, so I'll revert that one if the bug still exists with v1 of this test kernel.
<kirkland> jsalisbury: installing now
<jsalisbury> kirkland, this one needs the linux-image-extra package as well as linux-image
<kirkland> jsalisbury: k
<kirkland> jsalisbury: I'm just trying to apport-collect before I reboot
<jsalisbury> kirkland, ack
<kirkland> jsalisbury: rebooting
<kirkland> jsalisbury: Linux OrangeBox01 3.13.0-33-generic #58~DustinTestKernelv1 SMP Wed Jul 30 17:40:39 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<kirkland> jsalisbury: booted just fine ;-)
<jsalisbury> kirkland, Hmm, cool.  So that means with was one of these four commits:
<jsalisbury> 7ba40e8 xhci: delete endpoints from bandwidth list before freeing whole device
<jsalisbury> 8172925 usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
<jsalisbury> 00bd7b9 xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
<jsalisbury> c349a2e xhci: Prevent runtime pm from autosuspending during initialization
<jsalisbury> kirkland, I'll try to revert only two of them and see if we can narrow it down.
<Joe_CoT> smb, I was able to reproduce it right away. Can you toss me your public ssh key, and preferably your IP, and I'll give you access?
<Joe_CoT> For reference, it was m1.small, in us-east-1c, off the latest Ubuntu 14.04 PV SSD AMI, straight off
<smb> Joe_CoT, You should be able to use "ssh-import-id smb" for that
<Joe_CoT> nifty
<smb> So in theory I should be able to get there if you pm me the external host name
<Joe_CoT> yeah, give me a minute and I'll have you set up
<Joe_CoT> smb, all set. PMed. You have full reign of that server. Just lmk when you're done with it
<smb> ack
<Joe_CoT> smb, that server has ssh allowed in, http and https allowed out. LMK if you need more than that. You can reboot it as many times as you want, but please don't shut it down, as the problem may go away if they switch hardware on me.
<smb> Joe_CoT, Ok, sure. 
<jsalisbury> kirkland, the second test kernel is ready at: kernel.ubuntu.com/~jsalisbury/kirkland/
<jsalisbury> kirkland, if my guess is right, this kernel should still have the bug.
<jsalisbury> kirkland, I think the bug is going to be caused by: 
<jsalisbury> 8172925 usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
<jsalisbury> kirkland, I'll start building a third test kernel with just commit  8172925 reverted.
<kirkland> jsalisbury: testing that 2nd one now
<jsalisbury> kirkland, ack
<kirkland> jsalisbury: Linux OrangeBox01 3.13.0-33-generic #58~lp1350480v2 SMP Wed Jul 30 18:25:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<kirkland> jsalisbury: hang on
<kirkland> jsalisbury: let me do a hard power down, and up
<jsalisbury> kirkland, ok.  I expect it may have the bug
<kirkland> jsalisbury: yeah, sorry, that previous warm boot worked fine;  it's cold boots that suffer
<jsalisbury> kirkland, good :-)
<jsalisbury> kirkland, A 3rd kernel is building now with only commit 8172925 reverted.  I expect it will be the fix
<kirkland> jsalisbury: boom
<kirkland> jsalisbury: explosions in the sky
<jsalisbury> kirkland, I'm already crafting an email to the patch author.  In the mean time, we can request a revert upstream and in Ubuntu, once we verify it's that commit.
<jsalisbury> kirkland, build should be done in a few minutes
<kirkland> jsalisbury: okay, I'm ready and waiting :-)
<jsalisbury> kirkland, The kernel is ready at: kernel.ubuntu.com/~jsalisbury/kirkland/
<jsalisbury> kirkland, If it fixes the bug, I'll fire off some email to have it reverted
<kirkland> jsalisbury: k
<kirkland> jsalisbury: v3 boots fine (cold + warm boot)
<kirkland> jsalisbury: Linux OrangeBox01 3.13.0-33-generic #58~lp1350480OnlyCommit8172925Reverted SMP Wed Jul 30 18:56:31 U x86_64 x86_64 x86_64 GNU/Linux
<jsalisbury> kirkland, great.  I'll send email upstram and cc you.  I'll also request that this gets reverted in the Ubuntu kernel
<kirkland> jsalisbury: fantastic, thanks for this :-)
<jsalisbury> kirkland, np
<smb> Joe_CoT, So I would be off the machine for today.  I extracted some data. Interesting that most time info actually is correct. Like uptime and even the formatted time in /var/log/syslog. Just the seconds in the timestamp are off. Also interesting that while the timestamp in dmesg on my local system is correct, the vcpu_info time actually is the uptime of the host. Apparently that gets corrected by the delta (of tsc 
<smb> timestamp in the same struct and result of readtsc)
<smb> While on that host it seems to be the same
<smb> So looks a bit like the correction delta goes wrong and you end up having the hosts uptime in dmesg
<Joe_CoT> the formatted time in syslog is correct, when using rsyslog. When using syslog-ng, it ends up with logs in october
<Joe_CoT> because it's using the time from kmsg
<Joe_CoT> but when I reported I brought it down to the core problem, which is the dmesg timestamp
<Joe_CoT> If you're done for the day I'll turn it off then. If you need it again lmk. I'll try to be in the channel when I'm in the office, if I disappear give me a poke on the bug or by email.
<smb> Probably syslog-ng does its own calculation in some way. Just some additional fact. I mean the main issue is as you pointed out, the dmesg timestamp being wrong
<Joe_CoT> I think that syslog-ng does: current time - uptime + dmesg time. Which is why it's getting dates in the future
<smb> Sounds reasonable. Basically offset by the hosts uptime
<smb> and not the guests
<Joe_CoT> And if you do dmesg -T you'll see the same then
<Joe_CoT> yeah
<Joe_CoT> /proc/uptime ends up with the guest uptime, but /dev/kmsg is using timestamps based on the host uptime
<smb> Since the field containing the system time is the uptime of the host in both cases, there must be somethign wrong with how the delta is used. But I won't have enough brain for that to figure out right now. 
<smb> Oh when I say host I meant the host running the guest
<smb> And we probably are on the same page and I am just too dumb by now. :)
<Joe_CoT> lol, ok
<Joe_CoT> well if you need back on the server later, lmk. I'm just hoping to have this fixed before I've got PCI auditors rolling through. Don't really want to explain how our servers went back to the future :D
<smb> Heh ok, will do. You may always claim they run ahead of time to spot problems sooner. :-P
<Joe_CoT> For now I just changed syslog-ng to ignore the time from the kmsg logs. It means that on server startup the entire startup shows up in the logs as the same second. That's better than October.
<smb> True... unless it is October, though then it would be likely next year in the logs...
<smb> Btw, I write up some summary and will post it to the bug report
<bjf> slangasek, bug 1350035 is preventing any automated testing of Utopic by either CI or the kernel team
<ubot5> bug 1350035 in debian-installer (Ubuntu) "Debootstrap warning; Warning: Failure while configuring required packages." [Undecided,Confirmed] https://launchpad.net/bugs/1350035
<xnox> slangasek: bjf: i believe dropping essential:yes from init metapackage would fix it. Which i have done 10h ago, but it's stuck in utopic-proposed because of the alpha2 freeze block. And debootstrap doesn't know how to use overlay repositories, so we need to wait till tomorrow for block to drop, init to migrate and try again.
<xnox> updated bug report.
<bjf> xnox, many thanks for that update
#ubuntu-kernel 2014-07-31
<slangasek> xnox: if this is blocking anything we should override the milestone freeze, not let ourselves be blocked by it
<xnox> slangasek: i'm blindly test rebuilding stuff against llvm 3.5 =) if you wish, you can unblock it and then i'd test it when it propagates. All other autopackage tests passed so yeah freeze block is the only one.
<xnox> slangasek: but it's like on all images, thus it is respin the world trigger =/
<slangasek> xnox: no, it is not
<slangasek> xnox: we do *not* guarantee images are up-to-date with respect to the archive during alpha milestones
<vroomfondel> I am just jumping a bit through the kernel source at lxr.free-electrons.com... the container_of macro (which is a heavy-use macro) is defined in 10 files. Are there many redundancies like this one?
<TJ-> vroomfondel: The drivers/staging/ are probably because those drivers haven't been cleaned up yet after being out-of-tree, for the tools/ and scripts/ those are for separate compilation units, which leaves the gpu/radeon and include/linux to explain :)
<TJ-> vroomfondel: looking at gpu/radeon that is also a stand-alone tool ... leaving just include/linux :)
<smoser> hey. 
<smoser> http://paste.ubuntu.com/7914933/
<smoser> is this the same power woes we've seen before ? 
<rtg> smoser, doesn't look familiar to me, but its also a little sparse on details. apw ?
<smoser> rtg, well, what you see is all i know. that and "it died"
<smoser> :)
<rtg> smoser, is the bare metal ? I'm just not that familiar with P8
<rtg> is this*
<smoser> its a guest.
<smoser> kvm guest.
<rtg> smoser, prolly something we need to get the IBM guys to look at
<smoser> rtg, i'll file a bug.
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350889
<ubot5> Launchpad bug 1350889 in linux (Ubuntu) "kernel crash kvm guest on power8" [Undecided,New]
<apw> yeah not something i have noticed so far 
<hallyn> apw: stgraber: on 3.16 in utopic, in a unprivileged container, all of /proc is owned by nobody:nogroup
<hallyn> dat aint gonna fly
<pwaller> I can now reliably reproduce this kernel hang with BTRFS: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
<ubot5> Launchpad bug 1349711 in linux (Ubuntu) "Machine lockup in btrfs-transaction" [High,Incomplete]
<pwaller> The machine I'm using for testing won't necessarily be around for much longer, so if there are any further immediate diagnostic things should do it would be good to know
<rtg> pwaller, can you reproduce this on bare metal ? or is it just a Xen guest issue ?
<pwaller> rtg: It's an amazon EC2 instance. I don't have bare metal available to test on. Or rather, I can't get the partition where I can reproduce it to a bare metal machine.
<pwaller> (It's 750GB)
<rtg> arges, since you're just plowing through virt issues this morning, how about having a look at this one ^^
<pwaller> I should add, my test case involves using my existing partition. I haven't tried reproducing from scratch
<pwaller> Mainly because I suspect a problem with the free space cache
<pwaller> It took 12 days before first manifesting. And then 2 hours of solid writes before I ended up in a situation where I could quickly reproduce again.
<rtg> pwaller, have you talked to upstream about it ? IIRC you said 3.16 still has the issue
<pwaller> rtg: I have mailed upstream and had no response. I've had some interest from #btrfs who suggested trying 3.16, as did the person who responded in the ubuntu bug.
 * arges looking
<arges> pwaller: so you said you can rapidly reproduce. Is that documented in the bug already (still reading)
<pwaller> Yes arges at the end
<arges> pwaller: ahh there it is : )
<arges> pwaller: so you pretty much just copy a large amount of files and get this error...
<pwaller> arges: that's basically it
<pwaller> arges: I haven't bothered trying to reproduce on a fresh BTRFS because I figure that that would be covered by other testing done to this thing
<pwaller> arges: and I'm also not sure what would constitute "interesting enough files"
<arges> pwaller: ok so at this point you can only reproduce on this specific instance. so if you created a new instance and ran your test it may not necessarily reproduce
<pwaller> arges: I reproduced it on a new instance with a snapshot of the same volume on a new EBS device
<arges> smb: ^^^ more xen fun, have you seen something like this
<smb> arges, no, nothing btrfs related which I can remember
<pwaller> arges: smb I'm migrating to the pub, but I will reappear on IRC in about 10 minutes in case you have further questions.
<arges> pwaller: ok i think on this end we'll try to digest the logs a bit
<pwaller> arges: thanks very much for looking into this :)
<arges> np
<pwaller> arges: I can also do further testing on the spot if you have more ideas for experiments.
<smb> arges, The fact it runs on ec2 may be just coincidental in this case
<arges> smb: yea i wonder if it can be reproduced in a non-ec2 xen enviornment : or ever non virt
<pwaller> I'm back arges/smb
<arges> pwaller: so has this happened with other btrfs volumes you've used?
<pwaller> arges: I've only observed this on this one filesystem (but copied the filesystem to another device and observed it there too)
<pwaller> We're running 5 systems which are configured the same, but only one other has a similar workload
<arges> pwaller: how did you copy the filesystem?
<pwaller> arges: EC2 snapshot restore to new volume
<pwaller> Even on the original system we haven't observed the crash since we upgraded kernel from 3.13 to 3.15
<pwaller> (which is now at 2 days 1h uptime)
<pwaller> but the workloads aren't very steady.
<arges> pwaller: but a copy of ~400GB of small files seems to cause the soft lockups
<smb> Though from the logs we see it is less of a crash than a lockup
<pwaller> arges it's probably more like ~275GB maximum
<pwaller> arges: I started copying all 275GB, and 2h in to the ~6 hour operation, it locked up. I then resumed from the point of the lockup after the reboot, and then it will reliably lockup within minutes, or even within 30 seconds sometimes.
<arges> pwaller: you resumed what exactly, and how
<pwaller> arges: the volume contains ~23,000 sqlite files of varying sizes (4kb - 12GB). I copy them all from $PATH to ${PATH}.new
<pwaller> I observe the machine hang at ${GIVEN_PATH}, and then if I choose files that are after ${GIVEN_PATH} in the list, I can rapidly reproduce the lockup
<arges> pwaller: so you observe the hang. then stop the cp process?
<arges> then resume it after teh point where it was hanging?
<pwaller> arges: the cp process hangs. If I terminate the cp process, a kernel thread is using 100% CPU
<pwaller> arges: If I leave the machine idle (except for the pinned CPU on a kernel thread) and unattended for 5-10 minutes, it locks up totally and becomes unresponsive to network traffic
<arges> ah
<pwaller> If I restart the machine and then resume the cp from the last file that was printed, it locks up fairly rapidly at that point
<pwaller> arges: one more detail: I run 2 cp's in parallel
<pwaller> arges: this is the literal command I'm running
<pwaller> cat sqlite-files.txt | xargs -n1 -I{} -P2 sudo sh -c 'rm -f {}.new; cat {} > {}.new; echo {}'
<pwaller> (then I resume with `tail -n+18082 | xargs`)
<arges> pwaller: can you been able to reproduce on a single cpu instance
<pwaller> arges: that is something I can try
<arges> 1) create around ~300GB of small files (sqlite files for example), put the files into a list sqlite-files.txt
<arges> 2) Start the copy:
<arges> cat sqlite-files.txt | xargs -n1 -I{} -P2 sudo sh -c 'rm -f {}.new; cat {} > {}.new; echo {}'
<arges> 3) When it hangs, identify where it hung as $NUM and resume with the following:
<arges> tail -n+$NUM | xargs -n1 -I{} -P2 sudo sh -c 'rm -f {}.new; cat {} > {}.new; echo {}'
<arges> pwaller: ^^^ does that sum up the test case
<smb> pwaller, where does the 87% full info actually come from? df info?
<pwaller> du -sch /volume, smb
<pwaller> arges: looks about right
<pwaller> arges: unfortunately the problem didn't manifest until 12 days of running originally
<pwaller> arges: though the write workload will not have been as pathological as what you just described
<arges> pwaller: what kind of workload were you running for those 12 days? 
<smb> pwaller, thanks... maybe try "btrfs fi df /mountpoint"
<pwaller> smb: https://gist.github.com/pwaller/ce4312f5e16147847a65
<pwaller> arges: user generated workload accessing those sqlite files for arbitrary read/writes
<arges> pwaller: have you looked at this wiki https://btrfs.wiki.kernel.org/index.php/Balance_Filters
<arges> one thing to note is 'if you are getting out of space errors' try 'btrfs balance ...' (i'm not sure if you already tried this)
<pwaller> arges: we just reproduced it on a single core machine in < 15s
<pwaller> (an AWS EC2 m3.medium
<jsalisbury> rtg, re bug 1350373, you have any idea why I can't describe commit b7dd0e in Linus' tree?  
<ubot5> bug 1350373 in linux (Ubuntu Trusty) "Kernel BUG in paravirt_enter_lazy_mmu when running as a Xen PV guest" [Medium,Triaged] https://launchpad.net/bugs/1350373
<jsalisbury> rtg jsalisbury@salisbury:~/src/linux$ git describe --contains b7dd0e350e0bd4c0fddcc9b8958342700b00b168
<jsalisbury> fatal: cannot describe 'b7dd0e350e0bd4c0fddcc9b8958342700b00b168'
<jsalisbury> rtg, am I just missing some git knowledge?
<pwaller> arges: it sprang back into life
<rtg> jsalisbury, there is likely no subsequent tag. is it after -rc7 ?
<jsalisbury> rtg, ahh, that makes sense
<pwaller> arges: probably just observed a volume warming up
<jsalisbury> rtg, so it will work in -rc8 or whenever the next tag is added
<rtg> jsalisbury, I think so
<arges> pwaller: ok so at this point test a bit with the single cpu machine. and 2) look at the wiki i mentioned, and see if 'btrfs balance ...' changes anything
<arges> its lunchtime here brb
<jsalisbury> rtg, got it, thanks
<pwaller> arges: I don't understand the rebalance thing. It's a single device volume, is rebalance even relevant if it isn't RAID?
<pwaller> smb, arges: one interesting feature of the single CPU is that at times, the write load drops to 0 during the copy but the sys cpu goes to 100%
<pwaller> which is spending ~10% in rcu_sched, 50% in kworker/u30:1 and some fraction in some btrfs processes (btrfs-transaction and btrfs-endio-met)
<smb> pwaller, It kind of would make sense with the assumption that something in the kernel desperately trying but never giving up doing something. 
<pwaller> the 100% sys load remains even after aborting the CP
<pwaller> a "sync" from the command line isn't completing
<smb> I would read the straces you posted as: the cp you do cause some background writes which are done by a kworker
<pwaller> "echo l > /proc/sysrq-trigger" causes the machine to freeze for quite a long time
<pwaller> dumping a stack trace via sysrq is considerably less interesting on the single-CPU machine, the stack just has "write_sysrq_trigger" in it
<pwaller> having said that there is another stack trace with "generic_write_sync" at the top
<pwaller> my sync is still going
<pwaller> and the CPU is still stuck in 100% sys
<smb> tbh not really surprised with that
<pwaller> arges: someone from #btrfs (I don't know their credentials) said that rebalance was unlikely to have any effect in my circumstances
<pwaller> smb: the sync finally finished after 8 minutes
<pwaller> smb: so I guess this could just be explained by a cold block store
<pwaller> the machine finally went down to 0% sys
<smb> now that is more suprising if that was a lockup
<smb> Hm... is this a case where io for some reason is slow as hell...
<pwaller> smb: well the machine was effectively unusable given that the kernel was consuming all of the CPU. I wouldn't expect that if IO was just "running a bit slow"
<pwaller> (but then I don't know if my expectations are "reasonable")
<smb> It certainly should not be that drastic. I mean the guest has around 4G of memory and sure that gets used up as cache . But it sounds a bit like the writeout was done in a polling fashion...
<pwaller> smb: "time echo l > /proc/sysrq-trigger" takes 18 seconsd
<pwaller> smb: why would that be?
<smb> Hm, cannot say for sure . maybe done in some soft-interrupt and if something prevents the cpu from processing them quickly...
<smb> no... apparently ipi but I think for xen those where using event channel(s)...
<iri-> arges: smb: I'm hitting the road so will appear/disappear from here out. Thanks for your help looking into things. If you have any further suggestions I guess I'll hear via the launchpad bug. Have a good day/evening :)
<arges> cya thanks
<iri-> I should add I'm also interested in ways to mitigate this since it affects production systems
<Joe_CoT> smb`, I see you've been busy. I showed my coworker your "I had a dream" comment
#ubuntu-kernel 2014-08-01
<smb> iri, I updated the bug report. Just to make sure, I would not be experienced enough with btrfs to claim something is good or bad right now. Just pointing out what observations I made with what we got
<iri> thanks smb, that's fine :)
<iri> smb: I left the single core machine copying overnight
<iri> https://gist.github.com/pwaller/cb8d088ebceb2707d24b
<iri> dmesg output: https://gist.github.com/pwaller/574a369ea4b65fe125b9
<iri> The first link is dstat output, which shows no IOPs and 100% kernel CPU
<iri> the second shows lockups in sync and btrfs-transaction
<smb> iri, The xen:ballon error is something that we know of but have not yet found a other effect that the messages flooding. It is something we cannot reproduce outside ec2 and I believe the bug report on that has not been updated for a while.
<iri> smb: I was assuming that error was not the root of the problem I'm experiencing
<smb> ok, yeah. just wanted to make sure. looking at the other messages right now
<smb> Hm, HVM guest. That does not need to be relevant either. Just not the normal type of guest I look at 
<smb> iri, Hm, I am getting a bit confused. from that dmesg I only see xvda1, xvdb (both pv disks) and some messages sounds like both get mounted as ext4/ext3... And then out of nowhere some device-mapper device seems to appear and have btrfs on it which btrfs recognizes as an SSD... Oh here, I missed the xvdt line. 
<iri> smb :)
<iri> smb: I attached the xvdt device after the machine booted.
<smb> So that is the one with btrfs on it. Still wondering how btrfs guesses this is a ssd... :)
<iri> smb: dark magic?
<smb> evil. :-P
<smb> So then the next stacktrace basically says background write seemed to hung in wait for completion. The sysrq trigger backtrace only shows that (probably of little use in a single cpu case)
<smb> Hm, ok so both the sync and the btrfs task seem to be in some wait_for_completion. if the stat correlates there was not a real big amount of data actually written. or read. could be (maybe more unlikely) that io requests get lost and must be retried. But in that case I would expect some messages in dmesg. Or the whole thing triggers a problem in the whole stack of guest-host-storage which unfortunately is a big blac
<smb> k box
<iri> hm :/
<smb> iri, Do you know whether you could snapshot/restore that testdata on non-ssd storage?
<iri> smb: I could give that a shot.
<smb> iri, Maybe just a blind shot but if it is possible it would give at least another pointer on how much influence the backing storage type has here....
<iri> smb: first interesting observation is that it detects the magnetic volume as an SSD anyway
<smb> iri, Ah. Oh well. So that is broken rather than clever I suppose. not expection a third type apart from real spindle and real ssd...
<iri> smb: hm. I'm getting unreasonably high read IOPS initially. 2-3000
<iri> and after 10 seconds we're now stuck in the SYS spin again
<iri> (single core machine, restored snapshot of the magnetic disk)
<smb> ok... sigh. at least consistent in that way
<iri> smb: I'm tempted to do a random write test to the block device
<iri> I don't care about what's on here since I'm only going to delete it
<smb> iri, yeah, that sounds reasonable. 
<smb> that way we get something to compare the performance of the fs against
<iri> smb: yeah. Any ideas how to pick somewhere sensible to send the writes within the block device?
<iri> smb: any ideas for anything better to write than /dev/zero? /dev/urandom gets 5.5MB/sec dd'ing to /dev/null
<iri> I fear /dev/zero may have funky behaviour, but that is just speculation
<smb> not out of my head. zeros and maybe one go just over the whole disks...
<iri> smb: I get a write rate of >2kiops immediately and looking fairly reliable.
<iri> (85MB/sec)
<iri> though to be fair this is at the beginning of the disk.
<smb> sounds like something one would expect roughly from standard sata.
<iri> I'm a bit surprised by the performance, this is more what I was expecting from an SSD volume
<iri> hm, I wonder if it is possible I have confused things.
<iri> oops. I think I did my test against the SSD.
<iri> I instructed the SSD to detach but it did not
<iri> smb: I picked numerous locations and did this: time sudo dd if=/dev/zero of=/dev/mapper/vg-lv bs=16k count=1M skip=400G
<iri> they all showed the expected SSD-like performance with >2kiops
<iri> I'm now going to try the magnetic disk file copy test
<smb> Probably should have said bare-metal spindle ... thought that was a numeber I see there for sequential writes... 
<smb> ok...
<smb> One thing just came to my mind... when the btrfs fs was created earlier with maybe another underlying disk... mybe worth checking what minimum blocksize is used. Though I have not yet found which command to use
<smb> Oh here, btrfs-show-super <dev>
<iri> smb: https://gist.github.com/pwaller/ea0386762852a9bf5462
<smb> ok, so sector size 4k. should be ok
<iri> smb: the rate is a *lot* slower on the magnetic disks so it will be a while before the caches are totally full.
<iri> smb: the initial behaviour I'm observing is ~100 IOPS read (max of 5mbs/sec), 0-2 write (max of 10k/sec), 100% iowait.
<iri> That's for ~5 minutes
<iri> I initiated a sync but that hasn't changed the write traffic situation
<smb> Hm, ok. sounds pretty slow somehow
<iri> smb: I suspect this is just a cold ebs which is not responsive to write traffic
<iri> I see a kworker and a btrfs-transaction kernel thread stuck in the "D" state
<iri> along with the sync and cat
<iri> smb: I'm going to go afk for ~1h, back in a bit.
<smb> ok.
<iri> smb: write load has finally warmed up to peaks of 10mb/sec @ 230 IOPs. Doesn't look like a stuck system. There are bursts of 50% SYS CPU about once per minute.
<iri> smb: I wonder if we're observing some inefficient algorithm in btrfs which goes horribly wrong when the IOPs are an order of magnitude higher
<iri> Ah, the sys bursts are getting lnoer and more frequent
<smb> iri, yeah that performance looks ok, not thrilling but ok. not sure obout a certain algorithm. rather something that causes the host side prerform badly. but not a lear idea atm
<iri> smb: the system now is stuck in 100% system CPU
<iri> (on the magnetic disk)
<smb> unfortunately we cannot see what goes on on the host.
<iri> There is still some IO traffic though, 2mb/sec @ 20iops and 1.5mb/sec @ 30 iops
<iri> 42% kworker/u30:1 load, 10% rcu_shed, <10% across several btrfs-endio threads
<iri> smb: it spent 13 minutes in 100% sys, then spending ~1 minute in 100% iowait, then back to 100% sys
<iri> and now back to iowait for five minutes
<iri> smb: curiously, it's the `rm` which is blocking for > 120s
<iri> (from dmesg)
<smb> sounds a bit like pushing hard and waiting for things to happen. could by causeing some form of sync..
<iri> ('cause I'm running `sh -c 'rm -f {}.new; cat {} > {}.new'`)
<iri> the iops are going low but not staying at zero for longer than a minute at a time
<iri> (*minute or two)
<smb> iri, I must admit I have no more ideas right now. Apart from trying to replicate your setup as closely as possible on bare-metal and see whether that shows similar behaviour,
<iri> smb: I might try to make a smaller testcase
<iri> smb: I'm thinking of deleting lots of files and doing a shrink
<smb> ok, if you get somethign, let us know in the bug report. That is less volatile with info than irc...
<iri> sure.
<iri> smb: are you still attempting to reproduce anything on your end or are you done at this point?
<smb> iri, I and/or arges will try to get something up just a matter of multi-tasking various things
<iri> great.
<iri> smb: is there a way to know the IO queue length to the underlying block device or anything like that?
<smb> iri, its not exactly the block device but there is some info under /sys/kernel/debug/bdi (backing device info) It is a bit tedious to use as its split into directories named after major:minor number.
<smb> Also only per whole block device usually, so not per partitions. But it could give some insight into various levels of the stack. You might have xvdt->dm-x->btrfs-x...
<iri> smb: I so no difference in what's in there whether it is stuck in "sys" or "iowait"
<iri> nor whether there are 100 IOPS or 0
<iri> smb: https://gist.github.com/pwaller/762f57f330cf8a5193ae shows the disk at the top and the lvm volume below
<iri> The DirtyThresh and BackgroundThresh vary a small amount
<iri> and I did see the disk go into state "c"
<iri> hmm, the lv state always seems to be "8" and the disk state flips between a few things, I've seen it read a/c/e/8
<smb> iri, I would need to look up in the code what that even means. But not having anything in writeback sounds like it might be without influence on the writeback code which kind of would be good as that takes away some things to worry about
<iri> I found the bits for state. 8 is BDI_registered, a is BDI_registered | BDI_async_congested and e is `a | BDI_sync_congested`
<iri> the majority of the time is spent in 'a'
<iri> so now I'm in an interesting case on the SSD machine where the device state is "8" (i.e, idle) but the kernel is using a whole CPU for a kworker
<smb> not sure but maybe installing perf-tools and watch perf top would help to get some hint.
<smb> I might be afk for a bit (or a bit longer) 
<iri> smb: a nice idea
<iri> smb: do you know where I can get linux-tools-3.16.0-031600rc7-generic / linux-cloud-tools-3.16.0-031600rc7-generic for perf?
<iri> (the packages)
#ubuntu-kernel 2014-08-03
<nobled> hey, https://wiki.ubuntu.com/Kernel/LTSEnablementStack says "Apport has and will be updated to allow bug reporting in Precise against the enablement stacks. These bugs will also be appropriately tagged to assist in searching."
<nobled> what are the tags for hwe bugs?
<apw> nobled, so i belive the tag you are looking for is qa-kernel-lts-testing
#ubuntu-kernel 2015-07-27
<sforshee> apw: did you see the chatter from friday about overlayfs and lxc?
<apw> sforshee, hmmm
<sforshee> apw: tl;dr is that in wily, overlayfs fstype is mountable in a user namespace but the overlay fstype is not
<apw> oh heh, that i could believe, and it would be broken
<apw> sforshee, is there a bug for that ?
<sforshee> apw: not sure. hallyn?
<apw> whever that was discussed it was not here
<sforshee> apw: lxc is trying to mount it as overlay if that shows up in /proc/filesystems, so it fails and that's a regression
<apw> yep, i am sure we failed to apply the overlayfs fix to allow user mounts to overlay,
<sforshee> it's probably a one-line fix, but I wanted to check with you that it's an oversight and not intentional
<apw> indeed, and its an oversite
<hallyn> sforshee: apw: no i didn't open a new bug.  there are adt failures due to it, wasn't sure if that auto-opens a bug
<apw> hallyn, no i don't think it makes ssh-keygen -f "/home/apw/.ssh/ldap_known_hosts" -R togetic.buildd
<apw> h yeah thanks
<apw> hallyn, no i don't think it makes a bug directly, i assume it is lxc which is failing ?
<apw> its self tests
<sforshee> apw: yes, lxc tests are failing
<sforshee> I've got a patch, just tested it and it's working
<sforshee> so I can make a bug and send it
<apw> sforshee, ack and ack
<hallyn> thanks guys :)
<infinity> apw: Has Laney (or anyone) whined at you about the udisks2 autopkgtests OOPSing your kernel on i386?
<infinity> apw: http://paste.ubuntu.com/11947918/
<apw> not that i have heard about
<Laney> Ð½ÐµÑ
<apw> infinity, the interesting things there is the first erorr is a disk error
<infinity> apw: It's a VM, so neat trick.
<apw> yeah, that
<apw> a bug would be nice, with the how to run those tests manually
<infinity> Laney: ^
<Laney> ÐÐ°
<infinity> Laney: Are you trying to tell us that you're being held captive by someone who doesn't have proper keymaps?
<infinity> Laney: Is Timmy stuck in the well?  What is it, boy?
<Laney> XNOX GOT ME
<xnox> infinity: i demand porterbox and early alpha2 release, and Laney will be free.
<infinity> xnox: Meh.  You can keep him.
<xnox> infinity: he is safe, inside a wall climbing facility.
<Laney> Just seal the roof
<Laney> apw: bug #1478623
<ubot5> bug 1478623 in linux (Ubuntu) "Kernel oops - blk_update_request: I/O error when running udisks2 force_test_removal test" [Undecided,New] https://launchpad.net/bugs/1478623
<wyvern> Hi folks, I'm on 15.04 and I need to use a newer kernel (ideally 4.0 or 4.1) to avoid a usb bug (http://www.spinics.net/lists/linux-usb/msg123652.html). How should I go about doing that?
<apw> wyvern, there are no official newer kernels published for that release, you might use the wily kernel which is at 4.0
<apw> or is it 4.1, 
<rtg> 4.1
<wyvern> I don't use ubuntu much; how crazy is it the kernel from a different release?
<wyvern> And, assuming it's not too bad of an idea, how would I go about doing so?
<wyvern> s/is it the/is it to use the/
<apw> we tend to do it pretty often, but you don't get automatic updates that way, so its pretty manual
<wyvern> Well right now my usb devices aren't working too well so manual is better than broken :)
<apw> you can obtain the debs from the +source/linux page
<apw> https://launchpad.net/ubuntu/+source/linux
<apw> if you don't have dkms packages, then just the linux-image* and linux-image-extras* package should be sufficient
<apw> wyvern, once you find out if 4.1 helps, then it would be good to file a bug (ubuntu-bug linux) saying where its broke and where it works, as that is the starting point for finding out what fixes it
<wyvern> OK I'll see what I can do.
<unixabg> apw: Greetings, just checking in on the overlayfs things with casper. Any progress?
<apw> unixabg, sorry no, been working on some critical cves, which have consumed pretty much all my time, those went out today, so tommorrow might be better
<unixabg> apw: Sounds good and thanks for your willingness to examine the overlayfs things.
#ubuntu-kernel 2015-07-28
<caribou> I know it is a dramatically noob's question but I keep forgetting : symptom of a memory leak is seen as an increase in VSZ or RSS ?
<apw> rss is just how much is curently in ram, it can come and go
<caribou> apw: so vsz would grow if there was some kind of pointer leakage
<apw> caribou, yeah you'd expect it to in all likelyhood
<caribou> apw: good, thanks!
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<cristian_c> jsalisbury: hi
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<cristian_c> jsalisbury: a fast questio 
<cristian_c> question
<jsalisbury> cristian_c, hi, sure
<cristian_c> jsalisbury: thanks, you have asmed me two questions about bug
<cristian_c> jsalisbury: now, has the regression revert to be reported upstream?
<jsalisbury> cristian_c, we may want to.  I need to do a little more investigation to see what changed in the code to cause the regression
<cristian_c> ok
<jsalisbury> cristian_c, I'll do some digging today or tomorrow
<cristian_c> ok
<cristian_c> thanks
<jsalisbury> cristian_c, np
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Aug 4th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
#ubuntu-kernel 2015-07-29
<teward> everyones aware of the kernel regression which caused hell on Trusty and others right?
<teward> (breaking Wine, introducing firefox explosions, etc.)
<infinity> teward: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1479093 ?
<ubot5> Ubuntu bug 1479093 in linux (Ubuntu Wily) "Segfault in ld-2.19.so while starting Steam after upgrade to 3.13.0-59.98 " [Medium,Confirmed]
<infinity> teward: You say "trusty and others", have you confirmed it on non-3.13 kernels?
<teward> infinity: well, Wine works on -58-generic
<teward> breaks on -59-generic
<teward> and it's not that bug.
<teward> infinity: i just reverted to -58-generic to see if Wine functions, and it does, going to -59-generic again to see if it crashes
<teward> cause it crashed once today
<teward> then never came up again
<teward> wonder if that had the details
<infinity> teward: What makes you say it's not this bug?
<teward> infinity: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1478844  <-- this is the one that people are seeing it on
<ubot5> Ubuntu bug 1478844 in ubuntu-release-upgrader (Ubuntu) "Last Kernel Update crash wine and other app like Firefox" [Undecided,Confirmed]
<teward> infinity: the one I'm aware of is ^ that
<teward> not the bug you've specifically pointed at
<infinity> teward: I'm sure it's the same bug.
<teward> (on Trusty)
<teward> infinity: ack
<teward> should those be duped then?
<teward> infinity: i also didn't mean 'and others'
<infinity> Looking to be sure.
<teward> i'm tired after beating my head against landscape all day
<infinity> Yeah, looks like the same bug.
<teward> infinity: i'm on the bug now want me to duep it?
<infinity> teward: Already done.
<teward> ack
<teward> infinity: so this is considered a regression, then?
<teward> and a fairly major one if it breaks wine, firefox, and others
<teward> I can do without firefox.  can't do without wine at the moment :/
<infinity> teward: Quite definitely, yes.  We're looking more deeply into it tomorrow.
<teward> infinity: so it's a 'first thing in the morning' kind of bug then
<infinity> teward: As soon as we can isolate the issue, we'll toss out a quick fix, I think.  It's clearly more widespread than just "some people can't play a video game or two".
<teward> infinity: oh, no doubt
<teward> infinity: any chance of a 'roll it back' update
<teward> although...
<teward> that would kill a sec update
<infinity> teward: Roll it back to what?
<teward> :/
<infinity> teward: Right.
<infinity> teward: Bit of a catch-22.
<teward> right
<teward> how major was the patched sec vuln, i didn't dig into the USN
<teward> (i have too many DSA's to read for work >.<)
<infinity> teward: Major enough that we did the update out-of-cadence to meet a CRD, rather than take our usual time fitting into our 3-week cycle.
<teward> mmm
<teward> um... CRD?  I'm still learning all the acronyms xD
<infinity> teward: That said, root vulns for your home gaming machine and root vulns for your colo server are certainly two very different things to consider.  And given all the people this bug affects, it seems pretty isolated to "weird stuff desktop people do" so far, so upgrade the server, roll back the desktop, maybe.
<teward> mmm
<infinity> teward: CRD = coordinated release date.  When all the distros and upstreams agree on the date and time to make an embargoed security vulnerability public.
<teward> ahh, OK
<teward> infinity: i know i have a couple people at work who said "Hey, why's Firefox crashing whenever I do my standard work during the day through it", and three people I do at-a-discount Linux support for saying similar, so from my perspective it's a major regression if it breaks everything.  roll back desktop, upgrade server, seems to me the course of action I'm taking, although I try and *not* have downtime on my servers...
<teward> ... speaking of which my LDS server apparently is having downtime, which means i cant pick/choose updates as easily for my other servers.... what joy >.>
<teward> infinity: thanks for keeping me in the loop, i assume there'll be additional discussions on this here, or that I can lurk here for status updates?
<teward> (I was about to file a bug on this issue too, glad I saw your response xD)
<infinity> teward: Discussion will happen... Somewhere.
<teward> ack
<teward> i'mma just lurk here then anyways.
<teward> an extra channel doesn't put additional strain on me or my bouncer :p
<apw> teward, are you in an awake part of your timezone, and if so are you able to reproduce any of the issues reported ?
<apw> (ie if we have anything to test, are you able to help validate)
<infinity> I think he's American.  I'
<infinity> m not sure why I think that.
<infinity> LP claims he lives in America/Eastern, so...
<apw> "not yet" then :)
<nusch> I've kernel panic on two systems recently, the reaseon is grub menu wasn't populated with initrd entry and encrypted root cannot be mounted. It's caused by lack of initrd bo user isn't alerted anyway that upgraded failed. Shouldn't grub skip such entry or alert user during upgrade that something failed? Users without knowledge about booting process will reinstall system in that case - there is no easily availble solution by googling error messages
<apw> nusch, well it is in theory at least valid to not have an initrd.  that said we rarely if ever do, so perhaps a warning is appropriate, but will an unsophisticated user cope with that
<infinity> A grub entry without an initrd isn't a bug or a misconfiguration, not sure what we'd be warning about.
<infinity> But if you mean an entry that points at an initrd that doesn't exist on disk because it didn't get created properly, that's a more interesting case.
<apw> nusch, i think the better question and better bug would relate to _why_ the initrd build failed
<apw> and noone was told
<infinity> Someone is always told.
<infinity> The postinsts fail.
<teward> apw: i'm awake now
<teward> infinity: LP is accurate with my timezone
<infinity> And apt/dpkg exit non-0
<infinity> teward: Excellent.  Andy has a kernel for you to test.
<teward> apw: the issues I can replicate are the firefox crashes (quite a few of em), Wine being 100% broken, and if you point me at what some of the other test cases are I can start testing at lunch - the actual 'error' i'm not sure of since there was never a crash bug created unfortunately
<teward> infinity: OK, i'm heading out the door in 3 minutes so i'll download/test/install once I get to work
<infinity> teward:  http://people.canonical.com/~henrix/CVE-2015-2390-trusty/
<teward> correction i'll download it now, test/install at work xD
<teward> infinity: back in a moment, i'll test those packages against what I have seen here (crashes, Wine not working, etc.)
<teward> infinity: booted up with those kernels - wine, which was broken under -59-generic, is now working again, so that issue was resolved.  Haven't gotten to the Firefox tests yet, but I'll run it through its paces and try and replicate the "randomly crashes for no immediately obvious reason" issue that was introduced previously
<teward> (and in the interim i temporarily told Grub the default entry to use is the -58-generic - the last packaging of the kernel which didn't torpedo Wine and Firefox)
<teward> (and specifically boot-tested the packages in the link you provided)
<henrix> \o/
<teward> VMware Workstation is complaining...
<henrix> teward: thanks for testing that kernel
<teward> but that's not atypical, every new kernel it needs modules rebuilt for virtual nics
<teward> henrix: glad to help, provided I'm not compiling kernels from scratch xD
<teward> henrix: besides, two of the tools I need today need Wine so bahh
<teward> it was either use -58-generic, or test :P
<henrix> teward: heh, yeah.  good thing it was easily reproducible ;)
<teward> henrix: definitely.  ESPECIALLY when it's a case of "The update makes Wine totally unusable and breaks 666% of everything"
<teward> bah, laggggy client >.<
<teward> henrix: it also helps knowing my way around the terminal, most standard users wouldn't be able to `dpkg -i` and know what they're doing or which packages to download xD
<teward> but yeah, that appears to work...
<nusch> @apw I meant the case when initrd isn't generated on disk by any reason(e.g low disk space) - if there is a way to tell if it should be generated we can use the same path to deduce that is necessary to boot, and if we from that point deduce that is neccesary to boot but not exists -> system is unbootable -> should we then create grub menu entry or at least make this entry default?
<apw> nusch, well the kernel install should fail in that case, becasue the postinst should fail, so you should know you are in a world of hurt
<TJ-> nusch: technically, GRUB's "/etc/grub.d/20_linux_xen" is at fault. It creates the list of kernels in 'linux_list' by searching for valid /boot/vmlinu* entries but doesn't also confirm there's a valid initrd (e.g. a /boot/initrd.img* *and* it passes the grub_file_is_not_garbage test. Obviously update-initramfs should make a lot of noise if the initrd.img isn't valid
<teward> infinity: poke - is the 8-12 hours for fixed kernel availability still on target (from the earlier statement in the bug)
<teward> and do I need to worry about a delta between the packages i tested from henrix for the issue and what's been pushed to builders
<infinity> teward: Yes.
<infinity> teward: And there should be no delta, but it might be nice if you could re-smoketest a binary or two.
<infinity> Which I'm about to do anyway.
<teward> sorry i've had my head in ESXi's command line all day >.<  by 're-smoketest' is that anything specific other than 'test to see if it fixes the issues' like i did earlier
 * teward yawns
<teward> (fixing VMs should NOT require editing the hypervisor >.<)
<infinity> Yeah.
<infinity> https://launchpad.net/ubuntu/+source/linux/3.13.0-61.100
<teward> ok
<teward> lemme reboot to -58-generic, the last known-to-work one, then remove the downloaded-by-hand ones i installed, then install from proposed
<teward> TESTING TIME :P
<infinity> It's not quite in proposed yet on mirrors.  Still some disk grinding on my end.
<teward> mmm
<infinity> Which is why I pointed you at LP. :)
<teward> indeed
<teward> infinity: it wouldn't be on the main archive mirrors?
<teward> (i.e. archive.ubuntu.com)
<infinity> teward: Considering it's still publishing to ftpmaster, no.  Not on archive yet.
<teward> ok
 * infinity gets to testing.
<teward> infinity: so, basically, download from LP, install-test, see if it breaks? :P
<infinity> Basically.
<teward> that's a fairly easy thing :p
<infinity> Okay, new trusty and lts-trusty binaries seem to work for me.
<infinity> bjf: You need/want any sign-off on this 3.13 fiasco, or shall I just release to updates/security as soon as it's all happy in proposed?
<teward> infinity: gonna install and reboot, and i'll give you my test results
<teward> (never huts to have more than one tester :))
<infinity> teward: Indeed.
<infinity> teward: Plus, you can reproduce the bug, I was just testing that the kernel wasn't obviously broken. :P
<bjf> infinity, i'm ready when you are ready
<teward> right
<teward> bjf: lets wait for this test - make sure this actually fixes the bug
<teward> (granted the delta between henrix's package and this one is probably near-zero but testing is always a good thing)
<infinity> bjf: Alrighty.  Doing the -signed dance, should be ready after that.
<teward> back in a moment, reboot time :)
<infinity> teward: The delta between henrix's and the ones he uploaded to LP is 3 lines in the changelog. ;)
 * henrix drums fingers...
<teward> infinity: +1 on it working and not torpedoing :)
<infinity> Good, good.
<teward> infinity: you never know, one off thing on the builder at the wrong moment and *BOOM*
<teward> could torpedo an entire system
<teward> and then you have other problems :P
<infinity> I wonder how many weeks/months it will take us to find all the duplicate bugs and dupe them against the original.
<teward> infinity: bet you a dollar it'll take 10 months, and more bugs will come in from people who don't pull updates frequently
<teward> who upgraded to -59-generic and didn't update since xD
<infinity> henrix: And it's all done (according to the LP DB, anyway, allow 6 to 8 weeks for publishing, etc)
<henrix> infinity: \o/
<henrix> infinity: thanks a lot
<infinity> henrix: Let's see if we can avoid this sort of thing for, like, a few months.
<infinity> Maybe we should switch to a BSD kernel.
<henrix> infinity: well... let's avoid it for at least the next week, as i hope to be mostly offline :)
<henrix> infinity: about the BSD kernel... yeah, let's talk about it over a beer in Seattle :)
<infinity> henrix: Heh.
<teward> infinity: US mirrors appear to have it, or at least the one I hit about an hour ago.  apt-cache policy shows it available :)
<teward> glad to see this was rapidly fixed :)
<teward> probably helps to have people affected testing and not just complaining about it, huh :P
<infinity> It doesn't hurt to have testers.
<teward> anyways, thanks to you, and the kernel team, for such rapid fix-release :)
#ubuntu-kernel 2015-07-30
<MoPac> Hello. I'm wondering if the patch for timing-induced data corruption with TRIM on Samsung SSDs is incorporated into the latest 3.19.0-XX release kernels in 15.04. I have an 840 EVO and am not sure whether it's safe to upgrade the firmware 
<apw> 8m ... thats not long to wait
<apw> MoPac (N,BFTL), if you know the specific patch you are talking about ... then ... we can check
<apw> henrix_, kamal, does the above description ring a bell ...
<apw> is that the "turn off trim for a family of drives" fix i wonder
<kamal> apw, what above description?  (I just reconnected to irc -- no backscroll)
<henrix_> apw: yes, it does ring a bell... checking
<henrix> apw: kamal: it's commit 9a9324d39696 ("libata: Blacklist queued TRIM on all Samsung 800-series") which is already in vivid
<henrix> kamal: there was a user asking if 3.19 had the fix for the 840 EVO SSD
<apw> henrix, thanks, the logs are complete even if they anr't here to appreciate it
<henrix> :)
<TJ-> Hopefully we can get this SSD TRIM fix backported: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc
<FourFire> Greetings, which is the latest kernel version which I can manually install on ubuntu 15.04 and expect it not to crash/have drivber problems?
<FourFire> I suppose that last qualifier complicated things a bit, just ignore it (drivers) if that's the case
<FourFire> from what I can see in the mainline repo, 4.0.9 looks like the best candidate, but I don't really know anything about kernel development so I've come here for a second opinion
<FourFire> ok, since noone has answered me in 15 minutes I'm going to go ahead and install 4.0.9
#ubuntu-kernel 2015-07-31
<oleg> Help! rm -r * fails to delete directories when using overlayfs in a user-namespace.  strace shows an EPERM in unlinkat.  OS details: ubuntu-14.04 with the linux-generic-lts-vivid kernel (or any 3.18+ kernel). The problem does not occur with the default 3.13 kernel.  A script which reproduces the issue is at http://paste.ubuntu.com/11974137/ .  Any advice would be most welcome.
<apw> oleg, could you file a bug against linux (ubuntu-bug linux) and put all that info in it please
<apw> oleg, and let me know the bug number
<oleg> apw,  Will do.  Can I file a bug without all the apport info?  (I don't have apport installed).
<apw> yep there is a +filebug link too
<apw> oleg, i am unlikely to look at it before next week
<oleg> apw, thanks, it's not an urgent problem.
<apw> oleg, get the bug number to me, and i'll put it on my list to look at
<oleg> apw, the bug number is 1480411
<apw> bug #1480411
<ubot5> bug 1480411 in linux (Ubuntu) "rm -r * fails to delete directories when using overlayfs in a user-namespace" [Undecided,New] https://launchpad.net/bugs/1480411
#ubuntu-kernel 2015-08-01
<DalekSec> A quick search only pulled up lp 1421530 and question 262057.  Stupid question, but has Ubuntu considered using the live kernel patching features of 4.0?
<ubot5> Launchpad bug 1421530 in linux (Ubuntu) "Kernel livepatch infrastructure in Ubuntu Server?" [Wishlist,Invalid] https://launchpad.net/bugs/1421530
<infinity> DalekSec: It's under investigation, yes.  It's not something that Just Happens without a fair bit of effort, mind you, but people are making plans and such.
<DalekSec> infinity: Of course, was just wondering if there was any plans or if it'd been considered, thanks!
 * DalekSec hides.
#ubuntu-kernel 2016-08-01
<xnox> apw, hi! will you upload zfcpdump-kernel into yakkety? https://launchpad.net/ubuntu/+source/zfcpdump-kernel
<xnox> or what's the next step there?
<apw> xnox, yeah, thanks for the reminader
<xboy> apw, do you know if it's available the daily release with kernel 4.6?
#ubuntu-kernel 2016-08-02
<gpiccoli> Hi, sorry to bother you. Just a quick question: Ubuntu 14.04.5 kernel is the _same_ of Xenial? I know they are the same version, but just want to be sure they are exactly the same build
<apw> gpiccoli, they are not exactly the same build, they are the same source but built locally in each release
<gpiccoli> OK, but source is the same, right apw? This is the important part for me hehehe
<gpiccoli> Thanks very much!
<apw> there is potential for configuration differences between them, though i believe there are none for X lts-X
<apw> the lts-X tree is built by applying the packaging delta to teh same base tree which was uploaded for X
<gpiccoli> Okay, very nice! Thanks for the information apw
<gQuigs> while the cycle starting on Aug 5th (05-Aug through 27-Aug) also include the upstream fixes from 4.4.16?
 * gQuigs is specifically interested in bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568729 with which the fixes appear to have already landed upstream in 4.4.16
<ubot5> Launchpad bug 1568729 in linux (Ubuntu Xenial) "divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault" [High,In progress]
<gQuigs> btw, http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html still doesn't show xenial SRUs (acaict)
<Guest55667> Hello there
<Guest55667> I am testing 4.7 on my Dell Precision 5510
<Guest55667> I notice there are no dell_wmi and dell_laptop modules included
<Guest55667> unlike 4.6.x
<Guest55667> without those, things like special hotkeys don't work
<Guest55667> is there any known reason for why these modules are missing in 4.7?
<gQuigs> Guest55667: how did you get 4.7?
<Guest55667> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/
<Guest55667> I guess there is no easy answer... thanks!
<gQuigs> sorry, yea, I didn't find an answer
<gQuigs> if you stay around long enough you might still get an answer though
<Guest55667> thanks for your effort
<Guest55667> I'll stick around for another while
<rtg> Guest55667, enabling CONFIG_DELL_SMBIOS=m did the trick, i.e., CONFIG_DELL_WMI=m was dependent on CONFIG_DELL_SMBIOS. I'll get apw to turn the crank again.
<Guest55667> cool
<Guest55667> so there's hope for 4.7.1 then?
<Guest55667> thanks a lot
<apw> rtg, i assume you mean rebuilding v4.7 mainline ... and done
<rtg> apw, yup, thanks
<apw> (it'll be an hour before it publishes)
<rtg> JanDrewes, ^^
<JanDrewes> ah
<JanDrewes> thanks, that was fast
<JanDrewes> I will check it out but I'll need longer than you... my internet is slow download alone will be several minutes
<JanDrewes> hm, no change visible under the below link
<JanDrewes> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/
<JanDrewes> oh my I should read better
<JanDrewes> 1h before it publishes
<JanDrewes> so then I'll check it out tomorrow, it's midnight in Italy
<JanDrewes> thanks a lot in any case!
<LocutusOfBorg> do you want to land 4.7 in yakkety?
<apw> LocutusOfBorg, it wil lcome
<apw> i want to land 4.6 first
<apw> (which i should do this week)
#ubuntu-kernel 2016-08-03
<LocutusOfBorg> thanks apw 
<LocutusOfBorg> I hope to have a new virtualbox before 4.7
<LocutusOfBorg> because the kernel module has some build failures here
<JanDrewes> Hello again
<JanDrewes> rtg apw : I have installed the recompiled 4.7 (201608021801), and the dell modules are there now
<JanDrewes> dell_led, dell_wmi, dell_laptop, dell_smbios, dell_rbtn
<JanDrewes> however, unlike 4.6.x, the radio-off hotkey (which is Fn+PrtScr on my keyboard) does not work.
<JanDrewes> in 4.6.x, it just cause a killswitch event which worked fine with network manager
<JanDrewes> in 4.7, it just gives me: "atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0)" in syslog
<JanDrewes> from a few initial powertop measurements, it seems as if 4.7 uses a slight bit less energy in idle though
<gQuigs> will code in https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/+ref/master-next be added to 4.4.0-34? or is that for 4.4.0-35, etc?
<gQuigs> specifically interested in what release will land 4.4.16 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1607404
<ubot5> Launchpad bug 1607404 in linux (Ubuntu) "Xenial update to v4.4.16 stable release" [Undecided,New]
<rtg> gQuigs, Ubuntu-4.4.0-35.54
<gQuigs> rtg: thanks!
<rtg> dannf, could you boot the test kernel referenced in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1608854/comments/12 ?
<ubot5> Launchpad bug 1608854 in linux (Ubuntu Trusty) "[arm64] nova instances can't boot with 3.13.0-92" [Undecided,In progress]
<dannf> rtg: will take a look after this meeting
<dannf> rtg: so the plan is to back out the arm64/EFI support in trusty?
<rtg> dannf, yup
<dannf> rtg: was that breaking something?
<rtg> dannf, according to the bug it regressed boot in a Nova VM
<rtg> 3.13 never had EFI support for arm64 anyway
<dannf> rtg: yeah it did, i backported it :)
<dannf> rtg: the way i read the bug, it was disabling the CONFIG_EFI setting that regressed it (which, sine the user is booting in EFI mode AFAICT, that would)
<dannf> rtg: it isn't clear to me why LP: #1566221 required disabling CONFIG_EFI on arm64
<ubot5> Launchpad bug 1566221 in linux (Ubuntu Yakkety) "linux: Enforce signed module loading when UEFI secure boot" [Undecided,Fix released] https://launchpad.net/bugs/1566221
<rtg> dannf, I disabled EFI on arm64 when backporting the UEFI signed modules patches failed to compile. Lemme recheck what UI've reverted.,
<dannf> rtg: ok - but i'm guessing that's the regression - the user was previously booting 3.13 in EFI mode, and they can't any more
<rtg> dannf, damn, those are your commits. Guess I'm gonna have to think about this harder.
<dannf> rtg: ok - let me know if you need any help w/ the compile failure
<rtg> dannf, will do
<cknavigator> Hello. I am trying to fill a bug report. Accordingly with the Ubuntu documentation, this bug should be reported against the kernel, as it happens when booting the Live USB.
<cknavigator> I'm just trying to understand what more do I need to include to make it usefl
<cknavigator> I already have the ubuntu-bug kernel info
<cknavigator> The bug is not being able to go past the Ubuntu logo screen on the Live USB due to the presence of a btrfs formatted partition on the local hard drive
<cknavigator> After deleting the partition the Live USB boots just fine.
#ubuntu-kernel 2016-08-04
<katronix> Hi all, is this a good channel to ask about issues doing custom kernel compiling?
<katronix> trying to compile my own kernel, when I execute sudo apt-get build-dep linux-image-$(uname -r) I get: http://pastebin.com/e6wGfzhR is https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel no longer correct docs?
<Adrien_D> Hi all. I would like more precisions about kernel version into ubuntu. When I type the uname -r command : 4.4.0-21-generic. But 4.4.21 doesn't exist. The last version is (now) 4.4.16. Which kernel version is ?
<zokko> hi guys! :-)
<zokko> is it safe to enable CONFIG_UEVENT_HELPER in 4.7?
<zokko> i'm interested mostly on http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/
#ubuntu-kernel 2016-08-05
<manjo> kamal, when is yakkety going to be rebased to 4.7 ?
#ubuntu-kernel 2017-07-31
<Tassadar> Hello, I'm running ubuntu arm port on cavium thunderx machine http://b2b.gigabyte.com/ARM-Server/R150-T60-rev-110 . When running a guest os in qemu with kvm, I get this panic whenever I try to run https://hastebin.com/raw/dadozecove
<Tassadar> anybody seen it before? Running 32bit programs in 64bit kvm should work, right? 
<apw> Tassadar, it is possibel that 32bit allows some non-aligned accesses wtf 64bit that 64bit does not
<jjohansen> sforshee: where do you have the 4.13 artful tree?
<sforshee> jjohansen: currently at git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable master-4.13
#ubuntu-kernel 2017-08-01
<ricotz> hi, any progress on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772 ?
<ubot5> Ubuntu bug 1699772 in scilab (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Undecided,Confirmed]
<ricotz> "Kernel version: Linux lcy01-08 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64" still shows this issue
<Tassadar> apw: thanks, turns out thunderx does not support 32bit at all
#ubuntu-kernel 2017-08-02
<icey> I'm currently testing a fairly small patch to my Artful kernel, the patch is proposed against upstream Linux but I suspect won't make it into the Artful kernel at release, assuming it works (in which case I'll +1 on the kernel ML as well), how hard would it be to get this patch added for Artful: https://patchwork.kernel.org/patch/9842347/
<tjaalton> do we handle v4.10.x.y stable releases?
<tjaalton> or whatever the version should be
<tjaalton> .17 is the last one provided by stable@
<tjaalton> too bad "[PATCH] drm/i915: Do not drop pagetables when empty" never was applied to v4.10.17.x if such a thing exists
<smb> tjaalton, afaik nobody started a follow-up longterm for 4.10. So anything that should go into zesty has to be individually sent to kt-ml
<smb> which rex tsai did recently
<tjaalton> smb: ok, so -cktNN releases for non-lts kernels are no longer happening?
<tjaalton> yeah good that the patch is now on the queue
<smb> tjaalton, no, unfortunately too many other things
<tjaalton> ok
<tjaalton> I only found out about the bug today :/
<tjaalton> my skl desktop is still on xenial
<smb> Yeah, I am rather conservative there as well
<icey> what's the policy for integrating kernel patches that enable hardware but aren't yet merged upstream?
<apw> icey, we prefer to see things whihc are being discussed upstream and making progress there over things that are flat rejecte
<icey> apw: seems to be still under discussion, it's just quite new: https://patchwork.kernel.org/patch/9842347/
<ricotz> apw, hi :), what is up with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772 ?
<ubot5> Ubuntu bug 1699772 in scilab (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Undecided,Confirmed]
<ricotz> the upstreamed patches are available since over month and included in 4.4.74 which still hasnt got into a 4.4 package release, this still breaks the i386 tests suite of libreoffice and the currently included patches for CVE-2017-1000364 are not sufficient
<apw> icey, one of those sorts of quirks would normally be pretty easy to accept as the only person you can screw is you
<icey> apw: I'm building it into a custom kernel now, I just don't want to have to d that regularly ;-)
<apw> ricotz, as far as i know those are the mm fixes on top of the fixes for the stackclash CVE
<apw> ricotz, and those i believe are out, they went out as an emergency kernel in xenial iirc
<ricotz> apw, I saw those but those are not sufficient
<ricotz> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y&id=4b359430674caa2c98d0049a6941f157d2a33741 and https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y&id=1f2284fac2180d7a9442c796d9755e3ce7ab0bd9 are required
<apw> ricotz, both of those are applied in 4.4.0-83.106 and -87 is in -security
<apw> though those are the original two commits so i assume those are not the ones you intended
<icey> apw: that patch works :)
<ricotz> apw, hmm, I see, not sure then which are the proper fixes, still the java crash is happening on i386 with -87
<apw> icey, so submit a bug against linux 'ubuntu-bug linux' and write it up in there, then send the patch to kernel-team@
<ricotz> apw, for reference https://launchpad.net/~ricotz/+archive/ubuntu/red/+build/13178350
<apw> ricotz, have you tried -88
<ricotz> apw, no
<icey> apw should I attach the patch even though the bug report includes a link to the patch on patchwork.kernel.org?
<apw> icey, not necessary
<icey> apw: should I send an email at all, or just link the bug (https://launchpad.net/ubuntu/+source/linux/+bug/1708120)?
<ubot5> Ubuntu bug 1708120 in linux (Ubuntu) "Lenovo Yoga 910 Sensors" [Undecided,New]
<apw> i would send the patch requesting the SRU to kernel-team@
<icey> apw: should it be an SRU for artful (unreleased) ?
<apw> icey, are you runnig artful, if so then just leave out the SRU bit of the wording as we don't call it that for devel
<apw> ricotz, do we know if this explods on artful too ?
<apw> so we can tell if this is a problem with the backports or generally, or indeed a bug in libreoffice
<ricotz> apw, I don't have i386 system to test this, so I am only seeing this on launchpad's i386 builders if the testsuite is made fatal
<ricotz> due to this issue libreoffice packaging was patched to ignore failing tests on i386 to have it built
<apw> how i wish we had shit-canned 32bit in xenial
<klebers> ricotz, what's the libreoffice version that's failing?
<apw> ricotz, well presumably one could fire up a 32bit image in kvm and test there
 * apw leaves ricotz in klebers' capable hands
<ricotz> it is not restricted to libroffice it is a jvm issue
<klebers> I can try doinf that
<klebers> ricotz, do you have a link to any log or something that could provide enough information to try to reproduce the problem manually on a vm?
<icey> apw: I get "Address not found" errors for kernel-team@canonical.com and @ubuntu.com
<ricotz> klebers, https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1436980.html , https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303
<ubot5> Debian bug 865303 in src:linux "libreoffice: Libreoffice Java features crash with Linux 3.16.43-2+deb8u1" [Grave,Open]
<tjaalton> icey: @lists.ubuntu.com
<icey> thanks tjaalton 
<apw> icey, @lists.ubuntu.com
<apw> trying to not say both bits together :)
<icey> apw: wouldn't want somebody getting spam onto the mailing lists ;-)
<apw> oh we get plenty anyhow
<ricotz> klebers, you should be able to reproduce this with any libreoffice i386 package in the archive
<klebers> ricotz, so it's reproducible not only on build but also on simply starting it?
<ricotz> klebers, yes, as it is documented in e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772
<ubot5> Ubuntu bug 1699772 in scilab (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Undecided,Confirmed]
<icey> mhcerri: regarding that patch update email for the yoga 910, given that I'm just trying to supply somebody elses patch (submitted upstream), seems strange to edit their commit to include the bug link? 
<mhcerri> hi, icey. no, that's standard practice. just make sure to use add a From: line with the original author (git format-patch --from will do that)
<mhcerri> icey, this way the original author will be kept when the stable team applies it
<mhcerri> you need to make sure it applies to the target kernel, so you probably need to cherry pick it anyway
<icey> mhcerri: I haven't even touched that patch file, I merely applied the 3 line change to verify that it works (I've never patched my kernel before ;-P) 
<icey> mhcerri: happy to learn, I appreciate the guidance :)
<mhcerri> icey, we usually use the ml list to review patches that are ready to be applied to our kernels
<icey> mhcerri: is there a good link to use as my git remote for the artful kernel?
<icey> mhcerri: understood, sent it to the mailing list at apw's suggestion :)
<mhcerri> icey, git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/artful
<mhcerri> icey, most of the kernel repos are listed here: https://code.launchpad.net/~ubuntu-kernel/+git/
<sforshee> tseliot: do you expect the nvidia driver updates to be done soon? We're planning to put a 4.12 kernel in artful-proposed sometime this week.
<tseliot> sforshee: yes, I'll deal with them this week. I've been busy with a couple of deadlines
<tseliot> *was
<sforshee> tseliot: thanks!
<icey> mhcerri: how should I link to the upstream patch, given that the patch hasn't been merged yet?
<mhcerri> icey, if it's not possible to wait until it's accepted upstream, you should mark it as "UBUNTU: SAUCE: ", the link has some info about that
<mhcerri> icey, you can add some information why it's important in a cover letter or in the commit message
<icey> mhcerri: I'd like it in Artful, and I have no idea how long it'll take to get into upstream; per discussion with apw earlier, it is a quirks patch to enable some sensors on a specific model of laptop ;-P
<mhcerri> icey, got it. to target artful prefix the subject with "[artful]". that's stripped when applied
<mhcerri> icey, `git format-patch  --subject-prefix='artful][PATCH'` will do that for you if you prefer
<icey> mhcerri: yeah, once I have this patch formatted, should I send it to the mailing list?
<mhcerri> icey, yes, usually `git send-email` is the simplest way to do that  and `--suppress-cc=all` is useful to not bother unrelated people. do you think you are able to build it and test it?
<icey> mhcerri: I'm running it custom at the moment, working on building this patch for you :)
<icey> mhcerri: do you mind me sending you the patch email before sending to the list to verify that it looks reasonable?
<mhcerri> icey, sure. np
<nomego> Hi! What's the easiest way to build the ppa-mainline (4.13-rc3) kernel yourself the Ubuntu-way ?
#ubuntu-kernel 2017-08-03
<sary> Salutations!
<sary> can anuone please teel me which mainline kernel should ethan test.. https://ubuntuforums.org/showthread.php?t=2367549&page=2
<sary> s/teel/tell
<apw> sary, i would advise he file a bug against the ubuntu kernel rather than use the forums
<apw> as for testing mainline, the norm is to test the latest -rc as that represents the current state of the art
<sary> apw: sure right , he did .. does this looks okay! https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1708191
<ubot5> Ubuntu bug 1708191 in linux-hwe (Ubuntu) "Xubuntu complete freeze with Intel atomic i915" [Undecided,New]
<sary> Ok, so he should go for kernel v4.13-rc3 first..
<sary> doen't seem like he ever did install a kernel manually with the debs files , i suppose it's time he learns how to , or is it okay to use ukuu ..!
<apw> i would teach them to use the .debs
<sary> Ok.
<sary> thanks apw , will advise him on that. anything else he should collect for the bug report!
<apw> i suspect that is all, depending on the h/w this might be something we have knowledge of, not sure right now and its too late in the day to be thinking too hard
<sary> noted. have a good one.
<White_Light> are debug packages made for the mainline ppa kernels?
<apw> White_Light, nope
<White_Light> too bad
<apw> too big to keep so very many of them
<White_Light> I understand
<icey> PHLin: hey, thanks for assigning me https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708120 , not sure what to do with it now though, this has been my first time working with kernel ;-)
<ubot5> Ubuntu bug 1708120 in linux (Ubuntu) "Lenovo Yoga 910 Sensors" [Undecided,Confirmed]
<PHLin> icey, sure thing, and thanks for spotting this
<PHLin> icey, now we wait for ACK (and comments, if any)
<PHLin> icey, you might be asked to verify it if the patch got applied and pushed to -proposed pocket
<tjaalton> sary: it's a dupe of 1680904 most likely
<sary> tjaalton: it looks as there're few bug with a comment " duplicate of: Bug #1680904 ".
<ubot5> bug 1680904 in linux (Ubuntu Zesty) "zesty unable to handle kernel NULL pointer dereference" [High,In progress] https://launchpad.net/bugs/1680904
<tjaalton> sary: you mean many dupes? yes and more on the way I bet :/
<sary> Chea!
<apw> tjaalton, do we have a fix for that yet ?
<tjaalton> apw: already acked on the list
<tinoco> smb: hi, not sure i understood what you said in reply to v2 for the "xfs: xfs_log_ticket leak" patch I submitted. 1st one missed "cherry picked from", there were 2 ACKs with comments on the missing part, I replied back asking if you wanted me to amend and resubmit on the same thread, got no response, submitted again. I have only insisted because master-next branch seems not updated to latest "acks" from the mailing list, so I wasn't aware if
<tinoco>  the patch had already been picked to the branch or not.
<smb> tinoco, normally if someone applies it they (should) send a reply to the thread with "APPLIED", which has not happened
<tinoco> smb: gotcha. so submitting the v2. was it needed ?
<smb> So that might have been pending still. That is why I send the nack to the old thread and acked the new patch again
<tinoco> smb: gotcha. 
<tinoco> smb: tks. just wanted to make i wouldn't do something bad next time this happens (hopefully i wont miss this again :o)
<tinoco> smb: tku
<smb> tinoco, maybe not. must admit I was distracted with other things this cycle so I may have missed something. the mailing list is my memory extension in those cases ;)
<tinoco> smb: i know that. sorry for extra burden, i know you guys are super loaded. tks for the sru
<smb> tinoco, np. just for you as my excuse in case it was incorrect. anything not on the list might be forgotten
<icey> sforshee: sorry about the shitty email patch, thanks for getting it up :) As soon as it's in proposed, I'm happy to switch from my self-built kernel back to a signed one :)
<sforshee> icey: np, will hopefully have a new kernel in proposed by early next week
#ubuntu-kernel 2017-08-04
<thejoe> Hello.  A patch similar to the one applied to ubuntu kernels in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1587714 has finally landed upstream in 4.13.  The patch is slightly different though, and the fact that the current ubuntu patch is no longer required may not get caught if your team relies on merge conflicts to catch it.  What's the best way to ensure that it doesn't get applied to 4.13+/artful kernels?  Thanks.
<ubot5> Ubuntu bug 1587714 in linux (Ubuntu Yakkety) "MacBookPro11,4 fails to poweroff or suspend" [Medium,Fix released]
<tseliot> sforshee: hey, 340 and 304 and in artful-proposed now. Thanks
<sforshee> tseliot: awesome, thanks!
#ubuntu-kernel 2017-08-05
<sary> Anyone believe i was rude or had unnecessary comments here: https://ubuntuforums.org/showthread.php?t=2367866
<sary> ^BenginM.
#ubuntu-kernel 2017-08-06
<who_me> hi, I'm trying to build kernel packages using the patches from mainline ppa but I can't even get a simple  "fakeroot debian/rules clean" to run properly . It fails with this message "dh_testdir: The control file has a Build-Profiles field. Requires libdpkg-perl >= 1.17.14"
<who_me> I was able to build kernel 4.4.77 just fine not too long ago
<uebera||> Hi. Does the 16.04.3 HWE stack (Linux 4.10 kernel) come with livepatch support?
<apw> who_me, depends which base chroot you are trying to build it in, that is saying your tools are too old to build that specific package
<apw> uebera||, i do not believe it does
<uebera||> apw: I posted the question on Dustin Kirkland's blog (http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html) as it was originally mentioned that including the HWE stack kernel might be considered at a later time, so let's seeâ¦
<who_me> apw, so there's no way I could build that kernel on 14.04 then :/
<apw> who_me, yes you debootstrap an artful chroot
#ubuntu-kernel 2018-07-30
<Laney> ha;lp
<Laney> I'm getting https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518
<ubot5> Ubuntu bug 1753518 in grub2-signed (Ubuntu) "package grub-efi-amd64-signed 1.93+2.02-2ubuntu8 failed to install/upgrade: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1" [Undecided,Confirmed]
<Laney> + grub-install --target=x86_64-efi --auto-nvram
<Laney> Installing for x86_64-efi platform.
<Laney> Could not delete variable: Invalid argument
<Laney> grub-install: error: efibootmgr failed to register the boot entry: Block device required.
<Laney> dpkg: error processing package grub-efi-amd64-signed (--configure):
<Laney>  installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
<Laney> etc
<Laney> grub-install: info: executing efibootmgr </dev/null >/dev/null.
<Laney> grub-install: info: executing efibootmgr -b 0000 -B.
<Laney> Could not delete variable: Invalid argument
<Laney> grub-install: error: efibootmgr failed to register the boot entry: Block device required.
<apw> Laney, uff, cyphermox ^ 
<apw> i asusme that is on upgrade of a grub2 ...
<Laney> yeah grub-efi-amd64-signed
<apw> cosmic ?
<Laney> nope bionic
<Laney>  *** 1.93.3+2.02-2ubuntu8.2 500
<Laney>         500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
<sforshee> LocutusOfBorg: we have a 4.17 kernel that's about ready for cosmic-release, except that it needs the virtualbox from -proposed to pass adt. Is that going to promote soon?
<apw> Laney, what kernel are you runing
<apw> when that fails
<Laney> laney@nightingale> uname -a                                                                                     ~
<Laney> Linux nightingale 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<LocutusOfBorg> sforshee, I'm not the one blocking it
<LocutusOfBorg> ask release team
<apw> LocutusOfBorg, what is blocking it
<LocutusOfBorg> when I requested to make xorg migrate, it was only blocked by qtbase
<LocutusOfBorg> sorry, only blocked by xorg
<LocutusOfBorg> now it is entangled with qtbase too
<LocutusOfBorg> soooo, I don't care anymore
<danieru98> jsalisbury, just finished testing your test kernel for bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783906 , i've posted an update there, long story short, you were right about reverting 2dc0b46b5ea3, that fixes that bug
<ubot5> Ubuntu bug 1783906 in linux (Ubuntu Cosmic) "Linux 4.15 and onwards fails to initialize some hard drives" [Medium,In progress]
<danieru98> Should i mark that bug as fixed, or wait for any further updates?
<jsalisbury> danieru98, wait for further updates.  I need to investigate that commit further to see if it can be simply reverted or needs to be fixed properly.
<jsalisbury> danieru98, I'll probably need to ping the patch author, but I'll cc the bug report, so it gets all the email exchange.
<danieru98> jsalisbury, okay, if you need me to test any other kernel feel free to just ask me. i'll keep my eyes on on that bug report for any updates
<jsalisbury> danieru98, thanks!
<tyhicks> sforshee: hey - for the /sys/class/net changes that I did for LXD, is it alright if I just "backport" them to ubuntu-unstable/master (currently 4.18 based) in order to land them in cosmic? I'd prefer to just ignore 4.15 for now
<sforshee> tyhicks: yes however you may also want to backport to 4.17 (cosmic/master-next)
<tyhicks> sforshee: oh, should I *only* do cosmic/master-next rather than unstable/master?
<tyhicks> they cherry pick to unstable/master but I haven't tried cosmic/master-next yet
<sforshee> should do both if it's easy, but if 4.17 is a big pain it's not that big of a deal
<tyhicks> sforshee: I'll figure out how to do both but 4.17 is a pain because lxd still isn't working there due to the 55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
<sforshee> tyhicks: that's odd, lxd adt tests pass on our 4.17 kernel
<tyhicks> sforshee: sorry, I meant 4.18 is a pain
<tyhicks> 4.17 doesn't have that commit
<sforshee> tyhicks: that makes more sense
<sforshee> oh yes the mknod thing ...
<tyhicks> right
<tyhicks> that never got reverted
<sforshee> tyhicks: I'll check in with brauner about that tomorrow, we're gonna need a resolution on that soon
<tyhicks> sforshee: I think there's a workaround in lxd now but it hasn't been released yet, IIRC
<sforshee> yeah I had thought they had a fix for lxd
<sforshee> but still problems because of systemd's everywhere without the fix
<tyhicks> right
<stgraber> 3.0.2 liblxc will have the workaround but yeah, won't necessarily help with the containers...
<stgraber> I think the LXD snap should also already include all the needed bits for 4.18
<stgraber> yeah, it does, so "snap install lxd" would get you a LXD with the needed liblxc bits
<sforshee> stgraber: I do know that adt is failing for both lxc and lxd on 4.18, I haven't had ac hance to look into it yet
<stgraber> yeah, that'll most likely fail until we push 3.0.2. We could cherry-pick just that one commit if that's the only thing that's blocking you with 4.18.
<sforshee> oh no that's far from the only thing
<stgraber> sforshee, tyhicks: btw, looks like the fix from jjohansen in bug 1780227 works fine, do you know if this is already in the relevant branches for the next round of SRUs?
<ubot5> bug 1780227 in linux (Ubuntu Bionic) "locking sockets broken due to missing AppArmor socket mediation patches" [Critical,Triaged] https://launchpad.net/bugs/1780227
<jjohansen> stgraber: it is not, in yet
<tyhicks> stgraber: not your problem but it looks like something in snappy is broke on 4.18 so I can't install the snap: https://paste.ubuntu.com/p/87rksWFPKk/ :)
<tyhicks> I can work around this in my test kernel build so no worries
<stgraber> tyhicks: sounds apparmor related, do you see a denial?
<tyhicks> that's the first thing I looked for
<tyhicks> hmm, there are some odd denials earlier in the logs
<tyhicks> audit: type=1400 audit(1532983771.976:97): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=1422 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"
<tyhicks> that sounds like a familiar issue
<jdstrand> it is
<jdstrand> jj fixed an issue that was a trace into a read
<jdstrand> snapd isn't fixed yet
<jdstrand> https://forum.snapcraft.io/t/custom-kernel-error-on-readlinkat-in-mount-namespace/6097/21
<tyhicks> jdstrand: ack, thanks - don't escalate priorities for it on my behalf as I can work around it in order to get my testing done
<jdstrand> tyhicks: you are on 4.18?
<tyhicks> jdstrand: yes
<jdstrand> yeah
<jdstrand> that is that
<tyhicks> alright, good to know
<jdstrand> tyhicks: it is pretty high on the list, but not all the way up
<jdstrand> tyhicks: if it comes time when you think it should be escalated, ping me
<tyhicks> jdstrand: as sforshee mentioned above, there are several other things blocking 4.18 landing in cosmic but it is coming soon
<tyhicks> dropping a bare ptrace rule into /etc/apparmor.d/usr.lib.snapd.snap-confine.real is going to let me do what I need to do
<jdstrand> tyhicks: so will 'ptrace read peer=unconfined,' :)
<jdstrand> I'll do a quick PR for that, and do the interrogating later
#ubuntu-kernel 2018-07-31
<TJ-> bug #1779974 is FTBFS for bcmwl (bcmwl-kernel-source) is failing DKMS builf for 4.15 kernels in 18.04 and 16.04; who would be reponsible for sorting it out?
<ubot5> bug 1779974 in bcmwl (Ubuntu) "install bcmwl-kernel-source , Module wl not found in directory /lib/modules/4.15.0-24-generic" [Undecided,Confirmed] https://launchpad.net/bugs/1779974
<apw> TJ-, 'us' in general ... i'll put it on the appropriate radar
<TJ-> apw: thanks :)
<TJ-> pc_magas: apw knows now so something will be done soon
<apw> TJ-, that is odd because our test matrix shows that built just fine on our test systems before release (for -24) in bionic ... but it does appear to be broken in xenial, hmmmm
<apw> TJ-, ahh i see now, the fix is actually in xenial-proposed but noone had marked it tested
<pc_magas> apw, so i guess somewhere in the next week will be a patch (if I suppose that dev sprints are week based)
<apw> which from the chatter appears to be working fine, so i have marked it so
<apw> pc_magas, there is a 'fixed' package in xenial-proposed you could try
<apw> though i am going to get that released as soon as the update purculated through
<pc_magas> Thanks
<jdstrand> tyhicks: fyi, those PRs were committed today. I suspect the core snap from edge will have it tomorrow. It seems it'll be in 2.34.4 which I don't have a timeframe on
<tyhicks> jdstrand: thanks! it sounds like it'll all land before 4.18 in cosmic
<jdstrand> tyhicks: that is the hope, yes
#ubuntu-kernel 2018-08-01
<steven29> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<steven29> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<steven29> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<steven29> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<m4v23> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<m4v23> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<m4v23> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<m4v23> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<hipp> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<hipp> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<hipp> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<hipp> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dan-18> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dan-18> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dan-18> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dan-18> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<cheapie13> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<cheapie13> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Guest29805> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<bobe8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<bobe8> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<bobe8> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<bobe8> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Neo14> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Neo14> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Neo14> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Neo14> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<luisoliv> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<luisoliv> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<luisoliv> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<april23> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<april23> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<april23> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<april23> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Gizmokid200516> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Gizmokid200516> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Ambroisie> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ecks6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<israfel> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mikedlr179> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mikedlr179> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mikedlr179> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<mikedlr179> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<KindOne> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<KindOne> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<beaver1> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<biberao18> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Texou> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<jesse16> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<jesse16> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<jimby29> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<jimby29> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<matlock> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<matlock> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<matlock> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<iDanoo3> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<iDanoo3> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<iDanoo3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<iDanoo3> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<c0ded> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<PuppyKun22> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<PuppyKun22> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<sl3dge__> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<sl3dge__> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ablackack8> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<tomek22> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Demp9> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<joepie9123> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mar77i_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<mar77i_> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<mar77i_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<justache28> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<justache28> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<justache28> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<l4z4i> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Guest13802> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<brand020> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<beaky26> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Harzilein21> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Harzilein21> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Harzilein21> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<swordsmanz27> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<tomreyn> have you considered "/mode #ubuntu-kernel +r", maybe with "+f #ubuntu-unregged" ?
<rbasak> I firmware upgraded and then dist upgraded my Dell XPS 9360 to Bionic, and now my wifi keeps dropping out. Turning wifi off and on from Network Manager seems to get it going again. Once after suspend/resume I lost it completely and had to reboot. Known issue? It's ath10k_pci 168c:003e (rev 32), and I see some other bugs but none that say 9360.
<rbasak> I guess I can bisect, try a mainline kernel, etc. if necessary.
<rbasak> Unless someone is already onto this one?
<apw> tomreyn, we have had it thus at points in the past but it tends to be a barrier to entry
<apw> rbasak, i have not heard any other examples of that
<apw> i have found in general that bionic userspace is more sensitive to the network environment
<rbasak> Perhaps I have two bugs.
<TJ-> rbasak: have you tried out the acpi_osi="Windows XXXX" trick?
<rbasak> The suspend/resume that only happened once.
<rbasak> And the dropping out which might be NM.
<rbasak> TJ-: no, though my goal is really to fix it for everyone rather than live with a workaround :)
<apw> for instance i have ipv6 on my network, and that tends to get it in ? a lot
<TJ-> rbasak: right, but you mentioned a firmware upgrade... we've seen that causing issues quite a lot
<rbasak> I have IPv6 available.
<rbasak> I regret not doing the firmware upgrade at a different time from the upgrade to Bionic.
<apw> as in a dell supplied bios etc update ?
<rbasak> Yeah using fwupdmgr
<rbasak> Perhaps I should run the Artful kernel for a while.
<apw> likely that was delivering you cpu firmware 
<apw> rbasak, runnig the last artful kernel might give you a feeling for that indeed
<matze5> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<matze5> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<quicksilver27> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<quicksilver27> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<quicksilver27> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<tomreyn> apw: and not setting +r (or +S?) may seem like a barrier to chatting here. ;)
<apw> tomreyn, yeah we cirtiany should do something given the current noise
<apw> who all do i ask for that
<ori6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<apw> tomreyn, so +r is enabled, lets see if that makes any difference
<tomreyn> actually just setting +n may already fix it
<tomreyn> apw: and it is surely needed in addition to +r
<apw> tomreyn, then lets try that
<tomreyn> :)
 * apw likes this channel to be as quiet as a church mouse
<hggdh> apw: yes, +r will help. I refrained to set it =r earlier on because I was not sure you all would agree
<hggdh> er, to set it +r
<apw> oh anything to keep them out :)
<hggdh> apw: next time we will do it, then.
<apw> hggdh: thanks, appreciated
#ubuntu-kernel 2018-08-02
<arvin_> Hi, I'm compiling the kernel from mainline and applying the Ubuntu patches, but it's not creating a /boot/abi-* file after installing headers and image from "make deb-pkg" any ideas?
<cascardo> make deb-pkg is an upstream feature to create deb packages, they do not conform with how ubuntu produces its deb packages
<cascardo> you should use the debian way of building debs, that is, run dpkg-buildpackage
<arvin_> i see. Would fakeroot debian/rules binary-headers binary-generic binary-perarch create it?
<cascardo> binay-generic should be enough, I guess
<arvin_> cascardo: appreciate the feedback thank you. I haven't verified it yet but you're fairly certain that should create the abi-* file if I apply the Ubuntu patches?
<arvin_> dpkg-buildpackage looks a lot more appropriatethan the make deb-pkg I was using. thanks again
<cascardo> well, gone before I could respond
<mispp> hey all, i have an issue with random freezes, been distohopping to see if it something distro related, but seems not. right now i'm using latest ubuntu and system randomly freezes
<mispp> anyone knows something about causes in kernel?
<mispp> (i've been told before when it's complete freeze, it has to be kernel; journal has nothing usefull)
<mispp> i've enabled kdump to see if i can catch something when it happens next time
<mispp> it happens on full amd build
<TJ-> mispp: have you investigated ACPI issues?
<mispp> TJ-: nope
<mispp> so, i should disable acpi?
<TJ-> mispp: some system firmware is predicated on running Windows and doesn't enable functionality/devices correctly for Linux. ACPI is required, but there's an acpi_osi= workaround that often helps.
<TJ-> mispp: see http://iam.tj/prototype/enhancements/Windows-acpi_osi.html
<mispp> with this parameter, it wont boot at all
<arvin_> hi, any ideas how to preserve the .config when running fakeroot debian/rules binary? tried everything. can compile kernel using kpkg or make deb-pkg but trying to get this method going to create /boot/abi-* file. Thx
<arvin_> i think it's related to "is not clean, please run 'make mrproper'" referring to the folder
<arvin_> FAQ's recommendations on removing include/config doesn't work and the git command removes the debian/ folder so when I rerun fakeroot debian/rules binary it recreates those again
<arvin_> so the issue was that it doesn't like a .config file in the root source directory. If I remove that and ran fakeroot debian/rules editconfig, then ran fakeroot debian/rules binary-headers binary-generic, all was good
<arvin_> if someone could add that to the FAQ
<arvin_> everything built well, didn't use the config I wanted though lol. Anyone know the right way of going about this?
#ubuntu-kernel 2018-08-03
<arvin_> ah, I see how it works. I can't try and use my old .config, have to use the editconfig and build out my new config like that
<mispp> so, acpi=off completely scewes up boot
<mispp> https://imgur.com/a/XmLmKdN
<mispp> anyone has an idea how to fix this?
<mispp> is this a driver problem for graphics card or?
<TJ-> mispp: ACPI is required these days
<mispp> alright
<trippeh> that is a pretty awful way to fail tho
<TJ-> Not much you can do if the firmware has put the system in a bad state to begin with
#ubuntu-kernel 2018-08-05
<raidensnake> does anyone know how i can update a preinstalled kernel with a new config option without changing the version?
<raidensnake> I need to add a missing config option config_rfkill_gpio=m
<raidensnake> it's bugging out the bluetooth functionality
#ubuntu-kernel 2019-07-30
<immu> hi 
<immu> can anyone confirm if kernel 5.3 will make it to 19.10
#ubuntu-kernel 2019-07-31
 * ciechomke[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/FBeBykkDsSyRlnKaOQyzVtno >
#ubuntu-kernel 2019-08-01
<richi235> I'm quite sure it will be 5.2 because 18.04 hwe-edge is 5.2 too in the bionic git repo. and usually lts hwe-edge and the newest non-lts distro have the same kernel
<apw> lotuspsychje, hey ... do we ahve any bugs filed for these bionic/linux-hwe issues
<lotuspsychje> not yet apw 
<lotuspsychje> i gotta go to city right now, ill try to debug after apw 
<apw> lotuspsychje, getting the reporters to file bugs would get the exact version combinations recorded
<apw> lotuspsychje, in case it is a linux-hwe/mesa/x missmatch or something
<lotuspsychje> ok tnx
<lotuspsychje> i told the -discuss crew to forwards bugs here
<lotuspsychje> we will keep an eye open 
<lotuspsychje> bbl
<tjaalton> what issues?
<tomreyn> tjaalton: two quotes (from different people running hwe on 18.04) from -discuss: "kernel 5.0.0.23 update made me boot in recovery mode and use the dpkg fix option, both machines"; "5.0.0-23-generic booted after dpkg recoverymode, but backlight doesnt work anymore"
<tjaalton> ok, that doesn't say much
<apw> tomreyn, could we get a bug number please with some versions and details in it
<tomreyn> apw: i'm not affected, can't file a bug
<apw> tomreyn, you likely could poke whoever you are quoting
<tomreyn> will do
<apw> ta
<apw> tjaalton, i have no information beyond what is here, that someone was mentioning it in #ubuntu-discuss
<apw> the "dpkg fix" is new information
<apw> and i don't know if that is indicative of a missmatch
<tjaalton> right
<ogra> apw, does the snapcraft.yaml in ther kernel.ubuntu.com trees get any active testing ? (specifically in ubuntu-bionic.git ) ... https://forum.snapcraft.io/t/with-custom-kernel-in-amd64-architecture-snap-command-not-found/12574
<ogra> s/ther/the/
<apw> ogra, we are not using it every cycle that is for sure, i would refer you to klebers in the first instance
<ogra> (i wonder if the re-built kernel misses any options or anything)
<apw> ogra, it would be using the original configuration i assume .. isn't the error about not having the snap userspace binary though in that case?
<apw> ogra, so something about their overall image and not specifically the kernel ?
<apw> ogra, its not saying "snap: i can't find some useful kernel feature"
<ogra> apw, yes, but i know that the core18 snap gets tested for exactly that before release, the image boots normally so the gadget is ok ... whihc only leaves the kernel (missing option ... issue because he used an old compiler parhaps .... whatever) as the first candidate for looking at
<apw> ogra, for not finding a userspace binary ?
<apw> that isn't even in the kernel or gadget snap is it ?
<ogra> the snap error can be a fallout of snapd not running 
<ogra> which can happen if you missing one of the snap options 
<ogra> )in the kernel)
<apw> /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
<apw> no that _really_ says there is no snap binary in the path
<ogra> the image is built from stable core18 and snapd snaps, the only difference to one of our images are gadget and kernel ... 
<apw> ogra, and the error still says the binary is missing
<ogra> theoretically it functiona exactly the same as our image
<ogra> geez
<ogra> *theoretically it should function
<apw> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<apw> snap says that if the server is not there
<ogra> yeah 
<apw> not snap: command not found
<apw> so ... the snap command is not in their image
<apw> somehow
<ogra> well, i'll dig on 
<apw> and as that is made outside of the machine it should be easy to confirm right ?
<apw> looking at the ISO/squash wahtever it is
<ogra> well, its a partitioned image ... not so easy to guiden an illiterate user though mounting it ... 
<ogra> and thanks to journald we dont have logs to read :/
<ogra> aha ! 
<ogra> he uses a brand-store !
<ogra> (and thanks for answering the initial question ... that was actually all i needed to know)
<lotuspsychje> apw: this is whats happening to my system: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1838644 
<ubot5> Ubuntu bug 1838644 in linux-signed-hwe (Ubuntu) "Booting into desktop results in flickering" [Undecided,New]
<lotuspsychje> tjaalton: updated #1838644
<tjaalton> lotuspsychje: well, dmesg from recovery mode doesn't help because i915.ko isn't loaded
<tjaalton> but if 5.1.21 works then it's bisect time..
<tjaalton> you have earlier mainline builds on the parent dir, try 5.1rc's
<lotuspsychje> allrighty
<tjaalton> which laptop model?
<lotuspsychje> tjaalton: Clevo Machine:   Device: laptop System: Notebook product: N7x0WU
<tjaalton> ok
<lotuspsychje> tjaalton: 5.1.0-050100rc1-generic also works
<tjaalton> right.. feared as much
<tjaalton> lotuspsychje: try the older build of drm-intel-next
<tjaalton> oldest
<tjaalton> https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2019-02-08/
<tjaalton> rc1 has some fixes on top of that
<tjaalton> hoping that this one is broken..
<lotuspsychje> lets c
<tjaalton> otherwise need to bisect using older drm-intel-next tags..
<lotuspsychje> tjaalton: also working 5.0.0-997-generic
<tjaalton> from that dir?
<lotuspsychje> yes
<tjaalton> have you built kernels before? :)
<lotuspsychje> no
<tjaalton> ok
<tjaalton> do you have time to hang around?
<lotuspsychje> a bit sure, i added to autojoin here
<tjaalton> well, I can also post to the bug
<tjaalton> getting late here
<lotuspsychje> ok tnx for your time tjaalton 
<tjaalton> as in EOD late
<lotuspsychje> ill see if i can catch a dmesg before the flickering
<tjaalton> I'm pretty sure what it's about
<tjaalton> so no immediate need for that
<lotuspsychje> what do you suspect?
<tjaalton> i915 watermark programming
<lotuspsychje> ok
<lotuspsychje> tjaalton: are you interested in my intel NUC test
<tjaalton> depends :P
<lotuspsychje> tjaalton: cause i dont have the issue there
<tjaalton> this is specific to hw
<lotuspsychje> i see
<tjaalton> display mostly
<tjaalton> I'll build you a kernel
<lotuspsychje> tnx
<tjaalton> will take a while
<lotuspsychje> sure thing tyt
<TJ-> Looks like it could be related to the i915 CDCLK changes
<TJ-> the dmesg from a flickering boot shows [   23.332952] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
<tjaalton> yes
<tjaalton> lotuspsychje: still here? first build ready, I'll copy it somewhere..
<lotuspsychje> ill test after dinner
<tjaalton> lotuspsychje: https://aaltoset.kapsi.fi/bisect/
<lotuspsychje> tjaalton: working Linux Rootbox 5.0.0-rc1
<tjaalton> lotuspsychje: the one I built is working?
<lotuspsychje> well i installed it and sudo update-grub
<tjaalton> ok
<lotuspsychje> ./boot/initrd.img-5.0.0-rc1 is the one right?
<tjaalton> these are all going to be 5.0.0-rc1
<tjaalton> the thing is to track the build number (-11 here)
<tjaalton> or, abi number to be precise
<lotuspsychje> Linux Rootbox 5.0.0-rc1 #11
<tjaalton> yes
<lotuspsychje> ok oof :p
<lotuspsychje> first food here now :p
<lotuspsychje> tnx for your tile tjaalton 
<lotuspsychje> time
<lotuspsychje> got a lot of clevo customers out there, so apreciate it!
<tjaalton> next builds will be quicker
<tjaalton> lotuspsychje: 12 copied
<lotuspsychje> cool
<EoflaOE> How can you make it faster?
<tjaalton> it doesn't clean the old files, and since only a subset of the source keeps changing between bisect points, only those (plus the packaging) will be rebuilt
<tomreyn> drm-tip builds seem to be partially broken (the current is, but also some of the previous ones) - possibly a git process concurrency / locking issue
<tomreyn> https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/ 
#ubuntu-kernel 2019-08-02
<alkisg> Hi, which kernel is 19.10 mostly likely going to ship with? We want to prepare some out-of-tree drivers before release...
<tjaalton> alkisg: 5.3 is planned
<alkisg> Thank you tjaalton :)
<lotuspsychje> hey alkisg tjaalton 
<alkisg> Heya lotuspsychje
<lotuspsychje> tjaalton: i been able to grab a dmesg on that intel flickering with a kernel param Bug #1838644
<ubot5> bug 1838644 in linux-hwe (Ubuntu) "Booting into desktop results in flickering" [Undecided,Incomplete] https://launchpad.net/bugs/1838644
<tjaalton> lotuspsychje: hi, tested -12 yet?
<lotuspsychje> tjaalton: no, did you own build or from mainline? can you link plz?
<tjaalton> same link
<tjaalton> https://aaltoset.kapsi.fi/bisect/
<lotuspsychje> ok lets test
<tjaalton> fifo underruns would match the expected symptom
<tjaalton> I'm going to be afk for a bit.. but will check once back
<lotuspsychje> tjaalton: Rootbox 5.0.0-rc1 #12 working : )
<tjaalton> really?
<tjaalton> it's basically 5.0-rc1
<tjaalton> now you can bisect using mainline rc builds while I'm gone
<tjaalton> back in 1,5h or so
<lotuspsychje> tjaalton: wich versions
<tjaalton> 5.0-rcN
<lotuspsychje> can you link plz
<tjaalton> same mainline repo https://kernel.ubuntu.com/~kernel-ppa/mainline
<lotuspsychje> tnx
<lotuspsychje> rc1==>rc8 right
<apw> lotuspsychje, obviously you should bisect it, -rc4 first or whatever
<lotuspsychje> apw: sorry im not really a dev, bisect means?
<apw> not a technical term, it is a search algorithm
<apw> divide-and-conquor
<lotuspsychje> can you explain a bit plz?
<apw> if you think the answer is between 1 and 10, and you can tell if your guess is too low
<apw> you would try 5
<apw> if the guess was too low you try 7.5, too high 2.5
<apw> and so on
<lotuspsychje> apw: we are looking for the bottleneck kernel version and guess into the middle?
<apw> you are doing the equivalent here
<apw> so always take a half way, eliminating half
<apw> for you you know 5.0-rc1 is good i think, and a 5.0 ubuntu kernel is bad
<apw> so likely i would test v5.0 itself next, to eliminate the ubuntu delta
<apw> then if that 5.0 fails (and you may have tested that already), v5.0-rc4 or something
<lotuspsychje> apw: so lets say i test rc5, how would i know if upper or lower is bad/good?
<apw> lotuspsychje, you know which is good, you are testing for something, like display issues right ?
<apw> so you said -rc0 does not have 'the problem' and ubuntu has 'the problem'
<lotuspsychje> apw: correct, intel gpu gives flickering at desktop boot
<TJ-> lotuspsychje: imagine you've got (to make it easy) 12 commits between the known-bad and later known-good. A bisect will build #6 first. if you report that works (good) it'll then build #3, if you report that bad, it'll then build #5, if that is good it'll build #4, if that is good you know it contains the fix. if it is bad, you know #5 contained the fix
<lotuspsychje> right
<apw> that is your test to say which way to go
<apw> if 5.0-final is good then we know ubuntu delta is faulty
<apw> if 5.0-final is bad we know the breaking commit is before 5.0 so try something later than good and before bad
<lotuspsychje> every kernel test i should update my bug with?
<lotuspsychje> apw TJ- 5.0.0-050000rc4-generic is bad
<RikMills> lotuspsychje: someone in #kubuntu reported same today: https://paste.ubuntu.com/p/JcrbHxq2hn/
<RikMills> sadly they have gone
<lotuspsychje> RikMills: can you check my bug if its related to the new KDE guy that replyed?  Bug #1838644
<ubot5> bug 1838644 in linux-hwe (Ubuntu) "Booting into desktop results in flickering" [Undecided,Incomplete] https://launchpad.net/bugs/1838644
<RikMills> lotuspsychje: no, as I said, they left the channel before I looked. I only have the log
<RikMills> I was just FYI
<apw> lotuspsychje, 
<apw> lotuspsychje, lower then 
<lotuspsychje> apw: ok
<apw> always closing the gap between good and bad
<TJ-> lotuspsychje: for what it is worth I examined the Ubuntu cherry-picked patches since 5.0.0-18.19 I think it was, comparing them with where they came from in the later kernel, and I got an indication a related patch that should have been cherry-picked was missing, but I ran out of time in analysing it in more detail to figure out which
<lotuspsychje> RikMills: did you read #12 on my bug?
<lotuspsychje> thats also a carl
<RikMills> lotuspsychje: oh, I sees. can't confirm, but seems likely
<lotuspsychje> RikMills: ok tnx for the notice
<lotuspsychje> apw: rc1 rc2 rc3 rc4 are bad
<lotuspsychje> now what?
<apw> lotuspsychje, huh ... -rc1 was reported good earlier in this channel, so now i am confused
<apw> lotuspsychje, or more specifically the thing you tested which was labelled 'basically' -rc1 by tjaalton was good
<lotuspsychje> apw: that was an own built one version from tjaalton #12
<apw> lotuspsychje, can you re-test that one to confirm it still works; if so that say -rc1..<tjaalton-12> has the fix
<lotuspsychje> sure
<lotuspsychje> Linux Rootbox 5.0.0-rc1 #12 SMP Thu Aug 1 19:38:58 EEST 2019 x86_64 x86_64 x86_64 GNU/Linux build from tjaalton confirmed still working
<apw> tjaalton, ^ it seems my mainline 5.0-rc1 is bad and that is good ... so we need to know how they differ
<apw> lotuspsychje, we need to t-jaalton now to know what to try, i assume he will be around later
<lotuspsychje> allright, tnx for your time apw 
<apw> lotuspsychje, np
<tjaalton> lotuspsychje: verify that you had -modules installed for the mainline builds, if not then i915.ko isn't available and you can't hit the bug
<tjaalton> you can also check with 'lsmod| grep i915'
<lotuspsychje> tjaalton: yeah i installed headers, modules and image on all tests
<tjaalton> weird
<lotuspsychje> tjaalton: did you check the dmesg with drm.debug=0x1e log_buf_len=4M maybe some clues there?
<tjaalton> it just verifies the bug
<lotuspsychje> ok
<lotuspsychje> tjaalton: that carl guy from my bug, also has intel 620 graphics like me
<lotuspsychje> on my NUC its intel 650 and there it doesnt happen
<tjaalton> it's not the gpu but the panel
<lotuspsychje> ah
<tjaalton> your nuc doesn't have one
<lotuspsychje> correct
<tjaalton> is it a 4k unit?
<tjaalton> resolution
<lotuspsychje> Resolution: 1920x1080@60.01hz
<tjaalton> ok
<tjaalton> so I don't know what to do now
<lotuspsychje> tjaalton: im currently browsing older bugs on underrun errors
<lotuspsychje> so far i didnt have customers calling for issues yet
<tjaalton> I wonder if your testing of my -12 was just incomplete, meaning that maybe it'd start to flicker later or something
<lotuspsychje> tjaalton: from my testing, i can reproduce pretty similar, aka, few seconds i see desktop, then the flickering starts heavy, cant do anything anymore in between
<tjaalton> maybe double check if you have i915 loaded with -12
<lotuspsychje> i am https://paste.ubuntu.com/p/4W83KkgT6M/
<tjaalton> yep
<lotuspsychje> tjaalton: im browsing this currently, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1550779
<ubot5> Ubuntu bug 1550779 in linux (Ubuntu) "[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun" [Medium,Confirmed]
<lotuspsychje> as they also mentioning flickering
<lotuspsychje> and jeremy31 found just this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824216
<ubot5> Ubuntu bug 1824216 in linux (Ubuntu Disco) "Linux 5.0 black screen on boot, display flickers (i915 regression with certain laptop panels)" [Undecided,Fix released]
<tjaalton> that was a revert of a commit 
<tjaalton> a regression in 5.0.x stable branch
<tjaalton> lotuspsychje: could you post dmesg without debug output from both -12 and mainline 5.0-rc1 somewhere..
<tjaalton> trying to search for hints why the other fails while the other doesn't
<lotuspsychje> on it
<tjaalton> btw, check for bios updates
<lotuspsychje> RC1: https://paste.ubuntu.com/p/QFJY3jNSHb/
<lotuspsychje> #12: https://paste.ubuntu.com/p/hTXK4KmgVS/
<tjaalton> thanks, I'll have a look..
<lotuspsychje> ty tjaalton 
<lotuspsychje> another fact i just found out, pressing backlight Fn+ F8/F9 brightness makes it flicker more
<tjaalton> they look mostly the same, my kernel has a slimmer config but all the framebuffer/drm things look the same on both
<apw> tjaalton, so perhaps a timing issue?  the extra weight changing the timing ?
<apw> could you perhaps make your kernel using the other config and see?
<tjaalton> sure
<tjaalton> lotuspsychje: -13 is built, using identical config as mainline rc1
<lotuspsychje> on it tjaalton 
<tjaalton> apw: I'm using 'make bindeb-pkg' btw, and gcc 7.4.0 from bionic. the mainline builds are built on a newer distro?
<apw> likely so yes
<apw> prolly against disco
 * apw realises he could use the version data to produce multiple, but uggg
<lotuspsychje> tjaalton: its flickering https://paste.ubuntu.com/p/B3WQDxfwdK/
<tjaalton> phew
<lotuspsychje> is that a good phew?
<tjaalton> yes
<lotuspsychje> yay
<tjaalton> at least we have a baseline now...
<lotuspsychje> well done tjaalton ; )
<tjaalton> ngh, looking at the config diff makes me sad
<tjaalton> let's just bisect
<tjaalton> I'll build drm-intel-next-2019-02-02 now, which was what you tested as -11 with the old config
<lotuspsychje> okay
<tjaalton> lotuspsychje: -14 is uploaded
<lotuspsychje> lets test
<lotuspsychje> tjaalton: Linux Rootbox 5.0.0-rc1 #14 SMP Fri Aug 2 16:28:16 EEST 2019 x86_64 x86_64 x86_64 GNU/Linux
<lotuspsychje>  working
<tjaalton> great
<tjaalton> now the actual bisecting can start..
<lotuspsychje> good luck
<tjaalton> you're still testing them :P
<lotuspsychje> apreciating the work you doing mate, its the least i can do
<tjaalton> my part is just mechanics, building kernels
<tjaalton> takes maybe 5min to build
<lotuspsychje> sure, coffee to the rescue :p
<tjaalton> beer
<lotuspsychje> lol
<tjaalton> ok it took 15min, -15 is available
<lotuspsychje> lets fire it up
<lotuspsychje> tjaalton: 5.0.0-rc1+ boot this now?
<tjaalton> yes
<lotuspsychje> allrighty
<lotuspsychje> tjaalton: + is flickering
<tjaalton> cool
<tjaalton> lotuspsychje: -16 done
<lotuspsychje> okay tnx
<lotuspsychje> tjaalton: 16 flickering
<tjaalton> great
<lotuspsychje> : )
<tjaalton> the actual compile takes a minute, then building the package takes 10
<lotuspsychje> dont worry mate, im used to idle
<tjaalton> lotuspsychje: -17 uploaded
<lotuspsychje> allrighty!
<lotuspsychje> tjaalton: Linux Rootbox 5.0.0-rc1+ #17 working!
<tjaalton> aha
<tjaalton> lotuspsychje: -18 up
<lotuspsychje> okay
<lotuspsychje> tjaalton: -18 flickering
<tjaalton> got it
<tjaalton> meanwhile, you could try booting 18 with 'i915.fastboot=1'
<lotuspsychje> tjaalton: im always installing ubuntu in legacy, will that param have effect?
<tjaalton> dunno
<lotuspsychje> ok lets try
<tjaalton> could be it's "drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen" but we have that backported in 5.0 already
<tjaalton> but if bisect points to it, then it needs some other commit(s) to work...
<tjaalton> -19 uploading
<lotuspsychje> want me to test 18 with param first?
<tjaalton> either way
<tjaalton> hmm maybe yes, if this replaces 18
<lotuspsychje> tjaalton: fastboot trick on -18 worked
<tjaalton> ha
<tjaalton> a true head-scratcher...
<tjaalton> lotuspsychje: and no fifo underruns in dmesg?
<lotuspsychje> https://paste.ubuntu.com/p/4GN5kzzJCq/
<tjaalton> that would be a no then
<lotuspsychje> tjaalton: try -19 now?
<tjaalton> lotuspsychje: so, boot the distro kernel with fastboot
<tjaalton> -19 should be bad
<lotuspsychje> 5.0.0.23 with fastbbot right?
<lotuspsychje> boot
<tjaalton> yep
<lotuspsychje> kk
<tjaalton> and then maybe boot 5.1 mainline with fastboot=0
<tjaalton> to rule this out
<lotuspsychje> tjaalton: working! 5.0.0-23-generic #24~18.04.1-Ubuntu
<tjaalton> now try suspend&resume :)
<lotuspsychje> tjaalton: suspend makes it flicker
<tjaalton> bingo
<lotuspsychje> \o/
<tjaalton> so, boot 5.1 with fastboot=0
<tjaalton> maybe add it to /etc/default/grub so that it's always there
<tjaalton> GRUB_CMDLINE_LINUX
<lotuspsychje> yeah im doing it that way
<tjaalton> cool
<lotuspsychje> tjaalton: i got a 5.1.0 and 5.1.21
<tjaalton> boot .21
<lotuspsychje> allrighty
<lotuspsychje> tjaalton: i915.fastboot=0 on 5.1.21 flickering
<tjaalton> marvellous
<tjaalton> apw: recent drm-tip builds have failed
<tjaalton> 07-30 is the latest
<tjaalton> drm-next too
<tjaalton> um, drm-intel-next that is
<tjaalton> lotuspsychje: install this https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2019-07-30/
<lotuspsychje> allrighty
<tjaalton> if it's broken, then all we can do is wait for the guy at intel responsible for this to return from vacation :P
<lotuspsychje> tjaalton: boot with fastboot=0 ?
<tjaalton> or bisect where it broke, but I'd say reverting something at this point would risk breaking it for others
<tjaalton> yes
<lotuspsychje> cross your fingerz
<lotuspsychje> tjaalton: 5.3 with fastboot=0 working
<lotuspsychje> try suspend?
<tjaalton> sure
<tjaalton> but that sounds promising
<lotuspsychje> not flickering
<tjaalton> try latest 5.3-rc then
<lotuspsychje> rc2?
<tjaalton> yes
<lotuspsychje> tjaalton: 5.3.0-050300rc2-generic working, but it doesnt wanna suspend
<tjaalton> ok, good. now test 5.2.5
<lotuspsychje> ok
<lotuspsychje> tjaalton: 5.2.5 flickering
<tjaalton> okay
<tjaalton> lotuspsychje: try this one https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2019-06-20/
<lotuspsychje> installing
<tjaalton> lotuspsychje: if that works, try the one before that
<tjaalton> on the parent dir
<tjaalton> and so on
<lotuspsychje> okay
<tjaalton> once we have known good/bad, it's time for another bisect..
<tjaalton> but I'm about to hop on a swimming pool :P
<lotuspsychje> tjaalton: 2019-06-20/ 5.2.0 flickering
<tjaalton> oh
<tjaalton> only a handful of commits between that and 5.3-rc2
<tjaalton> but a new build will take closer to an hour now
<lotuspsychje> allrighty, lets take a break :p
<tjaalton> 19 commits of which two are suspicious
<tjaalton> but both seem to fix commits not in 5.0 :/
<tjaalton> ok, swim/beer break
<tjaalton> lotuspsychje: -20 uploaded
<tjaalton> 5.2.0-rc4+
<tjaalton> lotuspsychje: ping?
<lotuspsychje> tjaalton: ok lemme test
<lotuspsychje> tjaalton: 5.2.0 rc4 flickering
<tjaalton> alright
<tjaalton> building the next one, seems to take a while
<lotuspsychje> okay tnx
<lotuspsychje> tjaalton: i need to still test them all with fastboot=0 right?
<tjaalton> yes
<lotuspsychje> kk
<tjaalton> lotuspsychje: -21 finally uploaded
<lotuspsychje> allrighty!
<lotuspsychje> tjaalton: -21 also flickering
<tjaalton> thanks
<tjaalton> building
<lotuspsychje> cool
<tjaalton> lotuspsychje: -22 uploaded
<lotuspsychje> okay
<lotuspsychje> tjaalton: -22 also flickering
<tjaalton> okie
<lotuspsychje> tjaalton: was the last one for today for me, ill continue tomorrowz ok
<tjaalton> ok
<tjaalton> I'll push 23 once it's ready, you'll find it in the same place
<lotuspsychje> allrighty!
<lotuspsychje> ill test when i wake
<tjaalton> thanks
<jeremy31> I just tried the 5.0.0-23 kernel on my laptop with the Intel UHD 620 graphics and have no flicker
#ubuntu-kernel 2019-08-03
<lotuspsychje> good morning to all 
<lotuspsychje> tjaalton: morning mate, 5.2.0+ #23 is working
<tjaalton> lotuspsychje: cool, building the next
<lotuspsychje> neat tjaalton 
<tjaalton> lotuspsychje: 24 uploaded
<lotuspsychje> ok tnx
<lotuspsychje> tjaalton: 5.2.0+ #24 is working
<tjaalton> ok
<tjaalton> lotuspsychje: 25 uploaded
<lotuspsychje> tjaalton: ok
<lotuspsychje> tjaalton: #25 is flickering
<tjaalton> lotuspsychje: ok, bisect ended and the result isn't anything sensible :(
<lotuspsychje> aww
<lotuspsychje> tjaalton: tnx for your time anyway, i got other users who affected on my bug aswell, i hope that will enlight us more
<tjaalton> I'll build some more
<lotuspsychje> kk
<lotuspsychje> tjaalton: i might hop on/off today, just ping me ok ; )
<tjaalton> yep
<tjaalton> building drm-intel-next-2019-07-08
<lotuspsychje> nice
<tjaalton> lotuspsychje: 26 uploaded
<lotuspsychje> kk
<lotuspsychje> tjaalton: 26 flickering
<lotuspsychje> bbl first now
<tjaalton> ok
<tjaalton> so I think the test result with 5.3-rc2 was bogus, there was probably some timing thing again as with 5.0 earlier
<lotuspsychje> tjaalton: ok, lemme know whats the next plan :p
<lotuspsychje> tjaalton: think this is useful? https://lore.kernel.org/lkml/1477510599-14843-1-git-send-email-lyude@redhat.com/
<tjaalton> no?
<lotuspsychje> ok
<tjaalton> that's ancient, and those have been in the kernel for a couple of years now
<tjaalton> check if there are bios updates..
<tjaalton> I need to cherry-pick drm/i915 changes from drm-intel-next-2019-07-30 on top of what you tested last, without any fluff from 5.3
<tjaalton> but that's not happening today or tomorrow, spent quite a bit of my "free" time on this already :)
<lotuspsychje> allright, tnx for trying anyways
#ubuntu-kernel 2019-08-04
<fling> How do I extract shiftfs from this 15M patch? -> https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.63/0001-base-packaging.patch
<lotuspsychje> tjaalton: i updated my flickering bug a bit with some different ubuntu releases/kernels and seems like lubuntu 19.04 with kernel 5.0.0.13 works bug #1838644
<ubot5> bug 1838644 in linux-hwe (Ubuntu) "Booting into desktop results in flickering" [Undecided,Confirmed] https://launchpad.net/bugs/1838644
<TJ-> fling: don't; use the git repo
<fling> TJ-: I have no idea in which repo to get a shiftfs patch for the specific version
<TJ-> fling: the index page gives the repo URL and branch to pull from
<fling> thanks
<tjaalton> lotuspsychje: ok, I'm building 5.0.0-23 with one revert
<lotuspsychje> tnx
<lotuspsychje> tjaalton: ill be afk for a while, ill find your ping later ok
<tjaalton> ok, should be ready any minute now
<lotuspsychje> oh all wait up then
<tjaalton> silly kernel build is mostly serial
<tjaalton> at least with >64 cores
<lotuspsychje> :p
<lotuspsychje> tjaalton: we are looking for a working one this time right?
<tjaalton> maybe
<tjaalton> hopefully
<lotuspsychje> kk
<tjaalton> only seven commits to i915 since 5.0.0-13, and one looks suspicious
<lotuspsychje> tjaalton: i saw that underrun error on lubuntu too, but it didnt flicker
<tjaalton> ah
<tjaalton> didn't try ubuntu 19.04?
<lotuspsychje> yes in a live
<lotuspsychje> those gave me flickering
<tjaalton> 19.04 live with 5.0.0-23? how's that possible
<tjaalton> it shipped with -13
<lotuspsychje> oh i might be wrong about that perhaps
<lotuspsychje> but 19.04 desktop surely flickered
<tjaalton> then this test build is likely pointless
<lotuspsychje> well if both have -13 and one works and the other not?
<lotuspsychje> its an ubuntu-desktop related issue then?
<tjaalton> no
<tjaalton> it just manifests in a different way
<tjaalton> you still get underruns
<lotuspsychje> ah
<tjaalton> did you look for bios updates?
<lotuspsychje> not yet no, i found the clevo updates link
<lotuspsychje> tjaalton: also weird is, i didnt get calls yet from any other clevo customer
<lotuspsychje> and they the other guy from my bug, its also a clevo with a different bios version
<lotuspsychje> anyway, need to bbl first
<lotuspsychje> ill test it when im back
<tjaalton> copying to the repo
<tjaalton> done
<TJ-> we really ought to have an automated tool for this :)
<TJ-> self-service
<lotuspsychje> tjaalton: no dice : (
<tjaalton> not surprised
<fling> TJ-: is there a tool for getting the shiftfs patch off there?
<fling> git is way too slow
<fling> I cloned deep enough but I only found shifts in the log in commit fea6d2a610c899bb7fd8e95fcbf46900b886e5a3 vfs: Use upper filesystem inode in bprm_fill_uid()
<fling> This does not look like a shiftfs patch
<fling> So how do I get it exactly?
#ubuntu-kernel 2020-07-27
<ricotz> ppisati, hi :), is Ubuntu-5.7-5.7.0-17.18 built somewhere yet?
#ubuntu-kernel 2020-07-29
<linuxr> hello anyone..so I've just had this situation where my 4 gigs of memory were exhausted because of firefox, resulting in a complete system freeze. How can this happen in 2020? How can one single process take all the memory and not being prevented by the OS?
<linuxr> what about OOM-killer?
<ogra_> what about it ? it randomly kills processes if you run out of ram
<ogra_> (it is a blindfolded berserk ...)
<linuxr> ogra_, apparently it did not work at all
<ogra_> well, it only kicks in if all your ram *and* all your swap space is used up ... are you sure the system wasnt still swapping ?
<linuxr> ogra_, maybe it was, but the music stopped, the cursor froze, and keyboard was dead
<linuxr> I'd prefer to completely disable swap then, how would I do that?
<trippeh> generally it will remain locked up for a while before it recovers (the situation is a bit sad, yes)
<trippeh> a while = could be hours
<linuxr> lol..can this somehow be tuned to agressively kill havoc processes?
<ogra_> iirc if you disable swap the kernel uses a completely different code path for memory mgmt ... not sure thats a good idea
<ogra_> (not sure if it still does it ... it was around 3.x times i looked at that last)
<linuxr> there must be a way to fix this
<linuxr> I mean, any shitty website can mess up my system as it appears
<ogra_> systemd is working on fixing it by trying to add an "intelligent" oom killer ... but not sure how far out that is
<ogra_> but yeah ... DOSing isnt easy to work against ... 
<trippeh> generally, disabling overcommit helps - but there also plenty of things that expect to overcommit a lot, so.
<linuxr> I'd be quite happy with a script that periodically checks memory usage and kills the most agressive process(es) in case a critical level is reached
<linuxr> how hard can it be to implement something like that?
<ogra_> try it ?
<ogra_> (i'm sure there is prior art though ... and you can always set the oom_score for your processes if needed so they get killed first)
<linuxr> the bad thing is, I've been using linux for over a decade and cannot remember something like this was happening in all that time
<ogra_> well, then facebook came aroud and created full apps inside your browser windows 
<ogra_> (and filled the remaining free ram with ads)
<linuxr> maybe that is the problem
<linuxr> web bloat
<ogra_> tell mark zuckerberg ð
<linuxr> but still, this should not tear down my system
<linuxr> it should just be handled properly (e.g. killed) when it gets too nasty
#ubuntu-kernel 2020-07-30
<ppisati> LocutusOfBorg: hi there - we are about to put a 5.8 into groovy -proposed
<ppisati> LocutusOfBorg: and i think the virtualbox dkms needs an update
<LocutusOfBorg> ppisati, thanks
<LocutusOfBorg> but meh, ENOYETPATCH
<ppisati> LocutusOfBorg: AFAIK, this is the vbox vs 5.8 status: https://www.virtualbox.org/ticket/19644
<LocutusOfBorg> https://www.virtualbox.org/ticket/19644
<LocutusOfBorg> yep, I was mentioning that
<LocutusOfBorg> I have to see in mail list if all agreeded on the implementation
<LocutusOfBorg> last time I had a look, it was not complete
<ppisati> LocutusOfBorg: ack
<LocutusOfBorg> in any case, please go ahead, and I'll followup and fix
<LocutusOfBorg> I'll do it now if the patch is good already
<LocutusOfBorg> ppisati, https://www.virtualbox.org/attachment/ticket/19644/local_patches
<ppisati> LocutusOfBorg: yep, it requires a kernel patch
<LocutusOfBorg> oh ok so we are good :D
<LocutusOfBorg> uploading in debian, will autosync in 12h or so
<LocutusOfBorg> virtualbox-hwe: uploading now
<ppisati> LocutusOfBorg: did you pull in those 3 patches?
<LocutusOfBorg> yep
<ppisati> LocutusOfBorg: ack
<LocutusOfBorg> meh, uploaded also in Ubuntu, so you can test it
<LocutusOfBorg> machine time is cheap
<ppisati> LocutusOfBorg: ta
