#ubuntu-kernel 2005-12-19
<zul> heylo
<zul> grrr...
<zul> Missing /home/chuck/kernel/builds/kotd/build/ubuntu-2.6/debian/abi/2.6.15-8.10/i386/dbg file
<zul> how do you disable the abi check?
<zul> nevermind
<BenC> debian/rules skip_abi=true build
<BenC> gonna need something better than dbg though
<BenC> it shouldn't be a new config target
<BenC> it should be created out of the already done builds
<BenC> using debian/post-install you should be able to grab the appropriate parts and create a .deb, just like linux-headers-* gets made
<jbailey> BenC: Remember that whole "doesn't seem to be crashing on me" thing?
<jbailey> *sigh*
* jbailey shakes his fist at X and wanders off for food.
<BenC> lol
<mgalvin> would there happen to be a short list of some new supported hardware, or should I just scrounge the package logs?
<mgalvin> just wondering b/c i am working on https://wiki.ubuntu.com/DapperFlight2
<Kamion> glad you told me before I sent out the release announcement ;-)
<mgalvin> :)
<mgalvin> its not all done yet, but almost
<Kamion> my announcements generally just list changes affecting the installer and the live CD boot process, since those are things people can't easily pick up just by following upgrades on a normal system
<Kamion> i.e. "why should you download this CD image rather than use your last one and upgrade" kind of things"
<Kamion> of course a page like yours is definitely worthwhile for other reasons - glad, if surprised, to see it :)
<mjg59> Kamion: You really should be in bed
<Kamion> so should you
<mgalvin> glad to write it, i thought it would be nice to provide a higher level overview of new features so people can see all the great progress being made more easily
<Kamion> is your intent to provide a delta from Flight 1, or from Breezy?
<Kamion> (just checking - I think the former's more valuable at the moment)
<mjg59> Kamion: But I've just got back from a crap club, so I've got an excuse
<mjg59> (Not drunk at all, honest)
<mgalvin> flight 1-2 delta
<Kamion> right
<mgalvin> agreed
<BenC> mgalivn: s/lowend//  s/highend/bigiron/ for server kernels
<BenC> server and server-bigiron, but same description
<mgalvin> BenC: done!
<infinity> BenC : Alive, still?
<infinity> [17179886.376000]  ata2: command error, drv_stat 0x51 host_stat 0x0
<infinity> [17179886.380000]  ata2: command error, drv_stat 0x51 host_stat 0x0
<infinity> [17179886.384000]  sr0: CDROM (ioctl) error, command: <6>Test Unit Ready 00 00 00 00 00 00
<infinity> [17179886.384000]  sr: Current: sense key: Hardware Error
<infinity> [17179886.384000]      Additional sense: Focus servo failure
<infinity> Over and over and over again.
<infinity> (ata_piix, -8.10)
<infinity> BenC : The disk driver seems fine, but atapi (the CD/DVD drive) is doing that as nauseum.
<infinity> s/as/ad/
<fabbione> BenC: 
<fabbione> Err http://archive.ubuntu.com dapper/main Sources                              
<fabbione>   Connection failed [IP: 82.211.81.182 80] 
<fabbione> Err http://ports.ubuntu.com dapper/main Packages
<fabbione>   Connection failed
<fabbione> are you having net access problem?
<fabbione> i can't update the chroots on zachery
<BenC> infinity: you are getting the 0x51 too
<BenC> guess I need to disable ATAPI on that driver.
<infinity> ... But wasn't I using ATAPI on it with -7.9?
<infinity> (In fact, wasn't the LACK of ATAPI on that driver what led to me having no CD/DVD drive at all, then enabling it gave me a CD...)
<infinity> Which worked fine, until the latest kernel upgrade.
<fabbione> good morning Ban
<fabbione> as soon as you show up the e3k disappear :)
<fabbione> BenC: did it die completely or is it just the vtun?
<BenC> died
<BenC> infinity: I had a guy had that same error with -7.9, and upgrading to -8.10 broke it
<BenC> fabbione: and it's below zero outside, so it will be a few minutes before I go reboot it :)
<BenC> infinity: err, upgrading to -8.10 didn't fix it
<BenC> infinity: are you using 2.6.15-8-686?
<infinity> BenC : Hrm.  Well, I was fine with -7.9, only -8.10 throws the error...
<infinity> BenC : yes, -686 in both cases.
<BenC> infinity: if so, can you try this replacement module: http://bugzilla.ubuntu.com/attachment.cgi?id=5314
<fabbione> BenC: eheh ok.. it was building the kernel tho :/
<fabbione> almost at the end
<BenC> the bu submitter tried it, but I'm not entirely certain he booted correctly with it
<BenC> fabbione: lol, ok
<BenC> sarcastic and belittling remarks toward me in a bug report
* BenC marks it P4 and minor out of spite
<infinity> BenC : Can you bug me about testing that tomorrow?... I'm in no position to reboot anything right now, and it's bedtime to boot.
<BenC> ok
<zul> heylo
<jbailey> Zooool
<mgalvin> morning all
<Kamion> hmm, prism54 firmware upload doesn't seem to be working
<BenC> not working as in it says it fails, or as in it uploads, but prism54 driver doesn't work afterwords?
<jbailey> Kamion: IIRC, Scott moved the firmware directory.
<Kamion> prism54: request_firmware() failed for 'isl3890'
<Kamion> the firmware's in /lib/firmware/isl3890 so I wonder if the driver's looking in the wrong place
<Kamion> or maybe if there's no firmware handling in udev-udeb ...
<jbailey> The firmware mechanism always confuses me, but I think it sends a udev event asking for it to be stuffed into the right file in /sys
<jbailey> I can fire up my laptop and upgrade it if you want me to check.
<Kamion> ah, I think it's the latter
<Kamion> no 80-programs.rules, and no firmware_helper
<Kamion> ok, errata
<fabbione> can somebody kindly tell Ben that i am abusing his sparc?..
<fabbione> thanks :)
<fabbione> later
<zul> child abuser
<mgalvin> i added a few things to https://wiki.ubuntu.com/DapperFlight2 and it is i think mostly all set, if anyone could review it one last time that would be great, thnx
<Kamion> just in time, too, I'm publishing the images
<mgalvin> :)
* Kamion goes through removing some apostrophes and stuff
<mgalvin> i am also, hopefully soon, move the images from my server to doc.ubuntu.com server
<Kamion> Perhaps it should link to ubuntu-devel-announce rather than ubuntu-announce, since the former's where the announcement is going?
* mgalvin worries about ./ effect on my pockets
<mgalvin> thats fine
<mgalvin> i just copied that bit from DapperReleaseNotes
<mgalvin> so do we have support for the broadcom wifi chips?
<Kamion> a prerelease of the driver is in but the firmware isn't
<Kamion> I don't think it's really right to say we support it until we've come to some kind of arrangement to be able to distribute firmware
<mgalvin> ok, just wondering, i received a few suggestions and that was one of them
<mgalvin> Kamion: also just added a small Note (warning)
<mgalvin> at the top
* Kamion nods
<BenC> fabbione: your kernel build appears done
<CataEnry> hi all
<fabbione> BenC: yes i saw thanks.. i will wait tomorrow to upload otherwise i will kill your bw.
<fabbione> bbl
<BenC> you can start the upload at the meeting tonight if you want
<BenC> that is in about 13 hours, right?
<jbailey> Ugh.  It's the middle of the night meeting tonight, isn't it.
<BenC> yep
<BenC> 3am for me and you Jeff
<zul> heh...i probably wont be there then
<zul> unless i cant sleep
<doko> mgalvin, Kamion: OOo2 is not 2.0.0 final, but 2.0.1 rc2
<mgalvin> doko: ah, good catch, fixing now
<doko> already fixed :)
<mgalvin> :) k, cool
<slushpupie> so are the timestamps in the kernel messages (dmesg, et. al) from a ubuntu specific patch, or where did those come from?
<dilinger> what is this (in breezy), anyways?
<dilinger> tmpfs                 506M   13M  494M   3% /lib/modules/2.6.12-10-686-smp/volatile
<dilinger> i assumed it was an initramfs thing, but grepping for volatile in /usr/share/initramfs-tools brings up nothing
<BenC> jbailey: is therm_pm72 working for your G5?
<BenC> I've loaded it on mine, and the fan is still blowing like a wind tunnel
<BenC> dilinger: linux-restricted-modules, IIRC
<jbailey> BenC: It's fine here.
<BenC> dilinger: I think it has to do with boot-time linking for some GPL violating modules
<BenC> jbailey: was there something else you had to do besides loaidng therm_72pm?
<BenC> pm72 I mean
<BenC> does it show anything in dmesg?
<jbailey> Nope.
<jbailey> I'm on the phone, lagging.
<BenC> np
<BenC> sucks, just booted flight2 live on my G5, and it's steady fan
<jbailey> jbailey@starshine:~$ dmesg |grep pm72
<jbailey> jbailey@starshine:~$
<BenC> maybe therm_pm72 was just xserve
<dilinger> BenC: ah
<dilinger> thanks
<BenC> I think I found mine
<BenC> windfarm_pm81 or windfarm_pm91, not sure which
<BenC> it shows therm control now in dmesg, and shows all my fans, but hasn't slowed them down any
<BenC> windfarm, that's definitely what this sounds like in here
<BenC> windfarm_pm91, for G5 Desktop, 81 is for iMac G5
<BenC> so this should be working
<BenC> jbailey: can you cat /proc/cpu and tell me what your cpu is (PowerMacX,Y string)?
<BenC> /proc/cpuinfo
<jbailey> motherboard     : PowerMac7,3 MacRISC4 Power Macintosh
<BenC> yeah, mines 7,2, so you and I both use therm_pm72
<BenC> 8,1 and 9,1 are much newer I guess
<fabbione> BenC: i won't be at the meeting.. i will be flying to another city to give a talk at that time :)
<zul> hey fabbione 
<fabbione> hi zul
<BenC> fabbione: how much longer till you leave?
<fabbione> i will leave in 11 hours
<fabbione> + or -
<BenC> ok, start the upload when you leave, and it should be good
<fabbione> sure.. no problem..
<fabbione> BenC: let's do it even simpler.. all the kernel is in /org/chroots/uploadqueue/
<fabbione> before you go to sleep just scp it to chinstrap in your home
<fabbione> i will sign the changes and upload to jackass when i wake up
<fabbione> so it won't bother anybody at all
<juliux> hi all
<juliux> i have a hp nx6110, with the live cd i can use the vga out, but if i try to use it with my installed breezy i get this kernel error: localhost kernel: [4297060.659000]  video bus notify
<juliux> what can i do?
<zul> check google or check in #ubuntu
<juliux> zul, in #ubuntu nobody knows and google hits are all on kernel packages
<juliux> so i ask here
<BenC> fabbione: ok
<BenC> mjg59: ping
<BenC> juliux: the "video bus notify" comes from acpi, try disabling acpi (noacpi or acpi=off, can't remember)
<juliux> BenC, ok thanks
<juliux> i will test it
<zul> BenC: can you do a pull from me later tonight i have one of two patches in my stable queue for you
<BenC> ok, thanks
<zul> i just have have to update the changelog
<juliux> BenC, with acpi=off it works but then supsend don't work, is this a kernel bug or acpi bug?
<BenC> probably hw bug
<juliux> shit
<BenC> check for newer BIOS, or for an alternate DSDT
<juliux> i think that a hp nx6110 works perfect
<juliux> but no i have allready trouble
<juliux> ok thank you for your help
<BenC> sure thing
<fs> I get an error updating my ubuntu-2.6 git
<fs> rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/upstream" (in pub) failed: No such file or directory (2)
<fabbione> fs: sucks to be you :P
<fs> heh
<fs> well, I am not really used at using git
<fs> I run git pull on my tree
<fabbione> there is a git version around that's borked heavly
<fabbione> try a full clone of death
<fabbione> or upgrade git
<fs> latest debian sid version
<fabbione> would that be j or l?
<fs>  0.99.9k
<fs> hehe
<fabbione> it's the broken one
* fabbione ^5s fs
<fs> wonderful
<fabbione> fs: suggestion... grab git from kernel.org :)
<fabbione> and use that one
<fs> well
<fs> I guess I'll do that
<fs> thanks anyway =)
<fabbione> no problem
<fs> btw, remember the never ending story I had at work with GFS and the borked storages?
<fs> looks like the suppplier finally managed to get them configured correctly, they don't reset on too much io-wait anymore now
<fs> this has been an issue since april
<fabbione> ah
<fabbione> so it was hw
<fabbione> nice to know
<fabbione> i am off to bed
<fabbione> cya tomorrow or friday
<jbailey> fabbione: Not at the meeting tonight?
<fabbione> jbailey: it's tomorrow morning for me
<jbailey> Bastard. =)
<fabbione> and no i won't be there
<fabbione> it was 3am last time for me :)
<fs> n8 fabbione
<fabbione> jbailey: i am going to give an Ubuntu talk tomorrow on the other side of DK
<fabbione> i will miss the meeting by 20 minutes or so
<jbailey> Excuses, excuses.
<fabbione> eh no
<fabbione> i have been telling since 2 weeks ago :)
<fabbione> jbailey: and it's at 9am for me :)
<fabbione> i already gave blood at 3am last time
<AcidPils> hi
<AcidPils> stupid acx :(
<AcidPils> association FAILED: peer sent response code 10 (Cannot support all requested capabilities in Capability Information field) <-- any ideas?
<mjg59> BenC: Hi
#ubuntu-kernel 2005-12-20
<BenC> mjg59: I had a bug I wanted you to look at...trying to find it
<BenC> 20979
<infinity> BenC : Still want that module tested?
<infinity> BenC : Should I be suspicous about the drastic file size difference? :)
<BenC> nah, it's all good :)
<BenC> he reports no difference, but I find that hard to believe
<infinity> What did you change?
<infinity> Other than shrinking the module. :)
<infinity> Mess of printks all over the place with your name on them? :)
<infinity> Oh, that's funny.
<infinity> You know that assertion I was getting every time I ran update-initramfs?
<infinity> Don't see that anymore... (of course, I get the spew of other erros instead)
<infinity> Anyhow, ready to reboot.  Back in a few.
<infinity> Ah-ha.
<infinity> BenC : I guess you just rolled back to an older version of ata_piix? :)
<infinity> Scary ATAPI errors gone, failed assertion back.
<mjg59> BenC: Weird. Haven't seen that.
<BenC> infinity: so the errors are definitely gone
<BenC> infinity: can I add you to CC for this bug?
<infinity> BenC : Sure.  I didn't add myself when I commented, but go ahead.
<fabbione> morning
<fabbione> hey BenC 
<BenC> hey fabbione
<fabbione> i am uploading the kernel right now
<fabbione> i thought you went to sleep
<BenC> my turn to be up at 3am :)
<fabbione> yeah i know
<fabbione> i need a smoke
<BenC> yeah, me too
<infinity> New kernel again?
<infinity> New ABI too?
<BenC> yep
<infinity> Or just bugfixes?
<infinity> Feh. :)
<BenC> fabbione's kernel upload is sparc64 8.10 build
<BenC> my kernel upload is waiting on hppa abi files so I don't ftbfs :)
* BenC finds out he can get a PowerMac G5 Quad for $1650
<infinity> !
<infinity> Send me one!
<BenC> there's a limit of one :)
<BenC> 256Mb nvidia card too, 250Gig ATA drive
<fabbione> BenC: ah new crack?
<BenC> 2xdual-core-2.5ghz cpu's
<fabbione> BenC: i know benh bought one
<fabbione> the kernel still doesn't really support it in full :)
<fabbione> and he is hacking heavily on it
<BenC> it comes pre-installed with YDL
<BenC> YDL and OSX
<BenC> but I have an offer of one machine, and I think I want to get a 17" powerbook
<fabbione> BenC: the powerbook i got is sweet
<fabbione> but it's a bit fragile
<fabbione> keybord is teh sux
<fabbione> i need to get a new one already
<BenC> damn, that does suck
<fabbione> keys are falling off and some of them get stucked.. go figure
<BenC> but I need a laptop...the one I had at UBZ, I just took it back and got a refund
<BenC> and powerbook 17" display is nice
<fabbione> oh yeah
<fabbione> the display is COOL
<BenC> plus it will give me a chance to test bcm43xx with the airport2 wireless
<fabbione> ehhehe
<infinity> I don't know very many powerbook owners who say they'd buy one again.
<BenC> pitti loves his :)
<fabbione> i wanted one becuase i needed a ppc
<infinity> Well, Apple fanatics, maybe, but not in the FLOSS world, where we're more hardware agnostic.
<fabbione> but yeah.. i heard that too
<fabbione> specially from elmo
<infinity> pitti is an exception to many rules. :)
<fabbione> he had to change his PB.. dunno how many times
<infinity> He's also an iBook user, which makes a qorld of different.
<infinity> difference, too.
<infinity> Only because the iBooks are much cheaper, so you don't feel so ripped off. :)
<infinity> OTOH, if you like laying out lots of cash, everyone in the company (me included) seems to be deeply in love with IBM.
<infinity> Go figure.
<infinity> I'd recommend the G5 desktops over the PowerBooks anyday, if you want/need a PPC machine.
<BenC> well, the pb will be at a reduced price too...get IBM to take %40 of the list price, and I'll go buy one :)
<BenC> I already have a G5 and 2 G4's, so I'm not really in need of anymore ppc's, just that I like powerbook looks
* fabbione waits for katie love on kernel
<fabbione> BenC: you got your bw back
<BenC> thanks
<fabbione> weird is that i managed to upload up to 40K
<fabbione> sometimes even faster
<BenC> really? damn, that's more like I am supposed to get
<BenC> maybe it's the atmosphere tonight giving me better xmit signal :)
<fabbione> linux-source-2.6.15_2.6.15-8.10_sparc.changes 100%   10KB  10.1KB/s   00:00    
<fabbione> cdrom-core-modules-2.6.15-8-sparc64-di_2.6.15 100%   54KB  54.2KB/s   00:00    
<fabbione> crc-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100% 2376     2.3KB/s   00:00    
<fabbione> ext2-modules-2.6.15-8-sparc64-di_2.6.15-8.10_ 100%   39KB  38.8KB/s   00:00    
<fabbione> ext3-modules-2.6.15-8-sparc64-di_2.6.15-8.10_ 100%  107KB 107.3KB/s   00:00    
<fabbione> fat-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100%   40KB  39.9KB/s   00:00    
<fabbione> ide-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100%  101KB 101.4KB/s   00:00    
<fabbione> ipv6-modules-2.6.15-8-sparc64-di_2.6.15-8.10_ 100%  144KB 144.2KB/s   00:00    
<fabbione> kernel-image-2.6.15-8-sparc64-di_2.6.15-8.10_ 100% 1512KB  40.9KB/s   00:37    
<fabbione> linux-headers-2.6.15-8-sparc64-smp_2.6.15-8.1 100%  719KB  51.4KB/s   00:14    
<fabbione> linux-headers-2.6.15-8-sparc64_2.6.15-8.10_sp 100%  718KB  47.9KB/s   00:15    
<fabbione> linux-headers-2.6.15-8_2.6.15-8.10_sparc.deb  100% 6379KB  36.7KB/s   02:54    
<fabbione> linux-image-2.6.15-8-sparc64-smp_2.6.15-8.10_ 100%   13MB  36.2KB/s   06:06    
<fabbione> linux-image-2.6.15-8-sparc64_2.6.15-8.10_spar 100%   13MB  36.2KB/s   06:02    
<fabbione> loop-modules-2.6.15-8-sparc64-di_2.6.15-8.10_ 100% 7256     7.1KB/s   00:00    
<fabbione> md-modules-2.6.15-8-sparc64-di_2.6.15-8.10_sp 100%  240KB 120.2KB/s   00:02    
<fabbione> nfs-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100%  206KB 205.9KB/s   00:00    
<fabbione> nic-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100% 1008KB  43.8KB/s   00:23    
<fabbione> nic-shared-modules-2.6.15-8-sparc64-di_2.6.15 100%   10KB   9.9KB/s   00:00    
<fabbione> parport-modules-2.6.15-8-sparc64-di_2.6.15-8. 100%   39KB  39.3KB/s   00:00    
<fabbione> plip-modules-2.6.15-8-sparc64-di_2.6.15-8.10_ 100% 9364     9.1KB/s   00:00    
<fabbione> ppp-modules-2.6.15-8-sparc64-di_2.6.15-8.10_s 100%   60KB  59.9KB/s   00:00    
<fabbione> reiserfs-modules-2.6.15-8-sparc64-di_2.6.15-8 100%  158KB 158.3KB/s   00:00    
<fabbione> MEH
<fabbione> sorry
<fabbione> i meant to paste only the -images-
<fabbione> that are a bit more interesting than the small udebs
<fabbione> ok good
<fabbione> katie accepted.. or better.. stalled it in NEW
<BenC> already copied the abi files
<BenC> hppa takes so long to NEW
<infinity> Well, we weren't building hppa CDs, so Kamion didn't do "Oh my god, the sky is falling, NEW, NEW, NEW" mojo on it.
<infinity> I assume elmo just did it in his usual NEW runs, which are often, but not instant.
<fabbione> yeah Kamion doesn't NEW SCC
<fabbione> BenC: do you alraedy have the new kernel ready for upload or are you still working on it?
<BenC> still working on it
<BenC> should be ready Friday
<fabbione> ok perfect
<CataEnry> hi :)
<zul> heylo
<zul> BenC: ping pull
<BenC> zul: pong push :)
<BenC> already pulled you, just haven't merged
<zul> ok...i updated the changelog though
* BenC found out how to pull to a branch so he can keep in sync, but merge at leisure
<zul> nifty
<zul> i almost have  a kick ass build script going on
<BenC> share :)
<AcidPils> hi
<AcidPils> i finally know why acx didnt work... it gets a link, not the ap but to my RTL8180L card 
<AcidPils> head -> table
<mjg59> AcidPils: Ah...
<infinity> hahaha.
<infinity> "oops"
<AcidPils> :p
<BenC> lol
<zul> zul: i will when its ready
<zul> doh..
<zul> im not with it tonight
<zul> today even
<jbailey> zul: But you clearly mean that you won't get it together in time for tongiht ;)
<zul> shaddup :)
<jbailey> zul: I'm actually not on the phone at the moment. =)
<jbailey> Since you're already clearly stoned, shall we chat? =)
<zul> meh...
<zul> so whats involved with the grub stuff 
<jbailey> Mostly it's closing bugs with "No, grub sucks, won't fix"
<zul> thats easy enough...any other stuff
<jbailey> Occasionally there's real problems.
<jbailey> Not often, though.  In practice we haven't done much to grub since warty, and systems have been installing fine.
<jbailey> Future development is happening on grub2, which I want to package and upload to universe at least.
<jbailey> But that's such a low priority project compared to my other stuff, I don't actually know that I'll get around to doing it.
<zul> yeah but grub2 only supports a few file systems doesnt it?
<zul> ill give it a go
<zul> so ill start the grub stuff tonight sounds ok?
<jbailey> It supports about a dozen now, iirc.
<zul> build you joker build...ahahaha!!!!
<zul> noooooo...build failed
<jbailey> Hmmm.  My usb scanner doesn't make a friendly device for me.
<zul> dapper or breezy?
<jbailey> dapper.
<jbailey> It looks like just udev rule confusion.
<jbailey> If I /dev/usb/scanner0 to /dev/bus/usb/005/006 and set the group right, sane seems happier.
* jbailey tests.
<crispin> I didn't think you needed devices these days for sane, I don't believe that mine has a device, and it works fine
<jbailey> Yup, works in the gimp.
<jbailey> crispin: USB Scanner?  Check to see if you have a /dev/usb/scanner* or /dev/usbscan*
<jbailey> Certainly mine didn't work until I had actually created the device.  sane-find-scanner saw it on the usb device scan, but scanimage -L didn't see it.
<crispin> no usb* at all, but running "scanimage -L" now doesn't appear to show the scanner either
<crispin> I haven't tried it in dapper yet, so you are probably right
<jbailey> I'm not sure it worked in Breezy, but I don't know for sure.
<jbailey> It's probably soething I should test on the liveCDs too.
<jbailey> Kamion: Can you add that to a checkbox list on the livecds maybe?  Can you scan an image?
<BenC> jbailey: do you know what the status is for ia64/klibc/initramfs?
<jbailey> BenC: I've got the build deps on halley to look at it now and haven't had time.
<BenC> what is the issue, I can take a look at it
<BenC> ?
<jbailey> segfault in klibc, apparently.  I haven't debugged it.
<jbailey> If you enjoy debugging ia64 asm, you're *welcome* to take it from me.
<BenC> is there a way to repro the segv from userspace?
<BenC> like can I chroot to the initramfs when it's unpacked?
<jbailey> You don't even need to do that, you can run them from the build tree.
<jbailey> You can even add debugging symbols and all that.
<BenC> ahh, even easier
<jbailey> Then you need to break gdb on whatever that arch calls the starter function and use stepi to walk through the setup.
<jbailey> I suspect that the problem is in there.
<jbailey> Best to do it with upstream klibc rather than the packge.
<jbailey> Upstream has made more changes which will also cause segfaults.
<jbailey> Otherwise, I will get to it probably tomorrow.
<jbailey> There are only a few places where klibc tends to fail.  Given that it works on amd64, I don't expect this ot be a place where it's a 64 bit issue.
<jbailey> Given that cat segfaults, I think it's probably the startup code.
<jbailey> REmember not to refer to glibc when fixing the bug.
<jbailey> klibc isn't GPLd.
<BenC> ok
<jbailey> dannf has been helpful when I've had questiosn before, though.
<BenC> should I use 2.6.15 headers?
<jbailey> Yes, that's what I have installed in there.
<BenC> jbailey: I just did a rebuild and "./utils/static.g/cat README" worked
<jbailey> That's what someone had reported as failing. 
<BenC> gzip works too
<jbailey> Try fstype
<jbailey> That uses a 5 arg syscall.
<jbailey> (llseek)
<BenC> works, recognizes my ext3 fs too
<jbailey> Hmm, should be fine.  Suggest trying to boot with it.
<BenC> ok
<BenC> I'm using the 1.1.1 in the archive, FYI
<BenC> maybe it just needed a gcc-4.0+linux-headers-2.6.15 rebuild :)
<jbailey> It's always possible.
<jbailey> do you have a local ia64 to try a reboot on?
<BenC> yeah, I have an i2k that I did the build on
<BenC> getting ready to test it, 15 minutes and we'll know
<jbailey> Is that 15 minutes to get dressed to go out to the barn? =)
<BenC> yes, pretty much :)
<BenC> I can reboot from here and get out to the barn before elilo starts :)
<BenC> wonder if vga16fb+usplash will work
<BenC> the only thing I saw was "Illegal Instruction", then a modprobe usage message, and then the /dev/root failure
<BenC> couldn't do much else, because keyboard doesn't work when it drops to a shell
<BenC> not sure what causes the illegal instruction
<Kamion> jbailey: it's in https://wiki.ubuntu.com/Testing/Long already
<jbailey> BenC: I think there's a debug mode in there that will sh -x it for you.
<jbailey> Or you can break it at the top and step it through by hand.
<jbailey> Can you tell me about the /dev/root failure?
<jbailey> There shouldn't be one.
<jbailey> root= should be passed on the kernel command line.
* jbailey checks that to make sure.
<jbailey> Kamion: Ah nice.  I didn't know this document.
<BenC> it's the failure about /dev/root and /dev/.static/root or something similar
<jbailey> BenC: Can you do a break in there and tell me what's in /proc/cmdline ?
<jbailey> You should never see /dev/root messages when using anything other than lilo.
<BenC> like when the scsi module doesn't get loaded, and the device doesn't exist
<jbailey> And it's just too broken to try fixing.
<BenC> that's not from the kernel
<Kamion> jbailey: it's new
<BenC> it's from the initramfs, drops to busybox shell
<jbailey> /dev/root is the node that we generate when we have to just mount the device by major:minor and don't know its name.
<jbailey> BenC: Right, I know.
<jbailey> Kamion: I'll forgive my own lack of omniscience this time then ;)
<BenC> what's the kernel command line option to get the initramfs to stop?
<jbailey> But next time!  Out the third floor window I go.
<jbailey> BenC: break
<BenC> ok
* BenC thinks we need to cleanup out distro specific kernel command line namespace
<BenC> break, usplash...
<BenC> I know for one I hate hearing about how "nousb" doesn't work on our system :)
<jbailey> BenC: My suggestion is that we do it by taking over the world.
<jbailey> BenC: What do you propose? =)
<BenC> if they had called it redhat/nousb, then we'd have an argument
<BenC> jbailey: world domination negates my argument :)
<jbailey> Given that it's not a techincal problem, I think perhaps we shouldn't take a technical solution.  Let's try my idea first. =)
<crispin> jbailey: fyi, my scanner problems in dapper are now bug 21061
<jbailey> crimsun: sane is in main, the bug should probably go in bugzilla.
<crispin> err, the name's crispin, and it is ....
<jbailey> Well, the first three letters are the same, the last is the same, they're the same length and it contains an s.
<jbailey> I don't even notice when I've gotten it wrong. =)
<crispin> heh, isn't tab completion wonderful (except when it gets it wrong) :-)
<jbailey> Try working for mdz and working with mdy. =)
<maks_> vorlon said that the statfs from klibc is not 64 bit ready
<maks_> altought it works on amd64 it fails on alpha
<jbailey> maks_: Did he say why it is?
<makx> 10:37 <vorlon> yeah, then I wonder what their kernel people were smoking when 
<makx>                they did their statfs implementation. :)
<makx> 10:31 <vorlon> cool.  Looks like there's more than one bug in klibc on alpha, 
<makx>                though; fixing struct statfs gets me one step farther, but then 
<makx>                the darn thing fails trying to clear the rootfs.
<makx> 10:32 <vorlon> (which is basically a bunch of unlink() and rmdir() calls, so 
<makx>                you'd think this wouldn't be a problem. :P)
<jbailey> Ooo, is he hacking on this?
<jbailey> BenC: Might be worht syncing up with Steve.
<makx> yeah he said that his patch is not yet amd64 safe so didn't send in yet.
<makx> but seems that you are chasing the same bug
<BenC> stupid ia64 kernel doesn't have AT keyboard built-in
<BenC> I need to rebuild a kernel before I can do more testing
<jbailey> BenC: AT keyboard?  Not USB?
<BenC> nah, I have a ps2 keyboard on it
<jbailey> BenC: If you can find a way of probing that in sysfs, there's no reason not to just load it in the initramfs.
<BenC> the installer loads it
<jbailey> BenC: But I prefer to have everything in modules if possible. =)
<jbailey> Right, I was more thinking for boottime detection if there's a port there.
<BenC> if it's built-in in i386 and amd64, I want to just match it
<jbailey> Right.  Perhaps it shouldn't be built in there either, though?
<jbailey> I don't know how many new machines even have ps2 ports anymore.
<BenC> ia64 is the only one of hte 6 that has it modular
<BenC> I don't know if there's a way to detect it, and the installer for ia64 just loads it regardless, and it was added to /etc/modules after the install regardless
<BenC> there's no test, it just does it
<BenC> plus, if modprobe is failing in initramfs for my ia64 like I think it is, then I have to build it in
<BenC> I'm going to try adding atkbd to /etc/mkinitramfs/modules first and see if that gets me any further
<BenC> will it still load modules with "break"?
<BenC> if not, that's another good reason for it being built-in :)
<BenC> jbailey: if statfs was failing like vorlon said, wouldn't fstype fail?
<jbailey> BenC: I don't think fstype actually stats the node.  It just llseeks it.
<BenC> ah, true, it reads stdin
<jbailey> Right.
<makx> BenC: if you look at init you have several stages of "break=$stage"
<BenC> makx: ok, thanks
<BenC> jbailey: statfs() call in run-init succeeds
<jbailey> BenC: And returned sane data?
<BenC> tested it by calling manually (not on boot)
<BenC> yes
<jbailey> I wonder if you can safely step through run-init in a chroot?
<BenC> returned 0xef53 for f_type, which is ext3, which is correct
<makx> how did you test BenC?
<BenC> and f_namelen=255, which is correct (and is the last memebr of the statfs struct, so proves it's not pushing 32-bit/64-bit values in the wrong places
<jbailey> Right.
<jbailey> Hmm
<BenC> ./utils/static.g/run-init /mnt /sbin/init
<jbailey> Can you drop strace in the initramfs and just watch the strace for stange values?
<BenC> where /mnt existed, and /init was /bin/true
<BenC> I don't think the Illegal Instruct is coming from the klibc stuff
<BenC> I think it may be busybox
<BenC> perhaps busybox needs to be rebuilt for ia64?
<jbailey> Wait a sec.  
<makx> hmm only static klibc is said to work on alpha
<jbailey> We never actually demonstrated there was a problem on ia64 for run-init.
<BenC> so maybe it's an issue of dynamic linking?
<jbailey> The /dev/root messages mean that initramfs-tools is getting bad info from elilo
<makx> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341181
<jbailey> BenC: Can you cat /proc/cmdline for me?
<BenC> root=/dev/sda2
<BenC> jbailey: no, the /dev/root is because the scsi module never gets loaded
<jbailey> Ah, okay.
<BenC> so /dev/sda neven exists
<jbailey> Try adding it to /etc/initramfs/modules, rebuild and see if it  works?
<BenC> modprobe fails just before that error
<BenC> it spits out a usage message
<BenC> just after the Illegal Instruction
<jbailey> The modprobe should be just the system modprobe, I think.
<makx> can you modprobe from shell?
<BenC> I think the failed modprobe is it trying ot load the scsi module
<BenC> shell doesn't work without atkbd, which is a module too :)
<BenC> jbailey: busybox doesn't have it's own? I can't see the system one working with klibc :)
<jbailey> There's glibc in the initramfs, though.
<jbailey> The system one is linked against that.
<BenC> hmm, what's the point of klibc is glibc is there too?
<jbailey> The idea is that eventually everything should be against klibc and it should be possible to eliminate glibc.
<jbailey> But correctness over optimisation.
<jbailey> klibc is sufficiently small that it doesn't actually matter that both are there for now, and there's some reall convenient tools that come with it.
<makx> would ease dist upgrades as no glibc dependency for kernel
<makx> i mean indirect dep
<BenC> how can I run klibc shared progs from normal userspace?
<makx>  sudo chroot /usr/lib/klibc /bin/cat
<BenC> segv
<BenC> so it is a shared lib issue
<BenC> wonder how I can run gdb for this
<jbailey> On the shared lib?  No idea.
<jbailey> gdb won't understand their shared library style, it's not elf.
<makx> strace that dannf posted doesn't show anything too..
<jbailey> makx: It really sounds like there's nothing wrong with the static libs.
<jbailey> Or with the syscall mechanism.
<jbailey> Probably just shared library initialisation.
<BenC> it segv's immediately following execve of /bin/cat
<BenC> I've replaced the shared klibc-utils with static ones, let's see if that changes anything
<BenC> if I can boot with that, we know it's shared lib issues
<jbailey> Cool.
<jbailey> I've also just started a build here to look as well.
<jbailey> But making lunch, too.
<BenC> "We've secretly replaced the ia64's shared binaries with static ones...let's see if it notices"
<makx> dannf reproduced it with a shared build by gcc-3.3
<zul> BenC: lol
<BenC> ok, that made a big difference, still not there, but a lot further along
<BenC> here's what I noticed this time, my scsi/ide modules got loaded, and it got to the point of mounting the roofs, and then the SIGILL happened
<BenC> I think the SIGILL isn't klibc related
<BenC> unless there's some other tool in the initramfs that is compiled against klibc (not from klibc-utils)
<BenC> what else uses klibc?
<jbailey> Nope, just klibc itself.
<BenC> is mount busybox and does mkinitrd use busybox too?
<jbailey> Mmm.  mount is probably busybox.
<jbailey> It's a simple syscall.
<jbailey> Do you mean does the mkinitramfs tool itslef use busybox?
<jbailey> No, it uses posix shell #!/bin/sh
<BenC> calling busybox mount from userspace works
<jbailey> BenC: Can you break in the initramfs and step through the rest of it by hand?
<BenC> if keyboard worked
<BenC> which means I'll need to do a recompile
<jbailey> Add the keyboard modules to /etc/initramfs/modules and reboot
<jbailey> well, regenerate the initramfs.
<BenC> I did
<BenC> didn't work
<makx> you need to load it too
<makx> add an modprobe somewhere at the beginning of init
<BenC> ok
<jbailey> Things in the modules file do get modprobed...
<jbailey> You just need to make sure you break after that point. =)
<makx> aahh zut forget that indeed.
<makx> but atkb or i8042 dont get modprobed by initramfs if build modular atm.
<jbailey> They should if included in the modules file.
<jbailey> Everything in there should get modprobed.
<makx> sure was speaking out of the box.
<BenC> you know what would be super neato?
<BenC> if I remembered you have to run elilo after updating initrd's
<BenC> after that it booted
<BenC> so it's just shared vs. static in klibc that is stopping ia64 from using initramfs
* BenC considers adding an assume_initramfs kernel command line param to avoid the unzip just to check it
<makx> wasn't there an optimisation patch that would only unzip some bytes of the initramfs head
<BenC> maybe, haven't checked
<BenC> btw, just adding atkbd doesn't do much without some more modules
<BenC> just going to make it static
<BenC> built-in I mean
<jbailey> BenC: Hmm.  so it's not declaring dependancies correctly?
<BenC> well, it depends on enough to load, but not really present itself as useful
<BenC> either that or it wasn't really loading
<jbailey> Hmm. Have to rerun elilo?
<BenC> I put "modprobe atkbd" right after depmod -a in  /init, and break=top, and it didn't work
<jbailey> do you think that update-initramfs should have a hook for that in it?
<BenC> can't check if it was loaded
<BenC> not sure, I mentioned that to lamont
<BenC> I think hppa will have to have the same
<jbailey> Right, for palo.
<jbailey> So does lilo FWIW.
<makx> btw on alpha we dont land into console too
<makx> even with atkb build in.
<makx> i assumed that to be a bb bug.
<BenC> how do shared klibc bins declare the dynamic loader?
<BenC> I think other things need to be built-in too, like serio
<jbailey> BenC: I think they declare klibc.so to be the dynamic loader itself.
<BenC> jbailey: I don't see anything about it from objdump
<jbailey> BenC: readelf -a will tell you.
<jbailey> I think objdump assumes too much.
<BenC> if I do strings, I see it
<jbailey> HIghtech debugging tools. =)
<fabbione> hey guys
<jbailey> I think I need to go lie down and get this headache gone.
<jbailey> back in a short while.
<makx> bonne sante' jbailey
<BenC> hey fabbione
<zul> how did the thing go?
<fabbione> very well
<zul> good to hear
<zul> jbailey: pinger
<jbailey> zul: On phone.
<BenC> data point, shared bins on ia64 atleast get to __libc_init
<jbailey> How are you tracing it? 
<BenC> write(0, "DBG-X\n", 6); in libc_init.c
<BenC> changeing X as I add more
<BenC> err, 1
<zul> jbailey: grub2 is already in universe
<BenC> segv occurs right when libc_init calls main()
<BenC> which it does differently for shared than static
<BenC> for static, it just calls the main symbol directly, but for shared, it grabs the point to main from the pointer just after the env vars
<BenC> and that pointer is correct, as far as readelf says (they match)
<BenC> but it's wrong when you take relocation into account
<jbailey> zul: Really out of date, though.
<BenC> aha, I found the cause!
<BenC> well, found the symptom that actually makes it crash
<BenC> the correct address for main is 0x4000000000000ec0
<BenC> note the 0x4 to start
<BenC> it is only seeing, 0xec0
<jbailey> Interesting.
<BenC> nm
<BenC> my printf was using %x and not %lx
<BenC> so it has the correct address, why is it crashing when jumping to it
<zul> jbailey: okie dokie ill re-write it then ;)
<jbailey> zul: =)
<jbailey> I don't remember if the packaging was any good or not.
<zul> its using cdbs
<jbailey> There are good ways to use cdbs and ugly ways to use cdbs, my friend.
<zul> meh...wouldnt know..ill just do what i know
<fabbione> it's *CDBS*! what are the good ways?
<jbailey> fabbione: Come over here with a tube of vasseli... wait.  This is a public channel isn't it?
<fabbione> ahaha
<zul> and a family channel fuckers
* lamont giggles
<fabbione> you guys are so tempting me to goatse all of you
<paulproteus|lapt> Is "mem=128M" supposed to work?  It seems not to have any effect on powerpc at least with linux-2.6.15-8 .  See http://bugzilla.ubuntu.com/show_bug.cgi?id=21073
<BenC> think I figured it out jeff
<jbailey> !!! =)
<BenC> compare klibc/arch/{x86_64,i386}/MCONFIG with the ia64 one
<BenC> you'll see there's no -T text section var
<BenC> klibc.so and the binaries code space are colliding
<BenC> doing a recompile to see if I can guess a good location for it
<jbailey> Ah, interesting.
<zul> fabbione: dont you mean goatcheese?
<fabbione> no
<fabbione> i mean goatse
<jbailey> zul: You don't want the goatse cheese.
<jbailey> It's a little.. ripe.
<zul> hehe..
<zul> baahh..
<fabbione> ahah
* fabbione heads to bed
<fabbione> night guys
<zul> later
<zul> im going to head home as well
<jbailey> BenC: Any luck?
<zul> later
<BenC> jbailey: just trying to find the right location, I'm trying glibc's libc.so location for trial
<BenC> not having any luck finding the right offset
<jbailey> BenC: Maybe ask in #parisc?
<BenC> ia64? :)
<jbailey> It's all the same people.
<jbailey> dannf hangs out in #parisc, he's the one who fixed elilo
<jbailey> Or lamont, lamont-away might be able to recommend a person.
<BenC> can't find a #parisc channel
* paulproteus|lapt waves to BenC , quietly asking him to look at http://bugzilla.ubuntu.com/show_bug.cgi?id=21073
<BenC> paulproteus|lapt: mem= is arch specific, it's not supposed to work
<paulproteus|lapt> BenC: I see, that's sad.  Is there any ppc way to limit how much memory the ppc kernel uses, then?
<BenC> the bcm43xx thing is a non-issue for ppc
<paulproteus|lapt> BenC: "non-issue"?
<BenC> limiting memory like that is mainly for highmem bugs on i386
<BenC> 1024megs isn't highmem on ppc
<BenC> so that isn't your problem
<paulproteus|lapt> Hmm, if you say so.  The latest Apple update for the Airport Extreme driver seemed to mention something about >1024M, so I figured it was maybe a bcm43xx problem instead of a PPC problem.
<paulproteus|lapt> Or a problem with the DMA code written by the bcm43xx people.
* paulproteus|lapt shrugs
<BenC> just remove a memory stick :)
<paulproteus|lapt> BenC: After all the trouble I had with trying to put one in, I kinda don't want to do that. :)
<jbailey> BenC: OFTC.
<paulproteus|lapt> BenC: I marked the bug as INVALID since mem= is irrelevant for this arch.  "Thanks" ;-).
<makx> vorlon found that is supposed to be pulling the errno from a1, which is *true* for most other calls; for unlink() the errno is apparently in v0, which is normally the return value (and glibc seems to handle this fine).
<makx> so it stomps over the false register on alpha for run-init..
<makx> so the shared failure seems very diff.
<jbailey> makx: Okay.  It's easy enough to write a little wrapper around it that grabs errno from the other register just for unlink.
<jbailey> makx: What channel is he hacking in?
<makx> oftc #debian-kernel
#ubuntu-kernel 2005-12-21
<zul> heylo
<jbailey> Zool.
<zul> hey jeff, i told you i would start tonight
<makx> jeff i know almost zero about alpha asm.
<zul> alpha...bleah...weirdos 
<makx> hehe
<BenC> lamont-away: ping
<jbailey> makx: Alpha asm isn't that hard, really.
<jbailey> ia64 asm confuses the !@#$ out of me.
<mgalvin> just noticed that the linux-kernel-headers-2.6.15-8-686 has a small typo, it is...
<mgalvin> Linux kernel headers 2.6.15 on PPro/Celeron/PII/PIII/PIV SMPP
<mgalvin> and i think it should be
<mgalvin> Linux kernel headers 2.6.15 on PPro/Celeron/PII/PIII/PIV SMP/UP
<mgalvin> in the package description
<mgalvin> or maybe its just that there is an extra "P"
<lamont-away> BenC: ack
<zul> well that was a good movie
<infinity> Which movie?
<BenC> lamont-away: hey, you know anything about ia64 interp loading? :)
<lamont-away> no.
<BenC> klibc bins work when they are static
<BenC> but dynamic is broken
<fabbione> morning guys
<BenC> hey fabio
<BenC> lamont-away: I booted an initramfs on the i2k today with static bins :)
<infinity> Well, that's sort of progress.
<infinity> I'm still this --><-- close to just dumping klibc entirely, building the one or two helper binaries it provides aginst glibc instead, and calling it a day.
<lamont-away> so why didn't my hppa machine running breezy autodetect the SCA SCSI drive when it got plugged into the hot-swap bay>
<lamont-away> crw-rw----  1 root tape 9, 0 Dec 15 20:41 /dev/st0
<lamont-away> wonder if we can drive that beast...
<fabbione> lamont-away: pretty sure we can
<fabbione> tar is your friend :
<fabbione> :)
<lamont-away> fabbione: not when the machine is 20 miles away, with no tape in the mech.
<fabbione> well.. that really doesn't help :)
<fabbione> how old is that thing?
<fabbione> i had one for a while (scsi tape, that's it)
<fabbione> but i had to force a bunch of options to tar, like block size and such
<jbailey> infinity: It would certainly be the simpler solution, with the downside that then we'd never get silly small initramfs'
<fabbione> otherwise the device was just answering back: GET A LIFE. KTHXBYE
<jbailey> infinity: But klibc is really an undertested piece of shit.
<jbailey> As amusing as it's been to hack on it.
<lamont-away> st: Version 20050312, fixed bufsize 32768, s/g segs 256
<lamont-away> Attached scsi tape st0 at scsi0, channel 0, id 3, lun 0
<lamont-away> st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 917504
<lamont-away> these machines were selling in 2000
<fabbione> it should be new enough to autoset block size :)
<fabbione> mine was older than that
<infinity> jbailey : I don't suppose there's a hope in hell of building a slightly reduced glibc in some hackish way?
<infinity> jbailey : Still, even without said possibility, I think what we gain from klibc isn't worth the pain.
<jbailey> infinity: Well, if you'd like I can fork off the utilities into a separate package, or we can try to get them integrated into busybox.
<jbailey> I don't know the BB folks at all.
<jbailey> It does crush my dream of the 100k initramfs, though. =)
<Mithrandir> jbailey: dude, casper alone is 50k. :-)
<Mithrandir> I should reduce the number of files it consists of
<Mithrandir> it's 10.6k of text
<infinity> jbailey : We can revisit your dream another day, but I think glibc is the saner way to go for now.
<infinity> jbailey : It will actually reduce the size of our initramfs in the short term (since glibc keeps ending up in there anyway right now)
<infinity> jbailey : And it'll allow more widespread adoption in Debian, which is a Good Thing.
<jbailey> Mithrandir: I think my first boot-use initramfs was like 20k. =)
<jbailey> infinity: 'kay.  I'll look at that tomorrow then.
<jbailey> infinity: Hopefully it's anoher slow day on the support side like today was.
<jbailey> (And unlike today, hopefully tomorrow I'l even be alert)
* lamont-away reboots just to find another harddrive.  stupid hotplug
<Mithrandir> BenC: any reason why SMP is not enabled in the amd64-generic kernel?
<BenC> Mithrandir: because there's amd64-k8-smp?
<Mithrandir> BenC: not on the live cd
<BenC> amd64-generic is like -386, which is not SMP either
<Mithrandir> can we change that?
<BenC> SMP is a performance hit
<Mithrandir> I thought you had the lock rewriting patch in place?
<BenC> for x86
<Mithrandir> can you port it to amd64 and apply it there too? :-)
<Mithrandir> smp is fairly common on amd64 and will be more so with dualcores
<BenC> I couldn't but I've no way to test it easily
<BenC> could
<Mithrandir> what's the easiest way to test it?  Boot and see if it blows up?
<BenC> pretty much
<Mithrandir> I could test it easily enough for you, then
<BenC> ok, it wont be in -9.11, but I'll see if I can get it ready for the next one
<Mithrandir> cool, thanks.
<Mithrandir> I'm on vacation from Wednesday until Jan 1st, so no hurry.
<jbailey> BenC: I have an amd64 here as well, UP though.
<BenC> nm, that was easier than I thought
<BenC> it will be in -9.11
<BenC> which means that there wont be a -k8-smp
<Mithrandir> coolie.  Any ETA on that?
<Mithrandir> or, when can I test it?
<BenC> I can try doing a build on concordia later
<Mithrandir> great, thanks.
<BenC> jbailey: well UP is what I want tested, the patch is pretty much a nop on real SMP
<fabbione> hey Ben
<fabbione> i also have UP amd64
<fabbione> so /me can test
<jbailey> BenC: Cool lemme know.
<BenC> cool, thanks
<jbailey> BenC: Especially if all these lazy sods go on holidays sooner than you're ready.
<BenC> hehe
<fabbione> i will have holidays... around the house.. *FUN*
<BenC> yeah, that's what my holidays look like
<BenC> fabbione: get used to that, with kids :)
<fabbione> BenC: yeah i know.. 
<fabbione> this time is more like because my wife needs to work
<fabbione> she doesn't have holidays
<infinity> BenC : While we're talking SMP/UP hacks, why does -386 not do SMP, now that you have the crazy hack in there?
<BenC> because some drivers are not SMP safe
<BenC> legacy things
<BenC> they wont even compile when CONFIG_SMP is enabled, or if they do, they wont load because they use things like cli() that is not exported with SMP builds
<infinity> Ahh, shame.
<infinity> Since we use -386 on the LiveCD, SMP could be a win there.
<BenC> with amd64 it's not so bad, since we don't have to worry about ISA slot ethernet and scsi cards
<infinity> (That's why Mithrandir was whining about amd64-generic, it's the LiveCD kernel, and he has SMP machines)
<BenC> yeah, I can't really do that without killing a whole lot of hw support...the sorts of things people really whine about
<infinity> Oh well.
<infinity> Will this patch eventually find its way into powerpc as well?
<Mithrandir> can we switch to 586 or 686 kernels for the live i386 CD?
<Mithrandir> it's not like the live cd will work well on a 486 anyway..
<Mithrandir> it will work, albeit slowly, on the last machine I had with ISA, at least
<infinity> The last machine I had with ISA was still pretty fast, but I'll admit I didn't have any ISA cards in there that would use scary SMP-unsafe drivers.
<Mithrandir> I'm sure you could come up with contrived cases, but they would be that, contrived.  Especially if you can do something like "nosmp" on the kernel command line to force UP
<BenC> ppc is a bigger animal
<BenC> mithrandir: nosmp doesn't fix the drivers not loading, and is generally moot now with smp2up kernels
<jbailey> Mithrandir: One of the TODO items in the ToolchainRoadmapNg is to figure out if we can drop pre-686
<BenC> well, nosmp isn't useless I guess on SMP machines
<jbailey> Mithrandir: So far noone has said no.
<Mithrandir> BenC: that's not fixable, I presume?
<Mithrandir> jbailey: buntu?
<jbailey> Mithrandir: Right.  Per-i686 can use buntu instead.
<jbailey> No need to have the whole distro ready for them.
<BenC> Mithrandir: not without fixing a driver that has been limping in the kernel source tree with no maintainer for 7+ years :)
<Mithrandir> BenC: which one is that, and why do we care? :-)
<BenC> actually we could just have a 686 kernel with generic code for non-686
<BenC> Mithrandir: there's a few dozen of them
<BenC> and the users care
<Mithrandir> bah, stupid users.  It's probably easier just to ship them newer hardware
<BenC> I'm getting bug reports for dapper about old ass scsi cards
<BenC> jbailey: we could have a 686 optimized kernel that could still run on 486
<Mithrandir> I don't envy you. :-)
<jbailey> BenC: Don't you lose superpages and CMOV then, though?
<jbailey> BenC: And the point is really, why do we care?
<BenC> me personally, I was happy saying you needed PPro or better, but others said "no" :)
<jbailey> In practice we don't actually support pre-i686 when you look at us not supporting isa-pnp, EISA, VLB.  We provide openoffice, a pile of heavy screensavers, require 2GB to install, etc...
<Mithrandir> jbailey: I had 2GB drives fifteen years ago.
<jbailey> Someone who wants a smaller system than that (say, for an edge router) can use buntu
<jbailey> Mithrandir: Right.  It would've been *full*
<Mithrandir> a few years later I had 486 machines without ISA or EISA.
* BenC had an 80Meg hd for his first win95 machine
<BenC> just barely fit
<jbailey> Mithrandir: Nice, so those machines would at least boot.
<jbailey> Mithrandir: As long as you did a minimum install.
<BenC> that 80meg hd became my first debian install
<Mithrandir> jbailey: do we support MCA? :-)
<jbailey> Mithrandir: You're still not arguing why it needs a full Ubuntu setup.
<jbailey> Mithrandir: I don't think so.
<BenC> personally, I think it's too late in the game for dapper to do anything about 386 install CD
<Mithrandir> oh, then it's not supported after all.
<jbailey> I'm not sure that code is even still in the Kernel.
<BenC> we really need more testing on it
* jbailey hates the old PS/2
<BenC> post dapper i have two huge specs I'm writing
<jbailey> Half a computer, designed to run half an operating system.
<BenC> will change the way kernels are maintained for distros...FOREVER!!!
<BenC> muhahaha
<fabbione> BenC: are we going to use that bootloader that builds the kernel at boot
<fabbione> ?
<fabbione> ehehhe
<BenC> hehe
<BenC> nah, just all these people complaing about their drivers being fixed in dapper, but not working in breezy has me thinking
<BenC> not sure how, but I want a better way to handle that
<infinity> A package for each driver, so you can do selective driver updates!  YAY!
<infinity> Cause that's "intuitive" to Windows users... Or something.
<fabbione> infinity: you won't be the first one suggesting that
<BenC> looking more along the lines of MacOSX
<zul> heylo
<fabbione> hi zul
<BenC> like driver groups: USB Subsystem, SCSI, IDE, ATA, Sound, etc, etc
<zul> hey fabbione how is it going?
<fabbione> BenC: how do you plan to cope with ABI's?
<fabbione> zul: not too bad.. my teeth are still hurting, but i will survive
<zul> hmmm...whats going on?
<BenC> fabbione: this is mainly for released systems
<zul> fabbione: oh that sucks..
<zul> we are suppose to be getting 25cm of snow today
<fabbione> zul: had a couple of extra holes without anestesia..(or whatever is spelled)
<zul> ouchie
<BenC> fabbione: but handling an ABI bump post release like we had for breezy is an issue that needs to be addressed
<BenC> fabbione: dentists suck :(
<fabbione> BenC: well it's an issue.. but i don't think we have any other solution
<fabbione> BenC: speaking of extra drivers people compiles on top of our kernels
<BenC> fabbione: one thing is maybe being able to pinpoint which driver groups are affected by the ABI bump
<zul> whats happeing with ABI?
<BenC> for example, and ABI change in skbuff shouldn't affect sound
<BenC> an ABI chance in ACPI may not affect most drivers directly
<fabbione> BenC: well the point is you can only check what's in the stock kernel
<fabbione> BenC: but like we had last time, there was a new entry in a struct that did look innocent
<zul> *sigh* ill go read the logs then
<fabbione> but it did trash ABI all over
<BenC> zul: sorry, talks about post-dapper handling of released kernels
<zul> ah ok
<BenC> fabbione: but we have diffs of affected symbols, which can be cross checked with symbols that the drivers need
<BenC> so it's easy to take the abi chances and flag the drivers affected
<BenC> changes
* BenC hasn't finished a cup of coffee yet this morning
<BenC> fabbione: it's sort of like doing it for libraries
<BenC> hacking up some of the module-init-tools code should make it easy to show a chain of affected drivers from the breaking build to the next
<BenC> s/next/previous/
<BenC> fabbione: for example, if the kernel security fixes don't change ABI, and no driver code is touched, then the security upload really only needs vmlinuz, not the whole 57 megs of modules
<BenC> if the security fix only touches netfilter, with no ABI change, then no reason to install a whole new kernel
<infinity> While it's all well and good to limit the amount of stuff we force users to download, it also does seem to make the whole process a bit harder to handle.
<infinity> Not tracking ABIs, that can be automated, but tracking package versions in general starts making it harder for people doing support, etc.
<BenC> making it easy to handle is my goal
<infinity> Right now, I can say "do you have kernel X.XX installed?"
<infinity> Later, it'll be "do you have kernel X.XX, and scsi-modules Y.YY, and blah blah?"
<infinity> And unless we just assume everyone's always up-to-date, the package combinations get much scarier.
<BenC> but doing full kernel builds for upgrades post release limits us to what we can update
<BenC> infinity: then we just make a tool that spits all that information out
<infinity> I assume your real end goal here is to be able to push driver updates?
<BenC> updates in general, but yes, that's the main goal
<BenC> the problem is, it will require a whole new build system (for the buildd's)
<BenC> you wont be able to build it like we do now, unless we start splitting up the source, which is a big no-no
<jbailey> BenC: Given the length of time it's taking to get Soyuz even basically online, much less actually meeting everyone's needs, I suspect you won't see much in the way of build structure changes even through dapper+1
<infinity> I think he meant a whole rethink to the linux-source package structure and debian/rules, but maybe I'm wrong.
<infinity> ie: shipping a source package, build-depending on it, building modules from it, or something like that.
<jbailey> Ah, okay. =)
<zul> so scsi-modules-x.x.x.y or something?
<BenC> infinity: basically yes, but we need to not rebuilt parts that haven't changed from the last release
<BenC> or atleast not repackage it
<BenC> but that idea conflicts with the whole source+bin versioning scheme that we currently have
<fabbione> BenC: i am pretty sure if the idea is valid, there is no reason to stick with the schema we have
<BenC> fabbione: when I say "source+bin version scheme", I mean the one that katie expects
<BenC> like if we do a full build of 2.6.15-8.10, and get all the .deb's from that, and then build 2.6.15-8.11, and only scsi-modules.deb is changed, katie wouldn't like getting a .changes for linux-source-2.6.15 with just that package
<fabbione> right
<fabbione> there is no way to solve that easily afaict
<BenC> I can think of a way, but it's way too evil :)
<BenC> elmo would probably kill me
<fabbione> such as?
<BenC> creating somewhat fake .tar.gz sources for each component, and build-dep on the real kernel source
<fabbione> ahahah
<fabbione> i did that for fake modular X
<fabbione> nothing new about it
<fabbione> you will end up in a mess to port patches around
<BenC> doesn't make it any less evil :)
<BenC> well the main kernel-source tree would spit out the seperate sources, so it all comes from the same place
<jbailey> BenC: When we were talking about doing almost-free Java, there were some things that couldn't be built with the free java compiler, but could were free themselves and ran on free software.
<BenC> sounds like a hack though, I'd rather come up with something that isn't trying to work around katie
<fabbione> that would kill the idea of building everything from the same source
<jbailey> BenC: I had proposed a binary package with some .o's in multiverse that could just be installed as needed, so the rest of the package was ready to move to universe as soon as those were resolved. =)
<BenC> jbailey: hehe, nice
<fabbione> BenC: probably the ideal situation would be the concept of source source
<fabbione> super source
<BenC> wasn't there a way to upload rebuilt binaries without source? I seem to recall doing that a lot for the sparc buildd
<fabbione> you upload source1 that generates new sources .tar.gz, diff.gz and .dsc -> autoreupload -> process again till you get only binaries
<jbailey> We only have source uploads in Ubuntu.
<fabbione> BenC: that'd be binNMU, but we don't do them here
<BenC> like of foo-1.1-0 was built with the wrong compiler, instead of waiting for foo-1.1-0.1, just rebuild it somehow with no change in source package
<fabbione> BenC: yeps.. binNMU
<BenC> jbailey: but maybe a source upload that gets built wont build all the binaries everytime
<BenC> that's basically what I need to happen to make this work
<fabbione> BenC: that would make other katie's sisters crazy to keep the pool clean of old junk
<BenC> interdepencies handled on the fly at build-time based on ABI changes and such
<BenC> fabbione: right
<fabbione> because you lose relation ship between source and binary versions
<BenC> basically it would need to track if the new source superseded a certain binary, but not mark the old debs that didn't change as "obsolete"
<zul> brb...my terminals are all screwy
<BenC> would be nice if the debs that didn't change could have their relationship changed to the new source
<BenC> since they didn't change, then the new source would build them just the same anyway
<jbailey> Mmm, right.
<BenC> basically the same way that the .dsc refers to a .orig.tar.gz that is already in the dist, but not uploaded
<BenC> could add the md5sums of the original packages to reroute to the new source, and mark them as "existing" somehow
<infinity> BenC : The archive scemantics won't change anytime soon, but the "build-dep on a master source package" thing has been done many times before.
<infinity> BenC : Then you just package the modules as tiny debian-native packages that build-dep on the kernel source, and build the right subset of modules.
<fabbione> infinity: i don't think we want to go there
<BenC> infinity: not sure it would work though
<fabbione> that's the whole point of why we build everything from one source
<infinity> It works well enough.  It's ugly, though.
<BenC> MODPOST embeds info in each module about it's deps, but all modules have to be built in order to do that
<BenC> fabbione: it would still be one source, just meta-source packages to make the archive happy
<infinity> Nowhere near as ugly as a source package that only occasionally builds binary packages, and leaves packages with out-of-sync versions.
<BenC> but it wont work for this case
<BenC> infinity: that can be fixed with changes to the source+archive system
<infinity> Like I said.  Not gonna change anytime soon.
<BenC> probably not, but that doesn't mean it wont ever change...the whole goal is probably a dapper+2 thing anyway
<infinity> The problem is that binaries are tied to the source that BUILT them, not the source you uploaded later.
<infinity> ie: nic-modules_1.2.3 -> linux-source_4.5.6, but scsi-modules_1.2.3 -> linux-source_9.8.7
<BenC> that's why it would need archive changes, to reassociate older version debs to newer version source (source that still builds that same deb)
<infinity> Since we can't regenerate nic-modules to say "no wait, we actually came from the newer source package, even though we didn't!", we either have to keep all the source revisions around, or we've broken the world.
<infinity> No guarantees that the old deb would build from the new source without actually building it.
<infinity> Some say that's a GPL violation.
<BenC> of course there is
<infinity> Others just call it problematic in general.
<BenC> because the build system checks that
<BenC> if it wasn't the same, it would upload the new version
<infinity> And the binary->source relationship is actually in DEBIAN/control in the binary package.  So you're altering the .deb to fix it.
<BenC> the whole point being that it only uploads when the build is different from the previous
<infinity> And whe nyou alter the .deb, people have to download it again, cause the md5 differs.
<BenC> infinity: I was just thinking of Packages.gz overrides
<BenC> anyway the package only refers to the source package by name, not version
<infinity> Nope, does both, if the versions don't match.
* BenC points to breezy lrm for examples of debs with different versions than the source
<infinity> apt-cache show php4-imap
<infinity> Source: php-imap (5.0.5-1)
<infinity> Version: 4:5.0.5-1
<BenC> it will always show just linux-source-2.6.15 though
<infinity> If binary version != source version, we include source version in the metainfo so we can tie them.
<BenC> and apt-cache source linux-source-2.6.15 will always pull the latest
<BenC> and the latest is assumed to build it, otherwise there would be a new deb
<BenC> infinity: that's just for the archive management
<infinity> yes... Which is what we're talking about.
<BenC> yeah, but it's a different case than this
<BenC> and very hard to explain non-verbal like
<infinity> No.  If scsi-modules.deb gets uploaded, but nic-modules.deb doesn't, then nic-modules.deb now refers to obsolete source.
<BenC> infinity: that's where the archive changes come in
<BenC> the new upload would reference the old nic-modules, so the archive could internally associate it to the new source
<BenC> and hence keep things sane
<infinity> We're pretty anal about GPL binary/source compliance (specifically because we don't provide the n-year offer)
<BenC> the archive would say "ok, old nic-modules can be built with this new source, so treat it like such"
<BenC> infinity: you miss the point
<infinity> So, how do we KNOW that the old nic-modules will build the same from the new linux-source?
<BenC> infinity: if nic-modules DOES NOT get uploaded, the new source builds it the same
<infinity> (not how do YOU know in your debian/rules, but how do WE (the archive) know?)
<BenC> otherwise the build system would upload it aswell
<BenC> uh, because that's the way it will work?
<BenC> if the source for a module changes, the binary gets rebuilt
<infinity> And if there's an error in your rules file where a package just doesn't get built? :)
<BenC> and a new package is uploaded for it
<BenC> infinity: now you're being pedantic :)
<BenC> the bug would obviously have to be fixed, but assuming it all works as expected, then there is no violation
<infinity> I dunno.  You're welcome to pitch it to Kinnison/elmo for launchpad candy, but I think it's pretty sketchy, personally.
<infinity> And for very little gain.  Kernel updates aren't THAT big.
<BenC> 22megs isn't that big?
<infinity> Not these days.
<BenC> when someone wants to update breezy just to fix their usb card reader, 22megs is a lot
<BenC> I have a shit load of bugs that I cannot get verified because people are on dialup
<infinity> Which is solved just by splitting out the subsystems into packages, and allowing people to download just some.
<infinity> No one's forcing them to grab all of them to test a bugfix.
<jbailey> I AM, ROAR!
<jbailey> err
<jbailey> inside voice, jeff.
<infinity> <laugh>
<BenC> IMO, the source hackery is just working around limitations int he archive
<BenC> the whole reason we have ABI in the kernel now is for this exact reason
<BenC> and we use it with things like lrm
<BenC> what I'm talking about is extending that, but without having to split up into half a dozen source packages
<infinity> And splitting into source packages is bad.. Why?
<infinity> Either way, you're proposing you rebuild the whole kernel, but only upload a few modules.  One way works, the other requires a fundamental rethink of how the whole archive works.
<BenC> because the kernel is not split upstream?
<BenC> makes maintaining it harder
<BenC> and plus we cannot do partial module build
<infinity> So, don't split the source.  Distribute the patched source as a package.
<BenC> they have to be all built at once
<BenC> and I don't want to do full builds for scsi/ide/nic/acpi/usb/etc
<infinity> (Any valid reason they all have to be built together?)
<BenC> MODPOST scans all the modules and saves the inter-module dependencies in the .ko
<infinity> That seems to happen anyway.
<BenC> we can do without that because of depmod, but then we can't make usb-nic depend on ieee80211 without manual checking
<infinity> Note, for instance, modinfo nvidia shows a dependency on agpgart.
<BenC> infinity: if I only builds drivers/scsi/, it wont happen
<BenC> infinity: that's because the symvers are in the linux-headers file
<BenC> brb, smoke
<infinity> I think I'll have to ^z this argument until another day.  It's 3am and I'm passing out.
<zul> BenC: but the modinfo is not always uptodate because some of the nic drivers dont export all of their information
<BenC> zul: we're not talking about that part of modinfo
<BenC> just inter-module deps
<BenC> the symbols it needs are always know (they have to be)
<BenC> same with any symbols that are exported
<BenC> but connecting them to the module that needs it, or provides it, requires those modules to be around, or the symvers file
<zul> heh...i guess i shouldnt have jumped in
<zul> BenC: couldnt you write a helper script like whe do with kernel-headers, ie: this deb depends on this blah blah
<lucasvo> 25.594 /w 12
<zul> bleah..
<zul> BenC: hey BenC 
<BenC> hey
<zul> BenC: you might want to post your idea to the kernel mailing list but i know all the cool people hang out here
<BenC> this is way off, I don't want to take focus off things that need to be done for dapper
<zul> ah ok
<BenC> once dapper is near release, I'll have a full spec, some code and testing setup
<fabbione> BenC: i just got ia64 and hppa :)
<BenC> sweet
<zul> so how  many is that you have now?
<fabbione> zul: 7 different arches..
<fabbione> about hmm....
<fabbione> 6 i386 active, 1 amd64, 1 ppc, 1 hppa, 2 sparcs, 1 ia64, 2 m68k
<zul> hmm...my wife would kill me if i had that many
<zul> powered on at the same time?
<fabbione> and i think i have at least 2/3 i386 that i could mount from spare parts
<fabbione> zul: rarely
<zul> ah..
<zul> 3 x86, 2 sparcs is it for me
<fabbione> brb
<fabbione> it's food time
<dilinger> o/~ stop!  hammer time o/~
<dilinger> i haven't heard from davem since he got the sunfire
<dilinger> i hope it didn't fall over and crush him or something ;p
<fabbione> dilinger: he got it
<fabbione> but it was half smashed
<fabbione> it still works tho
<dilinger> yea, i know
<fabbione> it looks like that either it was hitten or you didn't put enough foam on the front side
<fabbione> but he got it to boot again
<dilinger> i spent $20 on foam :(
<dilinger> it was hard to get around it, though, due to the weight
<fabbione> well it's not too bad.. at least it is not completely broken
<fabbione> food time for me
<fabbione> later
<zul> wohoo...i dont have to shovel when i get home
<jbailey> zul: You know, they have stores that sell those sorts of things.
<zul> jbailey: :P im talking snow...sicko
<jbailey> Oh! Whups.  I thought you said "I don't have *a* shovel"
<zul> yeah then i would have to bend over...nah...
<zul> later
<makx> jbailey: vorlon's patches are verified by another succesfull boot on alpha
<makx> would be cool if his alpha statfs64 fix could be tested on another 64 bit arch to exclude regressions
<makx> http://aipc50.ai.wu-wien.ac.at/~attems/klibc-342931-statvfs.diff
<dilinger> hrmph
<dilinger> PGP/GnuPG signature check failed on mysql++_2.0.7-1_i386.changes
<dilinger> gpg: Signature made Fri Dec 16 13:02:46 2005 PST using DSA key ID CFD42F26
<dilinger> gpg: Can't check signature: public key not found
<dilinger> (Exit status 2)
<dilinger> mysql++_2.0.7-1_i386.changes has bad PGP/GnuPG signature!
<dilinger> Removing mysql++_2.0.7-1_i386.changes, but keeping its associated files for now.
* dilinger contemplates just going through the ubuntu uploader process and just uploading there
<Tonio_> hi everyone
<Tonio_> little problem with latest kernel update.....
<Tonio_> tun device doesn't seem to work anymore
<Tonio_> sudo modprobe tun && ifconfig -a
<Tonio_> that gives me nothing
<Tonio_> was tun/tap option activated in the latest kernel ?
<fabbione> yes
<fabbione> you need to create the tunnels first
<fabbione> iptunnel or ip are your friends
* fabbione heads for bed
<fabbione> good night
<lucasvo> is there any bot here?
<Tonio_> fabbione: you mean creating the tun device ?
<Tonio_> already done....
<Tonio_> mkdir /dev/net && mknod /dev/net/tun c 10 200
<Tonio_> doesn't change anything.....
<Tonio_> and it was working 2 days ago......
<Tonio_> damn gone ;)
<BenC> Tonio_: I have vtun working on my box, so I know tun works
<Tonio_> BenC: hum...............
<Tonio_> I have no error message when loading module tun
<Tonio_> so I'm okay that it works
<BenC> how to get it to work is beyond my knowledge, vtun did everything for me
<Tonio_> but what sounds strange is that something changed with the last kernel upgrade....
<Tonio_> BenC: do you have a tun0 device or tunl0 ?
<Tonio_> not the same thing....
<Tonio_> tunl0 is create by the ipip module
<Tonio_> ifconfig -a will tell you....
<BenC> tun1
<Tonio_> no tun0 ?
<BenC> it's all the same
<Tonio_> hum.......
<Tonio_> if you have a tun1, it means that you have a tun0 that does not appear maybe....
<Tonio_> which shows there is a kind of issue with that device...
<BenC> it doesn't really matter
<BenC> no, it doesn't
<Tonio_> BenC: with openvpn it does lol
<BenC> it's only because vtun was restarted
<Tonio_> okay....
<BenC> tun0 was taken down before it started a new one, which became tun1
<BenC> was taken down after I mean
<Tonio_> in any case openvpn doesn't work anymore on my three machines....
<BenC> /dev/net/tun exists for me
<BenC> udev probably created it
<BenC> did you do a partial upgrade?
<BenC> it's 10/200, 0660, root:root
<Tonio_> same for me........
<BenC> I suggest a google search for openvpn vs. 2.6.15, and maybe emailing them
<Tonio_> yep maybe ;)
<BenC> emailing openvpn that is
<Tonio_> the strange thing is that it was working 3 days ago.........
<Tonio_> I'll have a look, thanks ;)
#ubuntu-kernel 2005-12-22
<zul> heylo
* #ubuntu-kernel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
* netjoined: irc.freenode.net -> brown.freenode.net
<zul> BenC: my dbg kernel doesnt boot yet..
<BenC> it's not supposed to be a bootable kernel
<BenC> it's just supposed to be a package with an uncompressed unstripped vmlinux that people can use for debugging
<fabbione> hey guys
<BenC> hey fabbione
<fabbione> oh finally.. i can start building sparc again
<fabbione> i just managed to get main in sync on the local mirror
<fabbione> adding ia64 and hppa was the suck :)
<BenC> hehe
<zul> BenC: ah ok
<zul> well thats a good thing then
<fabbione> later boys
<fabbione> i am off for a nap
<BenC> later fabio
<zul> nap its only 8:30 am
<fabbione> for you
<fabbione> it
<fabbione> it's 14:30 here
<zul> yeah i know...im just pulling your leg
<zul> BenC: well it builds then i just have to figure some things out then
<BenC> you are just building the .deb, right? You're not building an entirely new kernel for this vmlinux, right?
<zul> well i have a config.dbg and have modified the control files
<zul> so when i created the *.deb it contains the regular kernel right now with oprofile enabled
<zul> anyways
<zul> brb...need to check on the server
<zul> bleah
<lucasvo> is multicore working well with ubuntu-kernel?
<infinity> BenC : Dude, the president of "Adam's Discount Whitebox Servers" was totally at my house when I installed my server.  he even did all the work!  Surely, I need -bigiron, right?
<BenC> lol
<BenC> infinity: if he carried the system in under one arm, then probably not :)
<zul> stop making fun of me...
<infinity> Also, though I know damned well what it stands for, and I've administered NUMA systems, everytime I see "NUMA", I'm reminded of that company that made Christmas tree lights..
<infinity> (NOMA, was it?... I don't remember)
<infinity> "Install this kernel if your server has lots of lights!"
<zul> "Install this kernel if your server takes up a room"
<BenC> I remember the room at NASA where the Cray was installed
<BenC> they MADE NASA paint the room a specific color of blue before they would install it
<zul> hehe..
<infinity> Hah.
<infinity> Was that before or after the SGI buyout?
<BenC> way before
<BenC> this was like 8 years ago, and the machine was long gone
<infinity> Old fart. ;)
* BenC hocks a fat lugi on infinity
<zul> heh..back in my day we had computers made of vaccum tubes and you had to poke it with a stick to get it to work
<infinity> I never did get to play with a Cray, but I did have a Himalaya non-stop machine at one site.
<infinity> It always struck me as odd that DEC's supercomputer was MIPS-based, and SGI's (granted, purchased from Cray) was Alpha-based.
<BenC> I did get to see the SGI O machines where the first Mars photos were coming in back in the middle 90's
<infinity> CONFUSION.
<BenC> lol
<infinity> I used to have nerd wet dreams about playing with a T90.  I think I'm finally over that.
<BenC> the SGI machine used to be 384 on the top 500 list, but it's probably like 45000 now
<BenC> don't lie, you only thought about it because you had one last night :)
<infinity> Besides, the most recent RS/6000 kit I played with spat all over the T90 (and at a fraction of the cost), so I guess I should get over my old skool gear lust.
<infinity> And no, I will never call them "pSeries"... I just can't do it.
<BenC> my apple2e satisfied my retro urges
<infinity> Speaking of.  Are we going to try to work with anyone this time around to get bootable kernels on pSeries kit?
<zul> those apple ] [ gs were cool when i was a kid
<infinity> Apparently we missed the mark with breezy.
<infinity> I'm sure mdy has the contacts with IBM to get us testing gear.
<infinity> Not that I envision my living room having a 4096-CPU RS/6000 anytime soon, but I'd like to know we can at least boot and run in a VM partition properly.
<BenC> Mark got the IBM contacts, and now they are in touch with me
<infinity> Oh, spanky.
<BenC> the one guy is the head of the group that handles xSeries stuff
<infinity> I don't suppose IBM is pushing for us to do s/390 as well?
<BenC> and ACPI/PCI, so maybe we can get some bugs fixed
<BenC> not that I know of
<infinity> (damn)
<infinity> Not that I'd be happy debugging in Hercules or anything, but more commercial vendors shipping s/390 ports would be nice.
<infinity> I've met a few ISP/mass-vhosting type people who consider the 1U/blade->mainframe switch, but commercial support for Linux on mainframe VMs comes from far too few people.
<zul> ugh...politicans at my door
<zul> BenC: for the dbg kernels we would want to keep the vmlinnux somewhere else wouldnt we?
<jbailey> zul: Politicians are tasty on toast.
<zul> yes especially liberals
<fabbione> mommy mommy can i have a politician for dinner? well done mommy, i don
<fabbione> 't like raw dog meat
<zul> hehe
<fabbione> OOOOK
<fabbione> office rebuilding is complete
<fabbione> i did run out of network cables
<fabbione> and powercables
* fabbione will have to buy some more
<fabbione> not all the equipment is even plugged 
<CataEnry> hi :)
#ubuntu-kernel 2005-12-23
<floam> is there any possibility of getting CONFIG_USB_SUSPEND set to y in dapper?
<floam> linux-usb people are saying that it being off is the reason some USB devices can't turn off while plugged in.
<CataEnry> hi :)
<BenC> floam: cool, my kids want you for christmas
<BenC> floam: and as for USB_SUSPEND, it's marked experimental...if it isn't, then maybe they should get that fixed :)
<fabbione> hey Ben
<BenC> hey fabio
<fabbione> BenC: i just tested hppa stuff
<fabbione> .12-mckinley is no good
<fabbione> sorry i mean ia64
<BenC> you have a mckinley?
<fabbione> i am gonna have to play with it to see what's wrong
<fabbione> apparently i do
<fabbione> at least the installer detect it as such
<BenC> sweet, mines itanium, so I know that works
<BenC> cat /proc/cpuinfo just to be sure
<fabbione> it's turned off now.. let me see if i have it in the scrollback
<fabbione> fabbione processor  : 0
<fabbione> fabbione vendor     : GenuineIntel
<fabbione> fabbione arch       : IA-64
<fabbione> fabbione family     : Itanium 2
<fabbione> fabbione model      : 0
<fabbione> fabbione revision   : 7
<fabbione> fabbione archrev    : 0
<fabbione> fabbione features   : branchlong
<fabbione> fabbione cpu number : 0
<fabbione> fabbione cpu regs   : 4
<fabbione> fabbione cpu MHz    : 900.000000
<fabbione> fabbione itc MHz    : 900.000000
<fabbione> fabbione BogoMIPS   : 1347.58
<fabbione> fabbione siblings   : 1
<BenC> I2 I guess is mckinley
<fabbione> the error anyway was related to SCSI missing symbols
<fabbione> so it might be either a bad initrd or a broken kernel
<BenC> hmm, I should be able to see that for myself
<fabbione> i will look at it one of the next days
<fabbione> i didn't really have much time to debug, because i have only one console cable to share with 4 machines
<fabbione> and sparc doesn't like to stay without console
<BenC> if it's missing symbols, it's not because of t he kernel
<fabbione> i plan to go out and buy them tomorrow
<BenC> the builds show no missing symbols
<fabbione> yeah i think it's a missing module in the initrd
<fabbione> but that was .12
<fabbione> i have to check .15 too
<fabbione> http://www.fabbione.net/new_office.jpg
<fabbione> check out the local datacenter :)
<fabbione> the sparcbuildd is under the cisco switch ;)
<Mithrandir> you need to rotate the image
<fabbione> http://www.fabbione.net/new_ws.jpg
<fabbione> this is my ws :)
<fabbione> Mithrandir: i just took a pic on the fly
<fabbione> -ENOCARE :)
<fabbione> there is a black tower on the left, but you can barely notice
<fabbione> see now i should be maintaining the kernel.. now that i can test on arch: all
<fabbione> not when i only had i386
<zul> heylo
<BenC> fabbione: still getting bug reports that claim broken 2.6.12-10, but work with 2.6.12-9...one was a amd64 bug about GPF's at random, another is hibernation randomly broken
<BenC> I think I know the patch that is probably the cause
<BenC> I think it's the procfs patch
<fabbione> hmmmmm
<fabbione> for now just reassign the bugs to me
<fabbione> i am going to do the pending security stuff this week
<fabbione> and i can ask people to pre-test a kernel with reverted proc-fs
<BenC> ok
<BenC> yeah, the procfs one seems like the only one that could cause random issues (and lockups)
<zul> does anyone have a ccis raid card with dapper?
<zul> i guess not
<jbailey> zul: lamont might have access to one.  They're common in HP gear.
<zul> hmm...ill ask him then
<BenC> avahi+daapd == music heaven
<floam> BenC: want me for christmas?
<floam> I'm playful
<BenC> floam: hehe
<BenC> I didn't even know what floam was until my kids asked for it
<floam> heh.
<floam> I had this name before that goo stuff came out
<floam> I should sue 'em.
<floam> BenC: I didn't know what floam was until I got a letter from some guy on behalf on Nickelodian asking me if I want to sell floam on my website and make money (or hand my website over to them)
<floam> I had the #1 spot on a google search for "floam" at the time
<BenC> did you make any money for it?
<floam> I said no, and now it seems like they've gone nuts with search engine optimization and are above me now
<floam> BenC: nah, I didn't do it
<floam> I think their first email I have somewhere...
<floam> http://floam.sh.nu/files/misc/floam
<floam> it seemed like a ripoff, the letter looks mostly canned
<BenC> yeah, they didn't really make that look legit enough
<floam> BenC: so Ubuntu's policy is nothing EXPERIMENTAL?
<floam> maybe I'll try to get them to change that flag for 2.6.15, the feature has been there for 9 releases or so
<floam> with nothing bad reported that I've seen on lkml at lease
<BenC> well, we have some stuff from exp, but I personally I don't like enabling new things from exp without good cause
<floam> Idealy I was hoping I could get that enabled, and then I could make a patch to eject that would use it
<floam> so that when people unmount volumes through gnome the device would actually do what it's supposed to do (like in windows)
<floam> in windows, if you've got a USB device plugged in, before unplugging it you go to some "safely remove hardware" dialog and hit a button, which not only unmounts it but suspends it
<floam> some devices wait for the suspend signal before believing that they are "safe to disconnect"
<BenC> let me talk to gregkh and see if he thinks its safe enough
<BenC> since I don't personally know
<floam> he would, he added the feature I think
<floam> BenC: thanks :)
<BenC> but if he thought it was safe, he wouldn't mark it exp :)
<floam> maaaaybe
<floam> there are other exp things that are generally agreed upon to be stable
<floam> more of a "this is new" flag than "this is broke" sometimes
<dilinger> wow
<dilinger> permissoins on my breezy box are severly hosed since upgrading to dapper's udev
* dilinger upgrades to the latest udev in dapper, reboots and prays
<makx> hehe
<makx> may $deity with you dilinger
<HrdwrBoB> may you be touched by his noodly appendage
<fs> dapper?
<fs> ECHAN =)
#ubuntu-kernel 2005-12-24
<zul> heylo
<BenC> redskins crush the cowboys....my weekend is complete
<zul> meh...american football is boring
<BenC> maybe to you
* BenC enjoys it more than any other game on tv
<zul> too many stoppages for my taste
<zul> besides i didnt grow up with it on tv
<BenC> yeah, it's been a sunday tradition in my family as long as I can remember
<BenC> the odd thing is, I'm a redskins fan, and my wife is a cowboys fan, so Sunday's like today are anything but boring :)
<zul> heh...i dont think we have a family tradition for sunday
<zul> heh..my brother came over one time to my wife's parents house wearing a maple leafs hat, my mother in law nearly kicked him out
<infinity> Habs fan?
<zul> sens fan
<infinity> (I would have said Senators, but no one's a Senators fan... Are they?)
<infinity> Oh. :)
* zul slaps infinity 
<infinity> Any team that didn't even exist when I was a kid isn't worth kicking someone out of your house for.
<infinity> "Oh my god, you don't like the Sharks, out with you!"  Bah.
<zul> true but she gets violent when she watches hockey
<infinity> (Okay, if your mother-in-law is, like 80, and remembers the FIRST Senators team, then props to her)
<zul> hehe
<zul> must go watch family guy...bbl
<lamont> BenC: I expect I could probably find one... ping me tomorrow
<lamont> or email to lamont.jones@hp.com
<BenC> lamont: find what?
<infinity> A ccis controller.
<lamont> yeah, that
<zul> lamont: i wanted to test a grub boot on it
* BenC is still lost
<zul> ummm...BenC i asked earlier if anyone had a ccis raid controller so i can get them to test a grub patch that was done and jeff suggested that lamont might have access to it
<BenC> oh, ok, he said BenC, so I was wondering how I got into that :)
<infinity> Because this is your channel, and you're the channel OVERLORD, dude.  You know all.
<infinity> (Or you should pretend to)
<lamont> BenC: because I can't read, that's why
* BenC nods at the channel
<BenC> infinity: was that bug for i2c-keywest directed at the proper package?
<infinity> Yeah, though I wonder if I should offload the thermal hooks to acpi-support and mjg59, since I don't really grok what it's doing in initramfs. :)
<infinity> Is i2c-keywest always required, or just sometimes?... And will it hurt to just load it anyway, even if it's not needed?
<lamont> hrm... i386 with sata hdd... that should work, yes?
<lamont> (actually it's an amd64 box, but...)
<infinity> Works for me.  i386 and amd64 with SATA.
<infinity> Of course, it doesn't work for everyone. :)
<lamont> it barfed installing initrd-tools (breezy)
<infinity> OO, my Google t-shirt came in the mail.
<BenC> infinity: always required
<infinity> Kay.  I'll shove it in the PPC thermal bit, then.
<lamont> amd 64 3500+ cpu. yum
<dilinger> i used to have a google tshirt
<dilinger> :(
* lamont has a couple around here somewhere
<dilinger> urgg
<dilinger> udev is still screwy
<dilinger> crw-rw----  1 root root 1, 3 2005-12-18 16:50 /dev/null
<infinity> Nice.
<lamont> hrmpf.
<cjb> I reported my tales of woe from earlier in #ubuntu-devel, speaking of SATA:  http://bugzilla.ubuntu.com/show_bug.cgi?id=21248 
<lamont> 0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5954
<lamont> that's my current woe.
<lamont> fabbione: helep
<mjg59> cjb: Yeah, that looks like a bug
<cjb> lamont: I think I have one of those.  What's the problem?
<lamont> it;s the 'Unknown device'
<lamont> X doesn't like it
<cjb> (Mine's an HP a1250n with the crappy ATI bridge that can't count interrupts properly.)
<lamont> (II) RADEON(0): [drm]  drmOpen failed
<lamont> (EE) RADEON(0): [dri]  DRIScreenInit failed.  Disabling DRI.
<lamont> HP A1130N
<cjb> Oh.  I didn't have a problem; X worked even though lspci can't identify the chip.
<mjg59> lamont: dri being disabled doesn't sound unexpected
<lamont> mjg59: ok.  rebooting with the current (breezy-security) kernel
<lamont> then I'll worry if things don't work..
<lamont> Fatal server error:
<lamont> Caught signal 4.  Server aborting
<lamont> that's the acutally fatality
<mjg59> lamont: Oh.
<mjg59> lamont: Blame daniels
<lamont> I don't care who broke it, I just want X to work...
<mjg59> Try disabling acceleration
<lamont> uh... clue-factor on X config is kinda low here...
<cjb> Comment out 'load "glx"', for starters.
<mjg59> In the section that says ati, add Option "NoAccel" "true"
<lamont> mjg59: so that fixed it...
<lamont> I wonder if maybe the i386 ati driver doesn't like amd64 hardware...
<mjg59> lamont: No, it happens on i386 too
<cjb> The ATI card situation is such a mess.  We don't even have a proprietary driver for the latest batch.
<infinity> No terrible loss there; the proprietary driver sucks. :/
<infinity> (And I don't mean "sucks cause it's non-free, like the nvidia driver", I mean "sucks cause it sucks")
<fabbione> morning
<makx> zul: latest grub from debian just works on cciss
<makx> the sarge one has troubles.
<CataEnry> hi all
<zul> makx: cool
<fabbione> BenC: i think afb8765ea996378c42f1d5f8c93561d6a1873a06 has some leftovers
<fabbione> libata-core doesn't build
<BenC> yeah, I have it fixed now
<BenC> I'll push in a second
<BenC> fabbione: if you're inpatient, just add: #include <scsi/scsi_device.h> to the top of the file
<BenC> impatient
<fabbione> BenC: oh ok.. 
<fabbione> i just did remove some code :)
<fabbione> i was in a hurry to test some dri fixes on ppc from benh
<BenC> -9.11 is probably going out today
<fabbione> cool
<fabbione> BenC: btw.. that idea of modular kernel upload stuff...
<fabbione> you should probably talk with acme on netdev about it
<BenC> ok
<fabbione> he had a very similar idea for connectiva
<fabbione> we discussed about it a bit
<fabbione> that was before you arrived
<zul> heylo
<CataEnry> hi
<infinity> BenC : Actually, on second thought, I may fiddle with that hardcoded path first thing in the morning, so if the LRM ABI bump isn't urgent, may as well leave it to me.
<BenC> sure, it will be morning before the builds start getting done anyway
<zul> oh yeah i made a couple of patches this weekend i have to do a test build before i do anything else
<desrt> BenC; word.
<desrt> BenC; new firewire love in the coming kernel?
<BenC> desrt: somewhat...I reverted the code I had pulled from the firewire git tree
<desrt> ah.  i see.
<zul> BenC: you are always breaking things arent you ;)
<desrt> well.  i'll give it a spin when it hits the archives and let you know
<desrt> thx.
<BenC> ok, thanks
<CataEnry> bye all
<cjb> Mornin' all.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-9.11 uploaded (The "Breast Feeding Boswanian Bat" release)
<BenC> and with that, I am off to lunch
<BenC> zul: oh, I never break things, I only change their expected success patterns :)
<zul> lol
<zul> wtf is slashdot charging now?
<cjb> If you want to see stories early and not see ads.  It's nothing new.
<zul> thats retarded
<crimsun> eh, it's his blog, he can do wtf he wants *shrug*
<zul> BenC: i got a couple of patches for you that i need to test tonight, it enables hotplug in some drivers.
<zul> er...makes the drivers hotplug aware
<BenC> ok
<BenC> makes them autoloadable is probably what you mean :)
<zul> yeah..
<zul> huked on phonix wurked 4 me
<zul> oh yeah where do you want me to place the stripped/uncompressed vmlinux?
<BenC> not sure.../boot is probably a bad place
<BenC> /usr/lib/kernel/ maybe
<BenC> /usr/lib/dbg/
<BenC> there, that's probably best
<BenC> libc uses /usr/lib/debug/, and gdm looks there
<BenC> gdb I mean
<BenC> let's go with the latter
<zul> /usr/lib/dbg? okie dokie then
<BenC> no, /debug/
<zul> ah ok...sorry
<zul> later
#ubuntu-kernel 2005-12-25
<zul> heylo
<zul> *sigh* http://lkml.org/lkml/2005/12/19/115
<BenC> we have several bug reports like that
<BenC> k8 bug it seems
<BenC> even saw one myself on my emachines laptop
<infinity> That was a winner of a laptop, if I've ever seen one.
<infinity> Also, good morning.
<BenC> is it a good "lrm" morning? :)
<infinity> Won't be until your kernels get out of NEW.
<infinity> At least they all built, though.
<infinity> Even poor little ia64.
<BenC> yeah, well everytime I upload, I always know that 5 of the 6 are going to build :)
<BenC> never sure about amd64 until it actually gets there
<infinity> You don't do amd64 on concordia?
<infinity> Tsk, tsk.
<BenC> only when I know something with x86_64 changed (config wise or from linus tree)
<BenC> sparc lagging behind again
<infinity> I did i386 and amd64 in parallel on concordia the other day and wanted to kill myself.
<infinity> That machine's not fast.
<infinity> It's just... Faster than my laptop.  A bit.
<BenC> it's faster than all but my e3k
<infinity> My girlfriend's desktop outstrips concordia.
<BenC> my i386 is only 2ghz P4, and my PPC is a 500Mhz G4
<BenC> and ia64 is slow anyway
<infinity> Ouch.  My PPC is taice as fast as yours?  Sucks to be you.
<infinity> Blue G4?
<BenC> my 500mhz ppc can do it's 3 builds quicker than my dual 700mhz ia64 can do 4
<infinity> s/taice/twice/
<BenC> grey
<BenC> blue is G3 I think
<infinity> Oh, right.
<infinity> Blue was the G3, Grey was the G4 with the identical motherboard, but "ALL NEW, WITH ALTIVEC, OMG!!"
<BenC> I need to get that quad 2.5ghz G5
<BenC> yeah, lol
<infinity> (with altivec and half the cache, and half the cache speed, but who does integer with large dataset anyway, altivec is clearly better, fud, fud, fud)
<infinity> Which is precisely why I opted for upgrading my G3 with a 1GHz G3 instead of a 1GHz G4.. I kinda looked at my usage patterns and decided the G3 would be faster in 99% of cases.
<mjg59> infinity: Later G4s had a new motherboard, didn't they?
<BenC> both my G4's were free, so I can't complain
<mjg59> Or was AGP introduced with later G3s?
<infinity> mjg59 : Yeah, but not the 500MHz one Ben has.
<mjg59> Ah
<mjg59> I just remember the bizarro 66MHz ATI cards
<BenC> this was first generation G4
<infinity> Ben's would be, basically, a blue G3 with a sraypaint job and altivec.
<BenC> when it first came out
<BenC> 7400 PowerMac3,1
<BenC> PowerMac G4 AGP Graphics
<infinity> mjg59 : Oh, the crazy cards on the Beige G3, you mean?  I have one of those.
<infinity> The blue G3 had normal AGP.
<mjg59> The blue and white G3s had them too, I think
<mjg59> Hmm. No, not all of them
<infinity> Ahh, then they had two motherboard revisions.
<infinity> (shock)
<mjg59> Uhm. These would have been 266MHz G3s
<mjg59> Or maybe 300 - first gen new world machines
<BenC> this one has a 4x AGP ATI Rage 128 PF/PRO
<mjg59> Nngh argh where has oftc gone
<mjg59> Hang on
<BenC> I think I'm going to go ahead and get that PowerBook 17"
<BenC> I just can't pass up the deal
<BenC> in 6 months I'll get the quad 2.5ghz
* infinity is rather miffed this deal has shown up in every INBOX he's aware of except his own.
<BenC> which will probably be Quad x86_64 4ghz by then :)
<infinity> I could use the ppc64 machine...
<BenC> you know others?
<infinity> And maybe a cheap little iBook for my girlfriend, so she can be all trendy.
<infinity> BenC : Several, yes.
<zul> send me one..
<zul> im a hardware whore
<mjg59> I haven't received any excellent Apple deals
<BenC> infinity: with the deal, the cheapest 12" iBook would be $750, not really much of a deal
<mjg59> infinity: Daniels has got one. Just steal his desktop.
<infinity> mjg59 : Good, we can get drunk together and comiserate.
<infinity> BenC : Ahh, shame.  No iBook, then.  It's the desktop I really want anyway.
<mjg59> infinity: Yeah, I'll just hop over to OH NO HANG ON
<mjg59> infinity: Going to LCA?
<infinity> What dates are LCA again?
<BenC> LCA?
<infinity> linuxconf.au
<mjg59> 22-28 January
<mjg59> Or so
<infinity> Oh, 23rg to the 28th.  No, I'll be in London.
<mjg59> In NZ
<mjg59> Hahahahahaha
<mjg59> The irony
<infinity> <nod>
<mjg59> We'll probably crash into each other in flight
<infinity> I'll be snuggling with thom.
<mjg59> Awh
<mjg59> Are you there for two weeks?
<infinity> Yeah.
<mjg59> Right, I'll probably be around for some of one of them
<infinity> Zofia and I are going in advance for a short vacation, then some apache hacking with thom, then the distro sprint.
<mjg59> I'm not sure what dates I'll be in NZ
<mjg59> Need to check with the travel agent
<infinity> I've decided I desperately need a beverage.
<mjg59> We should introduce you to UK beer
<mjg59> (in large quantities)
<infinity> Dry mouth.  Clear thinking.  These things must be stopped.
<infinity> mjg59 : Do I have to drink it warm?
<mjg59> Yes. Bastard.
* infinity shudders.
<infinity> Oddly, thom has requested that I bring him Australian beer.
<mjg59> There is nothing wrong with warm beer
<infinity> As has Mithrandir.
<mjg59> It means you can actually taste it
<infinity> mjg59 : Except for the part where it tastes like piss, I agree completely.
<infinity> (note: That's the American usage of the word "piss", meaning "urine", not the British/Australian usage, meaning "alcoholic beverage")
<mjg59> You're wrong, and you're a grotesquely ugly freak
<infinity> Duely noted.
<infinity> (Twiggy)
<zul> BenC: there isnt an abiname for 2.6.15-9.11 in the git archive?
<BenC> zul: not yet, because I have no abi files yet
<BenC> actually, I was getting ready to do that
<zul> hehe
<BenC> everything is in NEW still, so I can't
<zul> blah...ill wait til tomorrow then..hmm...grub or shower...hmm
<infinity> "Everything is in NEW" is something I can work around, if you really want the files.
<BenC> skip_abi=1 is your friend
<zul> yeah i tried setting it to false and still no love
<BenC> mkdir debian/abi/2.6.15-9.11
<BenC> echo 9 > debian/abi/2.6.15-9.11/abiname
<zul> uh i mean true
<zul> there we go
<zul> night night...i can barely stay awake..
<zul> ill push my patches to my tested tree tomorrow
<BenC> ok
<cjb> BenC: OOI, what do I have to do to go from your git tree to a .deb as is built by the build machines?
<cjb> (make-kpkg, I'm sure, but don't know how to replicate your config/initrd/etc.)
<BenC> cjb: debian/rules binary-debs
<BenC> cjb: configs are in debian/config/
<BenC> cjb: if you only want to builds on flavor, do "debian/rules binary-debs flavours=686", and the .deb will end up in debian/build/
<cjb> Awesome.
<BenC> note that each flavour comprises debian/config/i386/config and one of debian/config/i386/config.{386,686,k7,...}
<BenC> same for other arches
<BenC> the config file are the common config items
<cjb> Building now.  Thanks!
<BenC> np
<BenC> sweet, the software for the online poker site I play works under wine
<cjb> Heh, everyone's playing poker lately.  I wonder how I can persuade them that Go is more interesting.
<cjb> Hmph:
<cjb>   DEVLIST drivers/usb/net/zd1211/zddevlist.h
<cjb> make[6] : *** [drivers/usb/net/zd1211/zddevlist.h]  Error 1
<cjb> Interesting.  The relevant awk scripts abort(3)s when run under gawk, which is my default awk, and works under mawk.
<fabbione> morning guys
<cjb> 05:46 <fabbione> morning guys
<cjb> >> /whois fabbione
<cjb> Oops.
<cjb> Good morning.  :)  Early there?
<fabbione> sort of
<lamont> Dec 19 23:25:45 mix kernel: [4369081.099000]  set_rtc_mmss: can't update from 3 to 55
<lamont> wth does that mean?
<fabbione> doh
<fabbione> never seen it before
<lamont> amd64 box with i386 kernel
<fabbione> dapper?
<lamont>  2.6.12-10-k7 on breezy
<lamont> iz production box
* lamont wonders if maybe linux-i386 might be a better idea for this machine
<fabbione> checking...
<fabbione> nothing fancy really
<fabbione> vi include/asm-i386/mach-default/mach_time.h
<fabbione> static inline int mach_set_rtc_mmss(unsigned long nowtime)
<fabbione> this is what sends out the message
<fabbione>         if (abs(real_minutes - cmos_minutes) < 30) {
<fabbione>         } else {
<fabbione>                 printk(KERN_WARNING
<fabbione>                        "set_rtc_mmss: can't update from %d to %d\n",
<fabbione>                        cmos_minutes, real_minutes);
<fabbione>                 retval = -1;
<fabbione>         }
<fabbione> looks like a clock skew of somekind with your cmos
<lamont> sigh... I guess I'll have to drop into the bios
<lamont> back in a few
<fabbione> ok
<fabbione> later
<lamont> fabbione: it looks like it's counting doubletime
<lamont> that is, every 10 seconds, it thinks 20 has gone by
<lamont> s/has/have/
<fabbione> weird...
<lamont> what I really want to know is how to get it to slow back down.  but for now, I'm going to go to bed
<fabbione> lamont: good night :)
* desrt blinks at JaneW with both eyes
<JaneW> hi desrt 
<desrt> how's life in ubuntu land?
<fabbione> Unpacking linux-image-2.6.12-10-amd64-generic (from linux-image-2.6.12-10-amd64-generic_2.6.12-10.24_i386.deb) ...
<fabbione> now..
<fabbione> catch the weirdness :)
<JaneW> desrt: good, how are you?
<desrt> JaneW; exausted from the term at school.  but last exam is tomorrow
<fabbione> lamont: chinstrap:/home/fabbione/linux-image-2.6.12-10-amd64-generic_2.6.12-10.24_i386.deb please test :)
<JaneW> desrt: cool, good luck
<desrt> thx.
* desrt goes to bed now :)
<desrt> cheerio.
<fabbione> night desrt 
<desrt> nite :)
<CataEnry> hi! :)
<cjb> lamont: Hello.  If that's an HP box with an ATO bridge, I know how to fix your double-counting problem.
<cjb> ATI, I mean.
<cjb> (And it's not related to which arch's kernel you use.)
<zul> heylo
<BenC> good morning
<BenC> infinity: ping
<BenC> anyone know how to get evolution to play well if I insert a diff inline that I don't want to have line feeds added?
<jbailey> BenC: Try highligthing it and marking it as "preformated"
<jbailey> In the style dialog
<BenC> ok
<zul> hmmm...thats weird
<zul> drivers/acpi/i2c-acpi-ec.c: At top level:
<zul> drivers/acpi/i2c-acpi-ec.c:309: error: unknown field 'name' specified in initializer
<zul> drivers/acpi/i2c-acpi-ec.c:309: warning: initialization from incompatible pointer type
<zul> drivers/acpi/i2c-acpi-ec.c:310: error: unknown field 'id' specified in initializer
<zul> drivers/acpi/i2c-acpi-ec.c:310: error: 'I2C_ALGO_SMBUS' undeclared here (not in a function)
<zul> make[4] : *** [drivers/acpi/i2c-acpi-ec.o]  Error 1
<zul> make[3] : *** [drivers/acpi]  Error 2
<zul> make[2] : *** [drivers]  Error 2
<zul> make[2] : Leaving directory `/home/chuck/kernel/builds/kotd/build/ubuntu-2.6/debian/build/build-686'
<zul> make[1] : *** [stamp-build]  Error 2
<zul> make[1] : Leaving directory `/home/chuck/kernel/builds/kotd/build/ubuntu-2.6/debian/build/build-686'
<zul> make: *** [build]  Error 2
<zul> sorry
<BenC> jbailey: thanks, that worked
<BenC> zul: current git?
<BenC> ah, I see the error in my build aswell
<BenC> I'll get it fixed shortly
<zul> BenC: remove the .name in the stuct is one fix
<fabbione> hey BenC 
<BenC> hey fabio
<zul> BenC: its look like its totally removed from the acpi-tree
<zul> or its an external driver..bleah..
<BenC> yeah, I'm fixing it up
<BenC> dev_acpi.c is broken too
<BenC> the compat ioctl stuff has changed
<mjg59> There's a new release of dev-acpi
<BenC> ah, that would be easier than all these changes I can't test :)
<mjg59> Not sure if it deals with that, but...
<BenC> well I got it to compile without errors/warnings, but that's just for x86...no telling about x86_64
<BenC> but since we're 64-bit userspace on x86_64, it shouldn't matter much
<BenC> wow, latest dev_acpi is like 6 source files instead of two :)
<BenC> nm, it just has extra tools
<BenC> mjg59: the new driver doesn't compile right either...I'm going to disable it for now (since it hasn't even been built for dapper yet anyway)
<BenC> zul: pushing changes now to get things compiling again
<BenC> dev_acpi and i2c-acpi-ec may end up getting removed
<BenC> nice, #21313, "Sound issues", no description
<zul> yeah its a dup
<BenC> of which one?
<zul> BenC: there is something about in the thinkwiki about that problem..its a laptop issue
<BenC> 21315
<zul> yeppers
<fabbione> BenC: can you slam an eye on netdev?
<zul> heh...one eyed monster...
<zul> my mine is in the gutter sorry..
<zul> mind even
<lamont> cjb: how do I fix it?
<lamont> and yes, HP box, ati bridge
<Robi-> crimsun , alive?
<Robi-> BenC, you maintain some usb drivers correct?
<infinity> Argh.
<infinity> BenC : You broke my headers!
<infinity> I guess that's what I get for not testing builds on all arches before I upload...
<infinity> BenC : amd64-k8-smp (at least) is missing (at least) the asm/* headers.  See the amd64 LRM failed build log.
<BenC> hmm
<infinity> yeah, that's one possible response.
<infinity> Another could be "yes, massa, I fix it right now massa"
<infinity> Or some variant thereof. :)
<BenC> is the package missing for k8-smp?
<zul> messa people think people going to die?
<BenC> oh, I see
<BenC> yes massa, it be fixted up for da nes upload massa
<infinity> Kay.  No -meta love until it is, or amd64 blows up. :)
<cjb> What was that about k8-smp?  :)
<BenC> I can do -9.12 tonight
<BenC> no ABI bump :)
<infinity> I'll dep-wait LRM on -9.12, so it'll trigger as soon as you get it in.
<cjb> Ah, I was just wondering where LRM was.
<infinity> BenC : Do you have a -meta upload primed that adds amd64-server?
<BenC> no
<BenC> but I'll get one ready to go out with -9.12
<zul> why the hell does it feel like a friday?
<BenC> holidays
<zul> true but im stuck at work..
<zul> the acpi stuff you did compiles
<infinity> amd64 / linux-restricted-modules-2.6.15
<infinity>   Version             : 2.6.15.3-2
<infinity>   Builder             : buildd+yellow
<infinity>   State               : Dep-Wait
<infinity>   Depends             : linux-headers-2.6.15-9-amd64-generic (>> 2.6.15-9.11)
<infinity> BenC : Ball's in your court.
<infinity> BenC : I can do linux-meta as well, and dep-wait it on LRM, if that'll help things get through quicker.
<infinity> (It'll get linux-meta out there for non-amd64 arches)
<BenC> ok
<fabbione> whats the deal with .12?
<BenC> fabbione: amd64-k8-smp issue only
<fabbione> ah ok
<fabbione> well you can still unleash LRM
<fabbione> if there is no ABI change..
<fabbione> BenC: the sparc kernel is in the archive if you need the ABI files
<BenC> ok, thanks
<BenC> is there a better place than ports.ubuntu.com?
<BenC> neither hppa nor sparc seems to be available from there
<fabbione> your e3k? ;)
<BenC> well there's that for sparc :)
<fabbione> BenC: it should appear in no more than 5 minutes on ports
<fabbione> i guess it's syncing from jackass as we speak
<BenC> lamont: ping
<infinity> BenC : Were you planning on doing SMP2UP on amd64?
<zul_> i think he already did it
<BenC> infinity: tried
<infinity> Failed?
<BenC> the linker script fails to relocate the lock table
<infinity> Ahh, poop.
<BenC> not sure what that's all about, it's the exact same thing for x86
<infinity> I suppose it will require a hammer of some sort.
<infinity> Would ne nice, though, since amd64 has a much more mixed SMP/UP install patter out there (especially with the multicore stuff)
<infinity> Anyhow, linux-meta is uploaded; it won't build on amd64 until the new amd64 LRM is built.
<zul> BenC: ping pull
<zul> oh wait..
<BenC> infinity: ok, thanks
<zul> now pull
<cjb> I'm running SMP amd64 on dual-core with LRM, if you need any testers.
<BenC> sucks, I can't do any upload till I get some hppa abi files
<BenC> and they aren't uploade dyet
<BenC> well, they are, but they got rejected because of some newline issue with the buildd mail relay or something
* BenC bothers lamont
<infinity> HP's mail relays wrap lines (as the RFCs claim they're allowed to do, to be fair)
<infinity> buildd-mail doesn't like gratuitous line-wrapping and barfs.
<infinity> I need to fix the latter, but I blame lamont entirely for not circumventing the former. :)
<BenC> infinity: user claims ata errors went away with -9, can you confirm?
<BenC> two users in fact
<cjb> Coo, they got X running on the Linux Treo 650 port.
<infinity> BenC : Iwas one of those users.  Read your bugzilla comments more closely. :)
<cjb> .. and I was the other.  :)
<CataEnry> bye all
<BenC> oh, that last one was from you :)
<BenC> I expected a "Hey dumbass, you finally got something right" if you confirmed it :)
<infinity> BenC : Even more interesting, though not valid to that report, so I didn't comment on it, those failed assertions went away with -9
<BenC> excellent
<infinity> (Or, at least, the printk went away)
<BenC> nice that I closing more bugs than are getting opened...I really was expecing more bugs after flight2 than what I've had
<BenC> most of the ones I'm closing, I didn't fix though :)
<infinity> Fixing bugs is so passe.
<infinity> I need to attack my bug list with a vengeance post-Christmas.
<infinity> Should be a barrel of laughs.
<BenC> yeah, why fix bugs when you can just upgrade to the latest version
<cjb> infinity: Anything interesting on it?
<infinity> I guess I can dupe all the fglrx and nvidia bugs against a master "prorpietary modules sometimes break, and I can't fix it" bug.
<BenC> The funniest bug report I have right now is 21034
<BenC> a user did an install, and then rebooted with all sorts of noapic nolapic options, and said it wouldn't boot
<infinity> cjb : I dunno.  I have 150 bugs or so, one or two are bound to be interesting.
<BenC> but has not yet tried booting without those options :/
<cjb> Yow.
<BenC> infinity: do what I did, canned message saying "test with latest version", mark it needsinfo
<BenC> if they don't respond post London-Sprint, I'm closing them :)
<infinity> Heh.
<BenC> I've actually gotten a lot of testing from it though...and most times, the bug is fixed
<mjg59> BenC: So, bcm43xx is pretty much moving over to the devicescape stack
<infinity> That's just mad scientist enough to work.
<mjg59> (by the looks of things)
<cjb> I also get "PCI: Cannot allocate resource region 0 of device 0000:010:11.0" if we're posting warnings.  :)
<mjg59> cjb: That's probably fine
<infinity> Oh, speaking of bcm43xx... If we're shipping it now, should we find some firmware of questionable origin that we can slap in LRM?
<mjg59> What is that device? Your IDE controller?
<BenC> mjg59: everything is moving in that direction
<cjb> (And boot hangs with noapic.)
<mjg59> infinity: Finding the firmware is easy, having any sort of permission to distribute it less so
<infinity> mjg59 : Right.  Though I'm not sure what our level of permission is on the acx firmware either...
<infinity> (It would seem to be implicit consent, or soemthing on that level of sketchiness)
<BenC> infinity: bad thing is, they didn't do such a hot job of naming the firmware with some way of having lots of it installed (like acx was)
<BenC> same filename, 5 different versions
<mjg59> infinity: We have the same problem with the firmware for the TI xx20 flash readers
<infinity> BenC : Easy enough to fix the driver to handle that.
<mjg59> Of course, we also have the problem that that's distributed in an encrypted form
<BenC> yeah, and we'll end up with a mapping of pci dev/ven/subdev/subven id's to match to versions
<BenC> which works for me
<cjb> Flash readers use firmware?  Eww.
<infinity> mvo : How do you feel about the state of our current draft of NetworkWideUpdates?
<infinity> mvo : If someone were insane enough to spend some "spare time" starting to build small bits of it...
* BenC pulls from linus and prays the abi hasn't changed
<infinity> Of course it has.
<BenC> post rc6 is supposed to be important fixes only
<infinity> And important ABI changes.
<BenC> hppa should hope for an abi change, else it willbe ftbfs from 9.12
* BenC ordered his powerbook today
<BenC> wont be here before christmas though, so no gift from santa :(
<infinity> nictuku : /me notes that mvo isn't in this channel, and he misfired.
<infinity> ARGH, TYPING HARD, SHOULD HAVE SLEPT LAST NIGHT, I BLAME MJG59 FOR EVERYTHING.
<cjb> BenC: Which Powerbook, OOI?
<BenC> 17" 1.67ghz
<cjb> Very nice.  I wish they did slightly higher resolution, though.
<cjb> (The Dell 17"s do 1920x1200.)
<BenC> 1280x1024 is good enough for me
<cjb> Heh.
<cjb> My desktop is 2560x1600.  :)
<infinity> My 1400x1050 thinkpad has spoiled me, I can't go back now.
* cjb <heart> Apple 30" Cinema Display.
<BenC> I only use X for firefox and now xchat and evolution, most of the VT's are used for actual work though :)
<BenC> X is my distraction
<BenC> yes, and Apple 30" display would keep me in X :)
<BenC> it's too easy to go Applications->Games while I'm on the gnome desktop
<cjb> Yeah.  On the 30", I have top-right quarter for firefox, bottom right for evolution, and the left half the screen is tiled with xterms and emacsen.
<BenC> spoiled you are
<cjb> It's true.  But I work from home, and value my comfort a lot.  :)
<BenC> sweet, no ABI changes for i386 so far
<BenC> lol
<mjg59> infinity: You were lying awake thinking about me?
<infinity> mjg59 : It's the concave chest.  Gets me hot and bothered.
<infinity> Mostly bothered.
<cjb> Ooh, do you really have a concave chest?
<mjg59> cjb: Yes
#ubuntu-kernel 2006-12-18
<BenC> infinity: You probably already know, but soyuz is borked
<BenC> s/is/was/
<infinity> BenC: Nah, had no clue, I'm trying to ignore work. :)
<infinity> BenC: What sort of borkage?
<BenC> it was telling me that linux-meta failed to build, but the log showed a build for some other package
<infinity> !
<infinity> BenC: On the website, or in the email sent to you, or both?
<BenC> website
<BenC> actually it showed dep-wait, because the package couldn't install all the deps it needed
<fabbione> yo guys
<derekS> is hald/udev related to the kernel? ie if they are having a bug, and i switch kernels, would that bug still be there?
<infinity> Oh wow, the web interface is completely borked...
<BenC> fabbione: Hey, how was your flight?
<BenC> infinity: So is it ok, just that the web interface is broken?
<infinity> BenC: No, I think the web breakage is a symptom of deeper arghitude.
<infinity> BenC: I'm going to leave it in cprov's hands, and go back to VACing, but I'll check in later.
<fabbione> BenC: almost eventless.. slept a lot.. talk with a couple of blonde hot chicks.. otherwise all good :)
<BenC> fabbione: sounds like a pleasant flight :)
<fabbione> yeah it was good
<fabbione> Seattle airport sucks tho.. passport check is REALLY slow'
<fabbione> infinity, BenC: did you guys already reported the problem to cprov?
<infinity> fabbione: Yes.
<infinity> fabbione: He's looking into it.
<fabbione> infinity: ok thanks
<fabbione> i assume we have no ETA..
<infinity> Hard to have an ETA without knowing what broke.
<fabbione> well they must have a record of the changes they did last week
<infinity> BenC: should be all better now.
<derekS> infinity: are hal/udev problems kernel issues?
<infinity> derekS: They're userspace issues, though obviously, kernel changes can affect them.
<infinity> derekS: This isn't a channel for reporting bugs either way.  File bugs on udev or hal (wheverever the problem is), and let it get triaged.
<derekS> ok
<derekS> thanks
<derekS> i am trying to fix myself :)
<infinity> [  160.240000]  fglrx: Unknown symbol sys_call_table
<infinity> BenC: ^^^
<BenC> where's that?
<infinity> BenC: When trying to load fglrx.
<BenC> which kernel I mean
<infinity> BenC: -2-generic
<infinity> (base)adconrad@cthulhu:~$ cat /proc/version /proc/version_signature 
<infinity> Linux version 2.6.20-2-generic (root@vernadsky) (gcc version 4.1.2 20061212 (prerelease) (Ubuntu 4.1.1-21ubuntu2)) #3 SMP Sat Dec 16 12:28:13 UTC 2006
<infinity> Ubuntu 2.6.20-2.2-generic
<BenC> ok
* infinity goes back to radeon.
<infinity> BenC: Want a bug report with more useful info, or is that enough for you?
<BenC> just a quick email to help me remember in the morning
<infinity> benc@ or bcollins@ ?
<infinity> I can never remember.
<BenC> latter
<fabbione> BenC: 
<fabbione> git clone git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-2.6
<fabbione> remote: Generating pack...
<fabbione> remote: Done counting 398707 objects.
<fabbione> fatal: unexpected EOF
<fabbione> fatal: early EOF
<fabbione> fatal: index-pack died with error code 128
<fabbione> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git' failed.
<fabbione> any idea what could cause that?
<infinity> BenC: Sent.
<BenC> sounds like something on kernel-org
<BenC> fabbione: try rookery:/srv/kernel-team
<BenC> infinity: thanks
<fabbione> BenC: ok
<kkubasik> do kernel crash messages go to  a log file?
<kkubasik> scratch that, I found it
<kkubasik> ok, i am experiancing a crash with 2.6.20 386
<kkubasik> http://pastebin.ca/283250
<fabbione> kkubasik: file a bug in launchpad.'
<kkubasik> alright, just wanted to make sure
<fabbione> BenC: did you notice any regression on PB G4 with .20-1 ?
<fabbione> it seems like the fn key is gone for good
<fabbione> gonna check with older or newer kernel later
<tepsipakki> what's the status of tg3-backport to dapper? Since there was a security-release last week, I suspect it will still take a while?
<Lure> BenC: just noticed this on 2.6.20: 
<Lure> [   25.304000]  speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPIconfig is depr
<Lure> ecated.
<Lure> [   25.304000]   Use X86_ACPI_CPUFREQ (acpi-cpufreq instead.
<BenC> Lure: good to know, thanks
<Lure> BenC: not sure if this was before in -17 and -19 - I just noticed it today on -20-2
<BenC> I think it has to do with some new config options that weren't adjusted for
<BenC> would be nice to have gotten a compile time warning about that
<kylem> moo.
<BenC> kylem: Roar! (like a bear)
<kylem> gah. enough with the bloody bear.s :)
<BenC> I showed me family the good/bad bear at an early Christmas gathering yesterday
<BenC> I think I ruined Christmas
<Lure> BenC: more info: http://lkml.org/lkml/2006/12/1/25
<BenC> Lure: Thanks, made the config changes
<mjg59> BenC: I don't quite understand your objection to the dscape patch
<BenC> mjg59: No objections, just somehow I managed not to have the ieee80211_ptr part of it in there
<BenC> Going to try having it in there next upload
<mjg59> BenC: Ah, ok. 
<mjg59> That would explain things :)
<luneo> I have a question.... Is there any way to maintain a Ingo Molnar rt patch based kernel? and I know that the rt patch from Molnar breaks the others ubuntu patches...
<BenC> bug 76294
<BenC> luneo: Sure, you are more than welcome to do that
<luneo> Another question... I am trying to cross-compile the rt15 kernel from Molnar... my host system is a ia32... and I am trying to compile for x64 systems... but the toolchain-source dosen't compile... gcc dosen't compile... so I used some wrappers... to parse the m64 thing,.. but at the infiniband driver, I get and error 1 and 2, (2.6.19.1 kernel), and the config is based on the Molnar x64 config... and he didn't had any problem... is the
<luneo>  a solution for the toolchain-source...
<luneo> for the toolchain-source I just did, tpkg-make amd64-linux, debuild binutils and debi, and then, tpkg-install-libc amd64, debuild gcc...
<luneo> ok, thanks for the effort tough...
<\sh> moins
<\sh> did anybody have a clue about this error message? Dec 18 19:23:11 fai-noc kernel: [361111.808688]  sudosh[31758]  general protection rip:402fd3 rsp:7fffffa6a6d0 error:0
<joejaxx> BenC: is 20-2 compiled with cell support enabled?
<BenC> yeah
<joejaxx> BenC: thank you :)
<BenC> you going to test it?
<joejaxx> i have someone to test it
<BenC> I'd really like to know if it works on ps3 :)
<joejaxx> yeah :) i am going to build a fluxbuntu feisty image with that kernel
<joejaxx> for testing
<joejaxx> BenC: i will let you know how it goes :)
<BenC> thanks
<joejaxx> BenC: you are most welcome
<pmjdebruijn> Cell support is going to be included on the PPC iso?
<BenC> the kernel has the cell options enabled
<BenC> whether we support it or not is a different story
<pmjdebruijn> ok, unofficially support it
<joejaxx> BenC: i think the biggest problem whould be the fact that people do not have machines to test it
<pmjdebruijn> won't that be just a matter of time?
<joejaxx> BenC: everyone has i386's and powerpcs
<pmjdebruijn> I mean Cell is just one configuration, just the PlayStation III, it's not like with a PC that you can have a quadrilion hardware configurations
<joejaxx> pmjdebruijn: i do not know if everyone is going to go out and buy a $600 gaming system for testing support
<pmjdebruijn> joejaxx, of course not... but some folks are bound to buy a PS3
<Keybuk> BenC: OOPS are not my friends
<BenC> pmj: question is will those ppl be capable of getting it working
<BenC> hmm, he left
<ivoks> eh :/
<ivoks> um, BenC i know this isn't support channel, but i'm kind of clueless where to look :)
<ivoks> BenC: do you know what could cause high loand (kacpid-work-0 takes 100% proc) with amd64 version of kernel (dapper) on intel xeon?
<BenC> not off hand
<ivoks> ok, thanks :)
<joejaxx> BenC: the G5's use the powerpc64 kernel?
<BenC> yes
<joejaxx> hmmm interesting
<PriceChild> ping BenC
<BenC> PriceChild: pong
<PriceChild> Hi there :)
<PriceChild> I'm a moderator from ubuntuforum. I'm here regarding a thread which has turned into actively suggesting people use the feisty kernel packages on their edgy system for "testing"
<BenC> who started the thread?
<BenC> or started the suggestion I mean
<PriceChild> was talking to laser jock about it who referred me to you to check what we thought
* PriceChild checks
<BenC> basically it's a good idea, as long as initramfs-tools, module-init-tools and udev are also upgraded from feisty
<BenC> I still run edgy on all the machines I use for kernel testing
<PriceChild> pochu, tormod, 
<PriceChild> Ok
<PriceChild> I posted a big scary red message telling people that they shouldn't be doing this... I'll edit it to say it is "sort of ok" if they upgrade those packages. However may still have problems and it will be hard for people to support them?>
<PriceChild> BenC: also what about bug reports from users using this method?
<BenC> as long as it's a kernel bug, and not some userspace issue, then file it as normal
<PriceChild> ok thankyou for your clarifcations :)
<PriceChild> *clarifications
<BenC> np
<zul> mmmm...evil
<zul> ..
<dade`> 516M    ubuntu-2.6
<dade`> never noticed :)
<Toadstool> heya!
<Toadstool> http://librarian.launchpad.net/5420830/buildlog_ubuntu-feisty-amd64.ifplugd_0.28-2.1ubuntu1_FAILEDTOBUILD.txt.gz <-- does anybody have any idea why the build worked on i386 and failed on the other archs?
<thom> Toadstool: looks like a linux-libc-dev bug
<BenC> Toadstool: It should not include linux/types.h
<Toadstool> ok thanks a lot :)
#ubuntu-kernel 2006-12-19
<eegore> I installed 4 gigs of ram in this box and the os only sees 3
<eegore> running dapper
<eegore> kernel 2.6.16-27-k7
<eegore> kernel 2.6.15-27-k7
<BenC> egore: There's some overhead in highmem
<BenC> eegore: ^^
<eegore> paging?
<kylem> i suspect it's because your bios reserves space for mmio.
<eegore> ASUS A*n-E
<eegore> A8N-E
<eegore> 25% overhead?
<kylem> well, that really depends how you look at it.
<kylem> when you have video cards with 512M addressable...
<eegore> so what you are saying is the bios is caching the data in memory as a i gig cache memory
<eegore> 1*
<mjg59> You have 4GB of address space
<mjg59> And some of that's being kept by the BIOS for PCI devices and the like
<mjg59> Check whether your BIOS says anything about memory holes
<mjg59> If not, you lose
<ajmitch> one case where it can be a good idea to run amd64
<mjg59> amd64 actually has the same problem
<mjg59> Well, with some chipsets
<kylem> mmm double address cycle.
<eegore> running a 64 bit cpu on 32 bit dapper
<ajmitch> it appears to be fine with my system, at least
<eegore> not enough app support for 64 bit
<mjg59> eegore: It's not an OS issue. Windows will behave identically.
<mjg59> I'm afraid it's something you'll have to discuss with your hardware vendor.
<eegore> so the system itself is using a gig to cache the I/O?
<mjg59> No
<kylem> it doesn't cache it.
<kylem> it doesn't address it.
<mjg59> The system can access 4GB of address space
<mjg59> Most of that is RAM
<kylem> you could remove one of the dimms, and it would make no difference.
<mjg59> But it has to put PCI cards and other mmio devices somewhere
<mjg59> The displaced RAM isn't used at all. It's idle.
<eegore> so I would need a bios patch if it is availble to access it fully with more options in the setup
<mjg59> There may already be one
<mjg59> But it'll be called something like "memory hole"
<mjg59> Otherwise, yes, you'd need some sort of bios support
<eegore> that is setable?
* ajmitch does see quite interesting memory sizes in dmesg
<eegore> [17179569.184000]  3200MB HIGHMEM available
<eegore> [17179569.184000]  896MB LOWMEM available.
<mjg59> Erm.
<mjg59> That would seem to suggest that you have 4GB.
<eegore> what is the 1 gig being reserved for 
<derekS> this probably isn't the right forum for this question, but what is the difference between "HIGHMEM" and "LOWMEM"?
<derekS> like why does it have 2 types
<derekS> (my comp also has 896MB of lowmem reserved)
<mjg59> lowmem isn't reserved
<mjg59> The split is because you only have 4GB of address space
<mjg59> And that has to be split between physical addresses and process address space
<derekS> mjg59: i only have 2 gigs
<mjg59> You have 4GB of address space
<mjg59> Because you have a 32 bit system
* derekS is going to do some googleing as to the difference between HIGHMEM and LOWMEM
<mjg59> http://linux-mm.org/HighMemory
<derekS> ahh
<derekS> thanks
<derekS> reading
<derekS> mjg59: but you said that this issue is also present on 64bit os's?
<mjg59> The highmem split isn't
<mjg59> But that's got nothing to do with eegore's problem
<derekS> ohh :)
<mjg59> It's normal to have a split between lowmem and highmem on 32 bit systems
<derekS> so i am better off wiping the 32bit os, and putting on the 64bit version?
<mjg59> If you've only got 2GB, not really
<derekS> ok
<mjg59> But PCI needs to live below 4GB
<mjg59> So unless the system supports remapping the memory above 4GB in order to leave space for PCI, you'll still have the problem even on a 64 bit OS
<mjg59> Especially since older Opterons can't remap memory
<derekS> i have an older opteron (i think)
<mjg59> But you've only got 2GB
<mjg59> So it's fine
<derekS> yeah, i am not worried
<derekS> i don't need more
<derekS> i was just interested
<ajmitch> mine appears to give me the 4GB, so I'm happy with it
<derekS> thanks for explaining
<eegore> mjg59: so a bios upgrade may push he pci past the 4gig barrier?
<mjg59> Possibly
<mjg59> But you'd then need to use the server kernel to access it
<mjg59> (Or the 64 bit version of Ubuntu)
<eegore> eeeewwwww
<eegore> The server kernel has to be comiled right?
<eegore> compiled
<mjg59> 32-bit kernels in "Not able to access memory about 4GB" shocker
<mjg59> No
<mjg59> linux-image-server
<eegore> will all the other hardware detection work or is that different in the server kernel
<mjg59> It should be fine
<eegore> I may have to bite the bullet and load up a 64 bit os
<derekS> hey, i am about to file a bug, i just want to make sure it *is* a kernel bug, and not an X bug (has to do with my mouse). I initially put it in udev, but fabbione said it wasn't there. can someone take a look at 73425 *just* to make sure it is a kernel bug?
<eegore> later all
<zul> morning
<BenC> hey zul
<zul> hey BenC how is it going?
<BenC> not too bad
<zul> good to hear
<zul> redhat is suppose to rlease their 2.6.19-rc1 xen kernel tomorrow
<zul> but other than that i have been better
<BenC> 2.6.19-rc1, as in based on the pre-release of a released kernel?
<BenC> or xen-rc1?
<zul> pre-released of a released kernel
<zul> yeah i know...:)
<zul> good thing the bossman at work is not going to be here tomorrow ;)
<\sh> datten:
<\sh> grmp
<\sh> BenC: in 2.6.20: are we including the PWC driver for logitech usb cams?
<BenC> \sh: Yeah, it's one of the modules I still need to forward port
<\sh> BenC: cool...
<dade`> BenC: on 2.6.20 the FN key of macbooks does not work anymore
<fabbione> dade`: confirmed here too
<dade`> fabbione: do you have a macbook ?
<fabbione> dade`: PB G4
<fabbione> same keyboard
<dade`> uh ok
<fabbione> BenC: ^^ do you want a bug for this?
<fabbione> BenC: or should I unleash your wife with the G4 against you? :P
<BenC> hehe
<BenC> let me check the config options
* fabbione heads for a smoke
<BenC> debian/config/powerpc/config:CONFIG_USB_HID_POWERBOOK=y
<BenC> same for i386
<BenC> and amd64
<fabbione> BenC: i think it's a code regression
<fabbione> it's the only key that's gone foobar
<fabbione> from .19
<BenC> anyone willing to bisect it?
<fabbione> wound't be easier to identify first whatchanged?
<BenC> the change was a switch to a generic hid layer
<fabbione> actually
<fabbione> benh
<fabbione> i am sure he knows
<BenC> I don't think it's anything ppc specific
<fabbione> yeah but i am pretty sure he is hiding the body of who did the change as we speak
* kylem ducks off for food.
<jbailey> BenC: What do you need bisected on pc?
<jbailey> ppc?
<BenC> pc or ppc, just has to be a macbook/powerbook
<jbailey> Oh, nope.
<BenC> to check the FN key
<jbailey> I was vaguely hoping it was my ppc64 booting bug. =)
<BenC> you have a ppc64 booting bug on feisty-2.6.20?
* BenC notes his ibm ppc64 has no such problems :)
<jbailey> BenC: Yup, submitted to you last night with a photo of the oops. =)
<jbailey> s/you/launchpad/
<jbailey> 'sokay, I'm sending this box to Kyle shortly to play with.  I suspect that all the bugs will suddenly melt away. =)
<BenC> jbailey: deja vu...sata_svw seems to never get any love till you find out it's broken, and I fix it :/
<BenC> I wonder if it's the same damn bug I fixed in edgy
* BenC checks
<jbailey> BenC: I'm glad I'm an early adopter, then. =)
<BenC> I'm betting it is
<BenC> jbailey: Can you test a kernel with this little patch to see if it works?
<jbailey> BenC: I'm not near the machine, but I can tonight.
<BenC> jbailey: I'll build it, put it on rookery and send you an email
<jbailey> Thanks, much appreciated!
<BenC> hello mdz_sort_of_online
<fabbione> mdz: do you want a shell from where you can irc without timeout all the time?
<BenC> jbailey: http://people.ubuntu.com/~bcollins/kernels/
<jbailey> BenC: Hm,  should I be brave and reboot the box remotely? =)
<jbailey> BenC: If it comes up, it worked, it not, I'll reset it when I get home in a couple hours. =)
<zul> jbailey: hey how is the new place?
<jbailey> zul: Wonderful!  It's so nice to be moved.
<zul> good to hear
<jbailey> BenC: Can't ssh to it, I think it didn't work.  Ah well. =)
<BenC> jbailey: Hopefully it's something else...I'm sure this patch fixed a bug
<jbailey> =)
<jbailey> Oh!
<jbailey> Linux starshine 2.6.20-3-powerpc64-smp #2 SMP Tue Dec 19 20:27:47 UTC 2006 ppc64 GNU/Linux
<jbailey> The bloody must've decided it was time to fsck.
<kylem> lol.
<jbailey> BenC: ^^
<jbailey> Was that the same thing as last time? =)
<BenC> sweet
<BenC> yep
<jbailey> I'm surprised other's aren't tripping on it.
<jbailey>   CHANGELOG: Do not edit directly. Autogenerated at release.
<jbailey>   CHANGELOG: Use the printchanges target to see the curent changes.
<jbailey>   CHANGELOG: Use the insertchanges target to create the final log.
<jbailey> *lol*
<jbailey> When you *know* something was a one-off build ;)
#ubuntu-kernel 2006-12-20
<jbailey> BenC: How do I get those attributes?
<BenC> jbailey: find /proc/device-tree | grep k2_sata
<BenC> it's either k2_sata or k2_ata
<jbailey> root@starshine:~# find /proc/device-tree | grep k2_sata
<jbailey> root@starshine:~# find /proc/device-tree | grep k2_ata
<jbailey> root@starshine:~# 
<BenC> try just k2 then
<BenC> is anything in device-tree?
<jbailey> k2-sata =)
<BenC> ah :)
<BenC> jbailey: Can you also send me a dmesg output?
<BenC> jbailey: cat <path to k2-sata>/interrupts
<BenC> or maybe just interrupt
<jbailey> root@starshine:/proc# cat /proc/device-tree/ht@0,f2000000/pci@7/k2-sata-root@c/k2-sata@0/interrupts
<jbailey> root@starshine:/proc# 
<jbailey> root@starshine:/proc# cat /proc/device-tree/ht@0,f2000000/pci@7/k2-sata-root@c/interrupts
<jbailey> root@starshine:/proc# 
<kylem> ...
<kylem> ?
<jbailey> kylem: Trying to get some info to BenC that I odn't know much about.
<BenC> duh, OBP interrupts is pointless compared to the internal mapping
<kylem> via ctcp...?
<BenC> if you got a ctcp, your IRC client is whacked :)
<kylem> 16:13:17 jbailey [n=jbailey@montreal.canonical.com]  requested unknown CTCP root@starshine:/proc# from #ubuntu-kernel:
<BenC> hehe
<BenC> jbailey: Can you send the dmesg? It should show the IRQ mappings
<jbailey> Oh whups, I haven't hit send yet. =)
<jbailey> kylem: Oh cool.  Yay magic characters. =)
<jbailey> BenC: I need to go home before the SWMBO gets annoyed.
<jbailey> bbiab. =)
<kylem> super wicked mambo?
<zul> single white male body order?
<a_thing> Was looking through the list of what gNewSense removed, and I saw that those files weren't in Ubuntu's kerel.
<a_thing> Why isn't this mentioned anywhere?
<gebruiker> is 2.6.19 stable in?
<\sh> does anyone know when HugeTBL FS support was added to the kernel?
<zul> whee..
<fabbione> BenC: http://zeus2.kernel.org/git/?p=linux/kernel/git/davem/sparc-2.6.21.git;a=commitdiff;h=54c9cc37c8559ed9e574c0ca2600099f3fe9ac14
<fabbione> it's propagated
<holycow> am i correct to understand that there are issues with i945gm and gma950 chipset/graphics from intel?  i'm googling support for this and cant figure out where the support is supposed to be dropping into the kernel for these ...
<BenC> holycow: We have support for that in kernel already
<BenC> at least in edgy and feisty
<holycow> aha, but not dapper.  so 2.6.16 and greater.
<BenC> no, actual support in stock kernels is 2.6.18+
<fabbione> BenC: can you confirm me that /sys/block/sda/device/type is 0 for harddisks and 5 for cdroms?
<BenC> I backported it for 2.6.17 in edgy
<BenC> fabbione: I'm pretty sure that there are other types, but maybe scsi layer consolidated those
<BenC> there was also RBC(?) that some sbp2/firewire drivers were reported as
<BenC> drives
<fabbione> BenC: i am happy to know if they are scsi disks or scsi cdroms :)
<holycow> BenC, well in that case, i could kiss you
<holycow> lol
<fabbione> OBP doesn't know much more... tapes.. but last time i checked, we don't install on tapes :)
<holycow> okay cool.  is it safe to say intel is playing nice with you guys and properly open sourcing drivers for these chips?
<BenC> fabbione: include/scsi/scsi.h starting at line 208
<BenC> holycow: I would say Intel is play far more than nice with us
<fabbione> BenC: thanks man
<BenC> fabbione: TYPE_RBC is the one I was refering too, if you see that, I'd say it's almost surely a disk
<fabbione> BenC: i don't think OBP can boot from it, can it?
<holycow> BenC, good to hear.  time to toss in a vote for them then.
<dade`> oprofile i
<dade`> ops
#ubuntu-kernel 2006-12-21
<BenC> fabbione: Not sure if the ones that have built-in firewire can boot from sbp2 or not
<BenC> fabbione: Actually, I think it is possible...I remember my Blade 100 had sbp2 support in firmware
<fabbione> BenC: hmmm
<fabbione> BenC: ok.. people can file bugs.. for now i am happy to support scsi/ide/sbus
* kylem goes to try and sleep off this horrible sickness some more.
<zul> good luck
<bronson> BenC: what are your -updates trees? Are they a place to stage patches before merging into the dist tree?
<bronson> i.e. patches are baked in ubuntu-edgy-updates.git, then pulled into ubuntu-edgy.git when it's time to release a new kernel?
<BenC> bronson: They are in -updates, and supposed to be put into -proposed where the get tested before inclusion in the main tree
<bronson> BenC: so, if I want to keep my linux-vserver kernel on top of Edgy development, I should periodically rebase it on top of -updates.  That way, when you do build a new kernel, my derivative kernel will be pretty much ready to go?
<bronson> or..  maybe I should track -proposed?
<BenC> keep it on edgy proper
<BenC> -updates can be broken at any time
<bronson> Ah good.  OK, will do.
<gnomefreak> BenC: are you here? initramfs-tools was unable to overwrite
<gnomefreak> is it safe to force the overwrite like i would with any other package?
<gnomefreak> btw no its not its missing depends (seems to be a bunch of crap that is stopping it
<fabbione> BenC: davem has a firewire device here.. we will get the OBP mapping today
<fabbione> he also thinks we can boot from it
<fabbione> but only if the device is plugged in at poweron
<BenC> fabbione: Yeah, I think I tested that a loooong time ago
<BenC> I'm pretty sure you can, if you have the latest OBP for the box
<BenC> fabbione: Write my name on that firewire drive too, so dave remembers where it came from :)
<fabbione> ahaha
<fabbione> it's just a shell script to parse the obppath sysfs attribute really
<fabbione> did you try booting your e3k with the new patched?
<fabbione> patches
<fabbione> find /sys -name "obppath*"
<BenC> not yet, I'll give it a try later
<fabbione> ok
<maks_> BenC thanks for the merge
<maks_> i seem to have posted my review of your changes to the wrong channel, will recap
<maks_> * check_minkver() lives in hook-functions you should have it twice now
<maks_> * +rm -f /etc/initramfs-tools/modules is doubled in postrm
<maks_> * ubuntu used to use busybox mount for nfs
<BenC> maks_: Ah, thanks
<kylem> BenC, i merged my -updates and the dapper security stuff, what do you think of a -proposed upload?
<BenC> kylem: I'll look at it in just a couple of minutes
<BenC> maks_: Can you merge the s/Build-Depends/Build-Depends-Indep/ change?
<BenC> maks_: And if you could add " | busybox-initramfs" to the depends, that would fix all the debian/control merges
<maks_> BenC remind me why is the s/Build-Depends/Build-Depends-Indep/ needed?
<maks_> yes i'll add that to the depends list
<BenC> maks_: Because initramfs-tools is binary-indep, so the build-depends are actuallt for the binary-indep portion of the build
<BenC> On the Ubuntu build, we only upload source
<BenC> so the binary-indep portion gets built on i386
<BenC> in order for the buildd to process that correctly, the build-deps need to reflect reality
<maks_> ok, thanks for the info
<BenC> maks_: One other question I had was the {-q,-Qb} modprobe inconsistencies we have
<BenC> I think the -b makes it respect modprobe.d blacklists
<maks_> debian modprobe didn't have that arg irc
<BenC> and the -Q makes it quiet about ignoring a blacklisted module (which -q wont do)
<BenC> the man page doesn't show it, but "modprobe -h" will show it
<maks_> no it's not there
<BenC> it has to be, unless you guys have a super old modprobe
<BenC> what version of module-init-tools?
<maks_> ii  module-init-to 3.3-pre3-1
<BenC> is it -Q or -b that it doesn't have?
<maks_> -Q
<BenC> ah, right, it's an ubuntu patch it seems
<BenC> maybe -qb then
<maks_> ok
<BenC> the -b is the important part, because users need to be able to blacklist modules and have initramfs scripts respect that (e.g. for the case of buggy force loaded modules)
<maks_> fully agreed
<BenC> maybe you could just export one MODPROBE_OPTIONS in /init
<BenC> modprobe will respect it, and that'll localize any changes we have to make for -Q
<BenC> maks_: In scripts/init-top/framebuffer, the VESA and SPLASH vars aren't used anywhere...I thought it was a leftover Ubuntu patch, but it's in your source
<maks_> # Set modprobe env
<maks_> MODPROBE_OPTIONS="-qb"
<maks_> export ${MODPROBE_OPTIONS}
<maks_> BenC: indeed, kick those
<BenC> maks_: Just uploaded ubuntu4 with the changes you mentioned, thanks.
<maks_> cool i get the diff, i'm monitoring :)
<maks_> BenC: the discussed changes on my side are in 0.85f, need to push 0.85e first into testing
<maks_>   * debian/control: Change Build-depends-indep to Build-depends as we need
<maks_>     debhelper and cdbs for the clean target, fulfills policy 7.6.
<maks_> so
<maks_> not sure if i want to pick that up
<BenC> hmm
<fabbione> BenC: get ready for ubuntu5 ? :)
<BenC> fabbione: Might just be 0.85fubuntu1 :)
<fabbione> ehe
<BenC> ubuntu5 uploaded...glad this isn't a heave package to build
<BenC> heavy
<fabbione> BenC: are we sure it doesn't have lvm or mdadm stuff?
<BenC> it has an mdrun that only gets used if mdadm isn't also there
<Mithrandir> BenC: fubuntu < ubuntu. :-P
<fabbione> hmmm
* fabbione hopes for the best
<BenC> fabbione: you asked me to remove it :P
<BenC> I don't have any machines with a lvm/md root to test
<fabbione> lvm is ok.. must go
<fabbione> i am not sure what that mdrun can do without mdadm installed
<fabbione> i guess i will have to clean up that clusterfuck when i am back in january
<fabbione> and the first guy that's gonna complain about the abuse of the word clusterfuck will get to solve all the mess
<BenC> fabbione: it runs if there is no local-top/mdadm, but it exects mdadm binary to be present if raid is required
<fabbione> ok, then it's totally useless :P
<fabbione> once you install mdadm you get local-top/mdadm :)
<BenC> probably debian/ubuntu friendly
<fabbione> probably
<fabbione> or probably due to lack of communication between the 3 developers that can't agree on where these scripts should exists
<BenC> maks_: Am I correct that the resume stuff in initramfs supports suspend2?
<fabbione> because our mdadm is the same as debian
<zul> yeah so one of the managers here at work changed the locks fo the server room without telling us
<kylem> i think that means you're fired
<kylem> or evicted
<zul> yay... just after i got my stock options
<maks_> fabbione, BenC: the mdrun hook is for partial upgrades from sarge -> etch, where you have initramfs-tools but not yet the new mdadm
<fabbione> maks_: kthx.. BenC we can kill it.. we don't support partial upgrades anyway
<maks_> yes there should be some code in mkinitramfs that can go as well
<maks_> maraked as to be removed after the etch release
<maks_> BenC: afaik suspend2 has it's own i-t boot hook, but i might be wrong never used that crap
#ubuntu-kernel 2006-12-22
* Starting logfile irclogs/ubuntu-kernel.log
<BenC> WARNING: "clear_page_dirty" [fs/reiserfs/reiserfs.ko]  undefined!
<BenC> WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko]  undefined!
<BenC> yay, I wonder if that's a good reason to disable reiserfs :)
<zul> pretty clear to me
* zul just discovered meld and fell in love
<zul> BenC, who wants to use a filesystem of a supposed wife killer anyways?
<maks> zul you could buy namesys :-P
<zul> BenC, i have the patch for 2.6.19 now i could possibly goto 2.6.20 though
<zul> BenC: ping *cough* http://zaitcev.livejournal.com/110306.html
<Mithrandir> 30 partitions?  Somebody needs to tell that guy about LVM
<zul> yay!
<zul> chuck@chucktest:~$ uname -a
<zul> Linux chucktest 2.6.19-xen #1 SMP Fri Dec 22 09:59:43 EST 2006 i686 GNU/Linux
<zul> Password:
<zul> Name                                      ID Mem(MiB) VCPUs State   Time(s)
<zul> Domain-0                                   0      737     2 r-----     10.3
<zul> test.cfg                                   1      128     1 -b----      0.0
<zul> test2.cfg                                  2      128     1 -b----      0.0
<zul> happy holidays everyone im off
<fabbione> hmmmm
<fabbione> and what't cool about .19 when we are at .20?
<siretart> the vmware modules don't build anymore against 2.6.20. is there some workaround for that?
<mjg59> Rewrite the broken bits, I suspect
<mjg59> There may already be a patch floating around somewhere
<zorglu_> q. how can i increase the efficiency of the /dev/random ? i use the box for like 10h and it is not even able to generate one key without blocking for 3min
<zorglu_>  /proc/sys/kernel/random/ <- is there some sutff in there that i could tune to make /dev/random more usable
<zorglu_>  i use ubuntu dapper kernel, if it helps
#ubuntu-kernel 2006-12-23
<schorpp> lo
<schorpp> BenC, did You solve Your rt2500 problem ?
#ubuntu-kernel 2006-12-24
<jldugger-tablet> is there any documentation about the lowlatency kernels?
<crimsun> jldugger-tablet: what do you seek?
<jldugger-tablet> the holy grail?
<crimsun> jldugger-tablet: so far there are only two changes from -generic, config_hz is 1000, and config_preempt is set
<jldugger-tablet> knowledge, mostly, like what changes and whether its useful for laptops / desktops
<jldugger-tablet> what's the generic hz?
<crimsun> 250
<jldugger-tablet> so that's longer time slices and pre-emptable kernel?
<crimsun> shorter
<jldugger-tablet> yes, i screwed up hz with ms ;)
<jldugger-tablet> crimsun, is there a spec or plans for this in the future?
<crimsun> jldugger-tablet: _MMA_ should be working on a spec for UbuntuStudio's use
<jldugger-tablet> heh, again ive failed to state that properly. didnt mean to imply that someone should be writing a spec
<_MMA_> Any help is welcome on the spec. contact me in #ubuntustudio.
<jldugger-tablet> "(spec | plans) for lowlatency kernel in the future" is what i meant, but that answer works in either case i guess
<jldugger-tablet> i dont really have any needs exactly for low latency, so i wont get in your way :)
<jldugger-tablet> just saw the kernel when i was apt-cache searching and it caught my attention. g'luck!
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.20-3.3 uploaded - Merry Christmas, and no bears. Use it, but there are still a few missing modules.
#ubuntu-kernel 2007-12-17
<mekius> Anyone know if pata_via is going to be reenabled in the Ubuntu kernels in the near future?
<mekius> If anyone is around, how is it determined whether to load ide-generic?  We have a chipset which doesn't work with the via28xxx module, but loading ide-generic makes the drive appear.  ide-generic is obviously not ideal, but at least it works.  Shouldn't this load if no other module loads for a piece of hardware?
<mekius> This is why I ask about pata_via since I'm assuming it will autoload
<Kano> hi, could somone fix the powerpc build of 2.6.24? it did not find a modules file
<kraut> moin
<tseliot> BenC are you there?
<tseliot> I'm trying to get the nvidia driver to work with DKMS however the compilation fails
<tseliot> here are the two files I had to add to debian/ :
<tseliot> http://albertomilone.com/ubuntu/nvidia-kernel-source.postinst
<tseliot> http://albertomilone.com/ubuntu/nvidia-kernel-source.prerm
<tseliot> and this is the modified debian/rules:
<tseliot> http://albertomilone.com/ubuntu/rules
<BenC> tseliot: it fails to compile in the postinst?
<tseliot> yep
<BenC> what's the failure message?
<tseliot> this is the command which the dkms should execute:
<tseliot> echo "MAKE[0]=\"export IGNORE_XEN_PRESENCE=1; make -C /usr/src/nvidia-${nv_drv_choice}/ -f Makefile.kbuild SYSSRC=/usr/src/linux-headers-${flavours} KBUILD_PARAMS="-C /usr/src/linux-headers-${flavours}" module\""
<tseliot> if you need the exact error I can log out, install the generated driver and reproduce the problem
<BenC> I can't really help you without knowing what the actually error is
<tseliot> ok, I'll be right back with the error
<tseliot> BenC here is what happens when I install nvidia-kernel-source
<tseliot> Unpacking nvidia-new-kernel-source (from .../nvidia-new-kernel-source_100.14.23+2.6.22.1_i386.deb) ...
<tseliot> Setting up nvidia-new-kernel-source (1:100.14.23+2.6.22.1) ...
<tseliot> Adding Module to DKMS build system
<tseliot> Doing initial module build
<tseliot> Error! Bad return status for module build on kernel: 2.6.22-14-generic (i686)
<tseliot> Consult the make.log in the build directory
<tseliot> /var/lib/dkms/nvidia/100.14.23/build/ for more information.
<tseliot> Installing initial module
<tseliot> Error! Could not locate nvidia.ko for module nvidia in the DKMS tree.
<tseliot> You must run a dkms build for kernel 2.6.22-14-generic (i686) first.
<tseliot> Done.
<tseliot> now I'll paste the real error from the log
<tseliot> DKMS make.log for nvidia-100.14.23 for kernel 2.6.22-14-generic (i686)
<tseliot> Mon Dec 17 18:34:23 CET 2007
<tseliot> make: Entering directory `/usr/src/nvidia-100.14.23'
<tseliot> make: Nothing to be done for `/usr/src/linux-headers-2.6.22-14-generic'.
<tseliot> NVIDIA: calling KBUILD...
<tseliot> make CC=cc -C modules
<tseliot> make: Entering an unknown directory
<tseliot> make: *** modules: No such file or directory.  Stop.
<tseliot> make: Leaving an unknown directory
<tseliot> NVIDIA: left KBUILD.
<tseliot> nvidia.ko failed to build!
<tseliot> make: *** [module] Error 1
<tseliot> make: Leaving directory `/usr/src/nvidia-100.14.23'
<tseliot> BenC this is all it says. Ideas?
<BenC> ok, next time, use pastebin :)
<tseliot> sure :P
<BenC> -C modules
<tseliot> BenC ok this is the only line of the new error
<tseliot> make: *** modules: No such file or directory.  Stop.
<BenC> well, it's doing -C in the wrong place
<tseliot> the nvidia kernel source package should put the content of the former nvidia source tarball into /usr/src/nvidia-100.14.23
<tseliot> BenC here is the content of that folder:
<tseliot> http://pastebin.com/m6c3fa512
<tseliot> BenC and here's the content of the dkms.conf:
<tseliot> http://pastebin.com/d769a1430
<mekius> Hi, anyone here able to tell me why the pata_via driver is not included in the kernel?  Also is there an easy way to build a single module without rebuilding the entire kernel so we can just package this module?
<rtg_> mekius: hardy? 'CONFIG_PATA_VIA is not set' might just be  an oversight.
<mekius> rtg_: On gutsy kernel, 2.6.22-14
<mekius> I have read there were issues with it during dapper/edgy, but haven't found any info on it from feisty/gutsy
<mekius> I saw some updates to it as recent as 2.6.22-6
<rtg_> mekius: dunno. you'll have to rebuild the kernel and experiment with it.
<mekius> ok, I will try it out
<rtg_> mekius: just so you know, the earliest opportunity to get it enabled by default will be for Hardy.
<mekius> Yes, I assumed was the case
<mekius> I have 3 VIA chipsets to test against, so I'll be able to provide some testing data
<mekius> Hopefully all goes well as we are having issues with a chipset that isn't supported by the old pata driver and ide-generic doesn't load by default to cover it
<mekius> rtg_: Is there anywhere that I could read why the module was disabled?
<cheguevara> damn the new linux-restricted-modules-2.6.24 FTBFS again
<rtg_> mekius: perhaps search LP? BenC was dealing with pata stuf f last time.
<mekius> rtg_: I work for gOS and have contacts at VIA who I'm trying to get to be more open and write their drivers in the community, so any information on what is broken would be good :)
<mekius> rtg_: OK, I'll look around
<BenC> mekius: I believe there is a bug about this...the libata-pata driver doesn't work as well as the ide driver, or something along those lines
<tseliot> BenC: any ideas? The nvidia-new-kernel-source package I made seems to contain the same files as Mandriva's equivalent nvidia-dkms package...
<BenC> mekius: I believe we disabled the pata-via driver because it was getting broken when host-protected-area was being ignored
<mekius> BenC: Ok, I will dig around, just unfortunate since we have some newer hardware and they are begging for it to be supported heh.
<BenC> tseliot: sounds to me like the proper vars aren't getting passed to the underlying build
<mekius> BenC: Do you know if anyone has attempted to fix these issues, or will they still exist if I build it manually?
<mekius> BenC: I'll look around launchpad, like I said I saw an update in 2.6.22-6 for it, but nothing after that
<mekius> Also some misc updates before that revision as well
<BenC> mekius: sad part is, that was disabled because of feisty, and it seems we never tried re-enabling it to see if it was still broken
<BenC> so it may work, we just don't know
<rtg_> mekius: if you saw updates in 2.6.22.Y, then they are also upstream.  You might try the current 2.6.24-rc kernel.
<tseliot> BenC: yes, I know, but how are those variables passed in the official debian/rules you made?
<mekius> BenC: Well I can test with a few chipsets and report back.  I will let you know how well it works.
<mekius> BenC: I realize that testing is hard without the hardware around :)
<BenC> tseliot: check the rules file, I don't recall off the top of my head
<mekius> rtg_: Is that in the Hardy repo?
<rtg_> mekius: yep, but you'll have to enable the CONFIG option.
<BenC> mekius: any testing you can provide is very much appreciated
<rtg_> mekius: I can build a CONFIG_PATA_VIA in about 20 minutes one if you want to test.
<mekius> rtg_: Sry, I'm not all that familiar with Ubuntu, I do this when I install the package?
<mekius> BenC: Can do, I need to test anyway, so might as well try to get this working upstream :)
<mekius> rtg_: Does it just run make menuconfig during install if I set evn var CONFIG=true?
<rtg_> mekius: um, its a little more involved then that. gimme a few minutes....
<mekius> rtg_: ok, thx
<tseliot> BenC: this is the line you use in your rules:
<tseliot> $(ROOT_CMD) make -C $(builddir)/$$i/nv-new -f Makefile SYSSRC=/usr/src/linux-headers-$$i KBUILD_PARAMS="-C /usr/src/linux-headers-$$i SUBDIRS=$(builddir)/$$i/nv-new" module;
<BenC> tseliot: I have to be honest, I've never worked with dkms, so I don't know how to set it up to pass those vars down to the sub-build
<BenC> tseliot: mdomsch would be the guy to talk to
<tseliot> BenC: I really appreciate your honesty. I'll go bug mdomsch then ;)
<rtg_> mekius: http://people.ubuntu.com/~rtg/linux-image-2.6.24-2-generic_2.6.24-2.3_i386.deb-pata-via
<mekius> gah, browser tries to load it heh
<mekius> wget :)
<mekius> rtg_: Is that just a .deb then?
<rtg_> mekius: yes. download it, then 'sudo dpkg -i linux-image-2.6.24-2-generic_2.6.24-2.3_i386.deb-pata-via'
<mekius> yeah
<reynaldo> rtg_ hi, can I stole you a minute?
<rtg_> reynaldo: yes?
<mekius> rtg_: going to take a bit of work since i need to install it via a chroot into the system I installed onto the harddrive.  Is this going to cause conflicts with the modules in the linux-ubuntu-modules package?
<rtg_> mekius: you need to be on bare metal in order to install a kernel. A chroot isn't gonna test your VIA disk problems.
<rtg_> mekius: and no, the modules installed are completely separate.
<mekius> rtg_: well what i'll do is install the kernel to the hard drive and then reboot to the hard drive, only option :/
<mekius> can't get booted into the hard drive copy, well maybe if i could load ide-generic in the initrd
<mekius> if this doesn't work, i'll try that
<rtg_> mekius: I see. then that may be the only way.
<mekius> rtg_: Yeah, I'm having all kinds of fun, can't you tell :)
<rtg_> mekius: yep - its a bitch when your base drivers don't work.
<mekius> indeed
<rtg_> reynaldo: I don't have a Freenode registered nick. You'll have to use email.
<mekius> ide-generic is so slow too, took over an hour to install heh
<rtg_> mekius: one of the features I hope our installer guys figure out is a way to blow an ISO onto a USB drive. It really speeds things up.
<reynaldo> rtg_: ok, sending it over, thanks a lot.
<mekius> rtg_: :)
<mekius> rtg_: wish me luck heh
<rtg_> mekius: hopefully it won't trash your drive, which is a real possibility with the protected area stuff.
<mekius> rtg_: Just a test system, no important date
<mekius> data*
<rtg_> mekius: I would expect to work on a fresh install, but an upgrade from a driver that honors HPA to a driver that does not is surely gonna trash something.
<mekius> rtg_: I think it's booting :D
<mekius> still waiting for it, but it has made it farther then before
<kylem> rtg_, BenC, i was going through old photos and thought you might like this: http://www.flickr.com/photos/__kyle/2117175970/in/set-72157603479056297/
<mekius> rtg_: So the new driver doesn't support something important is what you are saying?
<mekius> rtg_: Well it booted fine without destroying anything :D
<mekius> rtg_: This is good news for me heh
<rtg_> kylem: man, that seems like awhile ago.
<kylem> http://www.flickr.com/photos/__kyle/2116459477/in/set-72157603479056297/
<kylem> it was. ;-)
<BenC> kylem: sweet
<BenC> it was only a little more than 6 months ago
 * BenC loved the "Follow Me" truck
<BenC> I have the other side to the dueling cameras photo
<mekius> rtg_: Did you see any updates to pata_via since 2.6.22-14?
<rtg_> mekius: can you paste the 'lspci -vvnn' output in http://paste.ubuntu-nl.org/. Lets be sure its doing what we think.
<mekius> rtg_: I didn't find anything while searching
<mekius> rtg_: ok
<rtg_> mekius: I haven't been looking at the .22 tree since we stopped Gutsy development.
<mekius> ok
<mekius> hmm, ok, we may have some issues, can't gurantee they are due to this module exactly, but definitely having problems
<BenC> http://www.flickr.com/photos/__kyle/2117196194/in/set-72157603479056297/
<BenC> kylem: ^^ it's not too often you get to see what you'll look like in 40 years :)
<rtg_> mekius: for example?
<kylem> hehe
<rtg_> BenC: yuk, yuk.
<mekius> Well getting a lot of graphics corruption, might be due to files not being read of the disk?
<mekius> happens when i moved windows mostly
<rtg_> mekius: that could be VIA agp.
<rtg_> mekius: its unlikely to be a disk issue.
<mekius> Well we are using openchrome drivers, so maybe an incompatibility :/
<mekius> rtg_: paste.ubuntu-nl.org/48573
<rtg_> mekius: looks right. the 0581 PCI device ID is specifically supported.
<reynaldo> rtg_: sent, thanks again.
<reynaldo> BenC: hi there ben, gently pinging again. still waiting for your answer. I understand you must be _uterly_ bussy but I just dont want you to forget or even worst, to think I forget about it.
<BenC> reynaldo: I'll catch it in the morning. Sorry it's taking so long
<BenC> wtf
<BenC> I can't see what is causing this:
<BenC> dpkg-genchanges: warning: duplicate files list entry for package xorg-driver-fglrx (line 23)
<BenC> that's while building lrm on i386...can't reproduce it locally
<reynaldo> BenC: no need to be sorry, we are all just trying to help ;) thanks again!
<mekius> rtg_: Ah, might be due to the via drm driver getting loaded
<rtg_> mekius: it does sound like a graphics issue.
<mekius> yeah, i'll try to unload it, but the terminal is hosed heh
<mekius> having to type blind
<mekius> Good thing I know how the tab completion behaves like the back of my hand :0
<mekius> :)
<mekius> rtg_: Is is possible to build and distribute the pata_via module in a seperate package
<rtg_> mekius: yes, but you'll have to tell me what the advantages are.
<mekius> rtg_: Hmm, seems to only get corrupted when shaped windows come into play
<rtg_> mekius: I think its the only driver that supports you PCI IDs
<mekius> rtg_: Well we would just use it on our machines for now
<mekius> I've only tested it on the one machine
<mekius> i can test on another quick and see how that does
<mekius> Have another notebook with 1106:0571
<somerville32> rtg_, did you apply my patch?
<rtg_> somerville32: this one? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=c0bb64a179acfab520ef9050eb712afd715f6866
<somerville32> No, the one about the userspace typedefs being hidden behind #ifdef __KERNEL__
<rtg_> somerville32: did you send it to the kernel team mailing list 'cause I don't see it (which doesn't mean I might not have deleted it by accident)
<somerville32> rtg_, Yes I did send it
<somerville32> but I forgot to set the subject line
<rtg_> somerville32: did you ever see it appear? The SPAM filter might have eaten it.
<somerville32> I'll check the archive
<somerville32> It is in the archive
<somerville32> https://lists.ubuntu.com/archives/kernel-team/2007-December/001946.html
<mekius> rtg_: Do you think we'll have issues shipping pata_via or would my test here prove that it works ok?
<rtg_> mekius: I would like to see at least a couple of unique PCI IDs tested. I need to research just what the issues were, 'cause if they were HPA then there might be some update issues.
<mekius> rtg_: Ok, I will try to test on a couple more computers today and get back to you.  They should all have different VIA IDE controllers
<mekius> Two are laptops, one's a desktop.
<mekius> I'll have to double check, the others might be using sata
<rtg_> mekius: send the results to the kernel team list so it gets a little wider distribution.
<mekius> Ah ok, will do
<somerville32> rtg_, Did you find the e-mail?
<mekius> rtg_: Where can I find the list info?
<rtg_> somerville32: yes. I think I postponed dealing with it until I saw what happened upstream. However, its simple enough I'll go ahead and apply it (after build testing). If it causes on the next rebase it'll be simple enough to fix.
<somerville32> rtg_, Will you be able to upload today?
<rtg_> somerville32: no. its not likely until after the the 1st. Canonical is pretty much shut down all of next week.
<somerville32> The 1st of January?
<rtg_> somerville32: yes.
<rtg_> mekius: https://lists.ubuntu.com
<somerville32> rtg_, I needed the fix for Alpha 2.
<mekius> rtg_: thx
<rtg_> somerville32: its already too late. Alpha2 is being baked this week.
<somerville32> Then I guess I'll just have to patch xfce4-battery-plugin for now
<mekius> rtg_: If I verify that it works for a few devices would it be able to go into the Hardy alphas?
<rtg_> mekius: Alpha3 https://wiki.ubuntu.com/HardyReleaseSchedule
<mekius> rtg_: k
<tseliot> BenC: I just wanted to let you know that thanks to mdomsch and to your help I got DKMS + NVIDIA to work!!!
<BenC> tseliot: excellent
<tseliot> BenC: I was successful but I had to edit the dkms.conf manually.
<tseliot> However I can't seem to escape the dollar sign as I usually do
<tseliot> this command in the debian/rules
<tseliot> echo "MAKE[0]=\"make module KERNDIR=/lib/modules/\$kernelver IGNORE_CC_MISMATCH=1 SYSSRC=\$kernel_source_dir\"" >> $(CURDIR)/debian/dkms.conf
<tseliot> becomes:
<tseliot> MAKE[0]="make module KERNDIR=/lib/modules/\ernelver IGNORE_CC_MISMATCH=1 SYSSRC=\ernel_source_dir"
<tseliot> and I don't know why $kernelver becomes \ernelver
<tseliot> even if I escape the dollar sign with \$ i.e. \$kernelver
<rtg_> tseliot: try $(kernel_source_dir) 'cause I think its a make macro.
<tseliot> rtg_: mdomsch told me not to expand the variable
<rtg_> tseliot: ok, then how about $$kernelver and $$kernel_source_dir
<tseliot> rtg_: I get this:
<tseliot> MAKE[0]="export IGNORE_XEN_PRESENCE=1; make -C modules /usr/src/nvidia-100.14.23/ -f Makefile.kbuild SYSSRC=/usr/src/linux-headers-2.6.22-14-generic KBUILD_PARAMS=-C
<rtg_> tseliot: ok, I don't know enough about the layers of shell scripts and make files.
<tseliot> neither do I. thanks for trying ;)
<tseliot> rtg_, BenC: I solved it!
<tseliot> $$""kernelver
<tseliot> $$ gives $
<tseliot> however $$kernelver is interpreted as a variable and it's not escaped
<tseliot> $$""kernelver means $ + nothing + kernelver
<tseliot> yay!
#ubuntu-kernel 2007-12-18
<TheMuso> c
<TheMuso> argh
<kraut> moin
<abogani> amitk: Are you around? May i disturb you with a couple of simple questions?
<amitk> abogani: yes?
<abogani> amitk: about https://lists.ubuntu.com/archives/kernel-team/2007-December/001948.html
<abogani> amitk: Should i provide patches for enable building fo the rt flavour and for add rt packages into control file?
<amitk> abogani: if you can provide those patches, it will speed up the process. Otherwise one of us will have to spend time enabling and testing the build.
<abogani> amitk: Ok. I start working on.
<amitk> abogani: thanks
<abogani> amitk: Thank you.
<abogani> amitk: Mhhhh. Seems to me that http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;hb=HEAD;f=debian/binary-custom.d/README is outdate...
<amitk> abogani: you are right. While moving to the new tree, one of my patches has gone missing. It should be like this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=blob;hb=HEAD;f=debian/binary-custom.d/README
<abogani> amitk: I have a doubt. For add a custom kernel this link say to edit debian/rules.d/ARCH.mk file but seems to me that only necessary change is in debian/rules.d/0-common-vars.mk at line 92 (all_custom_flavours). 
<abogani> henrix: Hi Luis, Good news: https://lists.ubuntu.com/archives/kernel-team/2007-December/001948.html
<henrix> abogani: hi! just saw the mail in the list :)
<henrix> abogani: that's nice ;)
<henrix> I'll just clone it ;)
<abogani> henrix: I already do a short test on my i386 (x86_32) desktop and it works fine.
<henrix> abogani: tonight I'll try it on my laptop and maybe on a amd64. I'll let you know if I have any problem
<abogani> henrix: Ok. Thank you.
<henrix> abogani: np :)
<abogani> Someone could suggest me where i can buy Ubuntu pre-installed systems? Or at least deliver their products in Italy? I'm live in Italy.... Thank you!
<gaspa> abogani: good question. :)
<austen> Good afternoon. Hoping someone here can help me with why 7.10 i386 desktop edition kernel dies on boot up after install, as well as from the install CD directly.
<austen> Getting "BUG: ubable to handle kernel NULL pointer dereference at virtual address 00000000" with a further "abnormal exit from /sbin/modprobe"
<austen> Boot sequence ends with /root/device does not exist.
<superm1> the 2.6.22 ubuntu kernel can't recognize lzma compressed squashfs filesystems can it?
<mjg59> No
<superm1> that would explain some things then.  lzma appears to be the default for mksquashfs as of hardy
<superm1> when will 2.6.24 go active as default for hardy then?
<austen> I have a question about the difference in IDE support between 2.6.17-i386 and 2.6.22-14-i386 kernels. The kernel that ships standard with 7.10 fails to mount my root partition, saying "ALERT! /dev/hda1 does not exist..."
<austen> Hmmn.. 2.6.20 seems to boot...
<Nafallo> austen: #ubuntu
<Nafallo> austen: this is not a support channel
<austen> Yeah... Tried there.. Sorry for bugging you.
<jayson_r> anyone active in here?
<Nafallo> no
<jayson_r> I was just wondering how to get involved with the kernel team - it's my biggest area of interest - although I'm not a 'coder' I would love to learn more about making the configs, building the packages, etc, as well as testing out new builds and filing bug reports, etc. - that is if you have room for a 'student' on the kernel team...
 * Nafallo waits for one of the employees to answer that one.
<jayson_r> So, I take it from that answer, only Employee's work on the Kernel? If so, that's cool - I just thought I would ask :-)
<Nafallo> no
<jayson_r> oh ok.
<Nafallo> that's not the case, but "student" sounds like you want a teacher.
<henrix> jayson_r: you can start here: https://help.ubuntu.com/community/Kernel/Compile
<jayson_r> Well, I need 'direction' - I don't know where to start
<jayson_r> henrix: Thanks!
<henrix> (no, I am not a Canonical employee :) )
<jayson_r> henrix: I know that much - I know the mechanics of how to complie a kernel, etc., just need direction on how to get involved and contribute back to the distro
<henrix> jayson_r: ok, so you just need to follow the links on https://wiki.ubuntu.com/KernelTeam
<henrix> jayson_r: ah! and you can also create an account on LP and take a look on bug reports ;)
<jayson_r> henrix: THATS the info I was looking for - thank you so much - BTW, I'm already on LP https://launchpad.net/~jayson-r 
<henrix> jayson_r: np ;)
<henrix> jayson_r: good luck then :-)
<jayson_r> henrix: Thanks again!
<zul> jayson_r: no anyone can work on the kernel, bug triaging is a good place to start 
 * Nafallo count zul as employee ;-)
<zul> Nafallo: no im not
<Nafallo> zul: yes you are. but not of that company :-)
<jayson_r> Thanks guys - I just joined the Kernel Bugs team in LP
<jayson_r> So, I assume I look through https://bugs.launchpad.net/ubuntu/+source/linux/+bugs and find something I can fix?
<lamont> BenC: is the logic that anyone who wants to be on kernel bugs deserves it?
<lamont> :-)
<lamont> BenC: doing the installs on on the christmas presents today, fwiw
<lamont> so, uh, christmas is gonna be late
<zul> jayson_r: sure i would just go through the kernel team docs to see if the bug reports provide enough information first
<jayson_r> zul: reading through docs as we type
<zul> jayson_r: cool
#ubuntu-kernel 2007-12-19
<jayson_r> zul: I'm assuming you mean these: https://wiki.ubuntu.com/KernelTeamBugPolicies
<zul> Jayson_r: yep
<zul> since when has there been 154 bugs for the hardy kernel...oh wait never mind
<BenC> lamont: I'm not sure...I'm not even sure that the team is useful
<jayson_r> BenC: I'll do what I can to make it useful :-)
<zul> hah suck on it vmlinuz-2.6.24-rc5-xen
<zul> now to go watch the hockey game
<lamont> BenC: I'm going to go out on a limb and guess that an underlying gutsy install is good foryou.
<d|v> anybody know if intel pentium M dotham support was removed 
<d|v> in the latest kernel
<d|v> speed stepping is no longer working
<clever> how would i go about finding the difference between linux-image-2.6.20-16-386 and linux-image-2.6.22-14-386 within certain files?
<d|v> what do you mean files
<clever> a certain wifi driver has started to panic
<clever> in 2.6.20 it runs fine
<clever> in .22 it panics
<clever> id like to compare the source for those drivers to see what they f'ed up:P
<d|v> you can type in the linux kernel into google
<d|v> and it will load up the ubuntu kernel page
<clever> the driver isnt in the mainline kernel
<d|v> and then you can download the source
<clever> its only within the ubuntu kernel
<d|v> and look at that
<d|v> http://packages.ubuntu.com/feisty/base/linux-image-2.6.20-16-generic
<d|v> something along those lines
<superm1> d|v, kernel.ubuntu.com/git will get you both git trees
<clever> ive riped it out of a apt-get source before and merged it into a diff kernel on another pc
<superm1> you can download the source of the modules and diff them
<d|v> hey super do you know broke speed stepping
<clever> yep thats what i want to do
<d|v> in the latest kernel
<d|v> intel pentium M processors are stuck at 600 mhz
<d|v> with the dotham core
<clever> also .20 lacks a -generic(with smp) which is painfull on my new laptop
<clever> im stuck with the choice of smp or wifi
<d|v> its a known bug
<d|v> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132271
<ubotu> Launchpad bug 132271 in linux-source-2.6.22 "[GUTSY] cpu freq scaling not working anymore" [Low,Won't fix] 
<clever> and the ethernet cord is damaged and falls out
<d|v> but i can't figure out how to patch it
<d|v> and yes they aren't bothering to fix it
<clever> this driver half crashed 1 release ago
<clever> and now its just getting worse
<clever> it loose the last char in the essid
<d|v> i had problems
<d|v> with broadcomm wifi
<clever> my broadcomm refuses to work
<clever> no signal
<clever> 0/100 link quality
<d|v> you need the drive
<d|v> driver
<clever> i have the firmware
<d|v> firmware
<d|v> yeah
<clever> i just gave up
<d|v> i used that on mine
<d|v> to get my wifi working
<clever> and shove this in the pcmcia slot
<clever> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC (rev 20)
<clever> PANIC!
<clever> the -generic is .22 so it panics on that driver
<d|v> worst case you can use
<d|v> ndiswrapper
<clever> i could downgrade the box to .6.20
<d|v> its a bitch to configure
<clever> but then i loose smp and half my speed
<d|v> i'm stuck using the 2.6.20-16-generic kernel
<clever> i cant find a -generic of that
<d|v> the latest 2.6.22 kernel
<d|v> killed my processor
<clever> ouch
<d|v> it locks it in at 600 mhz
<d|v> a 1.7 gigahertz processor
<clever> ah
<clever> my newest system is dual 1.8ghz
<d|v> speed stepping is trashed
<clever> can step down as far as 800mhz
<d|v> and its a low priortiy bug
<d|v> that they aren't going to fix
<clever> my wifi driver was blacklisted so it wouldnt panic systems on boot
<d|v> theyre removing the speedstep-centrino
<d|v> from the kernel
<d|v> so if you happen to have an intel pentium M processor 
<clever> i cant even install 2.6.20 on the smp system
<d|v> you need to build your own kernel from now on and patch it
<clever> model name      : Intel(R) Core(TM)2 Duo CPU     T7100  @ 1.80GHz
<clever> model name      : Pentium III (Coppermine)
<d|v> i here there are problems
<d|v> with dual core
<d|v> processors as well
<clever> model name      : Pentium II (Deschutes)
<clever> thats most of my ubuntu cpu's
<d|v> i might go to fedora
<d|v> i don't want to have to constantly patch the kernel everytime there is a new relase
<clever> E: Unable to find a source package for linux-source-2.6.20
<clever> cant get the old source to compare:P
<clever> ah part of the last release
<d|v> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132271
<ubotu> Launchpad bug 132271 in linux-source-2.6.22 "[GUTSY] cpu freq scaling not working anymore" [Low,Won't fix] 
 * clever adds more sources
<clever> got the source the the 2 kernels
<clever> now to simply apply the diff and then diff it myself
<d|v> i found a patch
<d|v> hoping it iwll work
<d|v> on the new kernel
<clever> if you submit it they shold be able to just t and include it
<clever> without having to do any actual dev work
<clever>  but thats the fun in open source
<clever> with winblows you cant even patch the kernel:P
<d|v> yeah i just use windows for gaming
<clever> and how many bugs might the video driver have?:P
<clever> d|v: how would i apply the diff that i get with a kernel source to make the -16 version?
<clever> -p0 seems do it
<clever> seems they changed from r818x to r8180
<clever> wait
<clever> cant even find the rtl drivers in .22-14
 * lamont grumbles at mdadm
<clever> im getting lost just trying to compare changes to this driver to track down a panic
<clever> cant even find the source in the kernel that panics
<clever> looksike the modules have been split into there own source package
<clever> yeah here the source is:)
<clever> now i need a panic msg
<clever> null modem hooked up
<clever> using a nfs root system for the panic'ing
<clever> less chance of damage to the root
<clever> got a backtrace:)
<clever> now i could reverse changes to that and try again
<kraut> moin
<pmjdebruijn> hi
<pmjdebruijn> I'm having issues installing ubuntu-7.10-server on my HP DL380-G2
<pmjdebruijn> it has a ServerWorks HE-SL chipset
<pmjdebruijn> during the install, e2fsprogs goes wonky
<pmjdebruijn> (the installation of e2fsprogs that is)
<pmjdebruijn> however when using debian, it works just fine
<pmjdebruijn> My guess, is the new SATA style PATA drivers are causing this issue
<pmjdebruijn> as Debian doesn't use those, and Ubuntu does
<pmjdebruijn> is there any way to force those older drivers on Ubuntu as well?
<zul> all_generic_ide
<pmjdebruijn> ok, I'll try that then
<pmjdebruijn> say, if that would solve my issue, what information would I need to provide to get the new style module blacklisted for my system?
<cathyal> where's cj
<cathyal> maybe not
<cathyal> ;/
<reynaldo> about https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/177493
<ubotu> Launchpad bug 177493 in acpi "DELL Inspiron 6400 won't come back after trying to resume from hibernate with lid closed" [Undecided,New] 
<reynaldo> I was unsure about making it an acpi or hibernate bug, went with acpi only because it is the close lid what seems to trigger it
<reynaldo> hope its ok
<reynaldo> other than that, its confirmed, I have done several try outs, all with the same outcome.
<mjg59> reynaldo: acpi is a small program that prints battery information. File it against the kernel.
<reynaldo> mjg59: oh, thought it refered to ACPI as, well, ACPI :-)
<mjg59> No
<reynaldo> mjg59: changed acordingly. Thanks.
<mjg59> No problem
<elcasey> is joydev or other joystick modules that were broken in feisty still broken in gutsy?
<pawalls> Shite...
#ubuntu-kernel 2007-12-20
<zul> evening
<clever> evening
<clever> zul: want to help me debug a kernel panic?
<zul> cant right now
<clever> why not?
<somerville32> ...
<zul> because im busy right now
<clever> lol
<Keybuk> hmm
<Keybuk> sdhci, mmc_core, etc. are loaded
<Keybuk> but nothing happens when I insert an SD card
<clever> Keybuk: depends on your reader
<clever> some readers may just emulate a plain usb disk and hide the SD/mmc layer
<Keybuk> nothing from udev or in dmesg
<Keybuk> (other than the things that made it load those modules in the first place)
<bluszcz> i've created dapper server install with new kernel 2.6.22, but installer shouts "lack of kernel modules". anyone can help me?
<kraut> moin
<dade`> the linux-source apt-packages should contain all patches for xen kernel build too ?
<dade`> 'cause i'm using a 2.6.22-12 kernel and I can't see *XEN* in .config
<clever> i dont beleive the proper config comes in the source package
<clever> you need to take a config from /boot/
<clever> then make oldconfig
<dade`> yes
<dade`> i did that
<dade`> but there is nothing about xen in the config
<dade`> so i was wandering which source generates the -xen image
<clever> and you took the config for the xen image?
<dade`> no
<clever> /boot/config-2.6.15-29-386 would give the config for linux-image-2.6.15-29-386
<clever> you may want /boot/config-2.6.22-12-xen
<clever> which you will probly only get when the linux-image-2.6.22-12-xen is installed
<dade`> hm you're right
<dade`> but there is not -12-xen package aviable
<clever> find a older -xen image
<dade`> hm ok
<clever> and home the old config keeps working on newer source
<clever> most code should work with older config
<dade`> hope
<dade`> yes
<clever> but newer additions may not be enabled
<dade`> i can review 'em
<dade`> ty
<elcasey> I'm having trouble with the "usbhid" module...it's either not installed or something seems wrong with it. Anyone willing to help out?
<elcasey> http://ubuntuforums.org/showthread.php?t=596347&page=5
<mjg59> elcasey: You need separate modprobe commands for each module
<mjg59> usbhid is included with the kernel images
<elcasey> mjg59: so I can't modprobe multiple modules on a single line?
<mjg59> elcasey: Correct
<elcasey> this may have worked
 * elcasey checks
<elcasey> do I need to do a depmod now or somethign?
<mjg59> No
<elcasey> well I did three separate lines for joydev, usbhid and xpad and it doesn't seem to have worked
<elcasey> three modprobes, that is
<elcasey> i'll check the tutorial again and do it with separate lines instead of all on one
<elcasey> bugger...I still get no such device for /dev/input/js0
<elcasey> the guy who wrote the howto claims you need to reboot, but that doesn't seem right to me
<zdzichuBG> ecryptfs in 2.6.24-1-generic is broken? AES is unavailable...
<tseliot> BenC: I have added a new section to the wiki:
<tseliot> https://wiki.ubuntu.com/EnvyNG
<tseliot> the section is titled: Possible Solutions to the problems between Envy and the LRM
<zul> BenC: ping
<BenC> tseliot: ok, cool
<BenC> zul: ?
<zul> BenC, chuck@homer:~$ uname -a
<zul> Linux homer 2.6.24-rc4-xen #4 SMP Thu Dec 20 10:28:20 EST 2007 i686 GNU/Linux
<BenC> good deal
<zul> muhahahaha
<zul> now just to do rc5
<tseliot> if you agree with the changes I suggested there then I will start making patches for lrm
<tseliot> BenC: of course when you have the time.
<tjaalton> BenC: did you notice my questions yesterday on #u-d / read the mail about l-r-m on u-d?
#ubuntu-kernel 2007-12-21
<poningru> hey guys quick question
<poningru> I have a 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02)
<poningru> with hardy running 2.6.24
<poningru> should it be using the b43 driver?
<poningru> I had ndiswrapper installed
<poningru> but now its not working
<crimsun> yes, it should be using b43.
<poningru> I am going to assume no one has said anything
<kraut> moin
<sivang> hi all
<Kano> hi,when will be rc6 merged?
<zul> Kano: probably not til the new year
<Kano> not the answer i wanted to hear
<zul> well it is christmas basically
<Kano> next monday evening
<Kano> not before
<Kano> not today
<BenC> Kano: the kernel devs (and all of canonical for that matter) are on holiday till Jan 2
<Kano> what was the option to disable abi checks?
<BenC> It's on the wiki
<Kano> but doesnt that change the version?
<BenC> skip_abi=true
<Kano> ok, will try my own patchset then
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177725
<ubotu> Launchpad bug 177725 in linux "pnpacpi: exceeded the max number of mem/IO resources" [Undecided,New] 
<Kano> do you know if that is fixed in rc6?
<Kano> also a mini mac did not boot with current 2.6.24
<Kano> also does somebody know how to add a hook for initramfs to add a blacklist option
<Kano> i have such an optin a custon initrd for kanotix, as i need to blacklist prism54
<Kano> sometimes ehci-hcd
<Kano> prism54 is also loaded together with p54pci but my card only needs p54pci
<Kano> softmac cards never work with prism54
<zul> have a good christmas everyone
<Keybuk> so, if I have a built kernel source
<Keybuk> and I've changed the code to one module
<Keybuk> how do I rebuild just that one module?
<soren> "make M=/path/to/module modules" I belive.
<soren> The top-level makefile is richly commented. I'm certain there's an example describing just that.
<soren> Keybuk: ^^
<Keybuk> thanks
<JanC> someone should fix gcc/make to know that by itself  ;)
<Keybuk> that seems to try and build an external module
<soren> Keybuk: Stop pointing it at an external directory?
<Keybuk> that didn't work
<Keybuk> make path/to/module.ko worked from the top level
<soren> Hmm... I'm sure I've done in-tree builds the same way. Oh, well. 
<mjg59> Keybuk: Yeah, that's the way I always do it
<mjg59> Keybuk: You can actually do it from an unbuilt tree as well, as long as you mkdir .tmp_versions
<Keybuk> mjg59: so far, I know it's not just insertion that's broken
<Keybuk> but any kind of detection of the card
<Torgoton> Hey all. The folks in #ubuntu-installer sent me here. I'm trying the bare minimum install on a very old machine, using only the linux and initrd.gz files. Dapper and Edgy start the installer, but Feisty and Gutsy both crash, even when using the 386 versions. I can point you to the gutsy crash output if you like. Also, my keyboard gets mapped all crazy, but I can start an install (with dapper and edgy) if I use a serial console.
<ln-> you are very optimistic by assuming that someone cares.
<Torgoton> Indeed. An optimist I am.
<Torgoton> I thought someone might care that the kernels built for low-spec machines crash on some of them.
<ln-> let me quote what i was told about a crash: 
<ln-> 12:36 < amitk> ln-: If you want JustWorks (TM), you have to either help during beta testing or get a support contract. It is unrealistic to expect that a distribution will hit all your target usecases.
<Torgoton> I was hoping it would hit this one. I know the wiki is a community project and could be out of date, but it claims a 486 with 32MB RAM will be just enough machine for the job.
<Kano> haha, you get better pcs for free ;)
<Torgoton> This machine has 36MB RAM, but I paid a lot for it... when it was new... 15 years go.
<Kano> now you have to pay when you want to give it back ;)
<Torgoton> It's a ThinkPad 750P, and I have Woody on it, and the netboot files for Dapper, Edgy, Feisty and Gutsy, and I can load each of them with Lilo.
<Torgoton> indeed, kano!
<ln-> insignificantly small number of people run ubuntu on 486, i doubt anyone cares to investigate and fix your problem.
<Torgoton> In-, do you need a hug? Where's the holiday spirit?
<Torgoton> If anyone else cares, here's the Gutsy crash output: http://paste.ubuntu-nl.org/49098/
<ln-> i'm only telling the facts.
<Torgoton> Where I'm from, programmers tend to like challenges, especially low-level programmers... like the kind who would know about CPU initialization.
<johanbr> Torgoton: I think your best best might be to build your own minimalistic kernel and see if the error still occurs.
<JanC> I remember that mdz (I think it was him?) ran Ubuntu on a soekris in the past
<JanC> but that might have been dapper or even an older version  ;)
<JanC> Torgoton: is this a real 486 _with_ FPU ?
<Torgoton> janc, it's a 486SL which is supposed to have the FPU.
<JanC> hm, SL ?  I would have to check what that was again  ã
<Torgoton> I'm pretty technical (i've written i960 initialization code years ago), and a long-time linux use, but mostly with Fedora.
<Torgoton> so I am comfortable running suggested commands and capturing logs.
<JanC> ah, 486SL = low power 486DX, yeah, that should have a FPU I guess
<Torgoton> and as I wrote, Dapper and Edgy boot fine (except for the keyboard thing)
<JanC> AFAIK the -386 kernel is compiled with the 486DX as lowest supported CPU in mind
<Torgoton> (and yet they call it the 386 kernel :) )
<JanC> IIRC it's impossible to make a secure i386 kernel
<JanC> some bug in that CPU  ;)
<Torgoton> What?! a bug? in the CPU?!?
<JanC> "invalid opcode" â sounds like it tries to do something not supported by your CPU ?
<JanC> I know nothing more about it  ã
<Torgoton> well, I'll capture the Feisty output and see what's different.
<Torgoton> BTW, anyone know the kernel parameter to make it not mess with the keyboard? Is it keyboard=reset or something like that?
<JanC> how does it mess with the keyboard?  ã
<Torgoton> I type shift, and it shows "v"... the arrows, tab, space and enter don't work in the installer.
<JanC> and it doesn't do that with debian?
<Torgoton> not with Woody.
<Torgoton> 2.2.20 kernel
<JanC> I wonder if this is just a weird keyboard and recent kernels just don't include support for it anymore (at least by default) ?
<Kano> Torgoton: maybe 486SX?
<Torgoton> Kano, nope. 486SL.
<JanC> Kano: 486SL has all DX features + some power saving features, according to wikipedia
#ubuntu-kernel 2007-12-22
<Kano> Torgoton: best: get rid of it
<Kano> even a lowcost router has a faster risc cpu, usually 200 mhz...
<Torgoton> Feisty's nearly the same: http://paste.ubuntu-nl.org/49233/
<Torgoton> This is my first ever PC. I'd like to get her running something modern, just for the fun of it. It would be AWESOME to get the video (which was never ported to X.org), audio and PEN working, don't you think?
<Torgoton> That is, without running Windows for Pen Computing 1.0?
<Torgoton> Oops. Some stuff was cut off in that pastebin. I can re-do it if it would be useful.
<Torgoton> There it is: atkbd.reset fixes the keyboard issue.
<Torgoton> The #ubuntu-installer guys were really proud of the work they did to reduce the memory footprint of the installer in Gutsy, so I was really hoping to use that. But I'm starting an Edgy install. Wish me luck.
<gary4gar> i am looking at what version of driver are there in Ubuntu for Audio,Video(as you said),IDE, RAID & SATA & Ethernet (Networking/LAN/WLAN) for VIA k8m800 + VIA 8237?
<gary4gar> can anyone give any pointers?
<gary4gar> !info linux-ubuntu-modules
<ubotu> Package linux-ubuntu-modules does not exist in gutsy
<poningru> http://packages.debian.org/sid/kerneloops
<poningru> any reason we arent using that?
<poningru> just cause of our built in crash messenger?
<gary4gar> i am looking at what version of driver are there in Ubuntu for Audio,Video(as you said),IDE, RAID & SATA & Ethernet (Networking/LAN/WLAN) for VIA k8m800 + VIA 8237?
<tjaalton> BenC: I know you are on vacation already, but if you don't mind I'll fix lrm so that nvidia/fglrx is installable again on hardy
<tjaalton> also nvidia needs to divert libwfb.so
<tjaalton> huh, ati_revision is 7-11.. shouldn't that be 7.11?
<BenC> tjaalton: the shar file  has 7-11
<tjaalton> oh right
<tjaalton> those bastards :)
<tjaalton> heh, the newest version ("7.12") has 8.443.1 in it :)
<mjg59> BenC: The Toshiba hotkeys patch seems to have fallen out of the kernel again
<mjg59> BenC: Could I *please* have a list of the patches that haven't been forward ported? Gutsy really wasn't fun from that point of view
<maks_> mjg59: get the hacks upstream :)
<mjg59> maks_: Not all of them are upstreamable
<maks_> fedora only forward ports fixes that land in next revision
<mjg59> Some are desired functionality, but not yet in a state that would be accepted upstream. Some are policy decisions. 
<maks_> nommconfig foo
<maks_> congrats for your phd even if i know nothing about bio mjg59 
<JanC> why is this so difficult to "upstream"?
<mjg59> maks_: Thanks!
<maks_> acpi hacks have easily layering violations although i know nothing about the patches that are discussed
<maks_> mjg59: sure :), doing high energy physics 10^9 K stuff
<JanC> so, the kernel needs a clean way to hook in those special keyboard/hotkey things?
#ubuntu-kernel 2007-12-23
<BenC> mjg59: we have a list of the exact commits that didn't clear rebase, and that was one of them
<BenC> mjg59: list emailed to you
<Kano> btw. could someone update gspca? there is a new version out
<Kano> http://mxhaard.free.fr/spca50x/Download/gspcav1-20071220.tar.gz
#ubuntu-kernel 2008-12-15
<andresmujica> .
<speakman_> hello folks
<speakman> when is a kernel comming with the atl1e multicast patch applied?
<speakman> I'm running 2.6.27-10-generic and it's still not fixed.
<speakman> and second; why is scripts in debian/scripts/misc not set +x by default?
<abogani> Those scripts are x enabled on all.
<abogani> For atl1e patch you should point us at Upstream status (aka git commit).
<speakman> really? doing apt-get source requires me to manually set +x
<speakman> abogani: I've already done a few weeks ago :)
<abogani> speakman: You should use git and relative repos (if you want use Ubuntu build infrastructure).
<speakman> the only checkout with git that has atl1e fixed is the "master" branch, and that won't work with nvidia proprietary drivers.
<speakman> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/300698
<speakman> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=790be40d61f4d831dd1893b417d018ba304c5fca
<maxb> speakman: Debian source packages represent the changes against the upstream tarball as a patch. Patches don't preserve executable status
<speakman> oh, i see! thxn
<abogani> speakman: Probably you should wait for 2.6.27-11-generic to see that patch applied
<speakman> abogani: when is 2.6.27-11-generic planned for release? Can I get it now via Git?
<speakman> and btw, when doint apt-get source linux-image-2.6.27-10-generic It'll download linux_2.6.27-9.19.diff.gz
<abogani> speakman: No time planned at the moment. For updated source please read https://wiki.ubuntu.com/KernelGitGuide
<speakman> Really? It breaks alot of computers since ATL1E is very common on Asus motherboards, and Asus itself is a very popular brand. I really think this bug is enough for a kernel update itself.
<apw> speakman, if we release that change it would release as a -11 kernel, are you saying that the nvidia drivers don't work with -11?
<speakman> apw: i'm to "noob" to really make that statement, but I'm trying once again right now.
<speakman> (it's still compiling. it will probably take a while. I'll be back with the results)
<apw> speakman, are you building .deb's from our git tree?
<speakman> trying to, yes :)
<apw> 32 or 64 bit?
<speakman> i remeber last time, it didn't fail while compiling, but when dpkg -i the package
<speakman> nvidia-something failed
<speakman> 23
<speakman> 32
<speakman> It's done compiling! Trying install, please wait.
<rtg> apw: sounds like missing headers for dkms
<speakman> btw, is "header" supposted to beinstalled furst?
<speakman> first*
<speakman> DKMS is the word i was looking for
<apw> they just both need to be installed, but you need the generic and arch headers
<speakman> ? i've only binary-generic
<speakman> do I need another compile?
<apw> binary-indep
<apw> gives you the generic headers
<apw> which is linked to by the arch headers
<speakman> oh, debian/rules binary-indep ?
<apw> yep thats the one
<speakman> -rw-r--r-- 1 daniel daniel  630618 2008-12-15 14:19 linux-headers-2.6.27-11-generic_2.6.27-11.21_i386.deb
<speakman> -rw-r--r-- 1 daniel daniel 5889698 2008-12-15 14:27 linux-headers-2.6.27-9_2.6.27-9.19_all.deb
<apw> yep those are them
<speakman> why two? and why one -11 and one -9 ?
<apw> they should be both the same abi number
 * apw checks his
<apw> linux-headers-2.6.27-11_2.6.27-11.21~webcams1apw1_all.deb
<apw> linux-headers-2.6.27-11-generic_2.6.27-11.21~webcams1apw1_amd64.deb
<speakman> (sorry but I don't know what ABI (Applicatino Binary InterfacE?) number is)
<apw> the -9 and -11 are the abi level
<speakman> k!
<apw> and they should match!
<apw> i am building some -11 based test kernels at the moment, so if you don't get anywhere i can point you at those once they are uploaded
<apw> sadly for you i did the 64 bit ones first
<speakman> can I assist in any way?
<apw> heh nope, purely mechanical build, just waiting for it to complete
<speakman> btw, why ain't there any core2 kernels? wouldn't that optimize pretty much comparing to i686?
<fransman> speakman: I think i686 are core2 kernels, they just run on i686 as well
<speakman> if it can be run on i686 I can't imagine it's using the full potential of core2, but I'm no arch expert.
<speakman> i.e. I'd like PAE enabled to gain >4GB RAM even on 32bit arch
<rtg> speakman: run the -server flavor for PAE support.
<apw> there is very little specific to the newer processors which arn't exposed by cpuid bits and therefore used even on kernels targetted at the lower common denominator
<speakman> rtg: will it work even on my desktop machine? Not slowing the desktop down or anything?
<rtg> speakman: as long as you have the correct headers installed for your nvidia dkms build, it'll work fine.
<apw> everything is a trade off.  enabling pae is not free
<speakman> apw: do you mean there are drawbacks with PAE?
<apw> there are costs yes, every pte entry is double the size, that is not without cost
<speakman> should I be running 64bit on a Core2 CPU maybe? 
<speakman> no idea what pte entry is, but isn't that the same cost as with everything going 64bit?
<apw> i am running 64 bit on my core2 duo
<apw> yep, same thing going to 64 bit as well.  trading off equal use of all memory against things being bigger
<speakman> Not really a kernel question, but will I experience a better performace with a 64bit installation on my core2quad?
<zul> ubuntulog: 
<zul> doh..
<speakman> apw: how is your compiling going?
<apw> just completed the uploads
<apw> they are here: http://people.ubuntu.com/~apw/webcams1/
<apw> there are a couple of webcam id changes in there, otherwise they are the current -11 head
<speakman> okey, I'll just have to download and install and the atl1e issue is gone?
<apw> i believe from the discussion that the head of our tree had the fix in, if so then those binaries should have them
<speakman> how come you got -11 but I got -9 on indep headers?
<speakman> http://henrikalexandersson.blogspot.com/2008/12/och-nu-internetcensur-p-riktigt-i.html
<speakman> Av allt elÃ¤nde pÃ¥ Internet sÃ¥ Ã¤r det p.g.a. spel vi ska filtrera det?
<speakman> Och pÃ¥ IP-nivÃ¥? 
<speakman> apw: is it really i386 and not i686 in your webcams1 dir?
<speakman> oh, sorry for the above, wrong window :(
<apw> i386 is the debian architecture not the kernel sub-architecture tho
<speakman> okay, it's fine running on my core2?
<apw> should be yes
<speakman> no problem with DKMS this time :)
<speakman> rebooting... brb
<speakman> Up'n'running, Multicast enabled and no Nvidia problems :D
<apw> speakman, good to hear no nvidia issues ... so you should be set until -11 is released
<speakman> ...and then the atl1e issue is gone anyway right?
<apw> speakman, yeah then you will get the same base kernel which has the fix, as it'll be based on the one i built there
<Keybuk> quick Q-of-the-day
<Keybuk> if I'm on amd64, how do I do an x86 kernel build?
<rtg_> Keybuk: dchroot using linux32 ?
<Keybuk> why do I need a chroot?
<rtg_> its just the way I do it, 'linux32 dchroot -c intrepis-i386' fior example.
<rtg_> I use a chroot because what I'm doing is sometimes interactive, like fixing compile errors.
<Keybuk> but you can do that anyway?
<rtg_> huh?
<Keybuk> I don't see how a chroot helps you there
<rtg_> if the compile error is unique to the 32 bit build, then its convenient to be in a 32 bit environment.
<Keybuk> the only thing that puts you in the 32-bit environment is linux32 though ;)
<rtg_> correct.
<Keybuk> the chroot just means you might not have 64-bit files around
<Keybuk> do you think make ARCH=i386 would work?
<mjg59> Yes
<mjg59> Setting ARCH overrides the cross-compiler settings
<Keybuk> though I assume I'd need to get the .config somehow
<mjg59> Keybuk: ubuntu/configs
<Keybuk> mjg59: they need catting together and other sed magickery though, right?
<mjg59> cat should be enough
<Keybuk> ok
<mjg59> Just cat generic and the specific i386 one
<mjg59> Later values override earlier ones
<Keybuk> cat ... > .config
<Keybuk> make ARCH=i386 oldconfig
<Keybuk> make ARCH=i386
<Keybuk> ?
<mjg59> Then make oldconfig
<rtg_> Keybuk: you can concatenate the 2 config files, e.g., config and config.i386
<mjg59> Right
<Keybuk> great
 * Keybuk just waits for git now ...
<mjg59> The kernel's entirely happy to do an i386 build on a non-i386 system, as long as ARCH is set
<mjg59> My recollection is that it special cases amd64->i386 to just call with -m32
<Keybuk> yeah, I've generally found it's easier to deal with Kbuild than the Ubuntu debian/rules <g>
<mjg59> kbuild is really optimised for the uncommon case
<mjg59> At the expense of failing at the common case, but that's fine because seriously, who builds their own kernels these days?
<rtg_> I got into the chroot habit when working on kernel dependent packages where the asm link _did_ make a difference.
<mjg59> Yeah, module crossbuilding is hard
<mjg59> Another reason everything should be upstream :)
#ubuntu-kernel 2008-12-16
<tjaalton> linux-libc-dev conflicts with libdrm-dev now? (they both have drm.h)
<tjaalton> bug 308387
<apw> now why would libdrm-dev carry headers from the kernel
<apw> bug #308387
<apw> bah
<tjaalton> apw: being changed as we speak
<apw> so we are removing them from libdrm-dev?  were they simply carrying them because our linux-libc-dev was short some headers?
<tjaalton> upstream moved them into the kernel
<apw> its my fault they are in there now, i fixed our package to track upstream form, carrying all userspace headers from the kernel in one place
<apw> how would i have detected this in advance, so i could have warned the right people
<tjaalton> well, it's fine now :)
<apw> heheh yeah happy its sorted, just wondering if there are any others
<tjaalton> but it's just difficult to know which API .28 has, and should libdrm be updated or what
<apw> we did it as a result of another package carrying some out of date headers which we should be exporting
<tjaalton> and what happens when we want to get 2.4.2 which the upcoming intel driver requires
<apw> so they were aware of the change, having triggered it, but we missed drm
<apw> the headers have to match whats in the kernel, thats the point of them
<apw> having newer drm headers doesn't make the kernel have the updated interface
<tjaalton> but in order to get the new intel driver we need newer drm headers in the kernel
<apw> thats why they have to come with the kernel in the first place, yes
<apw> by which i assume you mean you need an updated driver in the kernel?
<tjaalton> probably that too
<apw> right so thats a different problem, wanting a backport of a driver potentially
<apw> and whether that is possible at the level you want
<apw> if this is jaunty and the driver is mainlined then we should get it when we update our baseline
<apw> on the next -rc or .28 itself
 * abogani waves
<tjaalton> all I know is that the next intel X driver will require libdrm 2.4.2 and probably newer headers as well
<abogani> Is there change to have Ubuntu Build Kernel infrastructure (aka debian/* excluding packaging files) under git *separately* from kernel?
<apw> abogani, what would that do for you?
<abogani> apw: I would want offer the same features (ABI consistency check for example) of the main kernels in community kernel as rt as well. 
<apw> oh i see you want to add it to other kernels, hmmm
<smb_tp> I don't see that we would put it seperately
<abogani> Manually tracking (of your changes) is painful.
<smb_tp> But wouldn't it be possible to do a automated check for changes in that subdir?
<apw> abogani, why is it hard to track the changes in there?  can you not just take logs for that directory alone?
<abogani> I can only see the date of the last commit in debian/ with git log (ignoring changelog etc)
<tjaalton> apw: so, I need to upload a new libdrm-dev without the headers, and you need to add a Replaces for linux-libc-dev :)
<abogani> apw: No. script and Makefile are -generic/server oriented. So for do it works on -rt i must do same changes. Every times that you change debian/* files i must rebase my commit (for example getabi script).
<abogani> s/commit/commits
<apw> oh we do, yeeks, what do i need to add
<apw> can we fold your changes into our abi scripts without breaking them perhaps?
<apw> i wonder if the filter thing could help here, there is a git filter for making new repositories out of old ones, taking say just one subdir
<abogani> apw: I'll check it surely.
<smb_tp> hm, getabi source would be different hosts and specific to whether it is -ports or -rt or ...
<apw> tjaalton, ok so what specifically are we replacing
<smb_tp> abogani, Did we recently add or change something specifically that you missed?
<abogani> smb: rules and rules.d/* are heavily changed.
<tjaalton> apw: the current libdrm-dev, which is 2.4.1-0ubuntu7
<apw> hmm we did clean things up a bit
<tjaalton> lool: is this correct now ^^
<apw> so just that version or <= that version?
<tjaalton> apw: right, <= that version
<apw> Replaces: libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), dvb-dev (<< 1.0.1-6), linux-kernel-headers, libdrm-dev (<= 2.4.1-0ubuntu7)
<apw> as simple as that?
<smb_tp> abogani, And perhaps, would it work for you to take "git log debian", take a start point, use this for git format-patch and re-import those. Maybe this could get automated
<lool> Not really, it should be << next version
<tjaalton> lool: what's the difference?
<lool> It's cleaner for forks of Ubuntu, backports and the like
<apw> so is the next version ubuntu8 ?
<tjaalton> lool: ok, so you wanted to have just the upstream version there?
<lool> The former way is asserting something about version ubuntu7 and older which isn't really specific to that version, while asserting about ubuntu8 is pretty clear
<lool> tjaalton: An upstream version would have been ideal, but you don't have an upstream version just now so we'll live without
<apw> its cirtainly clearer that the change is in ubuntu8 if that is the one mentioned
<tjaalton> apw: yes, << ubuntu8
<abogani> smb_tp:  Oh it is very quick and dirty! :-) I'll do some tests, thanks for suggestion.
<apw> so: Replaces: libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), dvb-dev (<< 1.0.1-6), linux-kernel-headers, libdrm-dev (<< 2.4.1-0ubuntu8)
<lool> apw: BTW, I looked at the control file and it's cluttered by these very old and useless versions you see
<lool> apw: Say 2.3.2.ds1-6, that's before *dapper*, we can happily drop these IMO
<apw> abogani, if you recorded just the HEAD you last updated to you could do that with a git log <oldhead>.. debian
 * lool adds to kernel package cleanup wiki page
<apw> that sounds reasonable, i won't do that in this change tho.  that should be a separate pass over the file
<lool> Yes
<lool> Geez why is the session below BootPerformance
<apw> we do not support updates to N from anything other than N-1 do we?
<lool> apw: We do for LTS
<lool> apw: LTS to LTS
<apw> so from a kernel point of view we need to keep things 
<lool> So you should support upgrades from version of last release and version of last LTS
<apw> back to and including the LTS N-1
<lool> apw: Last LTS is hardy
<lool> Oh right, your sentence was cut, yeah
<apw> yeah i have a keyboard with a central return key, and i've just come back from using my latop for a week so i am hitting it instead of h sometimes, very anoying
<tjaalton> http://users.tkk.fi/~tjaalton/dpkg/drm.diff
<lool> You want to support upgrades from CURRENT-1 and LTS in your dev tree and LTS-1 in your LTS tree
<lool> LTS-1 isn't very clear, but you get the rules anyway
<apw> tjaalton, there should be an LP#NNNN in there yes?
<lool> tjaalton: Uh no
<lool> tjaalton: /usr/include/xf86drm.h is still to be kept in libdrm
<lool> See email thread I forwarded
<apw> lool yes, we can drop the lts-1 when we cut lts+1
<apw> lts+1 normal cycle
<tjaalton> lool: ah :)
<lool> apw, tjaalton: did you compare the list of headers you're moving?
<lool> I mean, I'd like one of you two to make sure that we're not losing any and that they change in a sane manner
<apw> i didn't check as i was unaware they were in libdrm-dev
<tjaalton> I'd like to see the list in l-l-d
<apw> that was somewhat unexpected
<tjaalton> ok see it now
<tjaalton> libdrm-dev has /u/i/intel_bufmgr.h, which I can't find in l-l-d
<lool> Not sure that is clear, but not only should linux-libc-dev Replace the libdrm package, it should actually ship these headers!  :-)
<apw> that package should ship all of the headers the kernel contains and exports, thats its function
<apw> and as of now, that is exactly what it contains
<apw> where are the other ones coming from?
<lool> apw: The problem is that libdrm's drm is usually more recent than the kernel's drm
<apw> but drm is provided by the kernel right?
<lool> I guess this situation is slowly being fixed upstream, but in practice with this move this means we're going to regress the libdrm headers
<lool> apw: The ABI yes, the API used to be provided by libdrm by pure accident for years
<lool> Or because it made life easier for them I don't know
<apw> the files we export define the interface in the kernel so don't they have to match to be meaningful
<tjaalton> newer version: http://users.tkk.fi/~tjaalton/dpkg/drm.diff
<apw> i would expect the lib to export its own headers for its incoming interface, not use the kernel ones for that side
<lool> apw: To be meaningful, everything should match since forever, but because we had the two trees and are moving over, I'd like the delta to be reviewed to understand what might regress
<apw> ie i could expect there to be two headers one for users from the library, and one for the library from the kernel
<apw> if the library is capable of handling a missmatch then it can
<apw> yep a check they match seems reasonable
<apw> if i can figure out how to get the two to compare
<lool> apw: For instance, some xorg stuff might have been built with libdrm's headers and make assumption about the drm which weren't true but we might only discover by a rebuild
<apw> yep, worth worrying about for sure
<lool> Or imagine macros which would only be provided by libdrm's version of the headers because it's slightly more recent, some packages might fail to build without the macros etc.
<apw> tjaalton, still missing a LP reference in that changelog entry need that to close the bug automatically
<tjaalton> apw: oh right
<apw> normally a LP #NNNNN in that text part
<tjaalton> fixed
<tjaalton> yes I've done that a couple of times ;)
<apw> ok so before any of this lot gets uploaded we need to confirm the headers are compatible
<apw> in case we need to revert the kernel carrying the drm headers instead
<apw> it'll probabally get unresolvable dependancy wise if we are not careful if we have to revert later
<tjaalton> should I try to build the intel driver with these?
<tjaalton> 2.4.1 was release five weeks ago
<tjaalton> *releaseD
<lool> I think the intel and ati drivers would be the most interesting ones
<lool> Given that they moved the most in terms of kernel API usage in the last months
<lool> apw, tjaalton: perhaps you can consider using a ppa with new linux, libdrm, intel and ati?
<apw> first i am going to get the two sets of headers and find out if they are different or not
<tjaalton> I could just upload the new libdrm to my ppa, followed by intel & ati
<lool> tjaalton: Yeah
<apw> these headers are pretty different
<apw> and there are some worrying comments in there on the changed parts
<apw> who owns libdrm
<tjaalton> was that a question?
<lool> I think these guys are http://dri.freedesktop.org/wiki/
<apw> i really meant who owns the package we ship
<tjaalton> the x team
<tjaalton> bryce is likely asleep, but that's why I'm here :)
<lool> apw: (xorg team == tjaalton + bryce :-)
<apw> the package seems to be a merge from debian and yet debian linux-libc-dev exports the drm headers, why don't they get this problem
<lool> We inherit from Debian though which has a bunch more, most active probably jcristau
<lool> apw: You just found out why I raised this problem in september :-)
<tjaalton> apw: only the experimental version ships those headers
<lool> Exactly
<apw> oh poop
<apw> sooooo .... we have two options 1) revert exporting the drm headers in our linux-libc-dev package, or 2) work out how we fix it properly
<lool> apw: What types of discrepancies are we talking about here?
<apw> with alphsa2 on thursday we need to decide now i guess
<lool> As you pointed out, it's all the same in-kernel drm ABI in both cases anyway
<apw> mostly its benign looking, but there is a bit about changing size_t to like unsigned long 'so the header can be used in the xserver'
<apw> that sounds pretty worrying
<lool> If that's a kernel ABI it's pretty clear we should align to whatever type is used there
<apw> a lot of the rest of the changes seem to be due to picking up the raw headers and making them work, like __iomem, however the kernel export strips all that
<lool> Is this something Ubuntu specific?
<lool> I mean, is this stripping an extra step we take or is it done by the upstream installation process?
<apw> the stripping of __user etc is a deliberate step the standard kernel header builder takes
<apw> it also strips the _KERNEL_ sections too
<apw> so they are 'clean' of kernel crap in theory
<apw> tjaalton, so, what direction is the experimental stuff going in debian?  any feel for their resolution
<tjaalton> apw: libdrm hasn't seen any changes yet, so I guess jcristau doesn't know about the change either
<apw> ok sooo, that sounds like a mess in the making, but not something we can resolve in days
<apw> so it seems prudent to not change drm, but perhaps to remove the drm headers from the kernel package pending understanding the longer term resolution
<lool> Hmm I wonder whether it's an issue to have a kernel with a version supposedly containing these headers but without the headers
<lool> I poked jcristau
<lool> I guess we should move the discussion to a place where he sits, perhaps #ubuntu-x or #ubuntu-devel
<apw> lool, pick one (channel(
<apw> the kernel has exported a bunch of headers for some time, we have not packaged them
<apw> that was now out of step with upstream and was affecting another project which wanted them
<tjaalton> lool: he's in india right now :)
<lool> tjaalton: k he was around a couple of hours ago
<apw> so it seemed reasonable to move to including them, perhaps that is not true for drm
<apw> at this point in time
<lool> I think it's sensible to stop shipping them until post-alpha2
<tjaalton> apw: yeah, I checked some of them, and apt-file showed that they were only shipped in linux-headers
<lool> And work on a plan for just after alpha 2 :)
 * lool lunch bbl &
<apw> i'll propose eliding drm in the headers for -alpha2, tjaalton sounds like you are in the frame for prodding a longer term fix
<tjaalton> apw: sure
<lool> In the ubuntu-hardy tree there was a debian/binary-custom.d dir with per arch or flavour patchsets; in ubuntu-intrepid and ubuntu-intrepid-lpia I don't see this dir; I can't find these patches in ubuntu-intrepid-lpia; does someone know about this dir and/or the lpia patches?
<lool> amitk is on holiday today
<smb_tp> lool custom build have been removed from the kernel tree. So you will not find them after that. special flavours and lpia have their own tree. About specific patches I cannot say something sure. 
<lool> smb_tp: Who would I be able to speak to for lpia matters when amitk isn't around?
<lool> Geez I think this is really serious
<lool> AFAICS all 13 lpia patches are simply ... not there
<lool> Not committed and not present as patches
<smb_tp> lool, currently there would be none directly. Let me take a look...
<lool> One of the patch I'm looking at is half merged
<lool> smb_tp: If you'd like to take a look, grab ubuntu-hardy and ubuntu-intrepid-lpia
<lool> smb_tp: debian/binary-custom.d/lpia/patchset/* are the patches I'm looking at
<lool> Hmm some patches have been merged upstream, just not the first ones I looked at
<lool> smb_tp: I was checking this because of https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/280669
<smb_tp> lool, The hardy half I got here. Let me update the intrepid part. I few patches look like they might have gone upstream. 
<lool> Some parts of 0018-sdio_crown_beach are questionable, but some went missing; consider the marvell quirk for instance
<lool> 0016-poulsbo_ide is the patch for LP 280669; that one went missing as well
<lool> If I look at 0013-poulsbo_pci_ids, some ids have been added under a different names, some others not
<lool> Hmm where's the lpia config for jaunty?
<lool> Blah and other patches in lpiacompat/
<smb_tp> lool, I not highly convinced how much from the hardy lpia really was used. All the netbooks I know of used the netbook kernel of the mid team. And to get things back into order is current work in progress
<lool> smb_tp: I don't think we're looking at this from the same angle
<lool> smb_tp: I have a real life issue with the current intrepid and jaunty kernels, all arches
<lool> And I would guess hardy i386 kernel would have the same issue
<smb_tp> lool, So what is the issue?
<lool> Which is that a 4 GB drive with two 2 GB parts appears as ony one 2 GB part
<lool> That's bug ##280669:
<lool> This report is public
<lool> (EPASTE)
<lool> This general issue brought to light that some of the poulsbo patches which we were putting in the hardy lpia build went missing in intrepid and jaunty
<lool> We can argue whether these patches would best be kept on i386 or lpia (my opinion is that it doesn't make sense to use Debian architectures only to carry patches), but we need the patches somewhere in all cases at least for supporting the hardware
<smb_tp> I did not follow lpia issues closely but I had the impression there had been moves to rather use the vesa driver. 
<lool> That's orthogonal: we didn't get a video driver for intrepid's kernel in time (we have it now though) so I moved xorg and all to using vesa for this pci id by default
<lool> smb_tp: for the record, the psb drm lives in hardy-lum below ubuntu/media/drm-poulsbo
<smb_tp> lool, Yes, right. This is split up
<smb_tp> lool, There is also a intrepid-lpia tree in amits personal tree. This is older but seems to include the patches from hardy. So, we ahve to ask amit why those differences are there
<lool> smb_tp: I think the patches were lost when he rebased against a new intrepid tree
<smb_tp> Or he is somewhat in the middle of doing so
<lool> smb_tp: We definitely used the tree without the patches for intrepid and I can tell you the intrepid i386 and lpia kernel behave the same and show only half of the disk
<lool> While the hardy OEM image works fine
<smb_tp> lool, I know that the hardy-lpia part has been a little neglected and maybe the intrepid tree also did not catch all changes. But we are working on that. The exact state of that progress I will have to find out
<rtg> apw: did you ever get back to bug #297750 ?
<apw> rtg i think thats the one you patched, and then i tried the kernel and found the black list was missing, and i posted another debdiff for
 * apw checks what happened to that second patch
<rtg> apw: right, but I asked for a more general version of the patch so that the oversight didn't happen again.
<apw> ahhh, then i've not got 
<apw> back to it yet.  will look now, _if_ my computer gives me any computrons
<rtg> pour caffeine on it?
<apw> i _wish_ that worked
<rtg> well, I need some.
<apw> me too ... will sort that out next
<lool> smb_tp: Thanks
<Keybuk> jet lag and kernel signals
<Keybuk> not a good combination
<apw> rtg, i've just dropped a debdiff for that module-init-tools thing onto the mailing list
<elmargol> Hi there is a rumor arround that ubuntu is going to have a vanilla kernel option in the future. Is this true?
<rtg> elmargol: apw has been assigned that task.
<silvergti> hello
<ogra> rtg, silvergti is the guy with 8111b cards in his thin clients
<apw> elmargol, indeed that is the plan, hoping to get to that sometime this week and get some samples up
<silvergti> ty for the intro ogra :)
<elmargol> apw: does this mean we can install 2.6.28 on intrepid too?
<apw> it may well do.  though they would be generic kernels, so if you needed any ubuntu'isms they won't be included
<apw> tjaalton, in preparing the patch to remove the drm headers from the kernel package, it has been suggested that assuming we are meant to be moving to the virgin headers that we migth be better off using dpkg-diverts in the libdrm-dev package to overide the headers which are functionally different (which is not all of them)
<silvergti> hi rtg, can u give some help? 
<rtg> silvergti: with regard to r8169 on Gutsy?
<silvergti> r8111b/8111c Ltsp Ubuntu 8.10
<elmargol> Do you think it is safe to use the ubuntu .config and just compile the lastest kernel using make and make install?
<apw> elmargol, well that won't likely attach the kernel correctly in the bootloader iirc but it should not affect your other kernels
<silvergti> rtg  r8111b/8111c Ltsp Ubuntu 8.10
<rtg> silvergti: so? what about 'em ?
<ogra> rtg, it doesnt seem to pick up an IP via dhcp 
<rtg> ogra: well, the LP report is gonna need more info then that.
<ogra> (using netboot and ipconfig -d eth0 from initramfs/busybox)
<ogra> rtg, right, thats why i pointed silvergti here so you can tel him what he needs to collect for debugging
<ogra> *tell
<ogra> i see bug 208012 that might be the right place to attach more info
<rtg> there is all kinds of standard info for those kinds of bugs. ogasawara has templates somewhere.
<ogra> (and being still open but confirmed for the same device)
 * ogra wonders why this channel has no bugbot
<ogra> https://bugs.launchpad.net/ubuntu/+bug/208012
<silvergti> but i think this is not exactly the same nic
<silvergti> oh... sorry, it is
<ogasawara> silvergti: in bug 208012 it would be good if you could attach debugging information that is outlined at https://wiki.ubuntu.com/KernelTeamBugPolicies
<ogra> the minimal info at least (though being stuck in busybox might make transferring it a manually copy task)
<ogra> (thin clients that dont get to their rootfs are a bit tricky) 
<silvergti> yes, it wont be easy :P
<ogra> but it will help to nail it down properly :)
<silvergti> :)
<silvergti> theres no lspci on thin client
<ogra> silvergti, do you have a possibility to boot the client off a USB CDRom or something ? 
<ogra> so you could run a livecd to get the right tools
<ogra> initramfs is really a tricky place to collect debugging info
<silvergti> no :( don't have any usb cdrom
<ogra> do you have a usb key ? 
<silvergti> wait... this thin was an embedded O.S.
<ogra> well, that wont get you the ubuntu info ... 
<ogra> though lspci should help a bit 
<silvergti> yep, just to get lspci
<ogra> but if you have a usb key and the client cn boot off USB, you can create a live usb key on the server with the usb-creator tool from an ubuntu iso
<ogra> that wuld get you all data at once
<silvergti> no usb pen... left mine at home... 
<silvergti> lol
<silvergti> tomorrow i will bring it
<tjaalton> apw: I read what was discussed on #u-d.. and I agree with lool, diverts are ugly and should be avoided if at all possible :)
<apw> ok i have posted my patch to our kernel list, and primed rtg on it
<apw> whether we can actually get the kernel rebuilt in time for -alpha2 is unknonw right now
<tjaalton> well, I'll build a couple of drivers on my ppa against the slimmed-down libdrm-dev then ;)
<apw> i suspect major explosion from what i've seen of the headers we have
<tjaalton> apw: yep, failed: https://edge.launchpad.net/~tjaalton/+archive/+build/815275
<iulian> Is there any meeting scheduled for today?
<apw> tjaalton, thought it would
<apw> iulian, what sort of meeting?
<apw> tjaalton, if you are on the kernel email list then reply and say that divert are vile, if not i'll do it later
<iulian> apw: The weekly ones, in #ubuntu-meeting.
<apw> yeah there was
<tjaalton> apw: airlied said that they'll release libdrm 2.4.2 when the intel headers won't conflict anymore. so perhaps the optimal solution for now would be to drop it from the linux-libc-dev and sort this out once there are new upstream releases available
<tjaalton> apw: yes, will do
<apw> it occurs at 17:00 UTC which was 1:39 ago
<apw> tjaalton, that fits with my feelings too, and my patch does exactly that
<iulian> apw: Ahh, OK, thanks.
<apw> so if you get kernel emails then replyin saying both that diverts suck, and upstream is saying wait for 2.4.2 and things will be good.  would help push the conversation alon
<tjaalton> apw: yep, sure
<apw> tjaalton, thanks
<tjaalton> huh, now building ati on my ppa fails because it wants to install an older linux-libc-dev
<zackr> hey, so what's the magic to compile a new kernel on ubuntu mobile? fakeroot make-kpkg --initrd kernel_image kernel_headers exits with debian/ruleset/misc/checks.mk:36 "Error. I do not know where the kernel image goes to [kimagedest undefined] ..."
<NCommander> I thought make-kpkg was obsolete
#ubuntu-kernel 2008-12-17
<lukehasnoname> Has anyone watched Greg Hartman's talk on Linux kernel development?
<lukehasnoname> http://www.youtube.com/watch?v=L2SED6sewRw
<tjaalton> old news
<lukehasnoname> He says Canonical "does not give back to the community" as it has only contributed half a dozen patches to the kernel since its inception. Either we don't make any changes to the kernel, and thus we are happy with its development by others (which should be just fine), or our changes to the kernel are just not being submitted directly to the tree. I don't get how he justifies sticking his nose up to Ubuntu like we a
<lukehasnoname> re worthless because we don't have the numbers he wants.
<tjaalton> you are 6 months late
<lukehasnoname> sorry to type so much, but this has come up in discussion several times with people, and them nor I have heard anyone's response on it.
<lukehasnoname> tjaalton, I know this isn't new, I see the June date, but I've yet to see anyone involved in the kernel (Ubuntu or otherwise) respond to his attitude.
<tjaalton> sure did, six months ago
<tjaalton> dig up the blogosphere
<lukehasnoname> broken record
<crimsun> lukehasnoname: several canonical staff have responded on their own blogs
<apw> yeah people have responded.  he was wrong, what can you say
<apw> he actually did the same talk at plumbers and wasn't taken very well
<lukehasnoname> touche, I should have looked a little more. Thanks for the pointer, though, apw
<lukehasnoname> hm
<lukehasnoname> came off as a bit of a vendetta in that plumber's conf. talk. Whatever.
<apw> yep, had an effect, pushing canonical employees to ensure they are using their canonical addresses when contributing
<apw> otherwise, his math was just wrong
<lukehasnoname> IMO, as if anyone cares, is that he is almost insulting to anyone who uses the kernel without giving back, as if, since we are users of the kernel, and thus know how to improve on it and have the desire to improve on it.
<lukehasnoname> poor grammar there, it's 4am in Houston
<apw> indeed, the implication that producing something that gets good penetration and thus is a good advertisment, somehow is not a good thing for linux as a whole if we aren't contributing 
<apw> (even if that was true, which it was not)
<CarlFK> I just got whacked by https://bugs.freedesktop.org/show_bug.cgi?id=18160#c8
<CarlFK> any chance there is something that addresses this?  otherwise I have to figure out how to downgrade xorg
<CarlFK> I would rather put my efforts into a fix than a workaround 
<bhuvi> how can i get ubuntu kernel source package
<CarlFK> bhuvi: logn shot: https://wiki.ubuntu.com/CarlKarsten My kernel howto: 
<rtg> bhuvi: start here: https://wiki.ubuntu.com/KernelMaintenance
<CarlFK> rtg: is there some docs for how to build a kernel.deb that does not address sending changes back up?
<rtg> CarlFK: I don't understand your question.
<CarlFK> rtg: that url you posted has "Once the tree is ready for upload, follow these steps to complete the package for uploading: "
<bhuvi> ah it's looks complicated
<CarlFK> but many people have no need for that
<rtg> CarlFK: what is it you want to do? Just a build?
<CarlFK> and so the extra steps to support it make it more "complicated" (good timimng)
<rtg> well start with 'Getting the source', then jump to 'Performing builds'
<bhuvi> i now downloaded 2.6.28 kernel from kernel.org can it be compiled and run under hardy without any problems
<bhuvi> this link also seems useful https://help.ubuntu.com/community/Kernel/Compile
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.27.9-patch_sigmatel_dell_studio_17.diff
<Kano> hi, just made that patch for ubuntu studio 17 laptop
<Kano> similar to
<Kano> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commitdiff;h=c7b7f1613bcfdd8e6ccaeea8a57daf9a3a122fc2
<Kano> please add
<Kano> confirmed to work
<Kano> did not know that it would be so easy, in #alsa they could not help me...
 * pgraner just added https://wiki.ubuntu.com/KernelTeam/UDS/Dec2008 
<Keybuk> CONFIG_LEGACY_PTYS=y
<Keybuk> CONFIG_LEGACY_PTY_COUNT=256
<Keybuk> really ?
<Keybuk> can we change that to CONFIG_LEGACY_PTY_COUNT=0
<Keybuk> leaving PTYS=y so that there's a boot option if people reallly need them
<Keybuk> (nothing uses them, and they just waste boot time with 256 mknod() calls)
<rtg> BenC1: ^^^
<Kano> also please begin testing nfs-kernel-server with 2.6.28
<Kano> whats now with the little alsa patch?
<s-corp> hi all... I have a Linksys WUSB11 v2.6 fot what I know with an Atmel chip
<s-corp> it worked fine with hardy and when I updated to intrepid today the kernel started spitting out an Oops error
<s-corp> i rebooted to win xp and tested id the device was working, and it was
<s-corp> with the firmware loaded by windows, I rebooted my pc back to ubuntu
<s-corp> and it worked fine until I restarted the devuce
<s-corp> device*
<s-corp> ideas :?
<s-corp> Linux <*******>2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux
<s-corp> http://pastebin.com/m63eb57aa
<s-corp> this is the dmesg output
<s-corp> should I file a bug report?
<s-corp> uh!... [  947.266329] BUG: unable to handle kernel NULL pointer dereference at 00000000
<[T]ank> hey all, wondered if there is a log file somewhere that tracks network interface activity. 
#ubuntu-kernel 2008-12-18
<apw> smb_tp, when we were talking about kernel builds, we talked about how we did make debug version of the kernel somehow, and how they were done special and went somewhere else.  got any pointers to how that works?
<smb_tp> apw, Hm, not really. I try to remember but at the moment I don't get it... :(
<apw> must ask benc
<smb_tp> Yeah, and I should memorize his answer...
<apw> nope it should be wikid
<apw> Keybuk, hey ... mmc things
<smb_tp> ^^^ talking mumble?
<apw> i am far too sophisticated for that
<smb_tp> good excuse :)
<apw> smb_tp, so do we have any sort of builtin system for setting up modules specifically to a machine during install?
<smb_tp> apw, Is there a specific example or case you look at? 
<apw> i have seen a number of bugs recently asking for specific module options for a particular machine
<apw> (the one i saw today was about the acerhk driver)
<apw> if the driver has pci'id detection or whatever then obviously we should be adding ids for that kind of thing
<apw> but for other things, i just wondered if we had something which builds modprobe.d/* specific to the machine; i am assuming not
<smb_tp> I was not aware of something getting added generically. But I might be missing a piece
<smb_tp> It would have to be done in the installer, so we might ask cjwatson...
<apw> it sounds like a dangerous thing to do probabally
<apw> as if you move the disk to new h/w its wrong
<smb_tp> Right, I would guess everything on a bus gets added if there is something with the right id. And other things should/would look for dmi information
 * apw is not entirly clear which things we are able to do direct probes for
<apw> it seems the driver i am interested here is actually being superceeded upstream by a new driver which does do appropriate things
<dee> Hello.
<dee> I've just build the Ubuntu Kernel like this: http://www.howtoforge.com/roll_a_kernel_debian_ubuntu_way
<dee> Because there are no audio drivers build in I must compile linux-ubuntu-modules too. Here's the tutorial: https://help.ubuntu.com/community/Kernel/Compile
<dee> Unfortunately the process do not recognize my new kernel and tries to use the old header files instead.
<dee> The file /lib/modules/2.6.24-22-386/build/include/linux/version.h does not exist.
<dee> Please install the package with full kernel sources for your distribution
<dee> or use --with-kernel=dir option to specify another directory with kernel
<dee> sources (default is /lib/modules/2.6.24.3-moto/source).
<dee> Did anyone know how to solve this?
<rtg> dee: https://wiki.ubuntu.com/KernelMaintenance, read 'Getting the source' and 'Performing builds', then install the linux-headers* packages
<dee> Okay, another version of compiling ...  I will try this one ...
<dee> bye
<fitzdsl> Salut tout le monde !
<fitzdsl> J'ai un petit problÃ¨me, j'essaye d'installer xen a partir des paquets (ubuntu-xen-server) (je suis sous intrepid), l'instal se passe bien, mais il ne me crÃ©Ã© pas de nouvelle entrÃ©e dans menu.lst 
<fitzdsl>  j'ai bien un xen-3.3.gz dans /boot mais c'est la seule reference a xen
<fitzdsl>  pas de initrd ni vmlinuz
<Nafallo> !fr | fitzdsl
<Nafallo> meeh. lacking bot.
<fitzdsl> sorry, i made a mistake
<fitzdsl> so Hi
<fitzdsl> i've got a problem to install ubuntu-xen-sever (i run intrepid), the install seems fine but it doesn't change my menu.lst
<fitzdsl> i've got a xen-3.3.gz in /boot but it is the only file with xen reference
<Nafallo> Ubuntu kernel development discussion ONLY <-- from the topic. you might want to try #ubuntu :-)
<fitzdsl> i've got no initrd nor vmlinuz
<fitzdsl> thx
<apw> Nafallo, any idea whome to poke to get the bots back
<Nafallo> apw: #ubuntu-ops I think :-)
<tjaalton> apw: seems that upstream fixed the intel headers http://bugs.freedesktop.org/show_bug.cgi?id=19132
<tjaalton> but it's not going to end up in .28
<tjaalton> so you probably want to pull that
<apw> tjaalton, thanks for the pointer
<apw> whats the upshot of the change, that the kernel headers are now usable
<tjaalton> apw: we should be able to drop the drm headers form libdrm-dev
<tjaalton> *from
<apw> ok ... will try and find it, knwo where the drm-intel-next tree hangs out?
<tjaalton> but maybe wait until there's a new libdrm version out, which should be around the corner
<apw> yeah won't rush into any change, the last one was dangerous enough
<tjaalton> heh
<tjaalton> I'm searching for the repo
<tjaalton> apw: here git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git
<tjaalton> drm-intel-next branch
<tjaalton> AIUI, those are then merged to airlied's drm-next branch
<tjaalton> in this case when .29 opens
<apw> ok, its not clear if that is sufficient
<apw> as in this fix fixes the interaction between the kernel headers and intel drm, but are any of the other consumers affected?  how can we know?
<apw> tjaalton, ^^
<tjaalton> apw: by building every driver, but I'd be surprised if the others would be affected. intel and ati are seeing most of the action these days (and nouveau of course, but it's not included)
<tjaalton> er, every driver that uses those headers
<tjaalton> so matrox, r128, savage, sis, openchrome
<tjaalton> intel and ati are now known to work
<apw> so intel plus that little fix, and ati with none work with the real kernel headers
<tjaalton> ati needs one fix, but it was for the X driver
<apw> tjaalton, can that fix move without the headers?  ie. can we do all the userspace changes without changing the kernel headers from the ones in libdrm-dev ... when they are all out _then_ do the kernel header flip flop ???
#ubuntu-kernel 2008-12-19
<tjaalton> apw: you mean making the headers in libdrm-dev to match the kernel ones, and when they work make the switch to using kernel headers?
<Keybuk> Dec 19 06:19:29 quest kernel: [246164.090552] BUG: unable to handle kernel pagin
<Keybuk> g request at ffffe22001651e98
<Keybuk> ... what does that mean?
<\sh> morning 
<\sh> did anyone had a kernel panic with amd opteron quad core cpus reading "your cpu is defect...this is not a software problem?" but board system check tells you : cpus are ok...and after a reboot everything is ok again?
<nessuno_> grazie
<nessuno_> grazie a tutti! ciao
<Keybuk> so nope, no memory errors found
<rtg> apw: Intrepid -11.22 pushed.
<abogani> Good news!
<apw> did you intend this one for everyone?
<apw>     UBUNTU: Default CONCURRENCY_LEVEL to _NPROCESSORS_ONLN
<rtg> apw: yep
<rtg> apw: it only affects local builds. 
<apw> ok cool
<rtg> apw: please update bug  #300803 with the revert notice.
<ubot3> Malone bug 300803 in linux "linux-libc-dev: please include video/uvesafb.h" [Medium,Fix committed] https://launchpad.net/bugs/300803
<apw> doh, yep
<rtg> lieb: please write the SRU justification for bug #281647
<ubot3> Malone bug 281647 in linux "Support IR remote for MSI TV Anywhere Plus tuner card" [Low,In progress] https://launchpad.net/bugs/281647
<apw> rtg bug update done
<Kano> dh_installchangelogs -plinux-image-2.6.28-3-server
<Kano> parsechangelog/debian: error: found trailer where expected start of change data, at file debian/changelog line 4
<Kano> dh_installchangelogs: changelog parse failure
<Kano> whats the problem?
<Kano> also i got this error before:
<Kano> fatal: ambiguous argument 'Ubuntu-2.6.28-3.4..HEAD': unknown revision or path not in the working tree.
<Kano> Use '--' to separate paths from revisions
<apw> looks like you are missing some tags?
<apw> where are you building this tree?
<Kano> well yes
<Kano> but now i rebuild 2.6.27 tree
<Kano> btw. i adopted my 2.6.27 patch for ubuntu studio 17 to 2.6.28, just a very small diff
<Kano> err dell studio of course
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.27.9-patch_sigmatel_dell_studio_17.diff
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.28-rc9-patch_sigmatel_dell_studio_17.diff
<Kano> first is for intrepid the other for jaunty git
<apw> Kano, and those have been confirmed to work on the hardware?
<smb_tp> Kano, Also, did you send the patch upstream as Luis suggested?
<Kano> well the first, for the 2nd i have to compile the kernel
<Kano> smb_tp: i sent it to the suse guy, the first one
<apw> a previous owner of a Studio 1837 (i assume its one of those as they had the same ids) claimed that selecting that model didn't work for them
<Kano> he said he will add it
<smb_tp> Kano, Ok, thats cool. Makes it simpler for the sru process
<Kano> apw: maybe that studio 18 has also + 1 in the id?
<apw> no that was a typo on my part, its a 1737
<apw> stupid fingers
<Kano> well he just played with the mixer and heard something
<Kano> with this setting
<lieb> rtg, wrt sru, will do
<rtg> lieb: I already did for that bug 'cause it was holding the upload
<Kano> i could not confirm teh 2.6.28 patch
<Kano> but as soon as i can compile the 2.6.28 git this should be no real problem to do so
<lieb> ok.  I''l go back and check what I missed
<rtg> lieb: its best to write the SRU justification right after you commit the patch.
<smb_tp> Might even make sense to do it concurrent with the mail. The text can just be the same
<Kano> did somebody test nfs with 2.6.28 yet?
<apw> Kano, is there  a bug associated with your studio 1737 patches yet?
<Kano> not that i know, it is only a kanotix not ubuntu user with that laptop
<Kano> maybe there is a ubuntu user with it too?
<apw> under bug #309512 we have a user with the same laptop
<ubot3> Malone bug 309512 in alsa-driver "Dell Studio 17 (1737), 2 headphones jack do not work in Intrepid 8.10" [Undecided,New] https://launchpad.net/bugs/309512
<apw> who i  have been talking who claims to have tried enabling that speciifc quirk via 
<apw> options snd-hda-intel model=dell-m6 and failed to get sound
<apw> your patch enabled that same quirk, so wondering about the testing, one of the testers must be wrong
<apw> hopefully ours
<Kano> well maybe he did not play with the mixer settings?
<apw> that is entirly possible
<apw> perhaps you could attach your patch to that bug?
<smb_tp> Right, we have to have the patch attached to a bug anyways and this one seems to match perfect.
<Kano> ok, will add the 2.6.27 patch there, as it is for 8.10
<smb_tp> Kano, Ok, thanks
<apw> perfect
<Kano> attached it
<Kano> could somebody change the insertchanges targe that it does not insert anything when no changes are made?
<lieb> rtg, I checked on that SRU and I did write one but the subject line was "PATCH SRU LP...." which probably choked in mail filters.  I take it "SRU" should be the first token?
<rtg> lieb: are you talking about the SRU justification comment in the LP report?
<lieb> ye
<lieb> yep
<rtg> did I just miss it?
<rtg> remind what the bug number is
<lieb> probably because of the "PATCH"
<lieb> PATCH SRU Bug #281647 Add support for MSI TV@nywhere Plus remote
<ubot3> Malone bug 281647 in linux "Support IR remote for MSI TV Anywhere Plus tuner card" [Low,Fix committed] https://launchpad.net/bugs/281647
<rtg> lieb: uh, I'm talking about the SRU justification clause in the LP report. While the bug might have been ACK's on the mailling list, we still need to tell the SRU folks what we're doing.
<lieb> an entry in launchpad?
<rtg> lieb: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/281647/comments/8
<ubot3> Malone bug 281647 in linux "Support IR remote for MSI TV Anywhere Plus tuner card" [Low,Fix committed] 
<lieb> ok, I cna do that.  you were pulling from my repo so which git url do I put in there?
<lieb> I was wondering how I tie off my end once I push it up to my repo.  these things are hanging about...
<rtg> lieb: well, don't write the SRU justification until _after_ the commit has been made to the core repo, then use the URL from gitweb to point at the core repo.
<lieb> ok. so I wait for your "pulled" reply and go to LP and write this up.  correct?
<rtg> lieb: yep
<rtg> and thats pretty much the tie-ff as far as you are concerned.
<lieb> I cna do that. pls add the commit sha in your "pulled" so I cna find it
<rtg> s/ff/off/
<rtg> lieb: do you know the gitweb URL ? your commit will generally be near the top of the listing of the particular repo.
<rtg> http://kernel.ubuntu.com/git
<lieb> I'll work it out.  If you had the commit sha, I know it's really in as opposed being in your queue.  think memory barrier ;)
<rtg> lieb: oh no, when I respond via email that its been pulled, that means I've really committed it to the core repo.
<lieb> ok gotcha
<lieb> I'll update the kernel bug wiki with this bit.
<lieb> my local build died w/ "ABI file missing" on a schroot 32 bit build.  what Fu am I missing?
<lieb> amd64 builds worked just fine in same git workspace
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/309268
<ubot3> Malone bug 309268 in linux "[regression] nfs-kernel-server fails with 2.6.28 (dup-of: 306016)" [High,Triaged] 
<ubot3> Malone bug 306016 in nfs-utils "nfs client broken since 2.6.28-2-generic upgrade" [High,Confirmed] 
<Kano> it seems somoebody reported that problem alredy
<BenC> Kano: what would you have it do if there are no changes?
<Kano> well somebody has nfs working,but he did not enable all options
<Kano> on my other pc i have got his kernel config
<BenC> Kano: I mean insertchanges
<Kano> well it cleaned the changelog completely and then no package could be created
<Kano> it was just empty, no * at all
<BenC> Kano: I know what it does...what would you expect it to do is my question
<Kano> BenC: just do nothing
<Kano> then i could leave it enabled in my script and it would never break
<BenC> Kano: then the builds will still fail
<Kano> nope, with the placeholder it compiles
<BenC> then don't run insertchanges
<Kano> well then i need a check for that...
<BenC> I want it to fail if there are no changes
<Kano> sure, as long as the changelog is untouched
<BenC> Kano: write a patch...the current behavior works for our purposes
<dade`> BenC, are you here ?
<dade`> mjg59, you too ?
<BenC> dade`: yeah
#ubuntu-kernel 2008-12-20
<maxb> wg #ubuntu-release 
<maxb> oops, sorry
<elmargol> How do I build the initrd image for a custrom kernel?
<elmargol> Are there some special ubuntu patched for power management in intrepid?
<elmargol> It looks like my nvidia GPU is about 10-15Â°C cooler on vanilla 2.6.28-rc8
<iulian> elmargol: For building the initrd image I usually do `mkinitramfs -o /boot/initrd.img-'kernel' kernel_version`
<elmargol> iulian: thank you. I have it running 1 hour now :)
<elmargol> I find it very strange that my GPU runs may cooler on the new kernel :/
<maxb> elmargol: Shouldn't you be considering potential differences between 2.6.27 and .28 before you wonder about Ubuntu specifics?
<elmargol> maxb: thats possible too
<iulian> Hmm, it seems that compiz is not working with 2.6.28-rc2-mm1.
 * maxb wishes the NEW queue processing could be automated for kernel ABI bumps
#ubuntu-kernel 2008-12-21
<Frink2> Hey I've gotta merge two branches and I'm not sure how to do that...
<Frink2> basically trying to do lpia-rt
<Frink2> as i understand I'd need to git the main branch and then merge the personal branches for the two projects -am I right?
<Frink2> bUMP!
<ziroday> Hi, anyone know what could possibly be causing this? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116752
<ubot3> Malone bug 116752 in linux-source-2.6.20 "NMI received for unknown reason a0 on CPU 0" [Undecided,Won't fix] 
<maxb> I'm being stymied by sporadic kernel panics on a HP Pavilion laptop, is there anything I can do to extract some useful diagnostic information?
<frink1> anyone awake?
<frink1> I'm trying to merge LPIA and RT patches not that familiar with git
<frink1> balbir: you familiar with git merge?
<crimsun> maxb: under what conditions? have you a backtrace? also, does said laptop have a broadcom wifi chipset, and if so, are you using linux-restricted-modules-2.6.27-11-generic from intrepid-proposed?
<maxb> Under seemingly arbitrary conditions. Backtrace: No. Is there any way to get one when the panic occurs whilst using X? Chipset: not sure. will check.
<crimsun> maxb: if you're fortunate, it will have been logged to /var/log/kern.log
<maxb> It's an intel 3945
<maxb> Ah, I wasn't aware of that, I shall check there
<frink1> is anyone here? really?
<frink1> still trying to figure out how to merge rt and lpia branches
<frink1> Hello?
<laga> frink1: try asking on the kernel team mailing list.. and try asking some real questions, not just meta question
<frink1> laga: I've got a specific question
<frink1> how do I merge two branches
<frink1> do I need to download the main source and then merge?
<frink1> or do I merge one to the other?
<frink1> or what...?
<laga> um, that's probably covered in the git documentation
<frink1> haven't been able to find it
<frink1> figured most kernel guys would know an answer to something stupid like that
<frink1> I'm just an svn guy - git is strange
#ubuntu-kernel 2009-12-14
<kayve> is it possible for me to use atomic_dec_and_test(atomic_t* v) in a user program?
<kayve> is it possible for me to use atomic_dec_and_test(atomic_t* v) in a user program?
<Keybuk> apw: any particular reason you've not uploaded a new linux-meta for lucid for the -8 ABI?
<ghostcube> apw: startet again without installing anything before and with one day pausing pc
<ghostcube> cam is dark again
<ghostcube> :)
<ghostcube> so all i can say its a bootup problem like you suggested from the beginning of this strange bug
<indus> hi
<indus> apw: hello 
<tseliot> apw: it looks like there's no backlight interface for intel in /sys/class/backlight in karmic (with KMS). Do you know anything about this?
<rtg> tseliot, apw is on vacation today
<tseliot> rtg: ah, ok, thanks
<Keybuk> rtg: why no -meta package update?
<rtg> Keybuk, for the kernel? I suppose 'cause Andy hasn't done it yet.
<Keybuk> I wondered if there was any reason for that
<rtg> Keybuk, -meta is at 2.6.32.8.8, which references the latest kernel. Andy uploaded it about an hour ago (though he's supposed to be on holiday)
<tseliot> smb: did my email convince you?
<smb> tseliot, It sounded reasonable. I now only try to make up my mind whether the problem is grave enough to justify direct inclusion or I rather try to get it included in one of the next upstream stable releases and get it back from there.
<rtg> smb, can you remind me what the ACPI knobs are for controlling C states?
<rtg> I have a system that resets when it goes idle
<smb> rtg, might be idle=poll,halt,... 
<rtg> smb, isn't there a /proc/ or /sys knob?
<smb> but maybe others... not sure about the later stuff I thought it was boot args
<rtg> smb, looking in processor_idle.c. it appears to be a module param
<smb> rtg processor.max_cstate=
<rtg> smb, right
<smb> rtg, At least does not show up in the parameters dir on my system...
<rtg> smb, I'm reasonably convinced that this platform resets when it goes into deep C states, or is throttled to P0, both of which imply an ACPI/BIOS problem.
<smb> rtg, Right, then I'd try either with the max_cstate=2 or idle=halt options on boot
<casl> greetings. ubuntu 9.04 x86 32-bit -- after installing 2.6.28-17 last week, i am no longer able to VPN using cisco client (4.8.02); reboot to -16 kernel and i'm back in business. cisco_ipsec module loads OK, no errors, but connection is never negotiated. any suggestions on debugging this would be appreciated.
<smb> casl, I am not sure I can help too much, but has the cisco module been recompiled for the new kernel?
<casl> smb, thanks. yes. i re-run the cisco installer with each kernel update. has worked OK for last 6+ months. kernel module loads OK. no obvious errors reported. 
<smb> casl, OK, cause the update had some connector callback changes that it needs to pick up. If the module has no debug option... maybe ethereal or was that wireshark nowadays...
<casl> smb, thanks! i just realized that there are .o's in the installer directory that did not get rebuilt. going to reboot, make clean & see if that helps
<casl> smb, THANK YOU!  "make clean" before the reinstall of the cisco vpn client seems to have picked up the needed changes!
<tseliot> smb: opinions on my last emai?
<smb> tseliot, maybe. err, if I would read it...
<smb> tseliot, give me a few minutes
<tseliot> smb: ok, thanks
<bjaglin> hi, i am not sure if this is the right place, but i am having troubles building 2.6.32 under karmic. I am trying to build an unpatched kernel (to start with) from the ubuntu git repostiory, following https://help.ubuntu.com/community/Kernel/Compile. The compilation goes fine if I build latest ubuntu-karmic, but it just hangs always at the same place when trying to build ubuntu-lucid 
<bjaglin> http://pastebin.com/f1530df67
<bjaglin> is there some requirements on the compiler that Karmic does not fulfill for building this 2.6.32??
<hyperair> i build my 2.6.32 kernel fine
<hyperair> s/build/built
<bjaglin> ok.. it's weird, because i don't get any error message, nor CPU usage once it hangs...  Always at: LD      ubuntu/dm-raid4-5/built-in.o - what is so special about it?
<logari81> Hi, trying to compile the karmic-proposed kernel under pbuilder I get the following error
<logari81> EE: Previous or current ABI file missing!
<logari81> what am I missing?
<rtg> bjaglin, use this page as reference: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<bjaglin> rtg: thanks, i already had a look at it actually, but it looks like I am facing a toolchain problem more than a config problem, since i managed to build 2.6.31 without any problem from the ubuntu git repo
<rtg> bjaglin, I'm not aware of any toolchain isses wrt building lucid under karmic.
<bjaglin> rtg: ok. Since it always hangs on the same file when linking, does it make sense to upgrade my binutils/gcc to the packages provided in lucid to exclude any problem there? the changelog for binutils between karmic and lucid does not look really relevant though...
<rtg> bjaglin, I think that'll just make a mess. I think your best bet is to install a lucid chroot and build within that environment.
<bjaglin> rtg: i'll try that, thanks
<JFo> hi ogasawara_ I'm ready whenever you are.
<ogasawara_> JFo: ok cool, I'll call ya in 2min
<JFo> no problem
<JFo> ogasawara_, think I lost you
<bjaglin> rtg: found my problem, it had nothing to do with the toolchain... fsam7400 was recently moved from misc to its own directory in ubuntu/, and in the Makefile, there is a KERNELSRC=?/lib/modules/`uname -r`/build that was empty for me since I did not have the headers of my current kernel, and freezing the following awk call. isn't it a problem?
<bjaglin> i am a pure newbie with kernel building, and please tell me if i am wrong but i find it strange that `uname -r` is used in a script, since the target kernel might be completely different than the kernel running, no?
<bjaglin> i am referring to http://archives.free.net.ph/message/20091208.182445.ab0091af.en.html
#ubuntu-kernel 2009-12-15
<apw> Keybuk, thats an amazing jump in times since alpha-1
<apw> (a positive jump)
<Keybuk> apw: you mean a good jump? :p
<apw> heheh yeah i do :)
<apw> Keybuk, looks like you moved everything out to plumbing though, so i guess its a bit less good than it seems
<Keybuk> i took out the framebuffer driver loading, etc.
<Keybuk> so we could get a clear picture of where we're really at
<Keybuk> if the cost of the splash screen is seconds, then that's an argument for trying to avoid having on
<apw> yeah not much point if all it does is slow things down
<apw> X seem to be doing a fine job ...
<apw> kernel had a good increment, but most of its the usplash shift
<Keybuk> yeah, definite half a second from the kernel itself though
<Keybuk> the other bit that's not obvious is that it already takes almost 3s of plumbing to get gdm started
<Keybuk> which is enough time to load the i915 driver in parallel
<Keybuk> (blacklisting it doesn't speed that up any)
<apw> Keybuk, ouch thats a long time
<Keybuk> yeah
<Keybuk> we budgeted 2s
<apw> Keybuk, do we have any idea what the heck the dkms component is in that boot? is this a first boot or is that there in all boots
<Keybuk> it's there in all boots
<Keybuk> I just took an axe to dkms
<Keybuk> mario will cry like a baby
<Keybuk> but there's no reason in hell dkms needs to run on boot
<Keybuk> it can build modules in postinst
<apw> hehe ... /me thinks there is a reason
<Keybuk> the reason is so that when you boot an old kernel, it recompiles drivers for you
<Keybuk> which is clearly broken
<Keybuk> if you boot an old kernel, it's because something with the new one *didn't work out*
<apw> yeah that sounds like the reason
<Keybuk> you don't want the new drivers backported - they might be the very things that were broken
<Keybuk> not to mention that we don't rebuild the initramfs either
<apw> a reasonable reposte to the argument me thinks
<Keybuk> fabbione: hey!
<apw> Keybuk, it feels like the dkms ending is when X starts
<fabbione> Keybuk: hi
<fabbione> feenode bump... just for a change
<Keybuk> apw: it is
<Keybuk> so dkms now doesn't have any boot-time scripts
<Keybuk> because taking 4s made it go BEEEEP on my radar
<apw> Keybuk, heh, so how much time you recon that is going to save?
<Keybuk> apw: dunno
<Keybuk> probably about a third of a second in reality
 * apw isn't going to sniff at .3s
<Keybuk> though a second copy does seem to block X for a second
<Keybuk> so maybe 1.5s
<fabbione> smells like fun
<Keybuk> fabbione: yeah, we're still having fun here ;-)
<Keybuk> how's things with you?
<fabbione> pretty good
<fabbione> we are about to open the new development cycle for the next cluster generation
<fabbione> that's going to be a killer
<Keybuk> fabbione: awesome
<Keybuk> apw: did we ever chase down those modules.builtin patches?
<fabbione> is there anybody here specifically in charge of dvb-t?
<fabbione> kernel driver regression
<Keybuk> fabbione: not specifically, but let either apw or smb know - depending whether it's lucid or karmic
<fabbione> karmic
<apw> Keybuk, i went looking for them on friday but didn't find them merged as yet
<fabbione> can't really explain the meaning of regressions to my wife when she holds a MythTV remote
 * smb knew fabbione just came to complain
<Keybuk> apw: I don't think they're merged yet - but they would be nice
<fabbione> smb: actually no.. i was about to offer help because I wrote most of that driver
<Keybuk> the author is the new kbuild maintainer, so they have a good chance :p
<fabbione> smb: and something did regress between .28 adn .31
<Keybuk> shall I drop him a mail to find out the status, cc you, and if he says ok, then you can merge?
<fabbione> smb: i really complain when you break LTS
<smb> fabbione, Hey cool. Don't take me too seriously
<fabbione> that really seriously annoy the hell out of me :)
<smb> :)
<fabbione> no trust me.. it takes a lot more than that to go on my nerves
<smb> fabbione, Ok, so what do we have as info. You have a bug report already?
<fabbione> Keybuk: btw.. nfs mount in karmic (with the new upstart jobs start) fails from time to time at boot, then recovers itself. Nothing critical whatsoever but spurious warnings can raise a flag for less experienced (l)users
<fabbione> maybe you already know
<fabbione> just can't even find the time to look at LP
<Keybuk> fabbione: yeah, slangasek is looking into it
<fabbione> ok
<fabbione> it's really a non-issue :)
<fabbione> "fail to mount /var/lib/mythtv/videos/porn" :P
<fabbione> kind of thing ;)
<apw> Keybuk, yep sounds like a plan to me
<logari81> hi, could anyone give me a hint on "EE: Previous or current ABI file missing! " ? google doesn't know a lot about it.
<fabbione> wow.. still ABI checker kicking in!
<fabbione> impressive to see that stuff still holds up after 5 years we did it :)
<smb> Heh, yeah. Amazing that google does not know anything about it
<fabbione> exactly
<smb> logari81, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
<logari81> smb: thanks, google probably knows enough about kernel ABI, but not about the error string I was looking for :) .
<smb> logari81, Yeah, maybe. :) In short, you start a new version, you need to have the abi files from the last version. Check for debian.master/scripts/misc/getabis
<Keybuk> apw: are you sure they didn't get merged?
<apw> Keybuk, nope, they may have now, there was 10k changes in there today
<Keybuk> ah no
<Keybuk> some confusion over the branch
<Keybuk> Subject: 	[resend][GIT PULL] kbuild updates for 2.6.33
<Keybuk> From: 	Michal Marek <mmarek@suse.cz>
<Keybuk> Date: 	12/12/09 14:47:30 (Sat, 12 Dec 2009 15:47:30 +0100)
<Keybuk> is the relevant thread
<Keybuk> the modules.builtin patches are in that tree
<bjf> **
<bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> **
<apw> Keybuk, remind me was there a bug on this modules.builtin stuff to help coordinate the kernel/modprobe stuff?
<bjaglin> rtg: thanks for the fsam7400 pull :)
<rtg> bjaglin, np
<apw> bjf, is there a bug associated with this 4MB buffer thing?
<bjf> apw, no, a request from dtchen
<apw> bjf ta
<apw> bjf ... meeting in 15 ?
<bjf> apw, yup
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
<bjf> ##
<rtg> apw, do you remember where ubuntu/Kconfig gets picked up from when running 'make oldconfig' ?
<apw> arch/x86/Kconfig ?
<rtg> apw, ah!
<rtg> thanks
<apw> :)
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<apw> smb, you there?
<Kano> hi, now it is 7 week after last karmic update and still no 2.6.31.7 update - since yesterday there is even .8. so who is sleeping all day long?
<apw> the last karmic update was 6 days ago
<Kano> apw: .7 and .8 kernels are already out - last with lots of ext4 fixes just like 2.6.32.1
<apw> yep.  but just cause they are out 'now' doesn't mean they can be released now, we have processes to prevent regressions
<Kano> well you told me that 1 week ago and absolutely nothing happend
<Kano> is that the process?
<apw> since 1 week ago we have released a security update and spun a new proposed, plus started reviewing the .8 patches.  so no, not nothing
<Kano> nothing in git visable
<apw> every release in the archive is in our tree
<mjg59> Kano: Ubuntu release process is, I suspect, primarily oriented towards Ubuntu rather than being especially concerned about niche derived distributions
<mjg59> Kano: Rebasing the Ubuntu patchset on top of newer upstream stable releases should be trivial for you to do yourself, if you're interested in doing so
<mjg59> In most cases it would just be a single git command
<apw> trust me, if we could get the stable updates out faster we would, they are nothing but a royal pain in the rear end to have more and more pending
<Kano> mjg59: usually a git pull fails because of some sauce patches
<Keybuk> Kano: that's probably why mjg59 said "rebase" instead
<Kano> the question is: why are those patches not upsteam
<Keybuk> Kano: the answer to that question can be found in each commit log
<Kano> thats why the .X.Y releases are
<Kano> i see no reason to add some extra ids or so just for U
<Keybuk> in those kinds of cases, the patches came from the upstream kernel
<Keybuk> just the current linux-2.6 tree rather than stable
<Kano> the really needed ones are officially backported
<apw> if you don't think any of the commits in our tree are needed other than those in 2.6.32.y why don't you make kernrels from there instead?
<Keybuk> e.g.
<Keybuk>     Note: This patch is useful to powertop to tell the utilisation of the sound
<Keybuk>     device. It is cherry-picked from upstream
<Keybuk>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
<Keybuk>     SHA ID: a2f6309e8
<Keybuk> from the commit log of the first SAUCE patch I found
<Keybuk> but, if you want to whine, I'm sure things like that won't stop you
<Kano> apw: just for a few extra things like aufs and some drivers
<apw> and thats how we end up with the patch load we have, things which people need which arn't in upstream in a timely fashion for our release schedule, its the same everywhere i am sure
<Kano> but not all backports are applied, thats why a git pull even fails after you updated it
<apw> indeed some patches are deemed too invasive or too risky dispite being in stable
#ubuntu-kernel 2009-12-16
<sneumann> Hi, I am looking for some way to build a vmlinux for an ubuntu kernel to run oprofile
<sneumann> I have a backup software (mondoarchive) that takes ages, 
<sneumann> and 9x % of the time are spent in the kernel.
<sneumann> I guess they trigger some pattern with suboptimal performance,
<sneumann> so I'd like to use oprofile to get a hint what that could be
<sneumann> samples  %        samples  %        linenr info                 image name               symbol name
<sneumann> 26121    75.6933  212      87.9668  (no location information)   no-vmlinux               /no-vmlinux
<sneumann> Of course, if there is a better tool to see what the kernel is doing, 
<sneumann> I am happy to take suggestions
<sneumann> Regarding my earlier question, I found the old debian way with /etc/kernel-pkg.config 
<sneumann> which takes "install_vmlinux=YES"
<sneumann> so I am looking for a similar option for "fakeroot debian/rules binary-generic"
<smb> sneumann, There is none I know of, but the vmlinux itself would be found in debian/build/build-generic
<sneumann> thanks smb, currently building with make-kpkg, but if I need another build I'll copy that manually from there
<sneumann> Actually, does this warrant a bugreport ? Debian was discussion where to place the vmlinux 
<smb> sneumann, nooooo, please not make-kpkg
<smb> sneumann, There is no warranty this ever has (for a while) or will work
<sneumann> a while back: http://lists.debian.org/debian-devel/2006/01/msg01038.html
<sneumann> Ack, will re-do that the Ubuntu way and manually copy vmlinux
<smb> Also, if you just are looking for vmlinux file produced by the normal builds:
<smb> http://ddeb.archive.ubuntu.com/ubuntu/pool/main/l/linux/
<smb> The linux-image-debug should contain the vmlinux file, but I notice there seem to be no recent version there
<apw> hrm everything over there is a .deb, don't we make .ddeb's now in build or something
<smb> I have to get into that. I thought to have seen linux-image-debug on local builds, but I might have dreamed that
<apw> #
<apw> mv ../linux-image-debug-2.6.32-8-generic_2.6.32-8.12_amd64.deb \
<apw> 		../linux-image-debug-2.6.32-8-generic_2.6.32-8.12_amd64.ddeb
<apw> h
<apw> we do that in our lucid builds, so we are making the damn things at least
<smb> I would assume to find them in https://edge.launchpad.net/ubuntu/+source/linux/2.6.31-17.54/+build/1389351 but that might be wrong. Checking the log there
<smb> Doh, yeah
<smb> apw, wrong path in my memory
<smb> sneumann, It is http://ddebs.ubuntu.com/pool/main/l/linux/
 * sneumann is looking at that
<sneumann> Also found the thread from earlier this year: http://old.nabble.com/linux-image-debug-td22301267.html
<sneumann> Hmpf. ddebs.u.c is painfully slow, ETA 2hrs :-(
<sneumann> How can I build linux-image-debug-2.6.31 from sources ? Could be faster ...
<smb> sneumann, Well not them. I got an ETA of 5min (but its 450M too)
<smb> sneumann, Either run the build with fakeroot debian/rules skipdbg=false or create the
<smb> directory /CurrentlyBuilding in your /
<smb> <smb> sneumann, Well not them. I got an ETA of 5min (but its 450M too)
<smb> <smb> sneumann, Either run the build with fakeroot debian/rules skipdbg=false or create the
<smb> <smb> directory /CurrentlyBuilding in your /
<smb> retransmitting myself as freenode seems to be jumpy again
 * sneumann didn't understand the /CurrentlyBuilding magic, and uses the commandline / variable solution. Looks cleaner to him
<smb> sneumann, It some magic to act differently when building on the buildd's (The directory exists there)
<sneumann> as I said, command line argument looks cleaner ;-)
<ghostcube> sooo, should i write my investigated thingies to my bug report
<ghostcube> :D
<smb> sneumann, Just as additional info. Whatever works for you. :)
<smb> ghostcube, If you did what apw has asked you to do (manually force the slower run by removing /var/lib/ureadahead/pack, and then comparing against other runs), then yes. ;-)
<sneumann> I'll try oprofile with these ddebs, and file a bugreport on oprofile to add that to its documentation / README.Debian.gz
<smb> sneumann, Note that ddebs are Ubuntu specific
<sneumann> Yes, but there is no README.Ubuntu.gz :-) 
<sneumann> https://bugs.launchpad.net/ubuntu/+source/oprofile/+bug/497424
<smb> sneumann, Ok, its ok for the Ubuntu package. :)
<ghostcube_> smb: i did and i did a week runs with and without updates
<ghostcube_> :)
<ghostcube_> and its definetly that this fast boot is the problemo
<ghostcube_> :)
<smb> ghostcube_, From those runs the parts without updates naturally are much more useful as nothing else has changed. Ok, if you got logs from non-working compared and one working, after removing the pack file, then you should put them in the report and write up your observations
<ghostcube_> smb: ok will do so
<sneumann> smb: thanks, have a working oprofile setup. Bye, STeffen
<dhillon-v10> ogasawara, hi :D how are you? Its been a while since I last talked to you and I have been feeling useless to the kernel team, can you get me started with something 
<ogasawara> dhillon-v10: sure.  give me a bit and I'll send you email
<dhillon-v10> ogasawara, thanks you are awesome :)
<dhillon-v10> ogasawara, hey is it possible for me to join the qa team, I have been pretty active in the community by now
<ogasawara> dhillon-v10: there are a few qa related teams, can you be more specific which team your interested in?
<ogasawara> dhillon-v10: if it's the ubuntu-bugcontrol team you'll have to resbumit your application
<dhillon-v10> ogasawara, I will for bugcontrol in a short time, I wanted to join SRU Verification team, now that I have done a bit of packaging with my mentor 
<ogasawara> dhillon-v10: sbeattie would be a good person to contact about that
<ogasawara> dhillon-v10: I'm not what criteria is in place to join that team at the moment
<dhillon-v10> ogasawara, alright thanks again, I have been reading some book on the linux kernel and hope to soon help out with bugs in the kernel
<dhillon-v10> sbeattie, hi :) I want to join the SRU verification team and also want to know a bit more about the criteria for joining the team
<sbeattie> dhillon-v10: re sru-verification, what I'd like to see is existing work verifying SRU bugfixes.
<dhillon-v10> sbeattie, I have done some packaging, and will get started with more, can you point me to some links that can help me out with more bugs stuff
<sbeattie> dhillon-v10: if your interest is becoming more familiar with kernel bugs, I'll point out that there's an existing karmic kernel SRU pending, with several bugs that need verifying.
<dhillon-v10> sbeattie, I know that you are very busy, but is it possible to walk me thorough on how to fix one of the bugs, I'll package it, just need some instructions on how to do the rest
<sbeattie> dhillon-v10: hrm, perhaps there's some confusion; sru-verification doesn't do any packaging work; instead we test already uploaded fixes to ensure that (a) the change actually fixes what's intended and (b) doesn't introduce any regressions.
<dhillon-v10> sbeattie, sorry that's what I meant :D alright so I guess I will find some bugs on launchpad that have the patches attached to them and test them to see if they work as intended
<sbeattie> dhillon-v10: http://people.canonical.com/~ubuntu-archive/pending-sru.html has the list of packages that are in the various -proposed queues.
<sbeattie> poking through the list of karmic-proposed linux bugs that are in blue (haven't been verified yet) would be a good place to start to look for fixes to verify
<dhillon-v10> sbeattie, thanks a lot, so what happens after I verify one of the patches and it works, I get back to you or comment on the bug that was filed
 * sbeattie cries looking over the list of fixes in the various upstream kernel stable point releases.
<sbeattie> dhillon-v10: comment on the bug report in question is preferred; you can ping me afterwards to review what you've done.
<dhillon-v10> sbeattie, alright thanks again, I'll work on one of the bugs, and then get back to you
<mr_engineer> hi
<mr_engineer> I will ask some quick questions related to installing kernel 2.6.32
<mr_engineer> 1. Should I use this guide (http://www.ramoonus.nl/2009/12/03/linux-kernel-2-6-32-installation-guide-for-ubuntu-linux/) to install the mentioned kernel?
<mr_engineer> 2. Does the second paragraph in the website mean that i don't have to worry a second about my nvidia graphic drivers?
<BenC> mr_engineer: I think you are better off just adding the PPA to apt's sources.list and using apt-get to install it
<mr_engineer> I will be back in a couple of hours
<mr_engineer> BenC, that sounds interesting, will that take care of my nvidia graphic drivers as well?
<abogani> BenC: So you are still alive... :-)
 * mr_engineer is now away, if you have anything helpful to say, do so. I will come back and read
<BenC> abogani: I am :)
<abogani> BenC: I'm happy to read you again. :-)
<mr_engineer> Oh my.. 
<mr_engineer> If I install the 2.6.32 kernel through the repository, will my graphics drivers be taken care of?
<syn-ack> They should be... thats taken care of by the postinstall scripts, iirc
<mr_engineer> nice
<mr_engineer> thanks.. thats all i've been wanting to know like since 3 hours ago heh
<mr_engineer> nice
<mr_engineer> yeah now i saw it.... dkms
<mr_engineer> hi, I was here a while ago
<mr_engineer> I installed everything but now my grub menu.lst is being useless
<mr_engineer> I still boot into 2.6.31-14
<mr_engineer> but my menu.lst shows all the kernels i have installed.. Grub only shows me like 3
<syn-ack> mr_engineer: you'd probably be better off in #ubuntu. This is kernel development channel
<mr_engineer> syn-ack, but does it have anything to do with grub 2?
<syn-ack> What's that? Asking in #ubuntu?
<mr_engineer> its basically the same thing
<syn-ack> What's basically the same thing?
<mr_engineer> that grub is not using menu.lst correctly
<syn-ack> listen. grub2 does not use a menu.lst, and second, this is the kernel development channel. You're going to have better luck getting help in the ubuntu help channel, which is #ubuntu
<mr_engineer> syn-ack, oh yes, indeed. Sorry about that, I thought you were asking me about it. I am asking help in the #ubuntu channel, but you saying that grub2 does not use menu.lst just cleared the whole thing to me. Thanks a lot!
#ubuntu-kernel 2009-12-17
<mozmck> What is the difference between the source from ubuntu-karmic.git and that obtained with apt-get source linux-image* ?
<ikepanhc> mozmck: ubuntu-karmic.git is the version control tree of karmic kernel, and what you get from apt-get source is the source code of a signle version
<mozmck> I see, so the git will have changes now that haven't gotten into the last released version.
<ikepanhc> mozmck: yes
<mozmck> thanks.
<RAOF> I've sent a couple of messages to the kernel-team@ mailing list about the current state of nouveau & what we can do to incorporate it in Lucid, but they seem to by falling into a black hole, and I'm uncertain about how to respond to this.
<RAOF> https://lists.ubuntu.com/archives/kernel-team/2009-December/008095.html is an example.  Has the kernel team come to a consensus as to what to do about nouveau, and so my investigations are useless noise?
<RAOF> Or is everyone taken up with other tasks, and no-one's specifically in charge of nouveau so it's just going unremarked?
<mozmck> how do I change the kernel configuration using the git tree?  can I just run make xconfig?
<dtchen> RAOF: priorities, etc.
<RAOF> mozmck: Depends on what, precisely, you're trying to do.  There are targets for changing the config in debian/rules, and that'll hook in with the various foo-{generic,server,virtual,etc} flavours.
<mozmck> hmm, I'm adding a patch for rtai and I need to enable some new options it will add and change some others.
<mozmck> trying to make a basically generic kernel otherwise.
<RAOF> If you want to make packages out of it, use the debian/rules targets.
<RAOF> If you just want to build from the same tree, go wild!
<mozmck> I want to make packages.  so will the debian/rules targets see the new options and put them in?  I'm used to using make menuconfig or xconfig
<RAOF> mozmck: Check out debian.master/rules.d/2-maintainer.mk; that defines targets like "updateconfig" and "docrazystuffwithconfig".  They'll run a configuration interface & then merge the results back into the flavour system.
<mozmck> ok, thanks!
<Vamp898> Hi, with 2.6.32 my Wirelss Card RT2860 does not work anymore http://bugzilla.kernel.org/show_bug.cgi?id=14750 is there a chance to use an older kernel until its fixed?
<ubot3> bugzilla.kernel.org bug 14750 in Staging "rt2860 does not work anymore in 2.6.32" [High,New] 
<ikepanhc> Vamp898: as I know, rt2860 driver is still in staging, do you enable it?
<Vamp898> for sure^^ there wireless card is detected too
<Vamp898> its just unable to connect
<Vamp898> the same happend with RT2870 after they renamed it from ra0 to wlan0 and now the same with RT2860
<Vamp898> http://pastebin.com/d4f1a1634
<Vamp898> with kernel 2.6.32 the RT2870 problem was fixed
<Vamp898> but now 2860 does not work anymore and i dont want to wait until 2.6.33 without any internet
<Sarvatt> hmm,  /sys/class/thermal/thermal_zone0/temp started reporting as 47000 instead of 47 somewhere in the past few kernel releases, kind of scared to adjust acerhdf fanon and fanoff values to work with that because whenever its fixed my fan wont come on anymore
<Sarvatt> or does anyone know if that change was intentional?
<Keybuk> I would imagine so
<Keybuk> temp
<Keybuk>         Current temperature as reported by thermal zone (sensor).
<Keybuk>         Unit: millidegree Celsius
<Keybuk>         RO, Required
<Keybuk> it's certainly documented as being in thousandths of a degree
<mjg59> Sarvatt: Yes. It was a bug that acerhdf reported in degrees.
<Sarvatt> ah thanks, indeed i found the acerhdf commit that made it milidegrees, was worried it would possibly change back to degrees but it looks like its safe to adjust the module parameters
<Keybuk> commit 7129b126cc64f530d793bd56eb1709a06ec65a2d
<Keybuk> Author: David Fries <david@fries.net>
<Keybuk> Date:   Wed Feb 6 01:38:09 2008 -0800
<Keybuk>     W1: w1_therm.c standardize units to millidegrees C
<Keybuk> commit 5e012760dfd5ec24c41b9eab9e654a88360bb026
<Keybuk> Author: Zhang, Rui <rui.zhang@intel.com>
<Keybuk> Date:   Thu Feb 28 07:51:30 2008 +0800
<Keybuk>     ACPI: thermal: show temperature in millidegree Celsius
<Keybuk> etc.
<Sarvatt> sorry for the noise and thanks for the help, i should have looked harder :D
<Sarvatt> i just have to be careful booting a .31 kernel in that case
<Laibsch> How does the Kernel team apply patches?  Patch the source and let it go to diff.gz or does it use a patch system?
<Laibsch> Looking at the unpacked source, it seems to be the former
<Laibsch> But the kernel package is complicated and I'd like to verify
<rtg> Laibsch, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<Laibsch> I was reading that (and lots of other wiki pages)
<Laibsch> yet, I still don't know
<Laibsch> it's a simple question
<Laibsch> (or isn't it)
<Laibsch> (or isn't it?)
<rtg> Laibsch, its not, which is why there are multiple wiki pages on the topic
<Laibsch> OK
<Laibsch> It's about bug 444801
<ubot3`> Malone bug 444801 in linux "prism 2.5 broke in 2.6.30.x (fixed upstream in 2.6.32)" [Medium,Fix released] https://launchpad.net/bugs/444801
<Laibsch> which I reported
<Laibsch> I did not have wifi for a while so could not test the fix that has already landed upstream
<Laibsch> I want to test now and ultimately get the fix into karmic
<Laibsch> lucid kernel seems to already have it
<Laibsch> what do you suggest I do?
<rtg> Laibsch, run the lucid kernel with karmic userspace
<Laibsch> then I have the fix, nice
<rtg> Laibsch, alternately, install linux-backports-modules-karmic-generic
<Laibsch> But I'd like to get the fix into karmic for everyone's benefit, too
<rtg> which is 2.6.32 based
<Laibsch> rtg: thanks for helping me
<Laibsch> I'm not looking for support
<Laibsch> but for a way to properly backport the fix
<Laibsch> for everybody
<rtg> Laibsch, understood, but LBM _is_ the fix, not the main kernel.
<Laibsch> I see
<Laibsch> Maybe it should be installed by default, then?
<rtg> Laibsch, nope, LBM is, and will remain, an elective install.
<Laibsch> rtg: unfortunately, LBM does not fix the issue, it makes my wifi card completely dysfunctional!  I have to concede, though, that the card won't work with today's mainline kernel, either :-(
<rtg> Laibsch, hmm, I thought you said it had been fixed upstream?
<Laibsch> there was a patch committed
<Laibsch> And indeed, I verified the patch works
<Laibsch> -> see discussion in the bug
<Laibsch> But it seems there is some other regression
<rtg> Laibsch, commited after2.6.32?
<Laibsch> not sure when it happened
<Laibsch> the patch to fix the original issue made it into 2.6.32, I believe
<Laibsch> bug 444801
<ubot3`> Malone bug 444801 in linux "prism 2.5 broke in 2.6.30.x (fixed upstream in 2.6.32)" [Medium,Fix released] https://launchpad.net/bugs/444801
<Laibsch> I'm currently recompiling the lucid kernel for karmic
<Laibsch> I'll see if the lucid kernel has the problem (I suspect it does)
<Laibsch> I'll open a new ticket, then
<rtg> Laibsch, why not just install the deb? you don't need to rebuild it
<Laibsch> I don't?
<Laibsch> I wasn't sure
<rtg> Laibsch, no, just use dpkg.
<Laibsch> I usually always recompile binary packages
<Laibsch> OK
<Laibsch> Thanks
<rtg> Laibsch, the patch in the bug report went in as of 2.6.32-rc1, so Lucid ought to be right. I'm surprised LBM didn't fix it also.
<Laibsch> I suspect a separate regression
<Laibsch> brb
<Laibsch1> rtg: lucid kernel works and is free of the original problem as well
<rtg> Laibsch1, cool, glad you're back in business
<Laibsch1> I guess outlook is gloomy, though
<Laibsch1> I'm glad I caught the error early
<Laibsch1> I guess it's time for another kernel bug report upstream
<yoasif> hey guys
<yoasif> quick question
<yoasif> im running lucid and id like to report a bug with my webcam
<yoasif> apport recommends that i try with a mainline kernel 
<yoasif> should i download the rc8 version on the mainline server or the plain 2.6.32?
<rtg> yoasif, use the plain 2.6.32 since its the official. 2.6.32.1 should also be there.
<yoasif> rtg, so just grab the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32/ (along with the headers and etc?)
<rtg> yoasif, you shouldn't need the headers unless you have a DKMS dependency (like nVidia)
<yoasif> yeah, i do have nvidia -- do i need to get the sources too, or no -- it's a large file
<rtg> just the headers
<yoasif> sounds good, thanks rtg
#ubuntu-kernel 2009-12-18
<lamont> someone remind me how to tell what the actual path to /dev/sdc is..??
<jk-> lamont: actual path?
<jk-> lamont: but 'udevadm info --query=all --name=/dev/sdc' is probably what you're after
<lamont> ah, yeah. thanks
<lamont> I kinda randomized the drives and needed to figure out where /boot migrated to
<PrototypeX29A> hi
<PrototypeX29A> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<PrototypeX29A> will this give me the latest version of the ubuntu-kernel or the release-version?
<PrototypeX29A> the kernelGitGuide says I will get "the master tree", but i find it strange to have to give the name of the release to get the latest version
<RAOF> PrototypeX29A: It will get you the the latest Ubuntu version + any changes that will presumably make it into the next Ubuntu version.
<PrototypeX29A> "latest ubuntu version" means "latest release version"?
<RAOF> If you clone ubuntu-karmic.git you'll get 2.6.32-9 + any changes since that release.
<RAOF> You _won't_ get Linus' linux-2.6 tree.
<PrototypeX29A> ok, that is what i intended
<PrototypeX29A> but i don't understand the principle 
<PrototypeX29A> what would happen if i replace karmic with jaunty?
<RAOF> You'd get the kernel that's in Jaunty.  If your question is "why isn't there a single git repository with branches for the various releases", then I don't know.
<PrototypeX29A> and how would i get the karmic without the changes?
<RAOF> It's tagged in the ubuntu-karmic.git repository.
<PrototypeX29A> ok, thanks
<PrototypeX29A> so my next question you have already answered :)
<junjun> hi
<junjun> i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch?
<junjun> i want to know which change Ubuntu made to the vanilla kernel
<junjun> it seems Ubuntu uses Non-exec patch from OpenWall?
<junjun> is it really the Exec-shield patch from Redhat??
<junjun> or if not, what is the difference between Non-exec patch and Exec-shield patch?
<jjohansen> junjun: you can find the ubuntu git trees at https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
<jjohansen> from there you can find all the patches that have been applied
<junjun> jjohansen: thanks
<mdz> apw: according to marjo's test report, we're still seeing bug 494052 in cert testing
<ubot3`> Malone bug 494052 in linux "bnx2 driver cannot find firmware" [Medium,Fix released] https://launchpad.net/bugs/494052
<apw> mdz, thanks for the heads up
<mdz> apw: I've emailed suggesting he take it up with the kernel team, but figured there was no need to wait for him to wake up to get the ball rolling
<apw> yep
<apw> mdz well the firmware was in the .udeb at least in -8 ... will talk to marjo and get a dmesg
<mdz> apw: you folks really ought to have access to pull data like that directly out of the certification db rather than having to ask for it (IMO)
<apw> mdz yeah probabally true
<lamont> gah.  wtf does it boot to a blinking cursor, instead of grub?
<rtg> lamont, lucid? the grub prompt is quite brief
<lamont> karmic
<rtg> oh, hrmm. is this something that used to work?
<lamont> workstation powersupply took out the MB, one drive of the raid array..  I can get to all of the array with karmic-live, but booting from the hard drives is not happening
<lamont> of course, when I pulled out all the drives and put them back in as part of getting the MB out, they got a tad bit randomized
<lamont> so /boot is RAID1 across /dev/sd{c,d,e}1
<rtg> but UUID should find the right one
<lamont> and root is an LVM partition on a RAID6 array across sd{a,b,c,d,e}6 or so
<rtg> kind of complex
<lamont> and (go me) I had the wrong UUID in fstab, so the root=/dev/MIX/root in menu.lst was saving the day before
<lamont> so I guess the real question is: given a running livecd, chrooted into the real root with all the other stuff mounted under that, htf do I get the MBR written on the drive of my choice?
<lamont> because I'm thinking all 5 is a good answer.... :-)
<rtg> lamont, a grub reconfigure or reinstall? might have to bug cjwatson on  that one.
<lamont> ok
<lamont> looks like maybe grub-install /dev/sd$i
<lamont> anyway, afk
<tim> hi, compiling kernel 2.6.33-rc1 with make-kpkg, i get this error http://pastebin.com/d66472fa7 after compiling ... any ideas, what i am doing wrong?
<ghostcube> The UTS Release version in include/linux/version.h   
<ghostcube> means the file shows a wrong verioning 
<ghostcube> version
<ghostcube> have you checked the file ?
<tim> ghostcube, yes, i can understand the error message, i already did a make mrproper in the source tree, though
<ghostcube> have you looked into the file o.O
<tim> http://pastebin.com/d5c3f079c
<ghostcube> kannst du deutsch
<tim> ja
<ghostcube> gut
<ghostcube> is das en ubuntu kernel source oder normaler kernel.org 
<tim> gibt es einen ubuntu kernel v2.6.33-rc1? ist linus/master
<ghostcube> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc1/
<ghostcube> warum nimmste nit den o.O
<ghostcube> is weniger action
<tim> o.O?
<ghostcube> hilft das ?
<ghostcube> :)
<ghostcube> oder musste selbst bauen
<tim> ja ... einfache debs nutzen mir nicht wirklich viel
<ghostcube> hmm ok 
<ghostcube> bauste patches ein oder wie ?
<ghostcube> weil bei dem kernelcode bug kann ich dir nicht wirklich helfen ich denke die zahl is falsh
<ghostcube> oder du hast da ne alte version
<ghostcube> irgednwo und der greift auf die zu
<tim> ich brauche ein paar dinge im kernel, die nicht unbedingt im ubuntu package aktiviert sind ...
<tim> ich hab das ./debian verzeichnis gelÃ¶scht, ein make mrproper gemacht, bzw das include/linux/version.h file gelÃ¶scht
<tim> aber der kernel selbst wurde schon gebaut, nur das debian package mag sich nicht erstellen
<tim> hm, ansonsten mach ich mich mal an ein git bisect zu v2.6.32 ... mÃ¶glicherweise hat sich das format der header files etwas geÃ¤ndert ...
<ghostcube> boah ich bau schon lange nich mehr selbst
<ghostcube> ich bin da keine grosse hilfe
<ghostcube> aber evtl hilfts wenn du wieder auf english wechselst
<ghostcube> weil keiner hier peilt was wir schreiben
<ghostcube> :D
<tim> hm ... i will drop by again tomorrow to have a closer look at this ...
#ubuntu-kernel 2009-12-19
<junjun> hi
<junjun> i am using 9.10. it seems 9.10 kernel doesnt turn on SYSENTER?
<junjun> i checked, and it seems SYSENTER_CS = 0
<junjun> so Ubuntu patched the kernel to disable SEP? why is that?
<lesshaste> hello
<ebroder> Now that Xen is starting to ship a set of dom0 patches against current kernel versions, is there any chance of reintroducing dom0 support for Lucid?
<jjohansen> ebroder: unlikely
<ebroder> Even if it was done in universe, like it was before?
<ebroder> Like, is this an issue of the kernel team being fundamentally opposed to having Xen support, or is it an issue of workload and maintenance?
<jjohansen> workload and maintenance
<ebroder> So what if somebody volunteered to put the patches together?
<jjohansen> ebroder: I can't speak to whether they would make it into universe but someone could volunteer and see where that went
<ebroder> Ok, thanks. I'll probably take this to the mailing list sometime soon
<jjohansen> good luck
#ubuntu-kernel 2009-12-20
<tim> hi, i have been using make-kpkg regularly to build kernels. trying to build 2.6.33-rc1, i get the following error message, though: http://pastebin.com/d357e706d ... i have been switching kernel versions before, did a make mrproper etc ... any idea, what may be going wrong?
<pgraner> tim: you can find 2.6.33-rc1 vanilla kernel builds for Ubuntu here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc1/
<tim> pgraner, i know, i prefer building myself, since i need a custom configuration
<tim> pgraner, also, it is hard to bisect a kernel tree with *debs :)
<tim> well, i manually edited include/linux/utsrelease.h to match the version now ... still, dkms is unable to determine the target kernel version, too
<tim> it seems that something has changed in 2.6.33, that breaks both make-kpkg and dkms :/
<zbert> Hello room, anyone in here?
<zbert> Looking for some newbie guidance
<zbert> Is this room sleeping?
<zbert> Wow, this is a disappointment, several rooms for ubuntu development are quiet, how can open source progammers assist if no one works on these projects?
<zbert> Anyone in here?  Is there a good starting point to contribute?
<Darxus> zbert: https://lists.ubuntu.com/mailman/listinfo/kernel-team      
<Darxus> You must be new to IRC.  Expecting a prompt response is.. not practical.
<Darxus> zbert: Also, see the channel topic.
<crimsun> it's also the weekend, and it's close to major holidays.
<zbert> Sorry to get back late... thanks for the list...
<zbert> Not really expecting a prompt response either.
<crimsun> do you have any specific questions?
<crimsun> probably one of the easier ways to get involved is via the kernel bugday
<crimsun> (this tuesday)
<zbert> No, I got my questions answered but thank you.  Unfortunately, I only have time to code on the weekend so Tuesdays are out but I'll remember that if the kids have another snow day this week
<crimsun> heh, same here.
#ubuntu-kernel 2010-12-20
<achiang> hughhalf: hi, i heard you had an arduino serial device?
<hughhalf> achiang, umm, not sure what you mean sorry, have done some arduino stuff, but arduino serial ?
<achiang> hughhalf: hm, JFo or apw claimed that you had arduino hardware that connected via USB serial to a pc?
<hughhalf> this sort of thing ? http://www.freetronics.com/products/twentyten
<achiang> hughhalf: maybe i should ask my real question. :)
<achiang> hughhalf: found a lucid regression, i filed a bug a few days ago, but it doesn't seem to be getting any attention -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/690798
<ubot2> Launchpad bug 690798 in linux (Ubuntu) "arduino USB serial device breaks on lucid kernel upgrade (affects: 2) (heat: 12)" [Undecided,New]
<achiang> hughhalf: the reason i poked you is because apw hinted you might have the hardware
<hughhalf> oh, ok, I've a few arduino's floating around here, yes
<achiang> hughhalf: can you find someone to take a look at it? it seems to be an easily reproducible kernel regression in lucid, which obviously isn't good
<hughhalf> achiang, will see what we can work out, sure. 
<achiang> hughhalf: great, thanks!
<hughhalf> quic read of that bug suggests that it may actually be that the kernel is now doing The Right Thing (TM) but that the application is now not working as it's relying on (arguably) "broken" behaviour
<achiang> hughhalf: really?
<hughhalf> well, like I said, an initial take on that patch is that it's correcting incorrect behaviour
<achiang> i see, interesting
<hughhalf> achiang, I may mis-read it though, but given Greg has signed off on it it suggests to me that he'd regard the behaviour as now being correct.
<hughhalf> Lemme look in the LKML archive and see if there is any discussion on it
<achiang> ok, thanks hughhalf 
<hughhalf> achiang, I take it that you know the person who wrote the code ?
<achiang> hughhalf: yes, i do know him
<achiang> hughhalf: i'd be happy to explain to him that his code is broken, if you can tell me why. :)
<hughhalf> well, broken may be too strong, but lemme dig a bit more
<achiang> hughhalf: stepping out to buy an emergency USB key, back in about 20
<hughhalf> no worries
<achiang> back
<hughhalf> :)
<hughhalf> achiang, so my read at this stage is that the kernel patch is in all likelyhood correct and that the app may need to be tweaked to implicitly set, or clear the DTR/RTS lines the way the arduino requires them.  This based on a couple of things \
<kees> apw: oh! were you able to reproduce 686705 ?
<hughhalf> The patch has been in for a couple of weeks now and was itself a revert back to the way the FTDI driver had been for some time
<hughhalf> and it's a patch that's been scrutinised by gkh and others who have deep familiarity with serial code
<hughhalf> secondly, the FTDI devices are used in a huge range of hardware, not just arduino, so I'd venture we'd be seeing more problems if it were in fact broken behaviour
<hughhalf> but, achiang, this all based on what is it, about 40 minutes of reading on my part
<hughhalf> achiang, I'm happy to update the bug to that effect though if you like, call it an educated guess :)
<hughhalf> well, somewhat educated :)
<achiang> hughhalf: what you outlined sounds reasonable to me. my concern was, "did ubuntu take a patch from upstream that was later reverted (in upstream)" 
<achiang> hughhalf: i heard a rumor about that, but admit, i did not do due diligence in chasing it down
<hughhalf> achiang, heh, no probs
<hughhalf> I mucked about a fair amount with USB serial code back in 2.4 days and the code, as reverted, rings true to me
<hughhalf> but the real clincher is the pervasiveness of FTDI devices
<hughhalf> achiang, happy to summarise in the bug if you like
<achiang> hughhalf: i'd say go ahead and update the bug and push back. sounds reasonable, and i know the person well enough to know that his feelings won't get hurt
<achiang> hughhalf: much appreciate the research, ta!
<hughhalf> achiang, my pleasure, a pleasant trip down memory lane :)
<hughhalf> achiang, I'll leave it to you to change the actual disposition of the bug once you chat with your friend
<achiang> hughhalf: wow, i've never heard anyone talk about usb, serial, and "pleasant" in the same sentence
<achiang> hughhalf: ok, i'll make sure to update the bug status as appropriate. thanks again. :)
<hughhalf> np
 * hughhalf steps away for a moment
<apw> kees, yep, seems one of my machines is showing the same symptoms ... going to rip out NX to confirm its the cause this am
<apw> cjwatson, i have a machine which seems to reproduce the warm boot hang ... i note it hangs on the warm boot before the grub menu, before purple is asserted; any way i can ask grub whats up?
<apw> cjwatson, just confirmed that it is NX emulation on i386 which is triggering the failure mode; backing that out clears things up
<cjwatson> apw: does 'grub-install --debug-image=all <device>' show any output?
<cjwatson> apw: wait, a *kernel* change fixes something that happens *before the grub menu*?
<cjwatson> apw: that's impossible
<cjwatson> oh, warm boot
<apw> cjwatson, heh nothing which occurs is impossible.  yeah warm boot
<cjwatson> good grief
<apw> i know ... mad isn't it
<apw> it has to be an assumption from grub about the initial environment
<apw> i suspect that we'd like to fix grub as well as undoing whatever we are not undoing before reboot in the kernel
<cjwatson> like I say, 'grub-install --debug-image=all <device>' should produce boot-time output that at least narrows down where it falls over
<apw> cjwatson, will get the kernel downgraded and see what i can find
<apw> cjwatson, woh that boots _slow_
<apw> yay purple ... this could take some time
<apw> cjwatson, how many lines of output would i expect from a sucessful boot
<apw> given they are coming out about 3-4 per second
<cjwatson> loads
<cjwatson> zillions
<apw> damn, i guess this test will take longer than i had hoped
<cjwatson> hopefully the last screenful will be useful since there's no shift-pgup
<cjwatson> what's the exact diff you backed out?
<apw> cjwatson, sadly this is the good boot, before the bad boot
<cjwatson> oh.  DDTT :-)
<apw> cjwatson, http://pastebin.com/MWcTAaZg
<apw> cjwatson, not sure if its quicker to let it finish, or boot a USB image and fix it
<apw> cjwatson, that diff is all about using user code segments to protect userspace from executing data
<cjwatson> I'd probably just let it run at this point
<apw> it is not at all clear how that could affect grub
<cjwatson> different CS on entry?
<apw> cjwatson, that diff btw is stupidly backwards, its the diff of the revert
<cjwatson> yeah
<cjwatson> mind you if CS were wrong *nothing* would work
<cjwatson> don't suppose it's reproducible in kvm?
<apw> cjwatson, if i hold shift i get GRUB loading, but no colour change and no menu
<apw> cjwatson, can't say i've tried it no, i was supprised when it appeared on a previously working machine
<cjwatson> right, that's where I need the debug-image stuff, I need to know how far it gets
<apw> though that occured cause i moved it to 32 bit for performane
<cjwatson> have roughly no hope of narrowing it down otherwise
<apw> yeah ... well i have the debug on :/  and once i get booted i will reboot and let you know
<apw> still reading the menu on this boot sadly
<apw> near the bottom at least
<cjwatson> so should this happen with the generic kernel on any i386 machine?
<apw> cjwatson, i cannot say i am 100% sure if that, i suspect it cannot be all i386s else we'd be inundated with whining and we are not
<apw> cirtainly it happens on a couple of atom systems, Sarvatt_ has an N270 and I have an N455 (64 bit capable) showing it
<cjwatson> do we know if the version of grub matters or if it's just the version of the kernel?
<apw> i suspect the bios could easily fix things
<apw> cjwatson, no i do not know if grub version helps, i hear but have yet to confirm that =text does not make a difference
<cjwatson> it would make even less sense for gfxpayload=text to be relevant
<cjwatson> that only does anything at all after the menu is displayed
<apw> yep indeed
<apw> though i was more thinking of the graphics=auto bit, might matter, the fact we used the bios to go graphical
<cjwatson> of course grub maverick<->natty is over 4000 lines of upstream changelog so exactly how much that would help for bisecting is unclear
<cjwatson> sure, but gfxpayload=text doesn't influence that
<apw> ahh yes so we might need a different test there to confirm if its that ... but as i have to wait on debug :/ i'll not be able to do that for a bit
<apw> cjwatson, man this thing does a lot of small mallocs
<cjwatson> yep
<apw> that cannot be cheap :)
<cjwatson> *shrug*
<matti> :>
<apw> cjwatson, ok rebooting with debug
<apw> cjwatson, no output what so ever
<cjwatson> blink
<cjwatson> joy, so it's really early
<apw> and a hard-reset gives me a debug boot
<apw> yeah really really early it seems
<cjwatson> so you get the full string "GRUB loading"?
<cjwatson> actually, what *exact* text
<apw> cjwatson, i did not hold shift, let me re-do the test
 * apw hates shift
<cjwatson> it might have punctuation after
<apw> will confirm
<cjwatson> grub-install *without* debug-image before you reboot!
<apw> doing that now
<cjwatson> then --debug-image=all before the warm boot
<cjwatson> I'd like to know where the cursor is too
<cjwatson> is it on the same line as "GRUB loading" (with possible punctuation), or on the next line?
<apw> i have to boot via a usb stick to clean up for the reboots, so it takes a bit
<cjwatson> diskboot.S prints a dot on each read from disk, and a newline when it's finished reading
<cjwatson> after the newline, it jumps to the GRUB kernel
<cjwatson> so we should be able to tell from the *exact* message there how far it got through diskboot.S
<apw> cjwatson, got u
<cjwatson> then there's a small pile of bootstrap assembly (grub-core/kern/i386/pc/startup.S) and then it jumps to grub_main (grub-core/kern/main.c)
<apw> GRUB loading.<newline>
<apw> cursor is on second line left edge
<apw> cjwatson, when it works it prints quite some debugging next before switching to grpahics mode and going much slower
<cjwatson> OK, so it got into the kernel
<cjwatson> (ours, not yours)
<apw> and none of that pre-graphics mode debug is here either
<apw> cjwatson, cursor is flashing, no idea if that h/w or s/w driven
<cjwatson> I doubt graphics is involved
<cjwatson> hardware
<cjwatson> if graphics init were relevant, there'd still be some debug output before that
<apw> anything else to get from here, or shall i start recovering
<cjwatson> it would be useful to try a grub2 package with debian/patches/ubuntu_really_quiet.patch reverted
<apw> ok
<cjwatson> can you assemble that or do you need me to?
<cjwatson> would be lovely to have a diff of register states
<cjwatson> I wonder if it's one of the GDTs
<apw> cjwatson, cirtainly we are changing something descriptor table like, though i thought it was the LDT from the descriptions in the patch
<apw> cjwatson, i think i can do the grubby thing
<cjwatson> seems to be GDT entries from the code, although I admit to not being very familiar with this stuff
<apw> cjwatson, then ... i suspect we need to put them back before reboot
<apw> though why this matters all of a sudden, it never seemed to on older releases ...
<cjwatson> there've been a few major changes to GRUB's startup code since maverick, so I suppose that could be related
<cjwatson> mainly the introduction of Reed-Solomon redundancy
<cjwatson> hesitant to finger that for sure though
<apw> cjwatson, well at least  it is different so it is possible this is new
<cjwatson> GRUB loads its own GDT on entry to protected mode
<cjwatson> I don't suppose no-exec ranges might be preserved across warm boot?
<cjwatson> so some bit of memory that GRUB's code is loaded into might be still marked no-exec?
<cjwatson> I have no idea how warm booting works really
<apw> no exec ranges in this context are simply segment size offsets
<apw> we are likely rebooting with the segment sizes limited
<apw> but those are in the GDT as far as i know, so it seems it would have to be bust before protected mode somehow
<cjwatson> but isn't the GDT only used in protected mode?
<apw> cjwatson, yeah indeed, it makes no sense what to ever
<apw> cjwatson, these extra prints, i wonder if they could be turned on by shift as well
<cjwatson> yeah, I was just thinking that earlier
<apw> ok i see the inverted hello message on a normal boot and _not_ on the failed warm boot
<apw> can't quite read it to tell you what it says, but i deffo get a new message on the normal boot now
<apw> cjwatson, ^^
<cjwatson> ok, so it's between the end of diskboot.S and the end of grub_machine_init
<cjwatson> still a hell of a lot of hairy code :(
<apw> cjwatson, can we print in that region ?
<cjwatson> it's tricky, a lot of that is in protected mode
<cjwatson> and printing is int 10h
<cjwatson> you would have to very very very very very carefully jump in and out of real mode
 * apw whimpers
 * diwic can't do that, his carefullness is limited to three very's maximum.
<apw> diwic, :)
<diwic> apw, nice to see someone working
<apw> cjwatson, i note that we move to real mode then setup the segment registers, is that the right way round?
<apw> cjwatson, ahh ignore that, it has to load CS to jump into real mde
<cjwatson> something like http://paste.ubuntu.com/545921/ might be worth tryinig
<cjwatson> *trying
<cjwatson> see if it's a bug in the RS code
<cjwatson> (untested!)
<apw> cjwatson, yep, doesn't even apply to the version in the archive :)
<apw> cmpiling nw
 * apw suspects this keyboard may have had it day
<apw> BAH avahi doesn't work on natty ... does anything work?
<cjwatson> no.  HTH
<apw> happy or hope
<apw> cjwatson, it seems to only see itself
<cjwatson> I meant hope
<apw> cjwatson, heh though you probabally did
<apw> i would have said "good luck with that" myself
<apw> cjwatson, ok i think turnng off the RS code there has also sorted it
<apw> Sarvatt_, about ?
<apw> cjwatson, yeah as far as i can tell turning off just that one line of code there is enough to sort it out
<cjwatson> ok, I'll have a poke at the RS implementation and try to find likely causes
<apw> cjwatson, no idea what it could be doing which triggers issues
<diwic> apw, any prognosis on when 2.6.38 merge window will open/close?
<apw> depends if he releases before xmas, which he has tended to do in the past
<apw> if so, i'd expect the window to open in the beginning of january
<diwic> apw, and it's open for a week or so?
<apw> diwic, normally a week, though if it opens when he releasaes i expect it to be a little longer, so probabally a full week into the new year
<diwic> apw, and since we're likely going with 2.6.38, getting patches in there is quite soon
<apw> diwic, yes, now is a good time to be getting stuff ready and in maintainer trees
<diwic> apw, the alternative is merging into Ubuntu, but the administration exercise is heavier :-/ 
<apw> diwic, indeed, we carry a lot of patches before tehy get to mainline if they are a justified
<apw> cjwatson, is this using RS to encode the grub payload?
<cjwatson> apw: yeah, it's because some things widdle over the boot track
<apw> cjwatson, what does STANDALONE mean in grub context ?
<cjwatson> apw: it's specific to grub-core/lib/reed_solomon.c
<cjwatson> it means it's being built for use at boot time rather than for use in the utility code (grub-setup)
<cjwatson> I wonder if it's something to do with trying to use memory at 0x100000 / 0x100100
<cjwatson> maybe that memory isn't available?
<apw> cjwatson, i am struggling to know what might be in there the second time that is not the first
<cjwatson> sort of sounds like we need a diff of e820 maps
<apw> cjwatson, i would be supprised if they differ
<cjwatson> you could try http://paste.ubuntu.com/545963/ or something just to see if it makes a difference
<cjwatson> picking a low memory region at random
<cjwatson> that doesn't really make sense though - grub decompresses to 0x100000 later anyway
<apw> cjwatson, i'll give it a try
<apw> cjwatson, this init function for the inverts does not seem to set the first element ... which i suspect means it would default 0 the first time
<apw> cjwatson, of course i cannot tell if it ever uses the [0] in the rest of the algorithm
<apw> cjwatson, i moved that bufer from 0x10... to 0x09... and it seems to work
<apw> cjwatson, some of this code handlng the scratch buffer is a little suspect
<apw> #ifndef STANDALONE
<apw>   chosen = xmalloc (n * sizeof (int));
<apw>   grub_memset (chosen, -1, n * sizeof (int));
<apw> #else
<apw>   chosen = (void *) scratch;
<apw>   scratch += n;
<apw> #endif
<apw> cjwatson, that bit for instance neither allowed enough space (scratch is a char * not an int *) and does not init it to -1
<apw> not that actually the init looks right either
<smagoun> Hi, the lenovo-sl-laptop driver was included in l-b-m for Karmic (bug 351586). I can't find this driver in 10.10 though. Anyone know what happened to it?
<ubot2> Launchpad bug 351586 in linux-backports-modules-2.6.28 (Ubuntu) (and 2 other projects) "please add lenovo-sl-laptop to ubuntu sauce (affects: 11) (dups: 4) (heat: 8)" [Medium,Fix released] https://launchpad.net/bugs/351586
<czr_> achiang, maybe the arduino problem is related to this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/655868
<ubot2> Launchpad bug 655868 in linux (Ubuntu) "[lucid regression] FTDI based USB to serial adapter no longer works (affects: 5) (heat: 38)" [Undecided,New]
<achiang> czr_: good catch, thanks!
<czr_> I'm being hit with the issue with lucid. using the newest backport kernel fixes it (without software modifications), but I lose bcm, and it's not a proper solution anyway
<xclaesse> That bug is still reproducable on latest natty: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/662946
<ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 38) (dups: 2) (heat: 208)" [Medium,Incomplete]
<xclaesse> it is making ubuntu unusable since maverick here
<smagoun> To answer my own question, it looks like functionality in lenovo-sl-laptop was at least partially folded into the asus-laptop driver
<kees> apw: but... the nx code is unchanged from maverick :(
<apw> kees, indeed so, there is an interaction between that and some new code in grub2
<kees> apw: yeah, very strange. is there a common "kernel is shutting down now" routine in the kernel? maybe it could reset the CS limit? that's the only thing I can think of that might survive a warmboot.
<apw> kees, i have actually tried just commenting out the CS limit checks and not had any success, i may have done it wrong but i don't think so
<kees> well, the checks aren't running at grub time, it would just be the CPU state left after boot, right?
<apw> kees, yep indeed, though grub loads the registers in use for this feature in theory
<apw> kees, simply put having poked it for nearly a whole day I am none the wiser as to why it occurs
<apw> i know of two ways to mitigate the issue, but no idea waht the issue really is
<kees> apw: what are the mitigations?
<apw> revert the nx patch (diabling it does not seem to work)
<apw> or turn of the error correction core in grub
<kees> error correction core?
<apw> or actually, 3) move the EC core scratch buffer
<kees> _move_ it?!
<apw> it does reed-solomon encoding on the the stuff in track 0 to cope with mangling of its stage2 or something
<kees> that makes even less sense. is a memory map surviving boot or something?
<apw> kees, i know ... it makes no sense on the face of it
<apw> i suspect it is a bug in the reed solomon decoder, but why the presence of the NX code triggers it i have no idea
<apw> the presense of it before the last full processor reset of course
<kees> apw: maybe the grub code isn't clearing some area of memory that just happens to have the NX code in it or something, and it's comparing the wrong areas? ram contents would survive the warm boot.
<apw> kees, yeah i am working on the assumption its a memory layout issue, that the NX stuff is moving things
<apw> but this is mad code written by propeller headed maths people
<apw> "this is simpler thought of in the frequency domain" .... EEEK
<kees> haha
<apw> i know ... and its all magic maths, special code doing powers and vile ick all with 1 letter viariable
<cjwatson> an uninitialised memory bug seems likely
<apw> yeah, and a pig to find that is going to be
<cjwatson> I've mentioned it to upstream
<apw> cjwatson, thanks
<apw> i have found one apparent bug, but i cannot really see how it would trigger this behaviour
<apw> as in it looks like it would be always broken or we are always  lucky
<cjwatson> the missing memset looks like a good candidate
<apw> cjwatson, doesn't seem to be a memset in STANDALONE either
<apw> though the allocation for that one is 1/2 it should be
<cjwatson> that's what I meant
<xclaesse> apw, about 662946 you asked me to test natty kernel... I'm running up to date natty here, and I can reproduce the bug
<apw> bug #662946
<ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 39) (dups: 2) (heat: 212)" [Medium,Incomplete] https://launchpad.net/bugs/662946
<apw> xclaesse, odd, noone else who had that original issue is still experiencing it (/me for instance) so i guess we have some other bug/trigger for kslowd usage ... hmmm
<xclaesse> apw, it is not kslowd anymore
<xclaesse> it is kworker
<xclaesse> but result is the same
<apw> indeed
 * apw wonders if kworker has any debug support
<apw> cjwatson, ok changing that size alone does not work
<cjwatson> apw: I'm attempting to valgrind it
<apw> cjwatson, woh ... now that is brave :) ...
<apw> cjwatson, am now building with a 'memset' over the array on that routne
 * apw thinks this one is going to be a tiny little error, and this is going to take some time to find
<apw> kees, do you have a machine which reproduces this issue ?  it seems any atom running i386 should be suspeceptible
<cjwatson> apw: http://paste.ubuntu.com/546052/ seems to be enough to make valgrind happy
<cjwatson> can you try that?
<apw> cjwatson, there is no memset in STANDALONE
<apw> i am trying this which is equivalent
<cjwatson> grub_memset
<cjwatson> and yes there is
<cjwatson> just have to spell it right :)
<apw> cjwatson, really there doesn't seem to be, i got a compile failure from moving that line down
<kees> apw: I don't, no. other atom systems I've tried don't show it.
<cjwatson> apw: hang on a moment then
<apw>   chosen = (void *) scratch;
<apw>   scratch += n * sizeof (int);
<apw>   for (i = 0; i < n; i++)
<apw>     chosen[i] = -1;
<apw> i just am using that
<apw> as i _think_ that is what they really meant, i don't think they want the bytes to be -1, but each choice
<cjwatson> apw: try http://paste.ubuntu.com/546054/ then
<cjwatson> apw: it's equivalent surely
<cjwatson> -1 is all-bits-set
<apw> i guess it is, yeah, but ... naughty
<cjwatson> still, would prefer you to test minimal-change from upstream if you could
<apw> cjwatson, yep, am testing with your patch now ...
<ohsix> is the rtc hack all you have when you don't have a serial port when you're debugging suspend/resume problems?
<apw> ohsix, pretty much yes
<apw> they should never have allowed them to take the serial ports off these machines
<mjg59> apw: USB debugging's not that hard to support
<apw> ohsix, some peoplpe have a pcix card with lights on which they use, but that involves taking your machines to bit
<apw> mjg59, yeah it is if you want to test suspend/resume though
<apw> as either its suspended and you can't use it, or its not and the behaviour of half your devices change (in my experience)
<apw> someone had a memory buffer for debug stuff somewhere, but i forget who
<ohsix> mine stopped waking up a while ago and too many things updated in the window for me to know which bit it is (i had been using the xorg-edgers ppa & kernel)
<apw> mjg59, we do build in some usb stuff to make it easier to debug, but not to much gain 
<mjg59> apw: Sorry, may not have been clear. The USB debug port spec.
<cjwatson> apw: thanks
<apw> mjg59, ahh yes, not that i've managed to find a device implementing the other half
<mjg59> It basically gives you a bit-banging interface that can function as a console even if you don't have the full USB stack up
<apw> cjwatson, i wish this compile was faster ... its a slow iteration what with the two reboots too
<ohsix> it should dtmf the pc speaker so you can record and decode it :D
<apw> cjwatson, hrm adding that produced _these_
<apw> reed_solomon.c: Assembler messages:
<apw> reed_solomon.c:699: Warning: ignoring changed section attributes for .text
<apw> ../../../grub-core/kern/i386/pc/startup.S:163: Error: attempt to move .org backwards
<cjwatson> oh 'eck
<apw> am i going MAD ?
<cjwatson> no, there'll be a constant size somewhere to adjust
<apw> oh one of those
<cjwatson> include/grub/offsets.h, crank GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART up until it works
<cjwatson> should only be a tiny bit to account for the code size increase
<apw> cjwatson, yeah slammed in 24 whole bytes of space
<ohsix> wasn't there something you can do to keep the display/console alive to spam you during wakeup? does that not work with kms/the non-vesa drivers?
<cjwatson> oddly, it compiled here without that change
<apw> cjwatson, wibble
<apw> +  //gf_invert[0] = 0;
<cjwatson> I'll clean my build tree and try again
<apw> thats the only other change i think i am carrying
<cjwatson> is that needed?  valgrind didn't pick that up
<apw> cjwatson, its commented out
<cjwatson> ok
<apw> i noticed it wasn't initialised in my testing, but i suspect its never used
<cjwatson> probably not.  I agree this is mathmo code
<apw> you can just tell its an implementation of some equasion ... it feels like RSA key generator code
<matahari> hi all
<matahari> After an apt-get upgrade, update-initramfs -k all -u -v is hanging. Last line of output is: Adding module /lib/modules/2.6.35-24-generic/kernel/fs/udf/udf.ko ;apt-get hang up on upgrade, and i had to run dpkg --configure -a , but it hook up at generating the initramfs... Do you have any hints what i could try or even a fix? Thanks!
<apw> matahari, not heard of that before no
<apw> you could try stracing it to see what it is doing
<matahari> how can i do that?
<ohsix> apw: stock ubuntu kernels can do pm_trace right? i just tried it and the rtc was still set to wall time
<kees> \o/ resize2fs corrupts filesystems in natty!
<matahari> apw: stacktrace is hanging as well; this is the output: http://pastebin.com/qJpwaPWc
<apw> matahari, you need -f on strace i suspect
<apw> cjwatson, that turned my grub into an instant reboot
<cjwatson> hmph.  well, EOD here ...
<matahari> apw: okay, now i see much more :-) actually it is hanging with repeating the following output all the time: http://pastebin.com/yzcAdBW4
<apw> cjwatson, yeah same here, same place same channel tommorrow for the next thrilling installment
<apw> cjwatson, of course it just exploding may be indicative that the memory scratch is pointing to is not a good place
<ohsix> yea nothing from the rtc thing,c an i assume waking up didn't fail? something after waking up is locking it up?
<apw> ohsix, very very hard to tell in all honesty
<ohsix> hrmph well i need it fixed, haven't got any work done most of the month :|
<apw> have you tried logining into the machine remotly to see if it is alive?
<ohsix> if the keyboard lights and stuff don't work when i hit caps lock and the drive doesn't make any noise, it's already dead, no? i can try that though
<ohsix> no on the network after unsuspend
<matahari> apw: now - after 15minutes strace is still hanging at that line.... :-( Do you have any ideas what i can do further?
<ohsix> [    0.612174] acpi device:02: hash matches
<ohsix> i'll have to dig some more later; i dunno why that was in dmesg actually, bbl
<matahari> apw: well, i'll try to reboot now - let's see what happens...
<kees> is upstream bugzilla down?
<kees> ooh, back now
<lamont> oh mighty kernel diziens: someone got a minute to 'splain md*/stripe_cache_size to me and save me digging in the source later?  (If you're gonna dig, don't bother - I'm just trying to save myself the reading effort)
#ubuntu-kernel 2010-12-21
<dsto> Hello, would you mind to help me moving this bug to the correct package? meta-package "wireless backports generic" depends on a kernel level matching package which is currently missing in the repo. Bug 445931, thanks, dsto
<ubot2> Launchpad bug 445931 in linux (Ubuntu) "linux-backports-modules-karmic not installable, dependency problem (affects: 3) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/445931
<apw> dsto, moved
<dsto> apw: thx
<apw> dsto this bug is a karmic bug, yet your symtoms are maverick
<apw> dsto, are you sure this bug still exists?  the archive is showing a consistent set versions wise
<apw> dsto, though the versions are -24 not -23 in the archive right now
<dsto> apw: I've seen it this morning, will try on another machine. sec
<apw>      linux | 2.6.35-24.42 | maverick-updates | source
<apw> linux-backports-modules-2.6.35 | 2.6.35-24.15 | maverick-updates | source
<apw> both are 35-24, so if you have -23 your kernel would be out of date
<apw> i am supprised that there wouldn't be a -23 of both currently though as they should be held for --security
<apw> linux-backports-modules-2.6.35 | 2.6.35-23.13 | maverick-security | source
<apw> so that should be in the pool and available.  hrm
<apw> dsto, it is possible the packages were promoted t
<apw> this morning to -updates and the publisher published half of the updates, if the rare cases that occurs it normally only persists for an hour
<apw> so it may be resolved now
<dsto> apw: I confirm, it's gone at 2.6.35-24 level. 
<apw> dsto, great, thanks
<apw> i'll clean up that bug
<dsto> fine, thank you 
<apw> dsto, yeah its an issue with the way the publisher works, if a package is promoted at exactly the wrong moment an inconsistent package set can be published for an hour, which is confusing
<dsto> the good part: I did not open a new bug and we were able to clean an old one ;-)
<apw> dsto, indeed :)
<dsto> pleasure having worked with you, take care, have a nice day. 
<apw> you too
<apw> cjwatson, ok confirmed ... adding that memset turns grub into a hard reboot on both warm and _cold_ reboots
<apw> cjwatson, so i assume that that buffer is the issue
 * apw goes restest with the memset in but the buffer at 0x09...
<cjwatson> apw: so I think that may well just mean that we got past one bug only to hit another
<cjwatson> apw: and probably means that my valgrind test wasn't extensive enough
<cjwatson> though odd for it to break cold reboots
<apw> cjwatson, i suspect that for it to break cold it is not something valgrind can see, i suspect there is something we care about in the area
<apw> cjwatson, normally we only damage a small section of it, the memset is splatting a far larger chunk and the symtoms are catestrophic, breaking grub itself
<cjwatson> rebooting at run-time usually means a unhandled trap - something that would ordinarily a segfault would be sufficient
<cjwatson> anyway, let me beat on it for a bit relative to the upstream code and I'll see what I can come up with
<cjwatson> if it's breaking cold reboots now then that should be accessible with kvm
<apw> cjwatson, sounds good, i have other issues to poke sadly
<Keybuk> I'm noticing a pattern here
 * apw is all ears
<Keybuk> brcm80211 works on days with a 'u' in them
<Keybuk> wl works on the other days
<apw> nice, a solution for every day :)
<Keybuk> except for the weekend, brcm80211 works all weekend
<Keybuk> (I actually expect it's something to do with the WiFi router)
<Keybuk> wl's failure mode on some is never to lock to a channel, despite being associated, and bounce between 2.4Ghz g, n and 5Ghz a & n
<Keybuk> brcm80211 works on those, but it's failure mode on the routers that wl seems to work fine on is ... to kernel panic
<apw> Keybuk, the joy of having two drivers
<apw> at least they are concentrating resource on the open one
<Keybuk> yeah
<Keybuk> the best plan at the moment seems to be to have brcm80211 blacklisted and use wl
<Keybuk> but then manually switch if wl isn't working
<Keybuk> because at least then you switch when the wireless is poo
<Keybuk> rather than reboot after a kernel panic and switch in a hurry
<apw> Keybuk, did you need to do anything special to get brcm80211 working in general, firmware etc ?
<Keybuk> I just grabbed the source from git
<Keybuk> fiddled with the Makefile to make it build against the maverick kernel
<Keybuk> and grabbed the firmware out of git
<apw> Keybuk, ahh on maverick
<apw> ok as the driver is built by the looks of it in natty
<Keybuk> yeah, I'm staying on maverick this cycle
<Keybuk> the firmware for it was in the "linux-firmware" git repo
<apw> cool
<Keybuk> actually checking my history
<Keybuk> I was git clone'ing that
<Keybuk> but since I was on wl at the time, in the end I cheated
<Keybuk> and installed the brcm80211-firmware package from Debian
<apw> heh ... got it to blammo in about 10s ... sweet
<apw> Keybuk, heh enabling the brcm driver seems to stop my lappy booting
<Keybuk> heh
<Keybuk> like I said, the failure mode of that driver is a kernel panic
<Keybuk> (or hang)
<apw> cirtainly not ready for prime time in natty 
<czr> hughhalf, thanks for the ftdi-regression kick btw
<Keybuk> hmm, here's an interesting gmail test
<Keybuk> if I tag all of LKML with one label
<Keybuk> and I tag certain people with another
<maco> they get two tags
<Keybuk> if those people post to LKML, does the entire thread they post in end up under the other label
<Keybuk> or just their posts?
<maco> in imap or in gmail interface?
<Keybuk> gmail interface
<maco> entire thread
<Keybuk> win
<apw> yeah its all thread based as far as i know, 'conversations' sorry
<cjwatson> apw: you're right, grub_memset doesn't act the way I thought
<cjwatson> apw: http://paste.ubuntu.com/546286/ is no longer in a reboot loop for me - can you see if it fixes your problem?
<cjwatson> (more or less the same as before, just with 'for (i = 0; i < n; i++) chosen[i] = -1;'
<cjwatson> )
<tgardner> cjwatson, apw is out for a bit. he should be back in an hour or so.
<cjwatson> no rush
<apw> cjwatson, will do
<cjwatson> ta
<apw> cjwatson, how funny we are back to the one combination i didn't test
<cjwatson> heh, and the one I asked you not to test earlier
<cjwatson> oh well
<apw> cjwatson, shit happens every day, can't worry about such things that is for sure
<apw> cjwatson, reality is if my machine compiled this thing faster i would have tested it, so i blame h/w
<apw> cjwatson, preliminary result is positive ... need to 100% confirm i have the right kernel bits but looking _good_
<cjwatson> whee
<apw> cjwatson, what _does_ grub_memset actually do as it doesn't set memory?
<cjwatson> I got an ack from upstream for the previous version as well, so I don't think I need to get a separate ack for this one
<cjwatson> it *does* set memory, it's a standalone memset
<cjwatson> obviously there's some subtle typecasting mistake I missed, but I'm not really interested :)
<apw> so really the question is why does it blow its brains out with memset and not with the loop
<apw> fair enough indeed
<cjwatson> this code is clearer anyway, as you observed earlier
<apw> yeah it would need to be well large to make any significant difference we might care about
<cjwatson> apw: shall I reassign bug 686705 to grub2 + me, then?
<ubot2> Launchpad bug 686705 in linux (Ubuntu Natty) (and 1 other project) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 seemingly due to nx-emu patch (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/686705
<apw> cjwatson, ok stock kernel reboots just fine with that fixed grub
<apw> so 'Tested-by: Andy Whitcroft <apw@canonical.com>'
<apw> Sarvatt, about ?
<Sarvatt> apw: yeah
<Sarvatt> apw: http://paste.ubuntu.com/546286/ ?
<cjwatson> committed upstream
<apw> Sarvatt, i have some binaries for that if you could test
<Sarvatt> sure thing! save me a year long compile :)
<apw> cjwatson, yes all yours on the bug
<cjwatson> Sarvatt: wuss
 * Sarvatt digs out that machine
<apw> http://people.canonical.com/~apw/misc/grub/ ... -pc and -common for i386 in there ... work on my box :)
<apw> Sarvatt, yeah she isn't a quick build, about 15 mins here
<Sarvatt> oh nice, it apparently hangs after a few days powered off too :)
<cjwatson> you can always edit debian/control before building and comment out all the binary stanzas except grub-common and grub-pc; that speeds it up a fair bit
<apw> Sarvatt, hrm!
<cjwatson> random memory contents I suppose
<cjwatson> not a huge surprised
<cjwatson> *surprise
<apw> cjwatson, normally the bios clears it doesn't it?
<apw> you'd hope anyhow
<cjwatson> I wouldn't like to rely on that
<apw> but yeah it is odd it works reliably the first time if anything ... and perhaps it doesn't :)
<cjwatson> wouldn't it take ages anyway?
<apw> cjwatson, well it does on large machines yes
<cjwatson> in bios terms
<apw> though they have to as its all ECCd so has to be cleared to be used
<apw> so perhaps not any more with small machines
 * apw reboots that machine for the 4th time
<apw> sucessfully!
<rsalveti> apw: seems we're still missing a meta update for omap 4, the new kernel is there already but it's not being pulled by default
<Sarvatt> apw: dingding we have a winner! :)
<Sarvatt> 3 reboots fine so far
<tgardner> rsalveti, which release?
<apw> Sarvatt, thank $deity for that
<apw> cjwatson, ^^ i think we have it nailed
<rsalveti> tgardner: latest is linux-image-2.6.35-1101-omap4, and meta is 2.6.35.1100.1
<tgardner> rsalveti, then you mean natty
<apw> tgardner, natty
<rsalveti> tgardner: oh, sure
<cjwatson> apw: hooray
<cjwatson> merging down the line through Debian experimental now
<apw> cjwatson, we were lucky to find that one
<tgardner> rsalveti, ok, gimme a bit
<apw> tgardner, thanks
<cjwatson> yeah
<apw> cjwatson, i think i mostly noticied it cause they had also mucked up the size bit
 * apw happily closes that one on his todo list
<rsalveti> tgardner: sure, thanks
<Sarvatt> apw, cjwatson: thanks a ton \o/
<cjwatson> reassigned to me then
<apw> kees, ^^-- seems that the 'NX issue' is indeed a grub bug and now fixed
<apw> cjwatson, well i learned a lot about grub2 (that i'd rather not have known) and had practice with quilt patches in debian, so overall worthwhile
<tgardner> rsalveti, uploaded linux-meta-ti-omap4_2.6.35.1101.2
<rsalveti> tgardner: great, thanks a lot!
 * apw invokes marjo
<cjwatson> sigh, "attempt to move .org backwards" only happens with gcc-4.4 not gcc-4.5, that explains why I didn't see it when working upstream
<cjwatson> evidently gcc-4.5 generates slightly smaller code
<kees> apw, cjwatson: \o/ so glad you guys found that. *whew* nice work. :)
<apw> kees, i did think that i was going mad indeed
<apw> cjwatson, that explains things
<apw> -#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xc90
<apw> +//#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xc90
<apw> +#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xca8
<apw>  
<apw> -#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x6f8
<apw> +//#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x6f8
<apw> +#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x710
<apw> cjwatson, ^^ i used that on mine
<kees> apw: I bet! I spent a few hours comparing the NX patches between maverick and natty trying to see any differences early on. :P
<cjwatson> the growth is 20 bytes so I think I'll make it 0x70c
<cjwatson> just to parallel that exactly
<apw> cjwatson, sensible
<apw> you do need to move both i think
<cjwatson> yes, you're right
<cjwatson> hm, wonder if it needs to be eight-byte-aligned
<cjwatson> doesn't look like it, I think four-byte-aligned will do
<apw> cjwatson, i'd be supprised if its not 4 or cache aligned ... ie 8 sounds unexpected
<cjwatson> the code uses .p2align 2 in various places which is 4 bytes
<cjwatson> ok, fixed that upstream too
<apw> cjwatson, round and round :)
 * tgardner --> lunch
<tgardner> apw, I see 2.6.37-rc7 is out.
<apw> tgardner, excellent will suck that up now, as i was about to do an upload
<tgardner> apw, looks like it wasn't more then an hour orso ago
<apw> tgardner, can't have been indeed as i updated about 2 hours ago to see myself
<apw> tgardner, perfect timing, this means i can get the cciss bug uploading
<apw> and unblock cert
<tgardner> apw, I don't think its mirrored yet. I'm not getting the -rc7 tag
<apw> tgardner, i get mine from master.k.o and it is there :)
<tgardner> cool
<apw>    b0c3844..90a8a73  master     -> linus/master
<apw>  * [new tag]         v2.6.37-rc7 -> v2.6.37-rc7
<tgardner> apw, do you know anything about the ALSA c-o-t-d builds?
<apw> tgardner, hmmm, no not really i think they are bjf's fun arn't they
<tgardner> apw, well, he's got the right perms on his zinc repo, so I was able to push an ABI bumper commit.
<tgardner> hopefully the automated scripts will pick it up
<apw> tgardner, ahh i see ... they run on tang i think
<tgardner> apw, do you suppose he pulls from his zinc repo?
<apw> tgardner, may i suggest you add the subject to the rally agenda, so he can document/transfer the knowledge
<tgardner> apw, what a good idea :)
<apw> tgardner, ok not tang then as he only makes the isos there
<tgardner> apw, dang, linux-meta_2.6.35.24.29_source.changes rejected again. wtf?
<apw> bubble
<hughhalf> czr (belatedly - you're welcome)
<tgardner> apw, I think I've lost interest for the day. see you in my AM
#ubuntu-kernel 2010-12-22
<czr> hughhalf :-)
<Kano> hi apw , when will rc7 be ready for mainline?
<apw> Kano, a couple of hours at least, seems there was some blockage due to fookage at kernel.org
<lamont> apw: so that ich10 thing we weree playing with smb on... (hardy)...
<lamont> I suspect that so long as it sees the disk, we're good, right?
<apw> lamont, blimey that seems like a long time ago, they were missing completly right?  so yes if you can see them then things must be good
<apw> lamont, can you remind me the bug number?
<lamont> we didn't have a bug number yet... missing PCI(?) ID
<apw> did smb or i make the test kernels, and where where they
<apw> (should help me find the original branch)
<lamont> http://people.canonical.com/~apw/lamont-ich10-hardy/linux-image-2.6.24-28-generic_2.6.24-28.83~lamontich10v201012031333_amd64.deb
<lamont> and smb threw together a random initrd that matches it
<apw> lamont, nice i should be able to find that
<lamont> sadly, that means that my initrd believes that I have a german keyboard, which makes the flaky kvm even less useful to me... WTF is the | key??
<apw> lamont, i presume you want than in lucid?  for that we need a bug for the SRU are you able to ubuntu-bug it for me?
<apw> lamont, i _think_ its something like altgr-7
<lamont> I need it in haryd
<apw> (as in rightgr)
<apw> lamont, same deal, and clearly hardy from the version number, doh
<lamont> unless you want to give me a working xen in lucid....
<apw> lamont, i would love to, but i think working xen is going to be n or o
<lamont> and yeah, once I confirm that I'm really happy, then I'll file the bug and push for the SRU
<lamont> 'zactly
<apw> lamont, sweet
<lamont> which means ppa builders are all hardy until at least then
<apw> lamont, i wonder, if we get it say in O then maybe Lucid+O backport will work for you
<apw> but i guess we wait for comfirmation that the xen as merged is actually useful
<lamont> yeah - merged will definitely give us an idea of when
<apw> lamont, heh my hardy tree is on the branch with that patch still ... i obviously do little to that
<lamont> apw: got a reference for me to stuff in the bug report, or would you just like the bugnumber and add it  yourself?
<apw> yeah i don't really need anything in the bug, just the number when you are happy
<lamont> [  122.278637] scsi 0:0:0:0: Direct-Access     ATA      ST3500320NS      SN04 PQ
<lamont> I do believe we done found a disk.
<apw> as soon as i have that i can get it on the kernel-team list for review
<apw> that does indeed look promising
<lamont> [  119.770221] hub 8-0:1.0: USB hub found <-- do we have enough USB, I wonder?
<apw> do those things have much usb in em?
<apw> i assume your keyboard is
<lamont> it's some random phat box in the DC - I'm on the serial console... and yeah, that many USB ports is not terribly surprising
<apw> these days they put additional hubs in in an area of the board rather than run cables, somehow its cheaper
<lamont> 24GB of ram, linux claims '8' processors, X5570 2.93GHz Xeon ('tever) w/8M cache.. these could be suitable builders
<lamont> which source package? 'linux'
<lamont> ?
<lamont> cool.  we did do the name switch that long ago
<tgardner> lamont, dapper is the last one with the version in the name
<lamont> tgardner: yeah, but I really care very little about edgy-gutsy
<lamont> well, less than "very little", actually
<lamont> dapper I do have some care for, at least for another 6 months
<tgardner> lamont, I have a similar level of concern
<lamont> in other news, for whatever reason, the maverick kernel running on lucid seems to make Xserves happier (ppc64-smp)
<lamont> tgardner: I believe we are on exactly the same page
<tgardner> lamont, so, the mutex race (or whatever it was) on PPC has gone away?
<lamont> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693401
<ubot2> Launchpad bug 693401 in linux (Ubuntu) "hardy kernel lacks support for ICH10 controller in Intel Server System SR1600UR (affects: 1) (heat: 6)" [Undecided,New]
<lamont> tgardner: I have completely forgotten what the particular failure is, beyond it filling the display with backtrace - well past any meaningful content, mixed with my abject failure to figure out how to get the *(^)^) box to use a serial console
<lamont> apw: you update it with fix info, and I'll +1 it when you poke me
<apw> lamont, will do
<apw> lamont, details of the fix are in
<lamont> and my +1 is in
<apw> lamont, ok the patch is up for review
<apw> it should be eligable for the next stable update
<czr> tgardner, tracking the ftdi-issue, any ideas on the timeframe ofor 32.27 on hardy?
<czr> s/ofor/for/.
<tgardner> czr Lucid will get uploaded to -proposed likely sometime first week in Jan
<czr> cool. will take it for a spin then.
<tgardner> czr: I don't think the issue exists in Hardy. 
<czr> ah. my bad :-). lucid I meant
<czr> using hardy for now because lucid is unusable.
<kees> tgardner: er, so what's the state of the kernels in -updates? some have CVEs.
<tgardner> kees, um, I'd have to check which ones got promoted. 
<kees> tgardner: I guess I'm worried about process -- the security team was not notified about it :( they need to go to -security too with USN publication.
<kees> lucid and maverick got promoted
<kees> and maverick is an ABI bump'
<tgardner> kees, I'm not sure sconklin was ready to have them promoted, but I guess the archive admins did it anyways. lemme check
<tgardner> kees, Lucid 2.6.32-27.49 was promoted to -updates and _does_ contain CVE, and it was also built in the non-virtualized PPA. You're right in that its promotion to -updates should have been coordinated with the security team. I assume the same is true of Karmic and Maverick
<kees> tgardner: yeah, though karmic doesn't seem to have been promoted yet. I'll ask in email, since pitti started a thread on that.
<apw> anyone know if pitti still about ?
<Keybuk> is he not on leave this week?
<Keybuk> kees: here/
<kees> Keybuk: well, I tried to make a minimal testcase, but it doesn't fail. this is bug 693510. I assigned it to upstart for now since it's not obviously a kernel bug yet.
<ubot2> Launchpad bug 693510 in upstart (Ubuntu) "child paused by SIGTSTP fails to cause wait() to report WSTOPPED (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/693510
<Keybuk> which version of upstart?
<kees> 0.6.7-1 with natty kernel
<Keybuk> right
<Keybuk> I've just built that on the maverick kernel
<Keybuk> and it passes
<Keybuk> so back to linux, I'm afraid
<kees> Keybuk: does my testcase match? because it passes on natty
<Keybuk> it's hard to tell
<Keybuk> because you've not really given any information
<kees> ?
<Keybuk> well
<Keybuk> an ssh into the machine that's failing to run the test suite would be nice ;-)
<kees> you don't have natty?
<Keybuk> no
<kees> let me construct a tunnel, gimme a minute...
<Keybuk> one of the differences is that the test case lets the child go first
 * tgardner --> lunch
<Keybuk> (or at least forces them to run in parallel)
<kees> adding sleep(1) to the parent doesn't seem to change anything
<kees> Keybuk: see privmsg for tunnel details
<stenten> Hi, does someone mind telling me how to set gfxpayload=text easily for testing a bug? Can I just put that in the parameter line in grub after 'quiet splash'?
<LLStarks> ogasawara, i've done a fair amount of testing and i believe that there is no future for the iwl3945 driver: http://pastebin.ubuntu.com/546765/
<LLStarks> oh wait, she's not here
<LLStarks> at any rate, i believe that the continuing regressions of the driver warrant a serious discussion with intel. i don't care if ipw3945 is revived/forked or if iwl3945 is rewritten. something needs to be done.
<ohsix> LLStarks: theres some power curve stuff thats being integrated into the drivers as time goes on, did you try checking out rssi and seeing if its flagging between bit rates
<LLStarks> rssi?
<ohsix> it's the number that you see for signal strength, it's kind of opaque and depends on the driver but you can use it to check for relative signal strength
<ohsix> the bit rate on the connection changes dynamically based on signal conditions and what the driver decides to do; sometimes it can get pathological and bounce between say 54mbps and 11mbps, you'll get better behaviour if you lock it to the lower bitrate, but if there are changes that are making it less stable those should probably be looked at
<LLStarks> why are there no userland controls that prevent that?
<ohsix> to prevent the flagging? it's something the driver is supposed to or is assumed it will do appropriately
<LLStarks> brb, i'd like to illustrate a point.
<ohsix> but the point of mentioning it was so you could watch rssi/bitrate (with wavemon) and see if its stable
<LLStarks> even with iwl3945, a 54Mb rate connection will not exceed 1Mb in actual speed
<LLStarks> that's the problem
<ohsix> ah
<LLStarks> wen yi is pretty much the only guy working 3945 drivers
<ohsix> there are some counters you can read for that too
<ohsix> for excessive retries and stuff, it could be just that the rate limiting algo changed
<LLStarks> i need a way to test all of this without senseless kernel rerolls
<LLStarks> compat-wireless splices are iffy
<ohsix> you could stash the .ko from the compat-wireless builds for each version you're testing
<LLStarks> true. and i've done that.
<LLStarks> i could back as far as i wanted if i so desired.
<LLStarks> not sure how far back the git goes though.
<ohsix> heres some info on the rate limiting stuff most things use and its inputs/tweakable stuff, i don't know what intel's stuff actually does with respect to this however http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel
#ubuntu-kernel 2010-12-23
<LLStarks> ohsix, is there any way to force compat-wireless to just build in the iwlwifi folder? the flags suck and still force everything else to be built.
<LLStarks> ohsix, you can't bisect a folder? can you?
<ohsix> yea, you can restrict the bisect to files in a directory, or to a single file
<LLStarks> ohsix, can't because of unmarked tree files
<LLStarks> *untracked working tree files
<psusi> ok, so I have a reproducible bug where the kernel gets stuck in the uninterruptable state.  the output of sysrq-w isn't detailed enough to be very helpful.  any suggestions on where to proceed from here?
<psusi> maybe a way to get the full call stack with parameters?
<jk-> psusi: sysrq-t ?
<jk-> won't have parameters though...
<jk-> that should have the same output as W, but include all tasks
<psusi> it's in the D state so w identifies and dumps it... t shows the same info just for all processes doesn't it?
<psusi> yea
<psusi> I don't need the other tasks... just trying to get more details on what the blocked one is doing
<jk-> the backtrace should give a decent amount of info, could you pastebin it?
<psusi> sure
<psusi> http://pastebin.com/6Yc5Ke1D
<psusi> all I can figure from that is that dmraid is issuing some kind of ioctl and device-mapper is waiting for something
<jk-> psusi: could you file a bug and include this info?
<psusi> I'm actually investigating an existing bug #666577
<ubot2> Launchpad bug 666577 in dmraid (Ubuntu) "dmraid fails on start with ICH9R under RAID 5 (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/666577
<jk-> looks like dmraid is waiting for another thread to finish with the device, or something is refcounting wrongly
<psusi> should I file a new one or just add linux to this one?
<psusi> I got the original user to attach the raid metadata and I compiled dmraid with the testing option enabled, and set up loop and dm devices to simulate his disks and then tried to activate like he did... got the same results, only I could see that the task was stuck and hit sysrq-w
<jk-> try sysrq-t too; that may show a task that holds a refcount to the device
<psusi> ok.. let me reproduce it again
<psusi> jk-, weird, starts off looking like: http://pastebin.com/wvifq9g9
<jk-> psusi: I think you're missing some of the earlier lines of that dmesg output, could you copy from a little earlier in the log?
<psusi> jk-, updated with the whole shebang
<jk-> same URL?
<psusi> yep
<psusi> err... wait, no... http://pastebin.com/xYR4bwhx
<jk-> looks better :)
<jk-> so you're getting errors beforehand?
<psusi> nope... dm-9 seems to be the new device it is trying to create
<psusi> and it seems to still exist... it's an error target
<psusi> hrm... I wonder if udev is doing something to the newly created device that is triggering a race condition
<LLStarks> ohsix, i've done.
<LLStarks> *done it
<LLStarks> i found the commits
<ohsix> nice, what was it?
<LLStarks> 1402364162afbaac1b8a74ee21aeb013e817ac7d or a6866ac93e6cb68091326e80b4fa4619a5957644
<LLStarks> i'm going to do a compat-wireless splice and test them
<ohsix> the commit messages look interesting
<LLStarks> i'd place my bets on 1402364162afbaac1b8a74ee21aeb013e817ac7d
<LLStarks> now for the waiting game. by now, every single dev on lk wireless general has seen my message.
<xclaesse> FYI, pcie_ports=compat option at boot fixes the kworker issue I have in natty
<xclaesse> I had same issue with maverick but process was kslowd
<xclaesse> https://bugs.launchpad.net/bugs/662946
<ubot2> Launchpad bug 662946 in linux (Ubuntu Maverick) (and 2 other projects) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 39) (dups: 2) (heat: 212)" [Medium,Incomplete]
<xclaesse> someone should set that bug as affecting natty too
<xclaesse> latest working kernel is lucid :(
<po4> hi room
<apw> tgardner, thats better, now by the fire :)
<tgardner> apw, wow, that didn't take long
<apw> tgardner, no indeed, the traffic is awsome
<apw> quite how i don't know though, it was supposed to be the worse of the year
<tgardner> apw, timing is everything
<tgardner> apw, pushed 'UBUNTU: [Config] Added autofs4.ko to -virtual flavour' to natty master-next
<apw> tgardner, cool thanks
 * apw eyes a gin and tonic
 * tgardner thinks apw should be _fondling_ a gin and tonic
<LLStarks> why is git.kernel.org so slow?
<apw> LLStarks, generally or instantaeously ?  there is no obvious load on the machine which serves it
<LLStarks> slow for cloning and gitweb
<LLStarks> and i have a 30mbit conn
<mjg59> LLStarks: Likely because the Android source release was last week and it's hosted on the same servers
<LLStarks> GINGERBREAD!!!!!!!!! CURSE YOU!!!!!!!!!!!!1
<apw> heheh
<LLStarks> "503 - The load average on the server is too high "
<apw> LLStarks, heh i miss read the machine name ...
<mjg59> apw: master.kernel.org isn't used for general serving, so the load there is probably much lower
<apw> mjg59, indeed, should have thoguht of that :)
<LLStarks> btw apw, i'm closing in on a fix for the iwl3945 speed issues that were introduced in the maverick cycle between 2.6.35-rc2 and rc3.
<LLStarks> well, not a fix, but a specific commit that can be reverted.
<apw> LLStarks, nice, what you found?
<apw> tgardner, ^^#
<LLStarks> down to 4 candidate commits.
<apw> nice
<apw> i assume you are bisecting
<LLStarks> a6866ac93e6cb68091326e80b4fa4619a5957644
<LLStarks> yes
<LLStarks> 1402364162afbaac1b8a74ee21aeb013e817ac7d
<LLStarks> 7d47618a2ade0cb6d8a0b2597029c383c1662fa0
<LLStarks> 6db6340c42d027b6364d49fa99d69019aca24de4
<LLStarks> i  can only assume a6866 is the culprit since its the largest
<LLStarks> or 7d4
<LLStarks> rather
<LLStarks> i'm trying to narrow further, but i hate kernel compilation. is there an easy way to compile iwlwifi on its own without splicing patches into a compat-wireless tree?
<tgardner> apw, saw that earlier this AM on the wireless mailing list
<apw> LLStarks, not that i know of, i generally just do full rebuilds every time
<LLStarks> can i offload the build to a farm or something?
<apw> LLStarks, i have a build machine i use at home for them
<LLStarks> hopefully, it be sufficient to pull a 2.6.34 release commit for compat-wireless and then patch upwards towards the bug.
<LLStarks> but even then, compat-wireless pisses me off since intel/iwlwifi driver selection builds everything but that directory.
<LLStarks> god. android needs its own vcs repo server.
<LLStarks> i never see vanilla kernel releases bog down the server this bad.
<apw> tgardner, right have gin and tonic in hand ... so am going to call it a day
<kees> apw: that's the way to start the holiday :)
<Keybuk> apw, kees: that's the way to start the working day too
<kees> Keybuk: heheh
 * jjohansen lunch
<Keybuk> yofel: thanks
#ubuntu-kernel 2010-12-24
<jjohansen> iback on later
<pmatulis> apw: any idea on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/688703 ?
<ubot2> Launchpad bug 688703 in linux (Ubuntu) "[lucid] netxen_nic driver and ethernet bonding broken at boot time (affects: 1) (heat: 12)" [Medium,Triaged]
<Sarvatt> mjg59: viewsonic put out their kernel source for the g tablet, a 3mb patch :) http://www.viewsonic.com/gtablet/support.htm
<ohsix> any standouts?
<mjg59> Sarvatt: http://mjg59.livejournal.com/131682.html (30 minutes ago)
<mjg59> I know all
#ubuntu-kernel 2010-12-26
<ilmari> huh, what happened to ppa:kernel-ppa/mainline?
<ilmari> ah, it never existed, why did I have that in sources.list.d?
#ubuntu-kernel 2011-12-19
<ronj> Hi, I'm coming for help to provide the debug info requested by Herton on https://bugs.launchpad.net/bugs/904569 . In the mentioned guide ( https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug ), I fail to complete step 1.4 ( sudo apt-get install linux-image-$(uname -r)-dbgsym ) because, as confirmed by a quick lookup in synaptic, there is no such package as that (-dbysym is only available till 3.0.0-12). What can I do to still provide the information
<ronj>  requested? Thanks.
<ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed]
<ronj> I'll be away but will read answers in a few hours and followup. Cheers.
<RAOF> ronj: You'll find the dbgsym packages in the ddeb repository, I believe.  wiki.ubuntu.com/Debugging/DebuggingProgramCrash
<ronj> RAOF, yes I installed this repo and updated my sources list
<ronj> however, the only -dbgsym I have then is 3.0.0.12 , which I guess won't help to isolate my issue on 3.0.0.15
<RAOF> Oh, oneiric-updates
<RAOF> I'm not entirely sure if they go into the ddeb repository.
<ronj> Herton seemed to suggest so. OK I'll wait for his answer on the LP bug
<ronj> thanks for the heads up
<ronj> good night
<ppisati> morning morning... :)
<apw> ppisati, moin
<cking> brr, chilly today
<apw> cking, yeeks 2.8c thats ... frigic
<apw> id
<cking> yup
<cking> wife took kids out and turned off the heating. 
<apw> OW
<cking> I wondered why it was cold in the office
<apw> heh, no wonder
 * ppisati -> away for 10mins...
<ppisati> "
<apw> "?
<_ruben> quite a meaningful quote :)
<apw> indeeeed sir
<ppisati> screen keystroke
<ppisati> the kexec patchset for arm is around ~70 patches
<apw> ppisati, kexec patchset, fixing what ?
<ppisati> kexec on arm
<ppisati> at least on omap4
<apw> how did it end up that broken
<ppisati> it never worked there :)
<ppisati> well
<ppisati> it's a "framework" patchset from rmk (how to properly reset the zillions of different arm boards)
<ppisati> plus
<ppisati> 6/7 patches for kexec itself
<apw> do we use kexec there at all?  is it being asked for ?
 * ogasawara back in 20
<arges> tgardner, got a wireless question for you. on someones machine, if they do modprobe -r iwlagn / modprobe iwlagn, they get 'FATAL: Module ucode_alternative=/lib/firmware/iwlwifi_6050_4.ucode not found.', but the file with s/_/-/ is there. Would this be a configuration issue, or indicative that the ucode file isn't correct? What would be the next thing to check? Thanks
<tgardner> arges, seems like the filename might be borked. what kernel version ?
<arges> tgardner, oneiric 3.0.0
<tgardner> arges, I'm thinking typo in the kernel
<arges> tgardner, would dmesg reveal that? i'm thinking of trying modinfo iwlagn, but not sure where else to look
<tgardner> arges, I'm checking drivers/net/wireless/iwlwifi/iwl-6000.c
<tgardner> arges, '#define IWL6000_FW_PRE "iwlwifi-6000-"' looks right.
<apw> tgardner, be suspicious of processing applied to the command line to convert the names of modules, which is needed
<apw> arges, http://people.canonical.com/~apw/misc/lp842560-udev/
<ogasawara> apw: thanks for doing meta.  I'm going to send out the email/post to blog assuming you haven't started already.
<apw> ogasawara, in the middle of it :)
<ogasawara> apw: heh, sweet.  carry on :)
<apw> ogasawara, good for me to practice on voices
<vanhoof> ppisati: heya
<ppisati> vanhoof: what's up?
<vanhoof> ppisati: was just curious what the official story is for omap3 in precise, it looks like theres still a build around, but just wanted to see if it'll for sure still be around :)
<ppisati> vanhoof: i hope so :)
<ppisati> vanhoof: no, seriously, no one officialy said we are going to demote it, so if i think it'll still be supported
<cking> apw, https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-power-management
<Atlantic777> Hi! How can I see default ubuntu kernel config?
<apw> Atlantic777, you get it with your kernel, in /boot
<ppisati> vanhoof: i heard linaro people are talking about leaving it behind, but AFA Ubuntu is involved, din't hear anything
<apw> http://www.hardwareanalysis.com/content/topic/17881/
<vanhoof> ppisati: ack, thanks for the info
 * tgardner -> lunch
<GrueMaster> tgardner: I hope you are the one to ping.  I am seeing an issue with oneiric linux-generic amd64 not installable from proposed.  Did linux-image-3.0.0-15-generic get pulled?
<bjf> GrueMaster: please file a bug
<tgardner> GrueMaster, bjf: did some binaries get pocket copied to universe again ?
<herton> bjf, hmm may be because some debs went into universe (http://archive.ubuntu.com/ubuntu/pool/universe/l/linux/), maybe shank bot running that time wasn't updated with code to check component mismatch
<herton> tgardner, looks like that's the case
<bjf> SpamapS: ^
<bjf> skaet_: ^
<GrueMaster> bjf: Looks like the kernel was pulled from -proposed, but the meta is still there.
<bjf> GrueMaster: we never pulled the kernel, it seems the kernel went to universe
<GrueMaster> It did?  netinstall was failing with -proposed enabled.  Trying with it disabled.
<brendand> bjf - hi
<brendand> bjf - hypothetically speaking, if we found a problem with CPU offlining would it hold up the SRU?
<tgardner> brendand, bjf is really out until Jan 3.
<brendand> tgardner - ah, cheers
<brendand> tgardner - hey, is a quick chat about iperf ok?
<tgardner> brendand, sure
<brendand> tgardner - we just got a big run of iperf done in the Montreal lab. maybe 20 systems, something like that
<brendand> tgardner - the median seems to be ~40Megabits p/s
<tgardner> brendand, I assume you're talking wifi ?
<brendand> tgardner - our setup is an iperf server sitting behind a router connected by ethernet
<brendand> tgardner - and the systems are talking via wifi to the router
<brendand> tgardner - this is 802.11b/g
<tgardner> brendand, 40Mbit is pretty good for G
<brendand> tgardner - we've got a few stragglers down at sub 10Mbit p/s
<brendand> one as low as 3 Mbit p/s
<tgardner> brendand, yeah, thats dropping pretty low. any disconnects ?
<brendand> tgardner - none evidenced. no dropped packets either
<tgardner> brendand, it could be that the rate selection algorithm in use by that particular driver is not very good.
<brendand> tgardner - heh, yeah - it's an atheros
<tgardner> brendand, hmm. IIRC it uses Minstrel and ought to do better then that. This is Precise ?
<brendand> tgardner - yeah
<tgardner> brendand, Atheros gets a lot of development. I'm surprised its tat slow.
<tgardner> brendand, if you start a bug and dump the HW specifics as well as the AP brand/model and setup I could hassle upstream about it.
<brendand> tgardner - ok. thanks
<brendand> tgardner - bug 906527. Still waiting for an apport-collect and the router details
<ubot2> Launchpad bug 906527 in linux "Toshiba Tecra A11 with AR928X Wireless Network Adapter has poor wireless performance" [Undecided,New] https://launchpad.net/bugs/906527
 * tgardner -> EOD
#ubuntu-kernel 2011-12-20
<caribou> morning,
<caribou> did someone hear about an Oneiric kernel issue wrt KVM ?
<caribou> Everytime that I start an Oneiric VM, it fails to shutdown properly & I end up having to 'virsh destroy' the instance
<caribou> I don't see that with any other version
 * apw waves
<apw> ppisati, about ?  do you normally prepare uploads for herton for natty/ti-omap4 and lucid/fsl-imx51 or do they do them ?
<ppisati> apw: i do
<ppisati> kexec on arm? just 75 patches away from master, but it works now! :)
<cking_> ppisati, yay well done!
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ppisati> "
<Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
<Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
<GrueMaster> I see new SRU kernels in the pipeline for ARM systems.  For me to be able to test them for publishing before EOY, they need to be available before this Thursday, 22 Dec.  Otherwise I won't be able to get to them until 3 Jan.
<apw> GrueMaster, yeah doko is very keen to have them in -proposed so they can put them on the buildds
<apw> GrueMaster, these carry the mmap fix, though i am inclined to say if they pass light testing from you, we get them tested for that bug by putting them on a buildd and testing the affected package build
<apw> GrueMaster, actually i think doko has a quick test for the fix rather than that java nightmare you were using
<Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
<apw> Pietjepuk, in general not easy to solve from just that information no
<apw> Pietjepuk, is this with some kind of extra backport modules from somewhere?
<Pietjepuk> this is trying to modify the cx231xx driver for use with a new device...
<apw> Pietjepuk, it looks like the detect probe failed and the driver didn't cope with its own probe function failing ... poor driver i'd suggest
<Pietjepuk> So I understood wrong in assuming that if I appoint a (useless but not empty) value this will not occur ?
<Pietjepuk> this is used in a function I do not need in the driver ... a tuner init... the whole function can be deleted for my purpose, but I don't know how...
<ppisati> brb
<apw> Pietjepuk, it is likely the driver will use the pointer you return
<Pietjepuk> Allready tried just to comment it out (http://pastebin.com/x5s7WWsW line 682-717), but this returns an error, seems cx231xx_tuner_callback is used lateron allso... 
<apw> many other drivers have no tuner so there must be a way to say that
<Pietjepuk> ... I allready tried swtching usb id's... no matter which device in the code I use I get the same error... Allso if I select one which has a tuner.. ( but of course I connect the wrong device afterwards... )
<apw> but you are definataly into very specific media tuner knowledge, so you are probabally going to get more useful help on their channel than here, we are more generalists really
<Pietjepuk> apw: ... you are probably right, but I thought this would be an easy thing to get out of the way... obviously it's not.... (They sugested I put it in their ML .. but I'm kinda to impatient maybe...)
<apw> without the h/w in hand and a firm grasp of the framework here and of C you are in a world of difficulty really
<Pietjepuk> Think I'll have to go with the mailinglist then.... Thanks for your time !
<GrueMaster> apw: Sorry, had to step out for a bit.  The testing I do is mostly automated, and only takes 3.5 hours at this time for most systems (imx51 & dove are quicker).
<GrueMaster> So the time it takes to run is mostly irrelevant.  I have a qrt test that fails w/o the mmap fix, so the results should be fairly quick.
<GrueMaster> My only problem is I will be out of state starting Friday, and won't be able to do the manual tests for SRU (which take ~5 minutes, but need to be hands-on).
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Jan 03, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> GrueMaster, yes with luck you should have testable images by 09:00 GMT, even if they are just in the c-k-t PPA, and in -proposed as soon as i can get an AA to hit buttons
<mustafa_> Hi everyone,  i want to join kernel team to contribute the development
<mustafa_> what should i do?
<JanC> say around longer...
<JanC> stay*
#ubuntu-kernel 2011-12-21
<psusi> linux-libc-dev says it's source is linux, but the control file in the kernel sources does not list that package.  What gives?
<brendand> why would a system fail to resume when suspended using pm-suspend, but not when suspended via indicator-session's 'Suspend' option?
<brendand> wouldn't they be the same?
 * apw yawns
 * cking offers coffee to apw
 * apw bites cking's hand off at the wrist
 * cking shudders
<apw> yumm
<apw> cking, good this morning, other than the stump ?
<cking> hard to type now
<apw> hazzard of the job
<cking> heh
<apw> working with flighty crazies 
<apw> with, Es, ... trying
<ppisati> cking: you made it to engadget, did you see it? :)
<cking> ppisati, yep, been tracking the hits over the past 36 hours
<apw> cking, do you get ping back information from your blog ?
<cking> yep
<cking> it's been hit by pcworld, engadget, reddit, thevargut liliputing and more besides
<cking> * thevarguy 
<cking> got 1.2K hits yesterday
<apw> heh cool
<apw> are they asaying anything sensible or making a molehill out of it
 * apw wonders why pcworld even has a blog on this subject given they don't do ubuntu on anything
<cking> apw, generally I think they are quoting my blog well, but maybe getting peoples hopes up a bit too high
<apw> yeah people won't get we are talking 5% saving at best on 20% of systems, ones they don't have
<apw> oh can i watch
<cking> it's predicated on people also verifying that the various fixes actually don't break anything and also all the bugs I'm filing are going to get fixed
<Kano> hi, whats up with the mainline server?
<ppisati> apw: uhm
<ppisati> apw: CVE-2011-2918
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2918)
<ppisati> bug 834121
<ubot2> Launchpad bug 834121 in linux-ti-omap4 "CVE-2011-2918" [Medium,Fix committed] https://launchpad.net/bugs/834121
<apw> ppisati, what about it ?
<ppisati> apw: see pvt
<apw> Kano, whats wrong with it?
<Kano> did not respond
<brendand> anyone here who i can ask about the status of the Oneiric SRU?
<cking> hrm, I can't seem to access any web content from zinc, including getweb pages, is it just me?
<cking> apw, ^ can you access any webby pages on zinc?
 * cking wiggles some wires
<apw> cking, nope, will poke is
<Kano> cking: mentioned that over 1 h ago already
<apw> yep didn't see your reply as it wasn't highlighted and was talking in another channel
<apw> Kano, cking, should be alive again now
<Kano> yes,seems to work again
<joshhunt> i know this isn't ubuntu-specific, but i figured i'd ask - i'm trying to understand how the route cache/table works for ipv6 - does anyone have a good reference? the old o'reilly book appears to only discuss ipv4 (unless i have an old version)
<brendand> jsalisbury - hi
<jsalisbury> brendand, hello
<brendand> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
<ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed]
<brendand> is this going to prompt a respin?
<jsalisbury> brendand, hmm, I'm not sure.  Still need to get the cause sorted out.  
<brendand> jsalisbury - do we know if it's a regression between 3.0.0-14 and -15, or haven't arrived there yet?
<jsalisbury> brendand, yes, it appears to be a regression between -14 and 15.  Thats what all the bug reporters state.
<brendand> jsalisbury - we're behind on our certification testing because we have an unmanned lab
<brendand> jsalisbury - what would people think if this was pushed into the new year?
<jsalisbury> brendand, that's a good question.  I'm away next week, but I'll continue to work on the bug for the rest of this week.
<arges> cking, apw: if i change debian.natty/config/config.common.ubuntu, check it in, then build a kernel will those config options be preserved when building the debian/ubuntu way? or perhaps a wiki I should be looking at for this newbie stuff
<brendand> jsalisbury - i'm just speculating. herton and bjf aren't here so can't ask them directly
<apw> arges, they will be the stating configuration options if that is the place they appear originally
<jsalisbury> brendand, right
<tgardner> arges, the ultimate .config is constructed from the various files in debian.master/config
<apw> arges, fdr genconfigs will make a CONFIGS directory with the configs it will use.  after changing anything in configs you should run fdr updateconfigs
<apw> arges, the former is a convienience to see the configs before waiting on a build
<arges> ok
<arges> so which config files take precedence? if I wanted to add a CONFIG_ for debugging, should I add it to the debian.natty/config/ or debian.master/config directories?
<arges> i think i can figure it out from here though. thanks guys
<tgardner> arges, add it to the confiig for that particular flavour, then run updateconfigs
<apw> cking, found that blueprint thing for you, in email
<cking> apw, cool, what is it referring to then?
<apw> arges, the configs for any branch is independant on that branch, debian/debian.env tells you which branch you are on
 * cking reads the reply, doh
<apw> cking, detail in email, too long for here
<apw> cking, there is a commandline tool mentioned in that commit to change it, assuming you have one of course
<cking> got it - I know what to do
<cking> thanks, I couldn't figure out what was meant in the bp after all this time
<apw> cking, yeah i sat an looked blankly at it for some minutes myself, and mid writing "no idea close it off" i remembered
<cking> I've been puzzling over it for the past week on-and-off trying to recall what it meant ;-)
<apw> cking, no idea if you actually have kit with such a thing in it of course, so it may be moot
<cking> apw, I do, I'm tinkering now
<apw> this is where we find you can save 8w by turning down the wick
<cking> cat /proc/cpuinfo  | grep epb 
 * cking now kicks off some soak tests to see if the MSR magic does any good
<GrueMaster> bjf: Will my updating the SRU tracking bugs before Regression-testing=confirmed screw up your scripts or the process? Now that the imx51 (Lucid) and omap4 (Natty) kernels with the mmap fix are in -proposed, I have started my test run.
<tgardner> GrueMaster, the stable team is out for the holidays
<GrueMaster> Figures.  :P
<GrueMaster> I am running the tests now, but I don't want to screw up the bug tracking automation by premature posting.  I can wait to officially check my box, and just vocally post results here.
 * tgardner -> biab
<apw> GrueMaster, i think i would expect the most likely failure would be for shank-bot to move the thing back to Confirmed when it thinks you should do the testing
<GrueMaster> apw: ok
<apw> and well, if it doesn't cope they can figure it out :)
<apw> GrueMaster, as this is a reasonable thing to do, you may be (in theory) wasting your time if testing done and then a revert was needed sort of thing, but a reasonable scenario that the tooling should cope with
<apw> there is so little in these that i doubt we will have any trouble
<GrueMaster> Yea, I don't foresee a regression or other issues.  I'm just getting pressure to test them asap, but I also want to do it right (not just install and run a simple mmap test to call it good).
<apw> very reasonable indeed
<cking> hrm, that MSR test really don't show up anything, when idle and fully loaded. That's a question to answer for 2012 now :-(
<maxime_> Hi, are there any plan to provide mainline linux-source*.deb packages along the headers and image ones in kernl-ppa ? see my detailed question here: http://askubuntu.com/q/89542/7567 Thanks !
<apw> maxime_, looking
<apw> maxime_, dkms doesn't normally need the source tree, normally it uses the 'headers packages' which contain the build infrastructure for out of tree objects
<apw> maxime_, indeed dkms is trigggered when both the linux-image and linux-headers packages are finally both installed ?
<maxime_> apw, that's also what i thought but installing the package still complains
<apw> installing which package ?
<apw> maxime_, ^^
<maxime_> apw, it's a package to get alps touchpad supported. Check this on askubuntu please
<maxime_> apw, is it okay to post dmks complains here ? not used to irc, sorry ^^
<apw> maxime_, ok that looks like a standard dkms package from seth, so i would be very supprised if it needs the source package to work
<apw> sforshee, ... does you dkms package for the alps touchpad require the full source package to work ?
<maxime_> apw, this is the last message i get : Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed.
<apw> maxime_, and which packages did you install ?
<apw> maxime_, and can you pastebin the entire log please
<maxime_> apw, see http://pastebin.com/szbT8rxQ
<apw> maxime_, ok and which packages from the mainline kernel archive did you install
<maxime_> apw, list of kernel packages i installed : http://pastebin.com/fvsQx1GK
<maxime_> after downloading them at http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc6-precise/
<lamont> why is it that my system keeps noticing that it has wireless?  (every 5-10 minutes?) it pops up a new box to type the wpa2 passphrase into
<cyphermox> lamont: on precise?
<lamont> oneiric
<cyphermox> ok
<cyphermox> then I'm not sure. is it N / iwlagn?
<lamont> stock oneiric, 12:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
<cyphermox> ogasawara: tgardner: fyi, my patch was rejected. it's been a few days already, but I keep forgetting to let you know
<tgardner> cyphermox, no surprise.
<tgardner> lamont, that driver has some issues, to put it mildly.
<cyphermox> tgardner: heh
<lamont> tgardner: heh
<lamont> which makes it no less annoying
<tgardner> lamont, I've got the same HW in a MacBook Pro. NetManager keeps trying to connect, which is why you get the WPA dialog.
<cyphermox> right
<cyphermox> is it connecting successfully at all, or just keeps trying to authenticate and timing out?
<tgardner> lamont, I suggest you disable wireless for now, or get an external wifi gizmo.
<tgardner> cyphermox, never authenticates IIRC
<cyphermox> ok
<lamont> tgardner: the alternate solution is to (yet again) type in the wpa passphrase so that it successfully connects, and then it stays there until someone decides that powercycling the WAP is the solution to their networking issues
<lamont> I'm totally going to stuff that thing in the ceiling where they cannot find it
<tgardner> lamont, where you is? at home ?
<lamont> tgardner: office space I took down with some friends, in town.
<tgardner> lamont, ah. well isn't AP power cycling simply matter of training? you should be able to prevail, especially over such a select group :)
<lamont> tgardner: tbf, the old netgear AP did have a strong tendency to fall over on large downloads
#ubuntu-kernel 2011-12-22
<apw> lamont, if you always get asked on reconnect I found on upgrade to oneiric (i think) i managed to somehow end up with two entries for the same network name in the NM database, that meant it always used the wrong one until you typed in the right one which it correctly wrote over the right one, but continued to load the wrong one on boot.  removing both and lettting it make a fresh new one fixed it up 
<apw> for me
<maxime_> apw, any clue about my yesterday question, if dkms incorrectly ask for the full kernel source or if i should install the source ?
<lamont> apw: thanks for the tip.  I shall check into that
<apw> lamont, luck with it
<tgardner> apw, what was the tip ?
<arges> apw, tgardner : whats the easiest way to find if a particular patch has made it into lucid/natty/oneiric? should i check the git logs of my trees, or is there a web tool ? thanks
<tgardner> arges, I typically look ni my local git repos for that release
<arges> tgardner, so you check everything before the tag of the latest release? how do I tell what version in the mainline / proposed? 
<tgardner> arges, grep on 'git log --prettyprint=oneline' ?
<tgardner> git describe --contains SHA1 ?
<arges> tgardner, jsalisbury just pointed me to the kernel versions webpage, thanks for the help!
<jsalisbury> np
<apw> tgardner, oh just that in the past i have found that i got two entries for the same network in nm, which made it always use the wrong password until you entered it.  deleting both then sorted it out
<tgardner> apw, ah, editing the wireless connections. I kind of wish NM had a "flush" button.
<arges> tgardner, was looking at : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317, when will this SRU be released? 
<ubot2> Launchpad bug 902317 in linux "Lucid update to 2.6.32.50 stable release" [Undecided,Fix committed]
<arges> for lucid
<tgardner> arges, sometime in January guess
<arges> tgardner, ok. 
<apw> tgardner, yeah in there.  it seemed that it used the wrong one to find the password then wrote it to the right one when you entered it, so then it worked until you s/r or whatever, then it broke again
<brendand> tgardner - sudo rm -rf /etc/NetworkManager/system-connections
<apw> arges, yeah nothing much will move forward until after the 3rd over there unless there is huge whining and gnashing
<tgardner> apw, my travel laptop seems to accumulate connection info. I see brendand has posted a handy flush mechanism.
<brendand> whoopsie. don't do that :)
<brendand> i meant /etc/NetworkManager/system-connections/*
<brendand> i.e. everything in it. DON'T delete the directory itself :)
<arges> apw, understood.
 * jsalisbury thinks the passwords stored in the /etc/NetworkManager/system-connections/* files should be encrypted :-/
<brendand> jsalisbury - you need to be root to view the files, soooo
<jsalisbury> brendand, that's true
<tgardner> brendand, think theft, loss, etc
<jsalisbury> or giving the wrong person sudo privs
<brendand> tgardner - sure, but all OS's have a way to view the stored keys
<brendand> i know OSX does anyway
<brendand> not saying that means it's a good idea :)
 * jsalisbury just hates and/or loves seeing passwords stored in plain text :-D
<brendand> jsalisbury - to be fair i thought precisely the same thing :)
<tgardner> yeah, seems like it ought to be stored in the key-rimg
<tgardner> key-ring*
<brendand> tgardner - i could swear it used to be. cyphermox?
<tgardner> yeah, it used to ask me for my key-ring password all the time
<brendand> tgardner - in most cases, if they have your root password they're going to be able to unlock the key-ring though, right?
<brendand> i assume we're talking about the case of somebody stealing your laptop with the root password somehow obtained and then using your wifi
<tgardner> not if that stuff is stored encrypted
<tgardner> brendand, how about if the just boot with a live CD, then mount the drive and look at the cleartext password.
<jsalisbury> or the laptop owners works wifi ;-)
<jsalisbury> s/works/place of employment/
<brendand> tgardner - can you view files owned by root with a live CD?
<tgardner> brendand, of course.
 * brendand is curious now
<tgardner> brendand, try 'sudo su -' from a Live CD terminal
<brendand> jsalisbury - i wanted to ask if there's anything i can do to help with the Suspend bug in the Oneiric SRU. Any ideas yet what hardware it's limited to?
<jsalisbury> brendand, if you can reproduce the bug, it would be great if you can test some kernels I build in the bisect process
<brendand> jsalisbury - yeah, that would be the trick. we haven't reproduced it on any certified systems.
<brendand> jsalisbury - i'll have a look at the bug and see if i can get any leads
<jsalisbury> brendand, ok, if you get to the point where you can reproduce the bug it would be great to have you test some kernels.
<jsalisbury> brendand, The bug reporter confirmed the issue happens between mainline v3.0.12 and v3.0.13, so I'm building a test kernel halfway between the two that will be tested next.
<brendand> jsalisbury - where does that map in ubuntu kernels?
<jsalisbury> brendand, well it tells us the bug was introduced in a mainline commit and not an Ubuntu specific patch.
<brendand> jsalisbury - ok. i guess that's good info. i'm just wondering does that mean it only is in the -proposed kernel or could it have been in 3.0.0-14 too?
<jsalisbury> brendand, It appears to only be in the -proposed kernel and not in -14
<brendand> jsalisbury - very good
<jsalisbury> brendand, indeed.  It makes me wonder though if this bug reporter realizes he has -proposed enabled :-)  I'm going to ask.
<jsalisbury> brendand, So to more clearly answer your question on how this maps into Ubuntu kernels, the bug existes in: 3.0.0-15.24 but not in: 3.0.0-14.23
<brendand> jsalisbury - thanks
<cyphermox> brendand: it was, now is in /etc/NetworkManager/system-connections on purpose; since connections are usually system-wide. if you make it per-user it will still end up in the keyring
<Kano> hi, found one commit that breaks suspend on some systems (incl. one of mine)
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
<ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed]
<tgardner> jsalisbury, ^^
<jsalisbury> tgardner, Kano, Thanks!
<jsalisbury> Kano, I'm running a bisect now, can you provide the SAH1?
<tgardner> jsalisbury, its in the bug
<jsalisbury> tgardner, awesome.  Thanks, Kano!
<tgardner> jsalisbury, be95a75a786d05896e8f12ad374fc5ab88232682
<apw> heh ... just replied to jsalisbury's email not realising the info in the bug was 1m old ...
<apw> thanks Kano for the bisect
<apw> jsalisbury, i say revert that and put some test kernels out and lets confirm it fixes the remainder of the reporters
<Kano> apw: best update to 3.0.14 as it is out
<apw> jsalisbury, as that will give us something to let them chew on over xmas
<jsalisbury> apw, sounds good
<tgardner> jsalisbury, you should also notify stable and tglx when you get results
<apw> Kano, so 3.0.14 is also ok ?
<jsalisbury> tgardner, will do.  Who is tglx?
<tgardner> jsalisbury, Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
<Kano> apw: after you revert that 
<apw> thomas gliexner (spelling?)
<jsalisbury> tgardner, doh, :-)
<apw> ok ... so for this bit we'll just want the quick revert as its mid test and out
<Kano> apw: i mean i see no reason to test with 3.0.13
<apw> its the way the process works, if we add .14 and there is another regression we can get stuck in a loop unable to release
<Kano> whatever you want
<apw> .14 will be in the first jan one i am sure
<apw> as tim will get bored and apply it to master-next by now i am sure
<Kano> well as the problem is upstream as well i think .15 ;)
<jsalisbury> Kano, apw, the bug reporter tested upstream .12 and .13 and reports the bug exists in .13
<Kano> jsalisbury: i know, it is in every newer kernel, also 3.1/3.2
<tgardner> jsalisbury, how about 3.2-rc6 ?
<Kano> well 3.2rc6 did not boot on the problematic system. it only likes to boot on 1 out of 3 of my boxes
<apw> yeah, jsalisbury my reading of the bug is that all kernels are affected yet the title mentions generic-pae, have i missed sometihng in the bug or is the title skewed
<jsalisbury> tgardner, I don't know about 3.2-rc6.  I'll ask the bug reporter to test it.
<Kano> i just tested the revert of the bug with 3.0.14
<jsalisbury> apw, all the kernels are affected, not just generic-pae
<apw> jsalisbury, ok perhaps change the title next time you have it open else we get more dogpiling
<jsalisbury> apw, will do
<apw> ta
 * tgardner -> lunch
<jsalisbury> tgardner, I'm still building the reverted kernel for bug 904569 I should be done shortly.  I rebuilt it a couple of time to make the build process muscle memory :-)
<ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15 causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed] https://launchpad.net/bugs/904569
<Kano> hi, did anybody notice that suspend usually kills usb 3 ports (xhci-hcd)?
<Kano> upgraded a few systems with usb 3 cards (nec+via) now
<thegreyspot> Is there a PAE release of kernel 2.6 On. that I could use? Or was that never release?
#ubuntu-kernel 2011-12-23
 * apw looks out at the silence
<apw> Kano, known ongoing issue with usb3 I believe, adding the module to the remove/readd list at s/r is still the work-around
<apw> thegreyspot, there are PAE kernels of all of distro kernels.  so i assume that not the question
<Daviey> apw: Does this mean that all my USB3 devices will not work over xmas?
 * apw waves to tgardner .... sooo quiet out there
<tgardner> indeed. not much going on
<tgardner> apw, just starting to look at the ecryptfs patch
<apw> tgardner, not sure its purfect but sure looks better than what we have
<tgardner> apw, I'm remembering the befits of the git-compare script that you wrote
<apw> heh, i'd forgotten about that oen
<vanhoof> ehy guys
<vanhoof> *hey even
<vanhoof> this regression in 3.0.0-15
<vanhoof> once this patch gets yanked, will we see the abi bump (-16), or an increment to -15.nn?
#ubuntu-kernel 2011-12-25
<bullgard4> In MAC OS X the following definition applies: "http://developer.apple.com/library/mac/#documentation/musicaudio/reference/CoreAudioDataTypesRef/Reference/reference.html: "In Core Audio, the following definitions apply: An Â»audio streamÂ« is a continuous series of data that represents a sound, such as a song." Does the same definition for Â»audio streamÂ« apply to Ubuntu?
#ubuntu-kernel 2012-12-17
<apw> infinity, that'd be me
<infinity> apw: Good morning, sunshine.
<apw> ugg
<infinity> Ugg indeed.  I just woke up 20m ago.  At 1:40am.
<infinity> I think I need to find something caffeinated.
 * apw makes tea, its somewhat so
<apw> infinity, so ... anything other than the lack of a flavour component in the daemon name ?  before i go ahead and fix that
<infinity> apw: I'd remove the _lbm thing too, just make it hv_kvp_daemon_$(uname -r)
<infinity> apw: But no, the bigger thing is that I'd also like to remove the daemonisation.
<infinity> apw: (I'd like to submit a patch upstream to make it an option, but we don't have time for that today)
<infinity> apw: And a one-line sauce change for Ubuntu doesn't seem a bit deal.
<infinity> s/bit/big/
<apw> it can't be _uname-r cause it clashes with the main kernel then
<apw> it is meant to match the main kernel and have _lbm
<infinity> apw: It doesn't clash with the main kernel.
<infinity> apw: The main kernel is just daemon_$(version-abi)
<infinity> apw: Since linux-tools isn't flavour-specific.
<apw> so it is, and hense why i have only added _lbm to avoid the clash, doh
<infinity> apw: Right, so s/_lbm/-{generic,virtual,generic-pae}/ and it all works.
<apw> so the real error is that the hv thing is flavour specific in the first place
<infinity> apw: Well, the error is that it's even version-specific, but yay linux-tools.
<apw> the cost of not having an api indeed
<infinity> apw: Still, I have userspace bits that just check and prefer foo_ver-flavour over foo_ver, so that works.
<infinity> apw: And since we can assume that foo_ver-flavour only happens in lbm builds, since linux-tools will always be foo_ver, then done.
<apw> yeah that all works, but it is so very wrong really
<infinity> apw: But the bigger change here is also making their upstart job not crack, which requires a one-line patch to hv_kvp_daemon itself.
<infinity> Huh. And since my latest Intel GPU crash, B is being rendered as a capital J.  *blink*
<apw> i assume its respawning it do death ?
<infinity> Hrm?  No, it just can't track a triple-fork.
<apw> and the ramifications of that is ?
<infinity> You don't have a job managed by upstart anymore?
<apw> but it is still running ok right?
<infinity> And people write perversely incorrect init scripts that use "killall" as job control.
<apw> i am trying to work out how bad this is, not avoid fixing it
<infinity> Yeah, it runs.  But accepting this init job into main isn't something I want to do.
<apw> i assume you have the patch already
<infinity> s#daemon(1, 0);#/* daemon(1, 0); */# :P
<apw> presumably we need to add an option to change that behavior now its existed with the previous
<infinity> I was going to whip up a proper getopt-using patch for upstream that introduces a -D option, but for us, I think just knocking out the daemon() call entirely is fine, and we can submit a proper fix later.
<infinity> Given that the previous daemon doesn't work right anyway, I think we're calling this all a wash.
<infinity> I'm installing a wrapper that refuses to run the linux-tools version of the daemon on kernel << 3.7
<infinity> And you don't ship it on 3.7 yet, so...
<infinity> That covers all possible cases. :P
<apw> "shipping a wrapper" ?
<infinity> http://paste.ubuntu.com/1444907/
<infinity> dpkg-diverting the wrapper shipped by linux-tools.
<apw> shipping that in what ?
<infinity> In hv-kvp-daemon-init
<infinity> The userspace bit that enables all this junk.
<apw> and ... that is why i was asking you about divert, as i think i should be doing that in lbm to support the lbm specific versioning
<apw> but that would probabally implode in the face of multiple flavour
<infinity> Doing it in lbm is trickier, since you have more than one package shipping it.
<apw> that indeed
<infinity> Updating the wrapper in the next linux SRU would be lovely, but not an option this Monday morning.
<apw> yeah that is indeed the plan, to update the official wrapper in tools
<apw> now are we sure the pre 3.7 version is even broken on 'not azure' ?
<infinity> Is there a "not azure" hv that matters?
<apw> that we know about, likely no, ...
<apw> can we make this thing just depend on lbm somehow, i suppose not
<infinity> Wow, this thing poops in /var/opt/
<infinity> We kinda should FHSify this some day.
<infinity> Oh well.
<infinity> That's not important right now.
 * apw closes his eyes and pretends not to see
<cking> la la la la not hearing that
<infinity> Hey, at least it's not /opt
<infinity> /var/opt is so dangerously close to /var/cache, I think we'll just pretend it's fine for this week. :P
<apw> i would have not been supprised at the latter either, it is a mess.  i am not totally sure we should even build this thing in the kernel package at all
<infinity> apw: No, we probably should tear it out and build it out-of-tree from the same package that ship the init script.
<apw> i wonder if the right thing would be to rip it out of lbm and of the kernel, and ... 
<apw> that indeed
<infinity> apw: But, again, not sure there's time to change that.
<infinity> Though, if you have a recipe to build it out of tree, I'm all ears.
<infinity> Dropping the insane dependency of hv images on linux-tools wouldn't be a bad thing.
<infinity> Of course, it could actually have some vague coupling to the linux version it's built against.
<infinity> And if it does, we've lost.
<infinity>         /*
<infinity>          * Get the address of default gateway (ipv4).
<infinity>          */
<infinity>         sprintf(cmd, "%s %s", "ip route show dev", if_name);
<infinity>         strcat(cmd, " | awk '/default/ {print $3 }'");
<infinity> ^-- Surely, there's a non-shell way to do that...
<infinity> I kinda don't want to read this code anymore.
<apw> i would indeed suggest not reading it any more
<infinity> There's no way this would pass an MIR audit if it wasn't already stapled and glued into the kernel sources.
<apw> ok my understanding on kernel dependancy is that the daemon is at least "now" meant to work with any kernel newer than the one it was built against
<apw> i cannot say for sure when that might have happened
<apw> s/ahppened/ become true/
<infinity> Well, when that became true doesn't matter, if we just take the 3.7 sources and build them against 3.2, and assume it works everywhere.
<infinity> But we already have this hackish "just ship it in LBM" solution for now, let's just flavour that up and call it done.
<apw> mir> indeed when we first enabled it, it didn't do any of this IP shit or have really any external activity like this, they have growed like topsy on the side of it
<infinity> And for 3.7/raring, where you're not building it yet ANYWAY, maybe we can fix it better.
<apw> we may be building it again by now, depending if i pushed the patch to fix its build
<infinity> (PS: it not being built for raring confused the crap out of me when I went to test things)
<apw> as it confused me as well
<infinity> I saw nothing in the changelog to indicate it should be building now, but I haven't upgraded linux-tools yet either.
<infinity> Oh man, this lack of capital Bs is confusing.
<apw> just stop using capitals
<apw> ok indeed this reenable fo hv is sitting pending on one of my branches
<apw> can i assume you have taken control of the hv_init_script package in the short term, as any change to lbm needs to be coordinated with that
<infinity> Yes.
<infinity> http://lucifer.0c3.net/~adconrad/CapitalB.png <-- I have Jytes instead of Bytes.
<apw> that is well fooked
<apw> i assume you have textures mixed up somewhere in there
<apw> and its not a real J either, its a J slightly down to the left plus a slight dotty thing
<infinity> Yeah.  Still, it's pretty cool to have bandwidth measure in kilojoules per second.
<infinity> s/measure/measured/
<apw> infinity, as for building outside the kernel, i believe actually its requirement is the linux-libc-dev headers, plus linux/hyperv.h from the kernel (which is not in tose headers currently)
<infinity> Ahh, so that could just be a buglet to include that header?
<infinity> Anyhow, I suspect that's something we want for raring, and potentially to backport later, but not something we want to do in P/Q a day before their deadline for all this crap.
<brendand> henrix, is the quantal -proposed kernel being released today too?
<henrix> brendand: i think so, but not sure. apw^^
<apw> i would imagine so but it is not my call
<henrix> the info i got from brad is that both P and Q should be released today
<infinity> henrix / brendand: Both P and Q should go out today, if we get all our ducks in a row WRT testing/validation.
<b-quirk> Hi! cking, a while ago I asked you about wmi in my laptop. It turned out that these buttons are actually an unsupported synaptics hardware
<henrix> infinity: ack, thanks
<infinity> henrix: If they don't go out today, we'll end up with some cloud images built against -proposed, which won't be world-ending, but I think we can all agree that's suboptimal.
<infinity> henrix: (As the generation of said images has a hard deadline of "Really Soon")
 * henrix -> late lunch
<brendand> henrix, how will the next -proposed kernels work with the holidays?
<henrix> brendand: i expect some delay, as most (all?) of us will be out. herton, do you have any details?
<herton> henrix, well, I belive we will skip next week, and resume work on Jan. 2
<henrix> herton: yeah, that's what i would expect
<henrix> brendand: ^
<brendand> henrix, reasonable
<herton> that means new SRUs on new year only
<infinity> hggdh: Do I get regression-testing on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088979 today?
<ubot2`> Launchpad bug 1088979 in Kernel SRU Workflow certification-testing "linux: 3.5.0-21.32 -proposed tracker" [Undecided,In progress]
<infinity> hggdh: (The correct answer is "yes", FWIW)
<hggdh> infinity: yes
<hggdh> infinity: (since this is the correct answer ;-)
 * infinity throws hggdh a cookie.
 * hggdh eats the cookie and goes into a hyperglycemic crisis
<hggdh> infinity: in fact, running now
<infinity> It was a sugar-free flax cookie.
<infinity> (God, what an awful thought)
<hggdh> infinity: heh
<hggdh> infinity: I will add flash-kernel to the package list on the armada issue with updating kernel and flash-kernel at the same time; perhaps dpkg also?
<infinity> hggdh: No, it's just flash-kernel's fault.  Though it's not a problem specific to flash-kernel, it does triggers much the same as many other packages.
<infinity> hggdh: Happy to look into it post-Christmas.  Totally not a priority now, it's been like this for ages.
<hggdh> infinity: some sort of warning should be given, then. I will replace linux-armada with flash-kernel then
<infinity> Well, the only real problem is that you'll reboot into your old kernel.  It's not like it renders your system broken or anything.
<infinity> (But yes, it would be better if it didn't have this oops)
<hggdh> indeed. 
<hggdh> infinity: there is also bug 1090591 on the armada.
<ubot2`> Launchpad bug 1090591 in linux-armadaxp (Ubuntu) "armadaXP: Unable to handle kernel NULL pointer dereference at virtual address 00000000 on shutdown" [Undecided,New] https://launchpad.net/bugs/1090591
<infinity> hggdh: Fun.  Tell Jani and Ike. ;)
<hggdh> infinity: will do, but this does not sound like a critical issue, so I am passing this kernel too
<infinity> hggdh: Well, it's not a regression.
<infinity> hggdh: Looks like it could point at a rather subtly more awful bug, but if it was already there, no point holding up a CVE fix.
<hggdh> yeah
<infinity> hggdh: Can you assign that flash-kernel bug to me?  I may not end up being the person who fixes it, but I want to be reminded of it in the New Year.
<infinity> (Since, if f-k is buggy there, so is eglibc, and any number of other packages...)
<hggdh> infinity: done
<infinity> hggdh: regression testing still running for Q?
<dhanasekaran> Hi Guys I am facing  problem my machine not boot it's still showing BUG: soft lockup - CPU#10 stuck for 23s! [kworker/0:3:566] 
<dhanasekaran> How to fix this , It's Hardware issue or kerenel issue
<dhanasekaran> please guide mme guys
<hggdh> infinity: still running
<hggdh> infinity: still running, one job to finish
#ubuntu-kernel 2012-12-18
<hggdh> infinity: quantal done
<infinity> hggdh: My hero.  Just waiting on Cert now.  Thanks for fast-tracking your bits. :)
<hggdh> infinity: you are welcome
<apw> dhanasekaran, that is most likely a kernel issue of some sort
<dhanasekaran> apw: I need to update the kerenl
<dhanasekaran> apw: or some I need to pass argument in boot arguments
<apw> dhanasekaran, i cannot say with the information i have so far, i would recommend filing a bug 'ubuntu-bug linux' from a terminal
<apw> dhanasekaran, if this problem is very new (ie just started happening) then you may be able to avoid the issue by booting an older kernel
<apw> dhanasekaran, from the grub menu, and if so then we will know when it worked and when it stopped working
 * henrix -> late lunch
<infinity> henrix: Shankbot appears to have failed to set tasks on https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1087221
<ubot2`> Launchpad bug 1087221 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-21.32~precise1 -proposed tracker" [Undecided,In progress]
<infinity> herton: (I'm going to promote it anyway, but thought you might want to look into why)
 * henrix checks...
<infinity> henrix: Oh, never mind, I know why.
<henrix> infinity: and the reason is... ? :)
<infinity> henrix: Same reason the armadaxp and omap4 bugs didn't get twiddled for quantal, they were derivatives of the previous version, which never made it to the promoted state.
<infinity> henrix: In this case, a bit more subtle, since it's no longer a derivative of the previous version, but you did re-use the bug that used to be. :P
<henrix> ah, makes sense
<henrix> i guess...
<infinity> Probably not a case worth worrying about, since this needs a bit of human smarts to determine it's "okay" anyway.
<herton> henrix, yes, master-bug property on the bug should have been adjusted as well
<infinity> (As in, I wouldn't be happy with the bot having marked those two ARM kernels, better for me to look and decide it was a good idea and do it myself)
<infinity> But, sure, for the re-used bug bit, you could have fixed it. :)
<henrix> herton: ok, got it
<dobey> hi all, can anyone tell me if this upstream change is included in the recent kernel updates for quantal? http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=248138b59880a3cc69e9b7f0e06fb0caedd58305
<herton> dobey, yes, should be in the quantal kernel released to updates today
<dobey> thanks
<dobey> then i suppose either that's not the fix i need, or it doesn't work for my problem
<infinity> dobey: Or you didn't upgrade?  When he says "released today", he literally means an hour ago or so...
<dobey> infinity: i just installed the latest kernel, and rebooted :)
<infinity> Ahh, well.  Nevermind, then. :P
<herton> Indeed. if you have 3.5.0-21.32, you have the latest update
<dobey> but i'm not certain it's the right change. as dnaiel just said "fix is in drm-fixes" and from the changelog it seemed the most relevant change to my bug, which is https://bugs.freedesktop.org/show_bug.cgi?id=51983
<ubot2`> Freedesktop bug 51983 in DRM/Intel "[ivb DVI fdi link train fail] Multiple Displays not working on Core i7 3770S" [Normal,Resolved: fixed]
<infinity> For the record, I don't see that commit in the quantal kernel.
<dobey> oh ok
<infinity> herton: You may have fibbed. :P
<herton> infinity, I see it here, commit dd86e0283ca61727e133cfae73ae21779188fbb5
<infinity> I'm looking at the source, which doesn't contain that code...
<dobey> where are the branches for the linux source packages for ubuntu anyway? lp doesn't show any in bzr
<herton> dobey, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git
<jwi> infinity: looking in ubuntu/i915?
<infinity> jwi: Oh, no, looking in drivers/gpu/etc... Which seemed to make sense. :P
<jwi> dobey: if you're running ivb, that commit shouldn't make any difference.
<infinity> Do we really have two copies of the code?
<herton> infinity, strange, well it looks commited. Yes, we have now i915_hsw with haswell backports
<jwi> infinity: afaik it's the hsw enablement
<herton> infinity, at ubuntu/i915
<dobey> hmm
<infinity> Right, looks decidedly more committed there.
<infinity> That's not confusing in the least. :/
<dobey> hrmm
<dobey> well, lunch. guess i'll worry about this a bit more later
<slangasek> should I be expecting 'git clone http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-quantal.git' to work?  That's the URL listed in the source package's Vcs-Git field, but I'm getting "connection timed out while accessing".
<henrix> slangasek: maybe that's just historical, i'm not sure. looks like it's like that since lucid.
<slangasek> henrix: let me rephrase the question: I'm trying to get the package source and it's not working.  Where should I be looking?
<henrix> slangasek: the correct url should be git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
<slangasek> ok, thanks
<henrix> np
<slangasek> should I raise a bug about the broken metadata in the package?
<henrix> that's probably a good idea....
<henrix> if you do, please let me know the bug #
<henrix> i can take a look at that and fix it
<henrix> (or investigate why we're using the wrong url)
<slangasek> henrix: well, I just tried to clone from the git:// uri and that failed *too* :)
<henrix> slangasek: interesting, i pasted the url and it seems to work
<henrix> slangasek: maybe you have a different prob then ;)
<slangasek> maybe!
<slangasek> yep, works from my laptop but not from a dev box on the same network - so it's a local problem.  thanks :)
<henrix> np
<infinity> henrix: shankbot's lying about promote-to-proposed being ready.  It's confirming the task before the binaries are all in.
<infinity> henrix: (It did this for both of Andy's lowlatency uploads, which are still building/publishing)
<henrix> herton: ^^ do you think it's still the same problem we saw the other day?
<herton> infinity, which bug #?
<herton> henrix, may be, if my fix still isn't in
<infinity> 1087213 and 1090123
<apw> herton, as i was doing the task fiddling for the prepare and upload tasks i may have doen something wrong
<apw> herton, i had assumed i should mark the upload-to-ppa etc fix released when completed
<apw> was that right
<herton> apw, ah, so you set prepare-package to fix released?
<apw> yeah cause i had done them indeed
<henrix> herton: do you know where the bot is running? is it on people?
<apw> henrix, i suspect i am missunderstanding my role ... please tell me how to do it right
<apw> herton, even
<apw> i had assumed i had two roles, preparing the packages, and uploading them
<apw> and that for each i would fix release them
<apw> when done
<herton> apw, in the bugs with two roles, like this one, the right thing to do is set prepare-package to fix released, like you did, and upload-to-ppa to in progress
<apw> yeah, but then it was uploaded, so i moved it fix released too
<infinity> "If Upload-to-ppa is present, Workflow Mgr. sets it to completed (status: Fix Released)."
<apw> is that the error
<herton> apw, yes, that's it
<apw> doh
<infinity> Looks like the intended workflow is to leave it as "In Progress" and let shankbot automate the rest.
<apw> hmmm, then the task should be upload and let build ... but hey ho
<herton> apw, my first question should have been if you set upload-to-ppa to fix released... the bot does that
<infinity> Though it still feels like a bug that shankbot doesn't do the "it's all built" test before setting promote-to-proposed.
<apw> heh i was bound to break it :)
<herton> apw, may be, yes, a bit confusing
 * apw will know for next time, soz
<herton> this two roles separation is only for cases like ti-omap4 or ec2, where someone pushes to git, and other do the upload, may be lowlatency doesn't need that
<herton> apw, also you set prepare-package-meta to in progress, the bot takes care of that as well, when you have a new meta
<infinity> lowlatency may again need it in the future, once Andy's sorted out getting the studio guys to do the rebases.
<herton> oh ok
<apw> yeah mostly they will want it, probabally at least for a bit
<infinity> Anyhow, I'll just be old-fashioned and wait for visual confirmation that it's all published to the PPA before I copy, no big deal.
<infinity> I almost always double-check the bot's work there anyway, out of complete lack of trust. :P
<apw> yeah it is all a bit odd, as if the bot checked for the things to finish and boinked the promote task
<apw> it wouldn't have to care about the upload or prepare tasks at all, and i could close them
<apw> and we have nothing open while building
<herton> apw, in summary, you set prepare-package to fix release, and all other prepare-package-* and upload-to* to in progress, bot takes care when build finishes
<apw> nng, perhaps it should do prepare-package too, so one can just leave them all open
<apw> as it is a little confusing to know you have one you do something different to
<herton> apw, it's this way now because prepare-package in this 'two roles' bugs means something a bit different, it's set to fix released when the person doing it prepared the source to be reviewed so who does the upload can push into ubuntu/ and upload
<herton> but perhaps this should be refactored, may be creating a new task and stopping subverting the prepare-package task
<apw> then all the packages should be fix_released in that case, and all of the non-invalid ones used to select which to check for to handle upload-to-ppa
<apw> me having to handle prepare-package one way and prepare-package-meta another in either case is very strnage and liable to trigger wrongness
<apw> if we can eliminate that need somehow then all to the good
<apw> herton, well i think if you just disconnect the promote-to-xxx from the tasks, makingit only wait for all packages that have prepare-* tasks which are not invalid
<apw> then i could use the prepares-* either way and things still work
<apw> they would get wacked if open, as should upload-to-ppa, but if they are already closed, who cares
<apw> that would make it user tollerant
<herton> apw, not sure about this. But I think I could just make the bot verify again that really the packages are on the ppa in any case before the promote-to-proposed is set to confirmed
<infinity> That's what he just said. :P
<apw> herton, i think if the mentality for any verifiable test, like package source in the PPA (should fix release the corresponding prepare-* task), package built in ppa (close upload-to-ppa), packages in -proposed (close promote-to-ppa)
<apw> and also set the approriate next task to Confirmed
<apw> then things would flow without anyone ever getting out of sync
<apw> as if they do it then we change nothing, if they don't then we fix it for them
<herton> yeah, ok I'll implement these extra checks. But I still think that may be we should also remove the upload-to-ppa may be, and just not "overload" the prepare-package task with two meanings
<herton> and sure, everything the bot can do to fix something out of sync is good
<apw> i think then all i have to do is build and upload them and it should just fix all my tasks right :)
<herton> yes, that can be done, I'll do changes towards that. If the bug has the package version, it should handle itself with no trouble
<infinity> herton: What's the magic for making the bot and reports ignore a tracking bug?  Just invalidate all the tasks?
<infinity> herton: 1090121 and 1090120 should just be closed out, since they're rebase requests for an x86-specific fix.
<infinity> (And I'm sick of seeing them on the workflow report) :P
<herton> infinity, just closing as duplicate of any other bug should do it
<infinity> herton: Ahh, kay, I'll just dupe them to the previous ones I just released, that'll do.
<herton> yep, I was thinking of doing the same too, thanks, really they shouldn't stay open
<infinity> herton: Done.
<herton> cool, thanks
<infinity> And this pre-holiday SRU cadence is almost done.  Just two more kernels to verify.
<infinity> Which would leave us with a clean slate (and everything in sync!) going into January...
 * apw is on the verifications now
<apw> infinity, ok i have boot tested all 5 of the kernels making up the P and Q lowlatency kernels
#ubuntu-kernel 2012-12-19
<infinity> herton: So, is there a reason the bot hasn't decided that 1090123 is fit for release?
<infinity> henrix_: ^
 * infinity suspects it may relate to verification tasks, and gives up and just releases it.
<herton> infinity, sorry, it's a bug I introduced in the bot today, fixed
 * apw yawns widly
<bambee> Hi, nvidia-current does not build with linux-image 3.5.21-generic on precise  (there is a 3.5 kernel packaged on precise)
<xnox> replied to above ^ in #ubuntu-devel.
<xnox> bambee: don't cross-post same message to multiple channels.
<bambee> xnox: I just realized that this message was for the kernel team and not for the whole #ubuntu-devel channel
<xnox> bambee: meh. it's an issue between #ubuntu-x package and #ubuntu-kernel package, therefore #ubuntu-devel is the common ground =))))
<bambee> okay, noted
 * henrix -> lunch
<apw>  break-fix: 639b321b4d8f4e412bfbb2a4a19bfebc1e68ace4 local-2012-2372
<apw> henrix, for the CVE where we only have a 'local' fix, i think using the title makes most sense as it will correctly catch the later application of the real fix
<henrix> apw: ok, cool. but for 2012-5532 i guess it makes sense to use the sha1s, right?
<henrix> apw: i'm about to commit the linux-overlay file
<henrix> apw: ok, pushed the changes for linux-overlay
 * henrix -> errand. back in 15mins
<apw> henrix, yeah i think so
<henrix> apw: about the btrfs hash collision: looks like the guy that found the issue agrees with you
<henrix> apw: "Finally, the first described attack, i.e., make impossible the creation of a given file within a shared directory, keeps still valid."
<apw> yeah
<apw> henrix, ok that seems to have worked finally
<henrix> apw: ah, cool! thanks for you help figuring this out
<infinity> hggdh: Did you have plans to polish off regression-testing on 1087212 before the holidays, so the kernel SRU workflow can start with a clean slate in January? :)
<infinity> hggdh: (That's the only outstanding SRU left, though no pressure if you can't get to it, or you're already on a beach somewhere ignoring me)
<hggdh> infinity: looking it up
<hggdh> infinity: given it is already in -proposed, I am running it now
<hggdh> infinity: we usually do not look at the regression-testing bugs until they reach confirmed for us. So, as a rule of thumb, if you need one done before confirmed status, please ping me
 * hggdh wishes there were beached in the Dallas area
<hggdh> beaches
<hggdh> well, there are lakes, and there is the mud/dirt/whatever at the water front. But that is not really a beach
<infinity> hggdh: Ahh, yeah, true that it wasn't marked confirmed because it's still in the verification stage, but I figured a bit of parallelisation here wouldn't hurt. :)
<hggdh> infinity: no problems for me :-)
 * apw looks outside, time to get out of this room
<slangasek> anyone around who could talk to me about bug #1040557?
<ubot2`> Launchpad bug 1040557 in Ubuntu CD Images "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
<slangasek> In talking with Samsung, it seems likely that the samsung-laptop module is triggering this; would it be possible to disable the samsung-laptop module only on systems booted with EFI?
<jsalisbury> apw, cking If you have a chance, can you review comment #69 in bug 1040557 ?
<ubot2`> Launchpad bug 1040557 in Ubuntu CD Images "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
<bullgard4_>  /sys/devices/'LINKSYSTM:00/ exists. '~$ rgrep 'LINKSYSTM' /usr/src/linux-source-2.6.32/Documentation/ 2>/dev/null' does not produce any output. How is 'LINKSYSTM' defined?
<bullgard4_> s/LINKSYSTM/LNXSYSTM/
<hggdh> infinity: done, I guess now it is just waiting for Ike to finish
<infinity> hggdh: Thanks. :)
<achiang> jsalisbury: ping, still around?
<jsalisbury> achiang, yes
<achiang> jsalisbury: hey, could you take a look at https://bugs.launchpad.net/ubuntu/+source/linux-nexus7/+bug/1088424 ? sounds like something you could poke at... or maybe actually it should be ogasawara 
<ubot2`> Launchpad bug 1088424 in linux-nexus7 (Ubuntu) "alsa midi sequencer not available on nexus 7" [Wishlist,Incomplete]
<jsalisbury> achiang, sure I'll take a look.  ogasawara is out until the new year
<achiang> jsalisbury: ah, ok. the real question is, did the audit of ensure the n7 Kconfig matches up with ubuntu's Kconfig ever happen. and if not, how can we make it happen? :)
<jsalisbury> achiang, that I don't know off hand.  Maybe apw can answer that.  I believe he is in tomorrow.
<achiang> or vanhoof ^^
<jsalisbury> achiang, I'll keep on top of it and ping folks tomorrow when they get in
<achiang> jsalisbury: works for me, thanks!
<jsalisbury> achiang, np
#ubuntu-kernel 2012-12-20
<nevyn> I have an insanely stupid question. what is the best path to a very current kernel (really just need a very very current alsa)) on quantal?
<apw> nevyn, i assume you are saying that the quantal kernel is not sufficient for your needs.  there is no supported later kernel.  you can (and i do) run raring kernels on quantal, but you do need to manually maintain them in the face of updates
<apw> hggdh, you guys do a bunch of kvm based testing right?  had any problems with recent rarings ?
<apw> henrix, this CVE with kees patch, have we asked security to add the POC to the QR tests ?
<henrix> apw: no, i haven't done that
<henrix> i guess i should :)
<henrix> i'll ping jj about that
<apw> thanks :)
 * henrix -> lunch
<apw> henrix, this -ELOOP patch, for P doesn't apply
<apw> well without fuzz anyhow
<apw> is that to be expected
<hggdh_> apw: we are running Precise for the formal tests (and yes, we have been having issues). On my local machine I run Raring, bu not as intensive (3, 4 images per day)
<apw> hggdh_, i am seeing corrupt background in my raring vms backed by precise, all crosshatchy, wondered if you had seen similar
<apw> hggdh_, though the whole thing was precipitated by someone asking on #ubuntu-quality about kvm and implying raring doesn't boot there, which does nto match my experience
<hggdh_> apw: I have not, but most tests are automated. OTOH we are seeing failures to start the domain. I do run raring KVMs on Precise (mostly no-desktop envs), and I have had no prolems
<apw> it would be nice to try and confirm if this is a local to apw issue or a general issue with graphics in the VMs
<apw> i would expect the unity lot to be moaning a lot if it doesn't work mind you
<hggdh> apw: the failures to start the domain happen (on Precise) on all tested versions. I will start monitoring for these paiting issues
<apw> hggdh, thanks
<hggdh> yw
<henrix> apw: ah, i see. you're seeing the 'Auto-merging ...' messages, right?
<henrix> apw: i guess i mixed up all the patches
 * henrix should have sent all the patches separated, per serie
<henrix> apw: if that's what you're complaining about, i just checked that the patch applies ok (i checked against the kernel i've tested)
<henrix> apw: but i can resubmit the whole set
<henrix> apw: i'll prepare the patches again, and send them again. this time, i'll send 5 different sets (L, O, P, Q and R)
<apw> henrix, no don't bother, i have applied them all now, you can make sure they are right on master-next once my build tests finish
<henrix> apw: ok, cool.  i'll do that. let me know when you push them
<apw> henrix, but for next time, i do tend to send out one series per release when it is complex, and say in teh 0/N which ones are identicle
<henrix> apw: yeah, makes sense. will do that next time. its too easy to mess up the whole set...
<henrix> apw: thanks
<apw> neither is ideal sadly, it is just a hard problem, people don't cope with lots of anything very well
<henrix> heh, true.
 * apw bets gomeisa is howling right now
<henrix> it is ;)
<henrix> fortunatly, my build ended already :)
<apw> load of 80, not bad
<apw> henrix, all pushed
<henrix> apw: Precise looks fine. shall i check all the others?
<henrix> apw: also, want me to build test them, or you've done that already?
<apw> all build-tested, p was the most worrying, but you might pass an eye and make sure on the others
<henrix> apw: ok, will do
<henrix> apw: diff returned 0 changes from my trees, so they all look ok to me
<apw> henrix, yay brill thanks, at least i did something right today
<henrix> :)
<henrix> thanks
<apw> henrix, did you add the break-fix magic for 2012-4530 in the end?
<henrix> apw: no, not yet. thank you for reminding me
<apw> henrix, i recon a :title() will work best on that one, using local-2012-4530, and the same in the tracker
<henrix> apw: yep, makes sense. i'll check the examples and add that to that CVE
<apw> yeah so as it is a U: S: patch it won't pick up the upstream one when that comes
<apw> so we will have to be sensitive to that appearing
<apw> and switch the local-NNN to that sha1 when it arrives
<henrix> apw: ok, i'll monitor that
 * henrix hopes not to miss it...
<apw> yeah it is not idea, as it will drop off the radar probabally
<apw> as in no longer be on the matrix to remind us
<henrix> i've added that to my todo list, so i'll see it everyday in my list
<henrix> hopefully that'll be enough :)
<henrix> apw: ok, just committed linux-overlay and cve-tracker
<apw> henrix, don't see the linux-overlay pushed ?
 * henrix goes check..
<apw> and hurry, :10 is when it all kickes off :)
<henrix> apw: it should be now
<henrix> heh, its done. i had forgot to press enter in the terminal :)
<apw> got it
<apw> looks right to me
<henrix> cool
<henrix> i added the two break-fix lines: one for the SHA1 and other for the local-
<apw> yep that look plausible
<apw> we'll know at about :45
<dhanasekaran> what is kworker?  I've started seeing something called "kworker" listed recently when I run top. 
<dhanasekaran> I have server running with 32 core, it's says kworker/3:0
<apw> kworker is a thread executing code on behalf of the kernel normally, code which needs a process context to allow it to sleep or the like and so cannnot be naturally executed as kernel code
<apw> i think the /3 suffix indicates it is a per-cpu kworker thread
<apw> for cpu #3 in this case
<dhanasekaran> apw: please look my log http://paste.ubuntu.com/1452690/
<dhanasekaran> top out put
<dhanasekaran> In my case running 32 cores
<apw> yes, and only top is runnig ?
<apw> dhanasekaran, nothing apparently unsusal about that output
<dhanasekaran> apw: kworker/28:1  ? kworker/11:0 ? 28:1 what? and 11:0? what, i think 28 is mean by core and :1 means what?
<apw> do you have 32 cores or 32 threads, they may be the hyper-thread number i am not 100% sure off the top of my head
<Nafallo> apw: what class of hardware? :-)
<Nafallo> oh. nvm.
<kees> apw: hrm, which patch?
<henrix> kees: he was referring to CVE-2012-4530, with commit d740269867021faf4ce38a449353d2b986c34a67 and the -mm patch exec-do-not-leave-bprm-interp-on-stack.patch
<henrix> apw: btw, looks like the matrix has not been updated as i expected
 * henrix goes back to see what's wrong
<kees> henrix: ah! yes. I'm still hoping akpm will send that to linus.
<henrix> kees: me too :)
<kees> the other patch that went certainly helps, but doesn't strictly solve it. :) (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d740269867021faf4ce38a449353d2b986c34a67)
<henrix> kees: yes, we've applied that one for this CVE plus the -mm patch
<infinity> henrix: Hrm, the bot seems to have failed its derivative security check.
<infinity> henrix: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1087212 was a rebase including a CVE, the master bug had a promote-to-security, I thought we'd agreed that meant derivatives should also?
<ubot2`> Launchpad bug 1087212 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1612.17 -proposed tracker" [Undecided,In progress]
<infinity> (And I swear this worked on some other rebases...)
<herton> infinity, I'll take a look
<henrix> herton: thanks :)
<kees> henrix: cool, great :)
<infinity> herton: I'll leave the bug alone for now so you can look at it, but I'll release this kernel to both updates and security, as that's where it should go.
<herton> infinity, ack thanks
<infinity> (Released)
<infinity> herton: When you figure out what went wrong with it, feel free to set my tasks to Fix Released for me. :P
<apw> henrix, it seemed to not update the kteam-tools repo locally, not sure why
<apw> let it run at :20 and see then
<henrix> apw: ack, thanks
<herton> infinity, sure, I'll take care of remaining status on the bug
<infinity> herton: Danke.
<xnox> is it expected that : include/linux/version.h is now under include/generated/uapi/linux/version.h or is this "temporary" ?
<Sarvatt> xnox: intended
<xnox> Sarvatt: /me is going through pains of porting dkms module..... to this whole new uapi world order. It moved header files around as far as kernelnewbies is teaching me.
<xnox> thanks.
<Sarvatt> yeah its a pain in the butt, all the blob video drivers needed fixing too
<ohsix> it's good medium & long term :]
<xnox> this is me first time tinkering with kernel related stuff. But I guess modules is not really kernel hacking...
#ubuntu-kernel 2012-12-21
<xnox> and all of this needs to be ported back to precise when it gets the next enablemnt kernel.
<xnox> *sigh*
<infinity> ogasawara: Want to commit something to git for me so Tim doesn't have a grumpy about me uploading things to the archive to fix bugs? :P
<bipul> I have a Question which always conflict to me http://en.wikipedia.org/wiki/File:Kernel_Layout.svg  In this above pics Kernel is Directly connected with Devices and Memory , But what i know kernel is connected with cpu then via cpu it get connected with Memory and Devices
<henrix> apw: remember the -mm patch? it just got accepted into mainline.
<henrix> apw: crap! i should have waited one more day before submitting the CVE fix :)
<henrix> apw: ok, i've just updated the cve-tracker and linux-overlay with the correct sha1
<apw> henrix, heh oh well, great that you have fixed the tracker
<henrix> apw: yeah, better do it now while its fresh. next year i wouldn't remember about it :)
<apw> infinity, i can take a look at that ...
<henrix> apw: btw, is it worth submitting this fix for raring as well? i didn't as i was hoping the fix to hit raring from mainline in this merge window
<apw> henrix, well it cannot hurt to put it in R as it will simply rebase out of existance when the real fix hits
<henrix> apw: ack, so i'll send it over.
<apw> ok ta
<henrix> apw: err... that's embarassing... i've sent it already, and it's already in master-next :-/
<apw> henrix, heh, then that is good
<henrix> apw: its just the cve matrix that didn't got updated. let me figure out what went wrong
<apw> henrix, i bet the title isn't the same, U:S: prefix missing or something
<henrix> apw: no, it looks correct to me...
<apw> henrix, ok then i'll have a look in a bit
<henrix> apw: ok, thanks. i guess we can wait a little bit more, as i've just updated it with the upstream sha1...
<apw> henrix, shove the CVE number in here in the history so i can keep track
<henrix> apw: CVE-2012-4530
<henrix> apw: i'll ping you later, after the next run (at :45, right?)
<apw> henrix, sure, i am going out for a bit shortly to get some food in before they sell out, so if i am quiet that is why
<henrix> apw: no prob :)
<henrix> oh, i just realised the raring is set to 'pending' for omap4 and armadaxp...
<apw> so those are rebase yes?
<henrix> yep
<infinity> henrix: omap4 and armadaxp don't have raring kernels, unless someone's finally gotten around to it.
<infinity> henrix: I just copy the quantal kernels to raring.
<henrix> infinity: hmm, right. i just got confused looking at the CVEs matrix, as it shows them as having raring kernels
<henrix> infinity: thanks
<xnox> has the number of file-descriptors and/or inotify user_watches been historically something like 4096? looking at the current /proc/sys/fs/[file-max|inotify/max_user_watches] it's much higher (390468 & 524288 respectively)
<xnox> (in upstart we try to exhaust inotify watches & check that upstart still works correctly, but it seems like allocating 4096 watches will not do it anymore)
<infinity> This seems like it could be a good thing.
<infinity> xnox: Also, /proc/sys/fs/inotify/max_user_watches is 8192 here.  What have you done to your computer?
<infinity> (base)adconrad@cthulhu:~$ cat /proc/sys/fs/inotify/max_user_watches
<infinity> 8192
<infinity> (base)adconrad@cthulhu:~$ uname -r
<infinity> 3.7.0-7-generic
<xnox> what about file-max?
<infinity> It's high.
<infinity> 1619078
<infinity> Then again, ulimit won't ever let me hit that.
<xnox> well, I have ulimit unlimited.
<infinity> (base)adconrad@cthulhu:~$ ulimit -n
<infinity> 1024
<infinity> Again, your ulimit isn't the default setup.
 * xnox runs bog standard ext4 (on top of lvm, crypt)
<infinity> But a testsuite that relies on these things might want to try to synthesize such a setup.
<xnox> well the idea is that we should exhaust it on a current machine and having artificial caps doesn't make sense to me, we should try to exhaust until we do =)))))
<infinity> Could take a while.
<xnox> it's a very tight loop, so i would not think so.
<infinity> Can't be any worse than the glibc testcase that throws my laptop's load over 10000 (no, that's not a typo).
<xnox> nice =)
<xnox> actually, interesting to know how glibc testsuite reacts to being niced =)
<apw> henrix, did your CVE sort itself out?
 * apw bets not cause i don't think the kteam-tools auto update is working at all
<henrix> apw: nop :)
<henrix> apw: now everything's 'needed', except for the omap4/armadaxp, which are 'pending' (??)
 * apw will investigate indeed
<henrix> thanks
 * henrix -> late lunch
 * henrix reboots
<apw> henrix, you made it back ... so it turns out to be a simple issue, after much debugging (sigh), i see we are using the wrong branch, master not master-next
<henrix> apw: you mean, on the autotriage scripts?
<henrix> apw: that makes sense then
<apw> heh yeah, doh
<apw> and if you look now, its all sane again
<henrix> \o/
<apw> an hour of debugging the code, wally me
<henrix> *g*
<henrix> anyway, i'll definitely need to dig deeper into 2 scary parts: the autotriage stuff and the shankbot :p
<henrix> these are two things i've been avoiding looking at too closely :)
<apw> they are both heaps of complexity for sure
<apw> the autotriage stuff is particularly nasty to read :)
 * apw wanders off ... have fun people
#ubuntu-kernel 2012-12-22
<Delemas> Would anyone here know why I'm getting these kernel traces? It is a new Z77 based system with a pair of E1000 PCI NICs. http://pastebin.com/i0Ld5MdA
<Delemas> They happen both on the latest kernel in 12.04 and the 12.10 kernel backported....
#ubuntu-kernel 2012-12-23
<jackbrownhf> Is ther anyone available to help me to enable my backlight keyboard on my laptop ? I found this guide http://blog.mgechev.com/2012/08/19/asus-n56vz-ubuntu-12-04-en/
<jackbrownhf> cat /proc/version
<jackbrownhf> Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
<jackbrownhf> Is ther anyone available to help me to enable my backlight keyboard on my laptop ? I found this guide http://blog.mgechev.com/2012/08/19/asus-n56vz-ubuntu-12-04-en/
<jackbrownhf> cat /proc/version
<jackbrownhf> Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
<xeon-enouf> jackbrownhf: for these channels, you just need to be patient
<jackbrownhf> ok
<jackbrownhf> xeon-enouf: 
<xeon-enouf> jackbrownhf: sure, just keep checking back on occassion (watch your status bar, for highlight, for when someone uses your nickname), but not repeating ;-)
<xeon-enouf> jackbrownhf: also, in the meantime, have you done /topic and read a bit of the URL(s) posted?
<xeon-enouf> heh. the topic also mentions what i just said, heh
<jackbrownhf> lol
<jackbrownhf> right
<trijntje> Hi all, I was wondering if someone who knows a bit about the kernel could take a look at this bug:https://bugs.launchpad.net/ubuntu/quantal/+source/ubuntu-defaults-builder/+bug/1075876 
<ubot2`> Launchpad bug 1075876 in ubuntu-defaults-builder (Ubuntu Quantal) "ubuntu-defaults-builder: only quantal 64bit does not build" [Undecided,Confirmed]
<trijntje> building a localised custom iso for quantal 64 bit fails with a dpkg error configuring the 3.5.0-17 kernel, and I have no idea why
<jackbrownhf> HELP -----> https://www.privatepaste.com/3cab992392
<jackbrownhf> Is ther anyone available to help me to enable my backlight keyboard on my laptop ? I found this guide http://blog.mgechev.com/2012/08/19/asus-n56vz-ubuntu-12-04-en/
<jackbrownhf>  cat /proc/version
<jackbrownhf> <jackbrownhf> Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
<jackbrownhf> hello
<jackbrownhf> is there anybody there
<jackbrownhf> Is ther anyone available to help me to enable my backlight keyboard on my laptop ? I found this guide http://blog.mgechev.com/2012/08/19/asus-n56vz-ubuntu-12-04-en/
<jackbrownhf>  cat /proc/version
<jackbrownhf>  Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
#ubuntu-kernel 2013-12-16
<gQuigs> has anyone already investigated why the daily kernel builds aren't building? : /home/apw/COD/linux/drivers/clk/clk-s2mps11.c:63:41: error: 'struct sec_pmic_dev' has no member named 'regmap'
<gQuigs> (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc4-trusty/)
<bjf> ppisati_, bug 1248492 needs verification if you can
<ubot2`> Launchpad bug 1248492 in linux (Ubuntu Saucy) "[saucy] [armhf] use pstore to save console log messages" [Medium,Fix committed] https://launchpad.net/bugs/1248492
<phillw> Hi good people, I'm just following through https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is it fairly obvious where the PAE flag is? (kernel is i686 of 3.11.0-12) I simply need to compile it as non-PAE
<apw> phillw, look at the config differences between the pae and non-pae kernels on lucid for example
<phillw> apw: where can I find them? (It's all very new to me!)
<phillw> hi melodie I think there is a missing step between https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel "Build Environment" and the next step "Modifying the configuration"... Any hints, tips etc?
<melodie> phillw I have never talked about that
#ubuntu-kernel 2013-12-17
<hyperair> bleh i just tried creating a nonpae build, but the package build is failing with ls: cannot access ../linux-image-3.11.0-15-generic-nonpae_3.11.0-15.23_i386.deb: No such file or directory
<hyperair> =\
<hyperair> weird
<hyperair> how does one introduce a new kernel flavour?
<hyperair> aha, debian.master/rules.d/i386.mk
<hyperair> dat elusive flavours variable
<hyperair> oh gawd ccache, why won't you play properly with sbuild
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 30 minutes
<jsalisbury> ##
<kdub> sforshee, i'm trying to tighten up/fix bugs around turning the phone's display on/off (from mir's perspective), and i'm trying to get some insight into powerd... would you be the one to bounce questions off of?
<sforshee> kdub: I can try, but if the questions are specifically about the integration with unity8 then ricmm is the one who worked on that
<kdub> sforshee, okay
<kdub> sforshee, so you wouldn't know if its a hard guarantee that the system is active (out of suspend) before powerd goes and requests the display on?
<sforshee> kdub: the system can't really request the display on if suspended ...
<sforshee> kdub: if you're talking about autosuspend, then the answer is that autosuspend is disabled before powerd would request the display on
<sforshee> however, there's one possible issue that I can warn you about
<kdub> i don't really know the terminology very well in this area... to me there's 'system on' or 'system off'
<kdub> and 'system off + mir attempting to display a frame == bad'
<kdub> :)
<sforshee> so here's the case which might be problematic
<sforshee> android uses this file in sysfs, I don't recall the exact path off the top of my head, but basically it says whether or not the display device is ready
<sforshee> there's a short period on some devices after disabling autosuspend where the device might not be ready yet, so you have to wait until that file says it's ready before you try to draw
<kdub> oh, wake_lock?
<sforshee> no
<sforshee> let me look
<kdub> okay, thanks
<sforshee> kdub: /sys/power/wait_for_fb_sleep
<sforshee> I know that when powerd talked to surface flinger it waited on that file, but I don't know if that's the case with the unity8 integration
<sforshee> oh, actually /sys/power/wait_for_fb_wake
<kdub> sforshee, excellent, sounds like what I need
<kdub> let me tinker with that file to see if i can avert the problet
<sforshee> kdub: actually it looks to me like powerd still waits on that before requesting the display be turned on
<kdub> i see that in the startup, but not on every display on/off request
<kgunn> sforshee: thanks for helping kdub...this thing has been a bear
<kdub> yes, thanks sforshee
<sforshee> kdub: I know the code worked when talking to sf, and the only part that's changed is that it now calls into unity instead
<kdub> yeah, let me dig into what exactly goes on there
<kdub> in the SF path
<sforshee> good luck
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 7th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 7th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * jsalisbury makes his first s/2013/2014/ mistake
<sforshee> jsalisbury: woah, no more meetings until Dec 2014? ;-)
<jsalisbury> sforshee, an another whoops :-)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 7th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jsalisbury> sforshee, changing the month and year at the same time caused an overload 
<sforshee> I just guessed it was consecutive copy/paste errors
<jsalisbury> heh, yup
<antarus> was teh meeting exceeding short, or am I missing something?
<sforshee> antarus: our meetings are always exceedingly short
<antarus> kees: or apw how do I go about getting https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-saucy/+bug/1244627 fixed?
<ubot2`> Launchpad bug 1244627 in linux-meta-lts-saucy (Ubuntu) "Please enable CONFIG_IMA in the ubuntu kernel" [Undecided,Confirmed]
<antarus> I might have filed it against the wrong thing (I am really aiming for Trusty I guess.)
<antarus> I wonder if there is a more generic pkg name
<apw> antarus, i seem to remember that was the one which in the past has caused terrible performance issues, and so it is enforced off, and i am guessing i said we would need some benchmarks to convince us it didn't
<apw> still cause the same degredation
<antarus> apw: I think we looked and it doesn't do anything without a policy loaded
<antarus> and it doesn't load a policy by default
<apw> antarus, iirc it made osmething bigger and the effect was devistating to performance (back when we tested it before)
<antarus> (the user has to load one)
<apw> even thought it really shouldn't be ... that is my worry
<antarus> so I'm going to clone trusty and enable it then
<antarus> and boot into it..and probably break my graphics ;p
<kees> antarus: if you can show benchmarks without CONFIG_IMA, with CONFIG_IMA, and with CONFIG_IMG + policy, in a bug comment, that should be sufficient.
<antarus> kees: that is what I am doing
<antarus> I'm still curious what benchmarks you want
<antarus> do you have any recommendations?
<antarus> (io? memory? something else?)
<kees> antarus: it was memory consumption in the past.
<mjg59> kees: Also intrested in those results
<antarus> kees: ok
<kdub_> sforshee, just to pick your brain some more... do you know  why powerd sometimes sends consecutive 'display on' signals?
<kdub_> i don't know if it means something by that, or if the second 'on' signal can safely be ignored
<kees> mjg59: subscribe to 1244627! :)
<antarus> wow, I do not understand your kernel build system..
<antarus> heh
<antarus> config.common.amd64 and config.common.ubuntu
<antarus> are they merged together when the kernel is built?
<kees> antarus: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<antarus> yeah I'm following that
<kees> cool
<kees> there are scripts that do the merge, yes.
<antarus> ok
<antarus> I was confused because half of my change landed in common, and the other half in teh per-arch configs
<antarus> thanks for your patience with me
<kees> no problem! the more people can build the kernel the better :)
<pkern> If we'd get one howto out of it that it's actually current. <insert xkcd about standards here>
<sforshee> kdub_: are the flags changing? That would be my guess.
<antarus> pkern: the kernel howto is fine
<antarus> pkern: also, stop working ;p
<kdub_> sforshee, i'll check... thats kinda my guess too
<sforshee> kdub_: it shouldn't emit a new event if nothing has changed, so if it's doing that then it's a bug
<sforshee> but if the flags are changing, well, then something changed ;-)
<pkern> antarus: This is my personal IRC. o_O
<antarus> pkern: sure it is ;)
<kdub_> from my end, (mir/unity-mir) i see two on's in a row, not sure how to interpret the second one
<sforshee> kdub_: how about this: if (signal.state == on && my_screen_state == on) return;
<sforshee> ;-)
<sforshee> that is if you don't care about any of the flags
<antarus> man this build takes its sweet time
<antarus> I have 64 cores
<antarus> I can do better
<kdub_> sforshee, yeah, i'll try something like that
<Sarvatt> antarus: dont build under fakeroot, makes it take 10x longer
<Sarvatt> aka, debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 build-arch then fakeroot debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 binary-debs
<antarus> lol
<antarus> my build failed
<antarus> missing moduels tpm_tis
<antarus> god I hate the tpm
<antarus> hrm, all the other tpm modules are there, but not tis
<antarus> weird
<antarus> anyway, lunch
<antarus> Sarvatt: thanks for the tips
<antarus> I'll try em next time
<antarus> ahh I see my error
<antarus> ok so tpm_tis used to be a module
<antarus> and it can't be with IMA on
<antarus> and IMA is not able to be compiled as a module
<antarus> and so I broke the kernel abi
<antarus> oh
<antarus> dch -i
 * antarus tsks
<spideyman> Hello! does anyone have any quick tips on debugging a compile failure of: make[1]: *** [sub-make] Error 2
<spideyman> how do I get more info?
#ubuntu-kernel 2013-12-18
<hyperair> is there a script i can use to fetch the abi files of the previously built kernel?
<hyperair> or do i need to manually download the debs myself?
<hyperair> aha, found it.
 * apw yawns
 * cking offers apw a coffee
 * smb thinks about another one
 * apw drinks some tea, and reads scrolback on #ibm
<smb> apw needs danger sensitive sunglases
 * apw idly wonders why so many people are suddenly want non-pae kernels, given its been like 4 releases since we supported them
<smb> apw, Because now it the next lts
<apw> you still maintining your fork of that ?
<smb> apw, No I never was
<smb> Oh you mean last last lts... if that was this lucid thing
 * cking wonders how old non-pae cpus are
<apw> yeah weren't you building something for a via
<smb> cking, still found in x86 embedded options
<smb> cking, Like AMD's Geode
<cking> oh, the Geode, bleah
<smb> cking, Incidentally what I am currently running my firewall/router on
<hyperair> apw: because phillw leveled up his bugging skills.
<hyperair> i told him to just build a nonpae flavour, stick it in a PPA somewhere, and roll it out in a custom ISO
<hyperair> for people with prehistoric hardware
<apw> it is only like 3-4 options config wise for sure
<xnox> apw: hola! =) I have a fresh armhf-cross-toolchain-base at https://launchpad.net/ubuntu/+source/armhf-cross-toolchain-base/1.103 I've blocked in -proposed at the moment. Can it be tested at cross-compiling & booting kernels or some such?
<xnox> it's a jump from eglibc 2.17 -> 2.18, compiled with gcc 4.8 instead of 4.7
<xnox> i'll compile a few things here and check that they are roughly sensible, but more testing would be nicer, considering that kernel/armhf folks probably rely on it more.
<xnox> arm64, powerpc, ppc64el are to follow.
<apw> xnox, i am sure we can, will see what i can make up
<xnox> apw: cheers. i'll be holding it in proposed, until some positive results.
<xnox> rbasak: ^
<rbasak> A cross-compile of the kernel is probably the best test I can think of. I'm not sure I can think of what else I can test that might be useful.
<hyperair> apw: 3-4 options sounds simple enough, but to someone who is unfamiliar with building kernels, it's hardly easy.
<hyperair> and i'm having trouble digging through the packaging stuff anyways
<hyperair> https://launchpadlibrarian.net/160113188/buildlog_ubuntu-saucy-i386.linux_3.11.0-15.23%2Bhyper2_FAILEDTOBUILD.txt.gz <-- so after over 5 hours, it tells me EE: Missing modules (start begging for mercy)
<hyperair> but it doesn't say which module is missing
 * hyperair sighs
<hyperair> fml
<hyperair> i guess that means i now need to find 20GB of free space to test build this so i can do a proper post mortem
<apw> hyperair, it should list them when it saysmissing modules, just above
<hyperair>       read 4149 modules : new(0)  missing(1)
<hyperair>       MISS: /home/hyperair/src/debian/linux/nonpae/ubuntu-saucy/abi-tmp-3.11.0-15.23/tmp
<hyperair> this line?
<apw> MISS: yeah, though the crap on the end of it, seems wrong
<hyperair> oh yeah you're right
<hyperair> O_o
<hyperair> it shouldn't be /home/hyperair
<hyperair> how did that line creep into the .modules files?
<hyperair> =\
<hyperair> apw: thanks
<apw> xnox it occurs to me that i don't need this package to cross the kerenl, so i don't think it is a good test fo ryou
<xnox> apw: oh, quite.
<xnox> kernels are independant of the libc6 ;-)
<xnox> sorry about that. In my world everything needs libc6 =)
<apw> heh yeah ... doh should have thought of that before going and trying to do ti :)
<imMute> so my kernel options include "console=ttyS0,115200n8" and even though I run "dmesg -n 7", KERN_DEBUG messages aren't printed to the console - I have to run dmesg to see them.  This is not the case on my other Linux machine - what is different about Ubuntu?
<kdub> sforshee, i came up with a patch that fixes/robustifies powerd against the problem i was seeing... just for my understanding though, what is 'earlysuspend'?
<yates> why am i getting such a long delay at line 831 here: http://ur1.ca/g7wwe -> http://paste.fedoraproject.org/62960/38739154
<sforshee> kdub: earlysuspend is specific to android kernels. Essentially it's a state where some drivers have suspended their devices but the system hasn't fully suspended.
<kdub> sforshee, is it more on older devices or new devices?
<sforshee> android kernels will commonly suspend he display and touchscreen via this mechanism
<sforshee> it's mostly older devices, I belive it's more-or-less deprecated
<sforshee> but it's still common
<sforshee> as far as kernels that I've looked at go I think only the nexus 10 wasn't using it
<kdub> and when coming out of suspend, some devices will exit suspend before the system is fully active, i presume
<sforshee> but as long as we wait on wait_for_fb_wake the display device _should_ be out of early suspend and ready to use
<sforshee> the traditional suspend/resume mechanism resumes devices before thawing userspace tasks
<sforshee> but earlysuspend doesn't
<kdub> sforshee, thanks, good info
<TooLmaN> Unique bootstrap question.  I'm trying to install Ubuntu Core on a Wyse thin client with a 1GB flash drive inside.  I have everything properly installed (rootfs, kernel files, etc) and syslinux'ed the drive.  On boot I just get "boot error" like it isn't seeing the drive.  I believe these TCs are setup as a SuperFloppy?  Any tips on getting it to boot?  Thanks
<TooLmaN> oh, I setup a 100MB FAT partition and the rest Ext3
<JanC_UEFI_test> TooLmaN: what CPU is in those?
<TooLmaN> I believe x86.
<TooLmaN> That's what the Live USB drive used
<TooLmaN> I haven't tried to replicate the test in a VM yet
<JanC_UEFI_test> TooLmaN: so, the live USB booted on the TC?
<TooLmaN> yes, I used it to do all the work.  formatting, partitioning, copying files, etc.  It runs fine off the live usb
<TooLmaN> I've used syslinux for years.  Just not sure what I'm missing here
<TooLmaN> My goal is to get one TC working properly and image it to deploy to the other
<TooLmaN> others*
<JanC_UEFI_test> maybe check what possibly relevant drivers are loaded by the live USB and make sure those are available in initramfs?
<JanC_UEFI_test> although, I guess the error you see might be earlier, in syslinux?
<JanC_UEFI_test> also, drives might be numbered differently depending on which one you boot from in some BIOSes
<JanC_UEFI_test> oh, and make sure the boot partition is marked as such
<JanC_UEFI_test> IIRC I had to do that on some old WYSE TC
<TooLmaN> JanC_UEFI_test, I'll check a few.  It's a syslinux-level error
<TooLmaN> the BIOS sees the internal drive as a hard drive
<TooLmaN> This is a wyse CL50 TC
<TooLmaN> it shipped with Suse but I had 2X ThinClientOS on it
<TooLmaN> wanting to make them simple web page display appliances running into screens around the plant
<TooLmaN> I can do this with RPi's, and I have a couple up, but I don't want them going to waste
#ubuntu-kernel 2013-12-19
 * amitk is impressed how well trusty is working on a haswell with a 276 dpi screen
<hyperair> why are the scancodes from showkey -s different from the /lib/udev/keymap -i?
<hallyn_> stgraber: /win 20
<hallyn_> feh
<hallyn_> stgraber: well, current trusty kernel is not letting root open uidmaps.
<hallyn_> well, i can manually use newuidmap ...  something's wrong in lxc perhaps
<hallyn_> yup, i messed it up in one of the coverity fixes.  bad serge
#ubuntu-kernel 2013-12-20
<imMute> so my kernel options include "console=ttyS0,115200n8" and even though I run "dmesg -n 7", KERN_DEBUG messages aren't printed to the console - I have to run dmesg to see them.  This is not the case on my other Linux machine - what is different about Ubuntu?
<xnox> imMute: what is your full kernel options?
<imMute> xnox: I don't have them presently, but the only thing changed from the default was that and "console=tty0"
<apw> imMute, loglevel=7 or whatever on the kernel command line allows you to have more out there on the console
<imMute> apw: tried loglevel=7 and loglevel=8 and neither makes KERN_DEBUG messages show up
<apw> imMute, i would expect them to come out at loglevel=8, of course nothing comes out until printk is up and running so it dpeend just how early things break
<apw> imMute, and there seem to also be an 'ignore_loglevel' to turn it off
<apw> MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
<apw>         "print all kernel messages to the console.");
#ubuntu-kernel 2013-12-21
<imMute> well, the stuff I'm interested in is in a device driver which doesn't get autoloaded (on purpose) so it's only an annoyance when the system crashes and I can't run dmesg to see what happened.
#ubuntu-kernel 2013-12-22
<BenC> apw: Do you know if Tim has or will integrate linux-ppc into master?
<BenC> For trusty...
<apw> BenC, i think he wanted to chat to you about it before taking any action
<BenC> apw: Ok...I'll hold off on creating a trusty repo then
<BenC> apw: He won't be back until Jan 2nd, will he?
<apw> BenC, if you are doing the rebase to 3.13 anyhow that would be a good step either way
<apw> as you have the h/w to test it
<BenC> Very true...
<BenC> I'll hold off on uploading then :)
<apw> sounds like a very good plan indeed
<infinity> BenC: I guess you rebasing first has the advantage that you can go through your patchset, clean up, decide what you no longer need, upstream bits you forgot you were carrying, and see how tiny (and isolated) you can get your delta. :)
#ubuntu-kernel 2014-12-15
<th3s3_3y3s> Why is Left-turn back?
<PaulePanter> Hi. I want to report a Linux kernel panic with Ubuntu 14.04.1. I always was able to log in with an OpenID account into Launchpad. Now it does not work anymore.
<PaulePanter> Running `ubuntu-bug linx` I was asked to open a Web browser which is not so easy on a server without X running. (There is w3m but I think thatâs unhandy.)
<smb> PaulePanter, Hm, login to LP with openid should still work... But for filing the bug you should also be able to use apport-cli ("apport-cli --file-bug --save=<filename> linux" and then transfer somewhere with X and run "apport-cli <filename>" )
<PaulePanter> smb: I am redirected to https://login.launchpad.net/ and told I need an Ubuntu One account.
<smb> PaulePanter, Have you tried to use the email addr and pw you had used with openid. It might just be named differently ... 
<PaulePanter> I did and it did not work.
<PaulePanter> Also I logged into Google now â my OpenID provider â and it was not picked up either.
<PaulePanter> So something is broken the way that I am unable to report something right now as I am unwilling to read the Ubuntu One usage terms.
<PaulePanter> smb: Thanks for your help.
<catbus1> Hi, do I understand it right that the module signature verification is enabled in trusty kernel from the CONFIG_MODULE_SIG* values: https://wiki.ubuntu.com/Kernel/Configs/SaucyToTrusty
<catbus1> does it prevent me from updating an inbox driver downloaded from the hardware vendor? ex, intel ethernet driver? 
<apw> catbus1, it is enabled but not enforced, so it will whine and taint when you load such a thing
<catbus1> ok, thanks. 
<hallyn> sforshee: apw: I filed bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402834 
<ubot5> Launchpad bug 1402834 in linux (Ubuntu) "fuse filesystems get disconnected on container exit" [Undecided,New]
<sforshee> hallyn: I'll look into it
<hallyn> thanks
<hallyn> (note this happens without user namespaces)
<sforshee> ack
#ubuntu-kernel 2014-12-16
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 6th, 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.
<dannf> hm.. is there a reason for the --timeout=120 on the git daemon on zinc? makes it impossible to clone to systems w/ slow i/o
#ubuntu-kernel 2014-12-17
<infinity> zequence: Merry Christmas: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1403242
<ubot5> Launchpad bug 1403242 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> zequence: Note that Andy and I did the previous one, so make sure you're picking up our changes and not working in dirty local trees.
<hallyn> i've got a potentially stupid question about 'cat' and stat(2).  When I cat a fuse file, it returns empty unless the getattr() function returns a non-zeor size.  But stat(2) on /proc/cpuinfo returns 0 size, while cat /proc/cpuinfo certainly works.
<hallyn> just wondering what cat is actually looking at
<hallyn> bc it seems to be treating procfiles differently
<infinity> hallyn: That may actually be a question about fuse.
<hallyn> true
<hallyn> yeah actually i think i get it,
<hallyn> if you do open(file); fseek(f, 0, SEEK_END); ftell(f); then fuse returns what it got fro mgetattr, i bet
<hallyn> though no, you get 0 in a procfile, 
<hallyn> but yeah i'm sur eit's something fuse is doing
<hallyn> so i'll just return the max possible size and screw it :)
<apw> hallyn, have you strace'd cat in both cases to see what cat actually does ?
<hallyn> apw: oddly, in both caess it does open; fstat;  and with /proc/cpuinfo you can see fstat returns st-size=0.  but it goes on to read the write # chars.  no seek/ftell.  magic
<apw> hallyn, and for your fuse it does what, open; fstat; seek; ftell; fails ?
<cking> the code that does the stat with st_size=0 may of course be ignoring that field, it may be stat'ing the file for other reasons
<hallyn> apw: no, it doesn't seek/ftell.  does the exact same things as with /proc
<hallyn> cking: right, but the point is that when my fusefs returns st_size = 0, then 'cat somefile' always returns nothing,
<hallyn> even though my read() is defined
<apw> right it is fstating the file, not for its size, but to check that in and out arn't the same
<hallyn> when i use a non-zero, then it does
<hallyn> in and out?
<apw> is it chekcing the major minors and the like
<apw> it is making sure you arn't doing like cat <foo >foo
<apw> cat foo >foo etc
<hallyn> oh
<apw> hallyn, and it is then oging to "read"
<apw> what does the failed read case look like
<apw> in the strace
<cking> of course, reading from /proc/.. one can never really tell what the size will be until it is read, so fstat won't work on getting the size
<apw> right, and that shouldn't matter, cause it does "read" regardless
<hallyn> cking and the same is true of my fusefs, ideally, since it sits on top of proc and cgroups
<apw> hallyn, what does it return for inode numbers and the like
<apw> those being "always the same" etc might throw it
<hallyn> apw: http://paste.ubuntu.com/9552719/ , so actually i bet fuse is the one saying "nothing to see here s oi wont' call read()"
<apw> and its behaviour changes depending if the stat returns that it is not REG
<hallyn> (which makes sense as i'm pretty sure i verified this with manual read(2) before)
<hallyn> but the files are REG
<hallyn> so must be fuse, in kernel or libfuse
<hallyn> it's a pain :)  but not a blocker at this point
<apw> hallyn, so this is a fuse remount of a /proc ?
<apw> hallyn, and yes, we did a real read, in the hope there was data, and fuse said 0 bytes
<hallyn> apw: yeah it's an overlay for cpuinfo, meminfo, etc.  (file-by-file, not the whoel fs)
<hallyn> apw: still wonder whether it's libfuse optimizing rather than the kernel... probably 
<apw> it might well make sense for it to use the underlying stat info to tell us the attmept to read is pointless, but ... odd
<infinity> hallyn: It certainly still seems to be reading it, so it's fuse returning the empty file.
<hallyn> infinity: yeah, it's still possible that libfuse intercepts, but that would seem even sillier than the kernel fuse module doing so
<infinity> hallyn: Line 37 is clearly a 0-length read, so your assertion that the read doesn't happen if the stat is 0 is false.
<infinity> hallyn: It stats, it reads, it gets nothing from fuse, you get nothing on stdout.
<infinity> hallyn: Oh, I have no opinion if it's userspace or the kernel module, but it's clearly the filesystem returning nothing.
<hallyn> infinity: i'm asserting that *my* read isn't being called
<infinity> hallyn: Curious.  cat's sure is.
<hallyn> cat's?
<hallyn> yeah the *system* call is being called.  
<hallyn> so i guess i need to see whether i can 'trick' fuse into calling read regardless
<hallyn> *calling my read handler
<hallyn> (we have some naming problems here :)
<apw> hallyn, it optimising it out, given it could work seems wrong
<infinity> hallyn: Well, the system call is being called, but returning no content.
<infinity> hallyn: So this still seems to be an issue with the filesystem.
<hallyn> agreed
<retabell> a Prob with 3.18.0-7 (own build)
<retabell> http://paste.debian.net/137128/
<vmesons> ubu-14.10 - unwanted suspend: http://pastebin.com/7Gr11Q3F -- I might get around to reporting a bug.. :)
<apw> retabell, i do not get that with the builds of teh same tip i am running
<retabell> ok thx
<ChrisP1948> After googling for this which I 'think' has been causing lockups [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle
<ChrisP1948> I filed a bug with Ubuntu - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331 and it was suggested in a comment that I update my bios
<ubot5> Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Low,Incomplete]
<ChrisP1948> I also, after  more googling found that others not using Ubuntu have experienced this issue so I added to a bug report here https://bugs.freedesktop.org/show_bug.cgi?id=75394 
<ubot5> Freedesktop bug 75394 in DRM/Intel "System hangs randomly with error message: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Critical,Needinfo]
<ChrisP1948> Today I received a comment on this bug wanting me to install and test the latest 3.18 kernel which so far I haven't done as I don't want to mess up my system.
<ChrisP1948> Earlier today I came home to a black screen with a mouse cursor only and had to reboot using the power button. Though the system kept working in the background
<ChrisP1948> I could not find the above error in my syslog. I'm imputing all this looking for some guidance
#ubuntu-kernel 2014-12-18
<zequence> infinity: updated and uploaded
<apw> ChrisP1948 (N,BFTL), a black screen with just a cursor is a common symptom when you have a graphics lockup, such as can be detected by the hang-check, so it is likley the same issue
<infinity> zequence: Ta.
<Neuticle> where can I find some documentation on Ubuntu kernel release dates? I'm specifically interested in when/if 3.17 will show up in ubuntu 14.04 or 14.10
<Neuticle> I've not been able to find anything so far, maybe my googlefoo is weak
<apw> Neuticle, there will be a 3.18/19 (whatever ends up being vivid's kernel) for 14.04 via the lts backport kerenls, there won't be any kernel version updates for 14.10
<Neuticle> apw, thank you, is there anywhere I can go to see the release schedules online?
<Neuticle> the link in the topic has a release list, but only through Raring, am I missing something?
<apw> Neuticle, the main release schedules are linked from https://wiki.ubuntu.com/Releases
<apw> which link has the list, stopping at raring, clearly something is amis there
<Neuticle> alright, well thank you very much
<apw> ahh this one https://wiki.ubuntu.com/Kernel/Release, which is woefully out of date ...
<apw> jsalisbury, https://wiki.ubuntu.com/Kernel/Release looks like it needs some love, or removing, or something
<jsalisbury> apw, heh, that is quite out of date.  I'll update it.
<apw> jsalisbury, thanks :)
<jsalisbury> np
<apw> jsalisbury, we need that on our "opening new release" list as well
<jsalisbury> apw, can you send me a pointer to where that is?
#ubuntu-kernel 2014-12-19
<zequence> infinity: All done
<adrian15> I have an Ubuntu 14.04 server virtual machine which just disappears (the kvm process no longer runs). Can I blame the ubuntu kernel for that? Can the kernel just poweroff the computer? Does it have an special name for it? Kernel version: 3.13.0-43-generic . Thank you.
<apw> adrian15, i would expect kvm to log the rewason it exited somewhere, and that to tell you if the inner kernel exited things, or kvm outside had an issue
<adrian15> apw: I only have these two messages at the host's syslog: http://paste.ubuntu.com/9574257/ . I suspect they happen to be after the virtual machine poweroffs and not before it. Is there any specific kvm log files? Or is it ok by taking a look at syslog?
#ubuntu-kernel 2014-12-20
<alkisg> Hi, is the 32bit kernel supposed to be loadable under a 64bit UEFI environment? If so, from what version onwards?
<mjg59> alkisg: No
<mjg59> Oh wait
<alkisg> mjg59: so http://cateee.net/lkddb/web-lkddb/EFI_STUB.html doesn't work under 32 bit?
<alkisg> I do see the 32bit kernels having that wrapper from 3.4 and after...
<alkisg> I'm just not sure if it's broken...
<mjg59> So yeah that will work
<mjg59> But not if you're just trying to boot it as an EFI executable
<mjg59> 64-bit EFI can't run 32-bit EFI executables
<mjg59> If you're using grub it *should* work
<alkisg> Wait wait maybe that's why I was having issues
<alkisg> I tried to load it from ipxe.efi (netbooting)
<mjg59> Right that definitely won't work
<alkisg> grub loads it as a bzimage?
<mjg59> Yes
<mjg59> But bear in mind that your firmware is free to put UEFI services above 4GB
<alkisg> So why the wrapper? At which case it would work? (in 32 bit images)
<mjg59> In which case a 32-bit kernel is never going to work
<mjg59> The PE/COFF wrapper will work fine if you have 32-bit firmware
<alkisg> Ah, got it
<alkisg> (09:53:26 Î¼Î¼) mjg59: But bear in mind that your firmware is free to put UEFI services above 4GB ==> so it's possible that I won't be able to load a 32bit kernel even with grub (as bzimage), right?
<alkisg> I mean, if I do have a 64bit uefi system which puts things above 4 gb and then calls grub, which then tries to load my 32bit bzimage kernel...
<alkisg> Thank you :)
<mjg59> alkisg: You'll jump into the kernel
<mjg59> But the kernel won't be able to make any UEFI calls
<mjg59> So various things will be broken
<alkisg> I was wondering about that... how clever are the 32bit kernels, autodetecting bios/uefi and adjusting their calls automatically...???
<mjg59> Pretty clever
<alkisg> Cool!!!
<alkisg> OK, my only question left now is if syslinux.efi is able to load bzimage and not just efi applications... I'll ask that in #syslinux. Thanks again! :)
<alkisg> Ah, no, I have another one:
<alkisg> Is it possible to boot a 32bit installation with a 64bit kernel?
<alkisg> http://askubuntu.com/questions/543658/install-64-bit-kernel-in-32-bit-ubuntu
<mjg59> That ought to mostly work
#ubuntu-kernel 2015-12-15
<xnox> apw, i am very impatient =) but when will the next linux upload happen? cause a fix for bug #1525297 is blocking image testing for s390x =)
<ubot5> bug 1525297 in linux (Ubuntu Xenial) "nic-modules udeb missing s390 modules" [Medium,Fix committed] https://launchpad.net/bugs/1525297
<xnox> and i guess current build will not migrate anywhere due to arm64 FTBFS - do i need to help with that?
<apw> xnox, i hope i have "fixed" the arm64 issue now, and i see the fix for your bits in my current upload
<apw> xnox, which i am preparing "now"
<xnox> apw, amazing =)
<rtg> apw, did you see this build failure ? https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/8438039/+files/buildlog_ubuntu-xenial-s390x.linux_4.4.0-0.5_BUILDING.txt.gz
<rtg> arm64 still has a compiler problem. I could not get any answers yesterday, but I remember you said you were working on it with doko.
<apw> rtg, sorting it right now
<apw> rtg, your 4.4 issue i think that just says you neither have s390x abi information nor it disabled there, did you update getabis config?
<apw> (the sorting refers to the 4.3 arm64 build issue)
<apw> rtg, i am about to upload 4.3.0-5 yell "now" if you have any objections
<rtg> apw, I carried forward your s390 patches from 4.3 . I _think_ I've got the right ABI files. I can dig into it if you're busy on other things.
<apw> rtg, i can look at it after i have done this upload
<rtg> apw, I just applied 4.3.3 if you wanna pick that up.
<apw> sigh
<apw> rtg, ack
<rtg> haven't pushed yet
<apw> rtg, if you push it now, i'll respin -5 with it in
<apw> may as well not do another upload tomorrow for it
<rtg_> apw, something weird going on with my laptop. gimme a couple mins
<apw> rtg_, heh that sounds like situation normal these days
<rtg_> I just booted it. its looks like it is swapping so hard that nothing else is happening
<apw> oh is this with .3 ?
<rtg_> apw, nope, good 'ol stock 3.13 trusty
<apw> heh, the best
<rtg_> anyway, pushed to xenial master-next
<xnox> omg linux-meta causes me a headache. took a while to realise that arm64 build of linux-meta is waiting on linux to build on arm64 which will not happen until next upload with apw implementing doko magic, to workaround partially fancy toolchains.
<apw> xnox, right, though broken seems more like the right description
<diwic> 4.4 as kernel seems to be a safe bet for 16.04? Or will 4.5 come out in time?
<apw> diwic, we are planning on 4.4, as that will have a long time to stabalise and will align with upstream too
<diwic> apw, yup, I was assuming so.
<diwic> apw, thanks for confirming
<apw> np
<xnox> apw, thank you for the upload and thanks rtg_ for fixing my bug. now it's "just" shepherding that is to be done.
<apw> xnox, hopefully be there by the am at least
<cristian_c> jsalisbury: hi
<Katronix> Greetings all, hope someone is active here :). Tried to run make menuconfig and I get the output here: http://pastebin.com/eH2EMeTS can someone recommend what my system is missing?
<mjeanson> Katronix: probably libncurses5-dev
<Katronix> mjeanson, odd, was sure I installed that but will check
<Katronix> ah I had installed the 64 bit versions
#ubuntu-kernel 2015-12-16
<cristian_c> jsalisbury: hi
<xnox> mount /tmp/live-installer/filesystem.squashfs /mnt/ -> hangs for me, and i don't know why.
<mkl> where can i ask about passing kernel module parameters?
<xnox> apw, any idea why would "mount -o loop -t squashfs filesystem.squashfs /mnt/" just "hang"? i'm in busybox, not sure what to check...
<apw> dmesg to see if the kernel got all whiney about the contents i guess
<apw> also modprobe loop before to make sure that works (if you can go back)
<xnox> apw, # modprobe loop
<xnox> modprobe: FATAL: Module loop not found.
<xnox> is that bad? =)
 * xnox looks for udebs
<xnox> apw, how come loop module is not needed on amd64, but is needed on s390x?
<xnox> apw, looks like s390x is the only arch with CONFIG_BLK_DEV_LOOP=m and all others have CONFIG_BLK_DEV_LOOP=y
<xnox> apw, can that be toggled please, and uploaded?
 * xnox hides
<slangasek> bjf, rtg: ^^ hi, we have an urgent kernel config change needed for s390x to unblock image prep; how can we get this done today?
<slangasek> bjf, rtg: we need CONFIG_BLK_DEV_LOOP=y on s390x, to match the other architectures, instead of the current CONFIG_BLK_DEV_LOOP=m
<rtg> slangasek, lemme know what it is ? send an email on the k-team list.
 * xnox is filing bug
<rtg> xnox, 4.4 kernel, right ?
<slangasek> rtg: list email also required, or does bug suffice?  4.4> this is current xenial-proposed, which is 4.3.0-5.14
<xnox> slangasek, rtg bug #1526869
<ubot5> bug 1526869 in linux (Ubuntu) "should be able to do live-installer installs from mirrors, and cdrom pool over the network" [Critical,Triaged] https://launchpad.net/bugs/1526869
<rtg> xnox, nevermind, looks like apw has been building s390x in the 4.3 kernel.
<xnox> rtg, yeap, it's just src:linux
<slangasek> yes, and needed in the archive as soon as you can have it :)
<rtg> xnox, slangasek: I can take it from here. no list email required
<slangasek> great, thanks!
<rtg> slangasek, xnox: [ubuntu/xenial-proposed] linux 4.3.0-5.15 (Accepted)
<xnox> rtg, thank you.
<rtg> xnox, it'll take awhile to build. should be done when you start tomorrow
<xnox> rtg, well, i care about the 27 minute build on s390x only =)
<rtg> ah, well then.
<xnox> rtg, and  like 1h for launchpad to publish it ;-)
<slangasek> rtg: package FTBFS on s390x though
<slangasek> EE: Missing modules (start begging for mercy)
<slangasek> https://launchpadlibrarian.net/230273302/buildlog_ubuntu-xenial-s390x.linux_4.3.0-5.15_BUILDING.txt.gz
<slangasek> xnox: ^^
<xnox> rtg, cause loop used to be available...... i guess it should be dropped from the abi compare files.
<slangasek> appears that a manifest needs updated now that loop is built-in
<rtg> slangasek, drat, one more turn of the crank
<rtg> xnox, slangasek: once more with feeling: [ubuntu/xenial-proposed] linux 4.3.0-5.16 (Accepted)
<slangasek> rtg: thanks!
<apw> that and the libseccomp fix should see us good i hope
#ubuntu-kernel 2015-12-17
<cristian_c> jsalisbury: hi
<cristian_c> jsalisbury: hi, again
<apw> cristian_c, hey, i suggest you ask your question, or whatever of him, so he can find it in scrollback
<cristian_c> apw: no particular questions to ask him, I'd like to know only if there are any news about his assignement
<cristian_c> :)
<jsalisbury> cristian_c, Hello, I have no new update on that particular bug as of yet.  
<cristian_c> ok
<jsalisbury> cristian_c, I hope to have some time today or tomorrow to look into it
<cristian_c> ok, thanks
<smoser> is the kernel for xenial expected to be 4.3 ?
<apw> smoser, 4.4 is the current plan
<smoser> apw, thanks
<apw> smoser, we have a very early 4.4 in testing in our unstable ppa
#ubuntu-kernel 2015-12-19
<sasha_> Does anyone here have instructions to create a kernel patch from a github driver file? Thanks.
<awreece> I'm noticing a behavior I'm having difficulty explaing -- my application is doing exceptional amounts of `mmap`s from many threads and is contending in the kernel on `mm->mmap_sem`. My expectation is that CPU profiling would reveal this contention; however, I appear to be missing it. 
<awreece> If I use the sched:sched_switch tracepoints with perf, I can very easily see that I'm getting dequeued
<awreece> I'm surprised that I don't see more CPU usage here: I guess `rwsem_down_read/write_failed` immediately deschedule if it fails?
<awreece> I must be blind, I don't see anything in the tree documenting rwsem
<awreece> `git grep rwsem -- Documentation`
<Noskcaj> Is there any recent change that would cause 15.10 to fail to upgrade to 16.04 with linux-image-4.3.0-2-generic install failure? I think it's lp:1527854
#ubuntu-kernel 2016-12-19
<bjf> henrix, please file a bug and then come back here and say what the bug id is
<bjf> henrix, ignore that
#ubuntu-kernel 2016-12-20
<furkan> hi all, i'm guessing there's somebody here responsible for the linux-firmware package?
<furkan> if so, could somebody pull the latest bonaire_uvd.bin from git?
<furkan> there is a major regression that needs fixing
<furkan> RE: http://www.phoronix.com/scan.php?page=news_item&px=R9-290-Linux-4.9-Update
<furkan> and https://bugs.freedesktop.org/show_bug.cgi?id=98988
<ubot5`> Freedesktop bug 98988 in DRM/Radeon "[Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance" [Normal,New]
<mamarley> apw: It looks like something might be screwed up with the i386 lowlatency 4.9 mainline kernel.  It makes all sorts of logspam about missing symbols and incorrect symbol versions.  The amd64 lowlatency image works fine though.
#ubuntu-kernel 2017-12-18
<stephen101> Nobody home? Lol
<FourDollars> Hi, I was asking about how to generate the Debian source package from git://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem last week. I can generate the Debian source package now after executing `fakeroot debian/rules clean`. However the Debian source package can not be built by sbuild with some error like http://paste.ubuntu.com/26207215/.
<apw> FourDollars, well at a most fundamental level that is actually what happens on a buildd
<apw> FourDollars, the error that is being reported by the kernel makefiles is that your tree is dirty
<apw> FourDollars, did you update configs in that tree for instance ?
<apw> FourDollars, i find the kernel makefiles say that if include/config exists or something like that
<FourDollars> apw: No, I just add my one commit and execute `fakeroot debian/rules clean` before `dpkg-buildpackage -S -us -uc`.
<FourDollars> Never mind. Let me try it again.
<apw> FourDollars, once yo have applied the fix, use a git clean -x -f -d on the tree, it will _remove_ everything not in version control so expect that
<FourDollars> apw: You are right. `git clean -x -f -d` does remove more files. Thx a lot.
<FourDollars> So the proper commands sequence will be `git clean -x -f -d`, `fakeroot debian/rules clean`, and then `dpkg-buildpackage -S -us -uc`.
<apw> that is what i do yes
<dupondje> There are no signed daily (or rc) kernels for ubuntu?
<dupondje> got 'some' errors on my new device, so want to check what is resolved yet in the newest kernel
<apw> dupondje, signed in the sense of signed for EFI secure-boot ?  no indeed
<apw> dupondje, though i am not sure why that would prevent them being booted
<dupondje> apw: going to try :)
<dupondje> allright booted 4.15.0-999-generic :)
<apw> dupondje, being unsigned means that grub hands off to the kernel in a different manner, with efi boot services closed down
<sforshee> kees: your patch which changes the behavior of the RLIMIT_STACK hard limit across suid exec, that has broken one of our tests. The test can be fixed, but I'm wondering how confident you are that it doesn't regress any userspace stuff?
<dupondje> apw: ok, tought uefi only accepted signed kernels
<dupondje> but good thing, new kernel fixes all my problems :)
<apw> dupondje, it only boots it in secure mode
<apw> if it is signed
<kees> sforshee: yeah, that broke a bunch of stuff, I've already gotten it reverted upstream (and it just landed in stable too)
<sforshee> kees: ok thanks, glad I didn't try to push that kernel through then :-)
#ubuntu-kernel 2017-12-19
<f_g> is the rationale for the ("tentative") choice of 4.15 for Bionic public somewhere? I already asked on-list some time ago (in reply to an even earlier question regarding the same), but there hasn't been a reply
<apw> f_g, mostly it is about the tension between new h/w support which is useful for upcoming machines and stability from a longer baked kernel; that take with a view on when we will get the kernle relative to our cycle
<f_g> apw: but why specifically 4.15 instead of 4.14, which is an upstream LTS release? is there some feature that landed in 4.15 that is more important than upstream LTS support? just "it's one cycle newer" seems kinda.. thin? :P
<f_g> I know the general balance between newer kernel - better HW support - shiny new features / older kernel - less breakage - more stability
<apw> f_g, we get input from vendors on where they are landing feature support, and that tends to be late in the game
<apw> the upstream stable kernles are generally chosen to be non-alighned with our cycle
<apw> we have to balance the work we will have to do porting stable fixes, against porting features
<apw> though iirc there was a change to how long LTS stables will be supported which may well make them more attractive
<f_g> apw: I am not sure whether the latter applies to upstream stable in general, or just certain ones? 4.4 got 6  years IIRC
<apw> thye all started claiming to be 2, but i do think they may well be doing longer now
<apw> 4.15 is still a tentative, and we will have a hard think before we move 4.14 -> 4.15 as we are not committed till that point
<f_g> apw: understood. thanks for taking the time to answer - it looks surprising from an outsider / downstream perspective, especially since 16.04 had 4.4
<apw> f_g, that was somewhat lucky for sure
<f_g> we moved from 4.4 to 4.10 and now 4.13 (downstream, based on Ubuntu kernel packages), and especially the move to 4.13 has been quite painful so we are a bit wary of 4.15
<apw> it is a difficult balancing act, newer is almost always better in terms of h/w support a big driver for desktop users who want the new shiney laptop to just work
<f_g> I know - which is why we use Ubuntu's as a base - there is no other distro kernel with the same mix of uptodateness and HW testing/support ;)
<apw> so we must be doing something right 
<f_g> :)
<apw> we will be reviewing the plan as we always do as we get each kernel in and "stable", 4.14 is still bouncing around in -proposed
<f_g> most of the pain with 4.13 was not Ubuntu's fault at all btw - just the usual upstream breakage. but much of it only got fixed in 4.15 and 4.14 stable updates, not in the short period of upstream 4.13 support
<f_g> great, I'll keep an eye out for future updates / plans then!
<apw> f_g, it is easier when there is an upstream LTS nearby to keep those updates flowing that is for sure
<apw> 4.13 is as far from an upstream stable as you can be
<f_g> indeed. there's only LP#1726519 left atm thankfully, but that seems to have stalled upstream
<dupondje> pcieport 0000:00:1d.0: AER: Corrected error received: id=00e8 => any idea on such error? tested daily kernel, but still seems to happen :(
<dupondje> 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1) (prog-if 00 [Normal decode])
<dupondje> hmm :)
<dupondje> oh my nvme disk is on that :(
<dupondje> Is there some daily linux-firmware package available?
#ubuntu-kernel 2017-12-20
<dupondje> anyone could give me some pointers to debug the following?
<dupondje> [ 2990.419420] pcieport 0000:00:1d.0: AER: Corrected error received: id=00e8
<dupondje> [ 2990.419434] pcieport 0000:00:1d.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e8(Transmitter ID)
<dupondje> [ 2990.419441] pcieport 0000:00:1d.0:   device [8086:a118] error status/mask=00001000/00002000
<dupondje> [ 2990.419446] pcieport 0000:00:1d.0:    [12] Replay Timer Timeout  
<dupondje> already tested latest daily built kernel, but same errors
<apw> dupondje, are you seeing any other symptoms with that error, as that just says it is a corrected error
<apw> ie is it a one off, does it repeat, does the machine crater after it
<dupondje> apw: it repeats, sometimes after 1 minute, sometimes only 1 per hour
<dupondje> its random
<dupondje> but nothing seems to hang/lock/die whatever :)
<apw> and i assume you didn't see them on older kernels
<apw> if so it may well be we learned how to report them
<dupondje> well I saw it on stock 17.10 kernel and on daily kernel
<dupondje> its on a new laptop, so no idea about older kernels :)
<dupondje> also seeing:
<dupondje> [   54.376166] nvme 0000:04:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0400(Receiver ID)
<dupondje> [   54.376169] nvme 0000:04:00.0:   device [1c5c:1284] error status/mask=00000081/0000e000
<dupondje> [   54.376172] nvme 0000:04:00.0:    [ 0] Receiver Error         (First)
<dupondje> [   54.376174] nvme 0000:04:00.0:    [ 7] Bad DLLP   
<dupondje> but way less frequent
<apw> was that nvme installed when you bought it ?
<apw> both of those errors are reporting that transactions on PCIE are failing, that would often imply h/w issues
<dupondje> yes
<dupondje> brand new device
<dupondje> its ofcourse possible something is wrong with it ...
<apw> or indeed that "occasional" errors are to be expected as long as they are corrected
<apw> you really need to find another machine of the same type and find out if it has the issue
<apw> what kind of machine is it
<dupondje> Dell Precision 5520
<TJ-> It could be an ASPM issue
<dupondje> could try booting 16.04 on a liveusb
<dupondje> and see if it happens there also ...
<TJ-> dupondje: is it a XPS 9560 ?
<TJ-> oh no, sorry, you said!
<dupondje> TJ-: its not, but XPS 9560 is actually (exactly?) the same hardware ...
<dupondje> afaik
<TJ-> dupondje: I see some reports with Dell + Hynix M.2 NVMe 
<dupondje> Model Number:                       PC300 NVMe SK hynix 512GB
<dupondje> :D
<dupondje> TJ-: link?
<TJ-> there's a workaround here but it sounds a bit drastic, maybe apw can comment? https://bbs.archlinux.org/viewtopic.php?id=229682
<TJ-> dupondje: it may be the ACPI DSDT isn't correctly configuring the device
<dupondje> but thats a bug in the kernel? Guess I should better open some bugreport then?
<TJ-> If it's ACPI it'll be a firmware bug. There's a common change I often recommend where there are unusual hardware issues, and it's very sucessful. See http://iam.tj/prototype/enhancements/Windows-acpi_osi.html
<dupondje> still thats a workaround then :) Needs to be fixed in the NVME firmware then?
<TJ-> dupondje: no. if the issue is ACPI and that fixes it, the bug is in the Dell PC firmware assuming it is running with Windows and not fully configuring the system when Linux is the OS
<dupondje> guess I should poke Dell then :)
<dupondje> they deliver the laptop with Ubuntu 16.04 on it, so you would expect that it works fine
<TJ-> Does it work without that error on 16.04? I think you said you're using 17.10 on it ?
<TJ-> Recent kernels have tightened up the ACPI implementation so we see a lot more of this kind of issue as a result
<dupondje> just booted into livecd of 16.04 now
<dupondje> but seems to be fine on 16.04, no such errors
<dupondje> So conclusion is that its a BIOS/ACPI bug that is visible only in recent kernels?
<TJ-> dupondje: the hint is there, yes
<dupondje> hmmmm, guess Dell doesn't have a bugtracker :P
#ubuntu-kernel 2017-12-21
<alkisg> Hi, https://wiki.ubuntu.com/Security/Features#Built_as_PIE says that it has 5-10% performance penalty
<alkisg> Does that mean that if I run `echo 0 > /proc/sys/kernel/randomize_va_space` on a pentium 4, it'll run Ubuntu 16.04 faster?
<alkisg> Or compiling with PIE enabled will result in performance loss anyway?
<apw> compiling as PIE will alter the emitted code
<alkisg> apw: I mean, does PIE mean a syscall that can be disabled in the kernel at runtime, avoiding the extra overhead, or is it a compiler time thing only, which cannot be disabled after compilation?
<apw> pie is a compilation option which changes the code to not assume its location, which has a cost associated with it
<alkisg> apw, thank you, so the only way to measure that overhead would be to recompile, which isn't really an option if one wants to use a recent Ubuntu version :)
<apw> right, you'd need to turn it off and rebuild the kernel
<alkisg> The kernel or the apps?
<alkisg> I thought that was about the apps...
<apw> both indeed, depends what you are trying to measure
<alkisg> Well in general how much slower a "desktop feels", maybe that would be 80% userspace and 20% kernel...
<apw> hard to say indeed, and humans are immensly sensitive to that kind of thing
<alkisg> E.g. a few years ago it was possible to watch youtube with a p4 1.7 ghz, now it's not even with p4 at 2.4 ghz
<apw> a few % and you can tell often
<apw> are the videos at the same resolution i wonder
<alkisg> Yes, but I'm not sure about the players
<apw> but it doesn't supprise me entierly, old h/w does get left behind over time
<apw> i wonder how old a pentium-4 mbased mchine could be at its youngest now
<alkisg> I used the same video back then and now, and tried with flash now as well as then when html5 didn't exist, but I don't know if flash or youtube added unrelated code that made them slower
<apw> browsers are more tightly controlled now days too
<apw> and video playback is one of those things where your computer is either fast enough or not
<alkisg> And there's compositing even in the legacy desktops, adding to delays... https too...
<alkisg> Ah, playing with vlc is fast now too
<apw> it might have been 1% faster than needed before and be 2% slower now and ... you lose
<alkisg> The browsers make it like 4 times slower
<apw> so it is ok in vlc ?
<alkisg> Yeah
<apw> so not inherantly unplayable then
<alkisg> Ubuntu 16.04 i386 is still fast enough to play an e.g. 1024x768 full screen movie without dropped frames
<alkisg> Indeed, but there's no way to convince youtube/firefox etc etc to make them more efficient for older machines, so I was looking to gain that 10% performance in case it makes things barely more functional
<alkisg> apw: so with regards to aslr/pie, we're not expecting any performance differences between e.g. 12.04 and 18.04, since all "major" programs like the kernel or firefox were already using them, correct?
<apw> that'd be my feeling
<alkisg> Thank you, I was worried that I would have to hold those machines with 16.04
<alkisg> Let them work with 18.04 as long as they have a bit of life in them
<apw> alkisg, as with all things, testing it out is a good plan
<alkisg> Indeed... hmm I'll actually do a larger comparison, 10.04/12.04/18.04 live cds, and watching the same youtube video...
<apw> sounds like "fun"
#ubuntu-kernel 2017-12-22
<alkisg> https://packages.ubuntu.com/rtl8812au-dkms needs a simple backport for xenial. The xenial version works for 4.4, fails for 4.10, and the bionic package works in xenial with 4.10.
<alkisg> Should I file an SRU for that?
<alkisg> Also, what would it take to (1) upgrade the source to a newer version 5.x from the realtek site,
<alkisg> and (2) to enable support for rtl8821au too? (21 instead of 12). Would another rtl8821au-dkms package need to be made?
<TJ-> alkisg: I'm sure I already did that a couple months ago!
<TJ-> alkisg: oh, no, it was the github package: https://github.com/abperiasamy/rtl8812AU_8821AU_linux.git
<alkisg> TJ-: are you maintaining that github?
<alkisg> Synching the ubuntu package code with that one would be just fine :)
<alkisg> indeed  21au works with that
<TJ-> alkisg: no, I pulled from there and had to add patches as kernel versions moved on. In the end I decided out-of-tree is not worth the effort, and dumped the devices
<alkisg> Since the realtek source code is GPL, why isn't it in the kernel?
<alkisg> *upstream?
<stgraber> because some code is GPL doesn't mean it's good code :) that's usually why some particular module isn't upstream yet, the author has to go through the upstream code review process and possibly have to change quite a bit of their code
<TJ-> ^^^ the code is terrible
<alkisg> Ah, I thought it was the same realtek developers that had all the other already upstreamed code...
<alkisg> (e.g. rtl816x)
#ubuntu-kernel 2017-12-23
<JanC> the upstream rtl8821au code is a mix of Windows, Mac & Linux code; there is no way it would go into the linux kernel verbatim  :)
#ubuntu-kernel 2017-12-24
<TeLLuS_> Upgraded from Zesty to Artful, 4.10.0-42-generic #46-Ubuntu to 4.13.0-21  Got regression that tg3 network driver stopped working in Dell PE sc1435 server.  ETDEV WATCHDOG: enp1s0 (tg3): transmit queue 0 timed out, Host status block, NAPI info. Installed 4.13.16, 4.13.17, 4.13.19 Got same timeout as in .21.     Installed kernel 4.14.0-13 from upcomming Bionic, now it is working again..
<bjf> TeLLuS_, pleas file a bug and them come back here and tell me what the bug number is ... thanks
<TeLLuS_> bjf: No way, I will not go down that path again.  I'm told that it is not how launchpad works, it will be set to invalid since it is fixed unpublished version and it will then be hidden from the launchpad search. Even when I'm told it is not.  Things like that hurt my feelings and I will not work on things that gets thrown away or hidden the next second.
<bjf> TeLLuS_, what do you mean it is "fixed unpublished version"
<bjf> TeLLuS_, i'm not sure why you have the impression that you do. if you file the bug i will make sure someone looks at it
<bjf> TeLLuS_, and it ill not be marked invalid. it *may* be marked as a duplicate if there is a duplicate
<TeLLuS_> bjf: Bug is already fixed in an unpublished new version. It can be handeled diffrently by xorg developers I guess.  But I'm told in #1640456 "Here on Launchpad, that's not how it works."   I don't need anyone to look at it since I have already found the issue and the fixed next version of it.  From what I can find there is similar bugs for tg3 (Broadcom) but not the same, mostly old ones and not for only the Artful version.
<bjf> TeLLuS_, from my perspective the response you got back in comment #6 was not helpful
<bjf> TeLLuS_, i have little say in how xorg bugs are handled. however, if you file the tg3 network bug against the 'linux' project things will go differently i believe
<bjf> TeLLuS_, but if you don't want to file the bug then i'll leave you alone
#ubuntu-kernel 2019-12-16
<zx2c4> apw: sigh
<zx2c4> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1856539
<ubot5> Ubuntu bug 1856539 in wireguard (Ubuntu) "wireguard package doesn't work on ubuntu eon" [Undecided,New]
<zx2c4> helping this guy involves walking him through rebuilding his dkms stuff (for whatever reason) and/or disabling secure boot
<zx2c4> that really sucks
<zx2c4> proper .ko cannot come soon enough :-)
<aberrant> good morning all
<aberrant> I filed a bug (#1856603) just now and am wondering whether I could get some feedback on it - do I need to provide more info or is it good as-is?
<aberrant> as an aside, if someone could step me through building a patched kernel, I'd appreciate it. The docs seem to be out of date.
<aberrant> fm
<aberrant> so, can someone please point me to the latest guide to compiling an ubuntu kernel (with an upstream patch)?
<aberrant> https://help.ubuntu.com/community/Kernel/Compile is a bit outdated, and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild isn't specific to Ubuntu (and is also, I think, outdated)
<connor_k> aberrant, Have you already cloned the git repository that corresponds to which Ubuntu kernel you'd like to apply the patch to?
<aberrant> connor_k: not yet. I started doing the "generic" instructions but figured that's probably not what I want.
<aberrant> connor_k: I'm on eoan
<aberrant> connor_k: should I just apt install linux-source-5.3.0 ?
<connor_k> aberrant, I suppose you could, but I prefer to use the git repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan
<aberrant> ah, ok
<aberrant> thank you
<connor_k> ping me once that's cloned and I'll walk you through applying your patch and building the kernel :-)
<aberrant> awesome! thanks.
<aberrant> still going. :)
<connor_k> It will probably take a few minutes :-) Do you already have the patch(es) you want to apply to it?
<aberrant> yes. it's one line
<aberrant> http://git.infradead.org/nvme.git/commitdiff/530436c45ef2e446c12538a400e465929a0b3ade?hp=400b6a7b13a3fd71cff087139ce45dd1e5fff444
<aberrant> I hope this file is in the ubuntu kernel
<aberrant> actually, it's like 10 lines. :)
<connor_k> it looks like it is
<connor_k> so on that page you linked, I clicked on the "patch" link and it'll take you here: http://git.infradead.org/nvme.git/patch/530436c45ef2e446c12538a400e465929a0b3ade?hp=400b6a7b13a3fd71cff087139ce45dd1e5fff444
<aberrant> it's in drivers, though. Does this require a new kernel, or just a driver?
<aberrant> "You merely need to compile a special driver. For this, you only need to install the linux-headers packages."
<aberrant> from https://help.ubuntu.com/community/Kernel/Compile
<aberrant> but this is useful info anyway, so let's march forward.
<aberrant> I'll be taking notes
<connor_k> Oof, lots of pressure for me to get it right then ha
<aberrant> hahaha.
<aberrant> I can build this on a different system than the one I need it on as long as the architecture's the same, right?
<connor_k> aberrant, yeah
<aberrant> ok, git clone finished
<connor_k> if you right-click the "patch" link on the commit page you linked me to, click "save link as" or something to download the patch so you can have it handy
<connor_k> or if you're ssh'ing onto a more powerful build machine then you can use a command line tool like "curl" or something: "curl http://git.infradead.org/nvme.git/patch/530436c45ef2e446c12538a400e465929a0b3ade?hp=400b6a7b13a3fd71cff087139ce45dd1e5fff444 > whatever-you-want-to-name-it.patch"
<aberrant> yup, got it. It has the email header in there. is that a problem?
<connor_k> no, git will ignore that when you apply it
<aberrant> ok, got it.
<aberrant> cd to .../nvme/host and then patch < patch1.txt ?
<connor_k> inside the "eoan" repo, if you run "git am ../path-to-that-patch-you-downloaded.patch" there's a chance it'll just fit in without any fuss
<aberrant> oh, use git. wow.
<aberrant> seth@hydrogen:~/kernel/eoan$ git am ~/patch1.txt
<aberrant> Applying: nvme: Discard workaround for non-conformant devices
<aberrant> done :)
<aberrant> let me just confirm some of the changed lines are there
<connor_k> nice!
<aberrant> yup, all good.
<aberrant> so far you're on a roll :)
<connor_k> Sweet! One last thing I'd do before spending time compiling it is to make sure that config option is enabled for the Ubuntu kernel you want to compile
<aberrant> ok, where is that specified?
<aberrant> or does make config take care of it?
<aberrant> (I also need kvm support, just FYI)
<connor_k> I looked in the folder where the code is that you patched (drivers/nvme/host) and saw the Kconfig specifies "NVME_CORE"
<connor_k> I'd just run "git grep NVME_CORE debian.master"
<connor_k> and I see in eoan: "debian.master/config/config.common.ubuntu:CONFIG_NVME_CORE=m"
<aberrant> debian.master/config/config.common.ubuntu:CONFIG_NVME_CORE=m
<aberrant> what's "m" mean?
<connor_k> so it looks like it's built as a module (which isn't terribly surprising since NVME seems pretty important to have these days
<aberrant> ah, ok
<connor_k> module just means that it can be loaded after the fact. Another value would be "y" which means it's built directly into the kernel image
<connor_k> er, module => "m"
<connor_k> so since the proper config is already set you could probably build the kernel
<aberrant> well, my boot drive is nvme, so
<aberrant> no 'make config' ?
<aberrant> (and what about KVM?)
<connor_k> before doing that I'd edit the changelog "debian.master/changelog" and inside the parentheses: linux (5.3.0-blah) I'd change the number in the parentheses to be (5.3.0-blah+MyPatch) or something
 * connor_k can't type fast enough :-)
<aberrant> linux (5.3.0-24.26+nvme_patch) eoan; urgency=medium
<connor_k> perfect
<aberrant> ok.
<connor_k> that's just so you know you're running your test kernel when you run "uname -a"
<aberrant> understood.
<aberrant> perfect.
<connor_k> but I think Eoan is also built with kvm support
<connor_k> git grep CONFIG_KVM debian.master/
<connor_k> debian.master/config/amd64/config.common.amd64:CONFIG_KVM=m
<aberrant> KVM worked out of the box with the iso install, so I think you're right
<connor_k> Ok. Looks like you're ready to put your CPU to work
<connor_k> make -j`nproc` bin-debpkg
<aberrant> basically I'd like the iso install kernel with this one patch :)
<aberrant> sweet.
<aberrant> j=6
<connor_k> at least I think that's the makefile target that produces the -image, -modules debian packages once it's all done
<aberrant> *** Configuration file ".config" not found!
<aberrant> ***
<aberrant> *** Please run some configurator (e.g. "make oldconfig" or
<aberrant> *** "make menuconfig" or "make xconfig").
<connor_k> oh woops, also I forgot at the very beginning
<connor_k> cp /boot/config-`uname -r` .config
<connor_k> then "make oldconfig"
<aberrant> config-5.3.0-24-generic ?
<connor_k> if that's what shows up when you run `uname -r` yeah, probably
<aberrant> oh, what packages do I need? it failed 'cause no flex
<aberrant> sorry. I'm building inside a VM
<connor_k> ah
<aberrant> flex and bison so far
<connor_k> in the eoan folder, if you open Documentation/Changes it has a list of packages
<aberrant> I have gcc and g++
<connor_k> probably need bc, libssl-dev, libelf-dev, libncurses5-dev
<aberrant> ok, give me a minute :)
<aberrant> where is mcelog?
<connor_k> try skipping that one, I don't remember ever having to install it to build the kernel. I think you can get away with build-essential (which has gcc, g++), make, libssl-dev, libelf-dev, flex, bison, bc
<aberrant> mcelog was removed from Debian and in turn Ubuntu bionic due to "ROM; obsolete; no kernel support in testing". Please see https://launchpad.net/ubuntu/+source/mcelog/+publishinghistory or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889741 for more details.
<aberrant> erm.
<ubot5> Debian bug 889741 in ftp.debian.org "RM: mcelog -- ROM; obsolete; no kernel support in testing" [Normal,Open]
<aberrant> ok
<sarnold> iirc mcelog has been mostly replaced by rasdaemon; I haven't had any MCEs on my own hardware (thankfully) to verify that it actually serves as a replacement
<aberrant> ok, what's after `make oldconfig` again?
<connor_k> should be good to go with: "make -j`nproc` bin-debpkg"
<aberrant> got it.
<connor_k> and then take a break to have a snack, read a book, watch a film, or maybe overnight depending on that VM :-)
<aberrant> hahah
<sarnold> :)
<aberrant> 6 procs off a 3400G
<connor_k> that make target will produce the kernel all packaged up, and you'll be interested in installing the one that has *image*.deb and *modules*.deb
<aberrant> do I run the make in debian-master/ ?
<connor_k> no, in the top level directory of the eoan tree
<aberrant> the config was in the eoan root, right?
<connor_k> yeah run it in the eoan root
<aberrant> seth@hydrogen:~/kernel/eoan$ make -j6 bin-debpkg UPD     include/config/kernel.release
<aberrant> make[1]: *** No rule to make target 'bin-debpkg'.  Stop.
<aberrant> checking the makefile
<aberrant> I can't find bin-debpkg as a target
<connor_k> hmm, weird... I suppose running: "fakeroot debian/rules binary" should compile the kernel and produce the same packages I was going for with the "bin-debpkg" thing
<aberrant> how about `make all`?
<aberrant> make help shows that building vmlinux, modules, and bzImage
<connor_k> yeah I suppose you could, I was just trying to go the route where it produces debian packages so you can uninstall the test kernel but I guess if it's a VM then you could go the route "make" "make modules_install" "make install" (but I don't know the right targets off the top of my head)
<aberrant> nononon. I'm installing it ont he hypervisor
<aberrant> so yeah, I'd like to be able to uninstall.
<aberrant> I'm building on a vm, but installing on the HV
<aberrant> seth@hydrogen:~/kernel/eoan$ fakeroot debian/rules binary
<aberrant> Debug: prepare-indep
<aberrant> dh_prep -i
<aberrant> /bin/bash: dh_prep: command not found
<aberrant> make: *** [debian/rules.d/3-binary-indep.mk:172: prepare-indep] Error 127
<connor_k> yeah i guess the way I'm most familiar with that should result in debian packages which are easily managed by dpkg or apt would be "fakeroot debian/rules binary"
<aberrant> let me try installing debhelper
<aberrant> seth@hydrogen:~/kernel/eoan$ fakeroot debian/rules binary
<aberrant> Debug: prepare-indep
<aberrant> dh_prep -i
<aberrant> dh_prep: "debian/control" not found. Are you sure you are in the correct directory?
<aberrant> make: *** [debian/rules.d/3-binary-indep.mk:172: prepare-indep] Error 255
<aberrant> hrm.
<aberrant> trying fakeroot debian/rules clean
<connor_k> yeah that should generate it
<aberrant> ok. I'm following https://help.ubuntu.com/community/Kernel/Compile
<aberrant> AUTOBUILD=1 fakeroot debian/rules binary-debs <--- does that look reasonable?
<connor_k> did "fakeroot debian/rules clean" followed by "fakeroot debian/rules binary" not start building it?
<aberrant> I just did the clean so far
<aberrant> should I do binary or binary-debs?
<connor_k> just binary
<aberrant> ok
<aberrant> building
<aberrant> I also had to install kernel-wedge
<connor_k> woo!
<aberrant> wait
<connor_k> not woo!
<aberrant> is there a way to `j6` this?
<aberrant> or will it just be single-proc?
<aberrant> checking for libudev.h... no
<aberrant> configure: error: Missing /usr/include/libudev.h
<aberrant> crap.
<aberrant> ok
<connor_k> Hmm I'm sure there's a way to do an equivalent -j thing
<aberrant> just installed libudev-dev
<aberrant> utils/helpers/amd.c:8:10: fatal error: pci/pci.h: No such file or directory
<aberrant> crap. what's going on here?
<aberrant> let me try a `make -j6 all` and see what happens.
<aberrant> I can always distclean
<connor_k> frankly I'm still sad that the "make bin-debpkg" didn't work, and am wondering if I hallucinated all of my previous kernel builds
<aberrant> https://wiki.debian.org/BuildADebianKernelPackage
<aberrant> :)
<aberrant> This is an obsolete now guide on how to build the Linux Kernel into a .deb package. Don't use this,
<aberrant> what happens with a `make all` ?
<connor_k> it'll just compile the kernel (but doesn't produce debian packages from it)
<aberrant> maybe the fakeroot will work if the binaries already exist
<aberrant> fakeroot debian/rules binary-arch
<aberrant> huh.
<connor_k> well... i've done some soul searching and realized i've misled you. I said "make bin-debpkg" but really what I should have said was "make bindeb-pkg"
<aberrant> oooh.
<aberrant> ok, should I stop this `make all`?
<connor_k> no
<connor_k> you can run "make bindeb-pkg" after the make all
<aberrant> you got it. Thank you for persevering here.
<connor_k> but DON'T run "make deb-pkg" make sure you run "make bindeb-pkg" because the one without the "bin" in the name executes a "make clean"
<aberrant> yup, I took notes.
<aberrant> wiki definitely needs an update :)
<connor_k> cool :-) have fun kernel hacking!
<aberrant> assuming this works.
<aberrant> Thank you very much. Hopefully this patch 1) works, and 2) gets into a mainstream kernel build.
<aberrant> nasty bug.
<aberrant> ok, gonna let this crank. I'll be back to let you know outcome one way or another :)
<connor_k> sounds good to me :-)
<aberrant> thanks again, connor_k - greatly appreciated.
<connor_k> no problem! happy to help
<aberrant> just to confirm, this will build 3 .deb packages, and I just copy those over to the hypervisor and do a dpkg -i on each?
<connor_k> you'll only need the ones that are -*image*.deb -*modules*.deb
<connor_k> unless you're gonna compile DKMS packages on the kernel you're installing, in which case you'll want the -*headers*.deb too
<aberrant> dunno what those are, so .. no.
<aberrant> how do I uninstall if this gives me problems?
<aberrant> will dpkg -r do it?
<connor_k> there should be a version number in the *.deb name, I usually do "dpkg --get-selections | grep linux" and look for the linux-image package with the version number that's encoded in your deb name, then "apt remove THAT_PACKAGE"
<aberrant> does that restore the old kernel?
<connor_k> when you reboot after uninstalling, yeah it'll look for the newest kernel (which will be the one you were running before you installed your test kernel)
<aberrant> ah, right. Cool!
<aberrant> still building, so I'm headed home. Will check later. Thanks again.
<connor_k> Np! have a good evening!
<aberrant> wow, build just finished.
<aberrant> make -j6 bindeb-pkg now
#ubuntu-kernel 2019-12-17
<aberrant> hi all
<sarnold> wb
<aberrant> thanks.
<aberrant> Does `make bindeb-pkg` make the modules? I don't have any .deb that has the word "modules" in it.
<connor_k> Sorry Iâm not at my computer right now to confirm but I think maybe the bindeb-pkg target might just roll them all up into the *images*.deb
<connor_k> If you run âdpkg -x | grep nvmeâ the modules might be listed
<aberrant> ok, thanks. let me check
<aberrant> sorry for being so high-maintenance
<connor_k> Wanting to learn something new is hardly high maintenance :-) if anyone tells you that then theyâre wrong
<connor_k> Er sorry âdpkg -x *image*.deb | grep nvmeâ
<sarnold> I don't see anything else in the make help output that looks like it'd generate modules debs
<aberrant> seth@hydrogen:~/kernel$ dpkg -c linux-image-5.3.10+_5.3.10+-1_amd64.deb | grep -i nvme
<aberrant> drwxr-xr-x root/root         0 2019-12-16 15:39 ./lib/modules/5.3.10+/kernel/drivers/nvme/
<aberrant> drwxr-xr-x root/root         0 2019-12-16 15:39 ./lib/modules/5.3.10+/kernel/drivers/nvme/host/
<aberrant> -rw-r--r-- root/root    163713 2019-12-16 15:39 ./lib/modules/5.3.10+/kernel/drivers/nvme/host/nvme-core.ko
<aberrant> that's dpkg -c
<connor_k> Okay cool, looks like theyâre all rolled up into *image*.deb
<aberrant> does that mean the modules are loaded?
<aberrant> ok
<aberrant> is that the right image deb?
<aberrant> I don't want dbg, right?
<connor_k> I think the *modules*.deb is purely an ubuntu artifact with how the scripts are set up
<connor_k> Yes thatâs the right deb
<aberrant> linux-headers-5.3.10+_5.3.10+-1_amd64.deb    linux-image-5.3.10+_5.3.10+-1_amd64.deb
<aberrant> linux-image-5.3.10+-dbg_5.3.10+-1_amd64.deb  linux-libc-dev_5.3.10+-1_amd64.deb
<connor_k> Dbg will only be helpful if you want to run that kernel under a debugger 
<aberrant> those are my choices
<aberrant> second one, I guess.
<connor_k> Yeah
<aberrant> ok, now a dpkg -i on the HV, right?
<aberrant> wish me luck.
<connor_k> Good luck!
<aberrant> W: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
<aberrant> W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
<aberrant> I seem to recall having that earlier too
<aberrant> so I'm going from 5.3.0 to 5.3.10.
<aberrant> will be back after reboot, hopefully. :)
 * aberrant waves
<connor_k> o/
<aberrant> w000000
<aberrant> seth@elemental:~$ sudo fstrim -v /
<aberrant>  seth@elemental:~$ sudo fstrim -v /
<aberrant> damnit, that's not pasting
<aberrant> suffice to say it works
<aberrant> we need to get this patch into the kernel :)
<sarnold> TIL there's a -v to fstrim :)
<aberrant>  /: 758.3 GiB (814159003648 bytes) trimmed
<aberrant> there
<aberrant> I'll update the bug report.
<sarnold> hmm which irc client do you have? I thuoght most? all? had paste detection to handle a leading / in a paste correctly
<sarnold> that might be worth a bug report for your irc client, heh
<connor_k> Nice job aberrant!! 
<aberrant> sarnold: I'm using irssi
<aberrant> connor_k: I couldn't have done it without you. Thanks so much!
<sarnold> hm. now I've got to try.. :)
<connor_k> Whatâs the bug number, aberrant?
<aberrant> 1856603
<sarnold> # fstrim -v /
<sarnold> /: 6.7 GiB (7215800320 bytes) trimmed
<sarnold> irssi 0.8.19-1ubuntu1.9 on this machine
<aberrant> sarnold: from what I understand the fstrim issue only manifests in certain nvme drives that don't follow the spec precisely.
<aberrant> 758.3 GiB trimmed seems like an awful lot though.
<sarnold> aberrant: heh, I was more just interested in the / leading char thing, the actual issue you and connor_k are discussing I haven't followed at all, hehe
<aberrant> I don't think I've gone past 20% utilization on the drive.
<aberrant> hahahaha
<connor_k> Cool! I wrote it down and can look at it tomorrow for SRUâing the patch into the kernel 
<sarnold> aberrant: how long has it been since you've done an fstrim on this system? what kind of write churn does it have? do you have the weekly fstrim timers running correctly?
<aberrant> CTCP VERSION reply from aberrant: irssi v1.2.1-1ubuntu2
<aberrant> sarnold: the machine is less than a week old. I've never done an fstrim on it.
<sarnold> 700G trimmed *does* feel like a huge trim if you're getting it done weekly already..
<sarnold> sheeeeeesh
<aberrant> I set up some vms on it, and transferred a bunch of data.
<aberrant> but currently I'm at 19% utilization
<aberrant> (1TB)
<aberrant> I wonder if the first fstrim on a brand new disk is somehow large. The subsequent one I did was 0 GiB.
<aberrant> oh, look
<aberrant> that's roughly the size of the total free space
<sarnold> yeah, any more and I'd have been very worried :)
<aberrant> so maybe it had to do a complete fstrim on the entire free list.
<sarnold> it's possible that the 'first' fstrim on the filesystem does have to start from scratch and trim it all, whether or not it'd been used
<sarnold> 250ish gigs, though, the average data would only need to be overwritten three times.. between write amplifications on small writes, OS updates on host and guests.. maybe 700-ish gigs of dirtied but no longer needed data isn't crazy for a 250-ish gig used system
<sarnold> I shudder to think about eg atime updates on all those bloody files. relatime is a good thing, but even then..
<aberrant> I'm mounting relatime
<aberrant> let's see what happens next sunday :)
<sarnold> :)
<aberrant> this channel is fantastic. Thanks for all the support here.
<sarnold> hmm does the timer use fstrim -v? or fstrim? or .. just run the ioctls raw?
<aberrant> as it turns out I have to RMA my motherboard.
<aberrant> it won't take a BIOS update. It's stuck on the penultimate version.
<sarnold> here's the logs from three of my machines http://paste.ubuntu.com/p/GGJHQKFDJj/
<sarnold> that's frustrating :(
<aberrant> yeah, so I confirmed: if I add the trimmed GiB to the used GiB I get exactly the capacity of the disk
<aberrant> so the first trim probably trims the entire free space
<aberrant> 758.3 + 158
<aberrant> well, not *exactly* but close enough for government work
<aberrant> ok. That's enough stress for one day. thanks again. Have a great evening, all.
 * aberrant waves.
<aberrant> morning all :)
<aberrant> after that patch everything is wonderful.
<tharrrk> hi there. may i have a question regd. mainline kernels here or is there a better channel to ask?
<sarnold> this may be fine, but there's also a #kernelnewbies on irc.oftc.net that's more about kernel programming. maybe ask and see what happens :)
<tharrrk> cool thanks
<tharrrk> so, all builds on kernel.ubuntu.com/~kernel-ppa/mainline/ from v5.3.7 failed for i386. Is that intentional? I mean, i386 is kind of dead these days but if there is a build recipe i think it should either build successfully or it should go away... If there's something i could help with..?
<sarnold> heh that's indeed one that wouldn't be useful for #kernelnewbies :)
<tharrrk> :)
#ubuntu-kernel 2019-12-18
<apw> tharrrk, failed in what sense
<apw> as i do not expect builds for i386 as it is no longer supported on the higher numbers
<aberrant> good morning all
<aberrant> I noticed that there's a kernel update today. I'm wondering whether it will overwrite my custom-patched kernel.
<apw> aberrant, that would depend on what version you have on your custom-patched kernel
<apw> aberrant, it will have a newer version that our old one, depends what version you picked; well and what package name used if different etc
<aberrant> apw: it looks like apt installed 5.3.0-24 on my other system
<aberrant> the system that has the custom kernel is Linux elemental 5.3.10+ #1 SMP Mon Dec 16 15:03:53 PST 2019 x86_64 x86_64 x86_64 GNU/Linux
<connor_k> 5.3.10 or 5.3.0?
<apw> if the package is also called 5.3.10, then it should have a higher version
<aberrant> .10
<aberrant> I built the custom kernel off of the master branch, I guess
<aberrant> seth@hydrogen:~/dev/kernel/eoan$ git status                                                                                                  âOn branch master                                                                                                                             âYour branch is ahead of 'origin/master' by 1 commit.
<aberrant> yup
<apw> and how did you biuld it, as if you used ubuntu packaging it would have suppressed the .10
<aberrant> apw: I followed connor_k's instructions :)
<aberrant> make -j6 bindeb-pkg
<apw> yeah so using debian's build, so sounds like you have higher versions, so you will be ok
<aberrant> so an apt upgrade will not overwrite my kernel?
<aberrant> I guess I can always reinstall it, but...
<aberrant> it would be great to get this patch into the mainline kernel.
<aberrant> running custom makes me nervous.
