#ubuntu-kernel 2005-04-11
<T-Bone> Finished at 20050331-0002
<T-Bone> Build needed 03:05:35, 643756k disk space
<T-Bone> that was atlas3
<fabbione> morning
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how is it going?
<fabbione> very busy today
<fabbione> and you?
<zul> im good...just got into work
<fabbione> ehehe
<zul> and having my coke 
<zul> so ill be awake in  a couple of minutes ;)
<fabbione> coke?
<fabbione> tsk :P
<fabbione> coffe + cock
<fabbione> MEH
<fabbione> coke
<fabbione> sorry
<zul> umm...ok :)
<zul> arrgh...why do people have to use 2.6.11
<zul> #8450
<fabbione> i don't see it on kernel-bugs
<zul> its under kernel-package
<fabbione> ah ok
<fabbione> zul: kill it with pleasure
<zul> Ill just 2.6.11 is not supported at this time
<fabbione> sure go ahead
<zul> wohoo...done
<zul> for that k3b bug are you using scsi-emulation?
<fabbione> nope
<fabbione> but k3b is the royal suckage
<zul> ah..
<fabbione> it uses external programs to perform N operations
<fabbione> and internal code for others
<fabbione> the internal code sucks
<zul> heh...sucks
<smurfix> Ouch. My ibook doesn't suspend-to-RAM any more ... or, more precisely, it doesn't wake up properly
<crimsun> fabbione: fwiw, I've been using 1.0-7167 for about a week, and it's fine.  It even works again with one machine with a TNT2, which was a showstopper with 1.0-6629.
<fabbione> crimsun: thanks
<crimsun> np
<T-Bone> howdy
<zul> hey
<zul> damn it thats 2 i hade to kill
<zul> the sis bug you need extra modules from the company
* T-Bone can't grok that phrase :}
<zul> grr...me english bad...me need caffine
<zul> #8426 - you need to download extra drivers from SIS to get the network and sata to work properly
<zul> brb...going for caffine
<fabbione> yeah
<T-Bone> huhu
<zul> ill have a look at it tonight
<fabbione> zul: no rush.. it won't make it for hoary
<fabbione> let's jerk a bit until the 8th
<fabbione> after that we need to really sprint a lot for the next 5 months and 3 weeks
<T-Bone> fabbione: and you call that a "sprint"? :)
<fabbione> yeah..
<zul> fabbione: sure
<zul> heh i been slacking off the past couple of days
<fabbione> yeah but you also deserve it
<zul> i do? :)
<fabbione> oh fuck you Chuckj
<fabbione> :)
<zul> hehe..:)
* fabbione shows the middle finger to zul
<zul> i love you to :)
<fabbione> ..|..
<fabbione> don't make me goatse you
<zul> fabbione: check the /topic ;)
<fabbione> haha
<fabbione> ok you deserved it
<zul> lol
<fabbione> ahaha
<zul> how ironic we talked about that at lunch today
<fabbione> yeah
<zul> oh how i hate the palm
* ..[topic/#ubuntu-kernel:lamont] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre33--2.6.10 playground: kernel-debian--experimental--2.6.10 | Get it or http://www.vijaygill.com/pics/stfu.gif | There are no kernel bugs.. only broken hardware | Kernel Team Meeting: see #ubuntu-meeting
<lamont> that late?  lunch time
<zul> hah i can die now
<zul> i can convert propiratary data from a scheduling program to palm pdb format..in essence i have written a conduit in perl ;)
<zul> yes i am crazy mofo
<T-Gone> perl? Thou shall perish for such a crime
* T-Gone has written a scheduling converter in C that convert "Varuna" calendars into various formats
<T-Gone> C/Yacc actually. Because I can ;o)
<zul> perl was available at the time
<T-Gone> still it sucks. Hell. =] 
<zul> its not that bad
<T-Gone> no, you're right
<T-Gone> it's worse than that ;] 
<zul> bleah...im going home...talk to you later
<T-Gone> cya
#ubuntu-kernel 2005-04-12
<jbailey> svenl: There?
<fabbione> morning
<zul> evening
<fabbione> hey zul
<zul> what are you doing up?
<fabbione> testing the cd image that Kamion prepared for me last night
<fabbione> before the daily run
<zul> ah..
<zul> i was just spending time with my wife tonight
<fabbione> my wife is sleeping at 5:40 am :)
<zul> well its only 10:40 PM and she is watching tv
<zul> wtf is lilo going on about?
<kylem> "april fools" i think.
<kylem> he's being a dumbass.
<kylem> some things are just way more irritating than funny.
<zul> heh...maybe the it people at work should turn off the mail servers...now that would be funny
<fabbione> i should just use one of my backdoors and shut down half of internet in europe for the rest of the day
<zul> shut off the french we dont need them..no one wants to talk to T-Bone anyways ;)
<fabbione> yeah i could do that
<zul> fabbione: send en email to -users saying that if you installed the nvidia drivers i now have backdoor to your system...kthxbye
<kylem> fabbione, eh? who do you work for? :)
<fabbione> zul: meh!
<fabbione> kylem: canonical.. but i have been working around alot :)
<kylem> :)
<fabbione> ahah
<zul> night
<svenl> jbailey: yep.
<jbailey> svenl: I managed to sort it out.  benh pointed out to me that yaboot can't boot directly off of a raid array - need a seperate /boot
<jbailey> svenl: Someone mentioned that you were hacking partman to set that all up correctly - are you still doing that?
<svenl> jbailey: nope.
<svenl> partman is an unmaintainable mess, i won't touch it even with a 10 foot pole, as they say.
<svenl> jbailey: i tried to do some partman-prep for prep and IBM rs6k boxes, but i doesn't work as expected.
<jbailey> 'kay.  In case I wind up doing it (which I might, since setting up raid was otherwise really annoying yesterday), am I right in that there isn't a special partition type for md partitions?
<jbailey> I wasn't able to find alot of information yesterday on mac partition tables and linux.
<jbailey> (I did discover that evms likes to eat mac partition tables, though...)
<zul> oi who is that ugly mug on planet
<svenl> jbailey: you really need parted 1.6.23 (not yet released) though.
<svenl> jbailey: last i checked, setting up lvm over raid was no problem in partman.
<svenl> oh, you mean telling partman you need a separate boot ? 
<jbailey> No, the raid configuration bits don't see any raid partitions, and partman doesn't give any way of setting some up.
<svenl> what i do is have a 1GB /boot and a 1GB swap on the other disk, and then do LVM over raid 0/1 with the rest of the partition.
<svenl> jbailey: that is because you don't use the right parted.
<svenl> jbailey: works fine with debian on pegasos.
<svenl> jbailey: would work out of the box with the 1.6.23 version of parted even on pmacs.
<jbailey> 'kay, so I won't fret about it - we'll get it automatically after we start merging again.
<svenl> yep.
<svenl> it should work on pegasos already though.
<fabbione> hey guys
<fabbione> we need a kernel release name :)
<fabbione> we are greenlight for -33 (security fixes)
<fabbione> from the last list we have:
<fabbione> 7:37fabbione"Orgasmic Onions"
<fabbione> 07:38fabbione"Tripping Tomatoes"
<fabbione> 07:38fabbione"Super Spinach"
<fabbione> 07:38fabbione"Marvelous Marrow"
<zul> gangreen goats
<zul> er..gangreen goatcheese
<fabbione> zul: since when goats are vegetables?
<zul> cheezy cantalopes
<fabbione> wth is that?
<zul> type of mellon
<fabbione> lamont: where are your kids?
<zul> heh i suck
<fabbione> i guess i need to dict cheezy
<fabbione> zul 
<fabbione> a cheezy melon sounds really disgusting
<zul> heh i know
<fabbione> shitty squash is more inviting
<zul> hehe
<fabbione> jbailey: you are a vegan...
<fabbione> you are supposed to know everything about veggies
* jbailey scrolls back a bit.
<jbailey> The only mellon I like is watermellon.  I chould ask Angie about a 'cheesy mellon' when she's back.
<jbailey> Or are you just looking for fun suggestions of 'adjective vegetable'?
<jbailey> The more I dig through Xu's initrd-tools stuff, the more I think that he wished he could do it in perl instead.
<fabbione> jbailey: just check the last 2.6.10 changelogs and you can get an idea
<zul> perky pear
<jbailey> If fruits are allowed, the deadly dragonfruit. =)
<fabbione> jbailey: something more positive about it? ;)
<fabbione> zul: we have a scheduled released called perky psomething
<zul> bleah
<fabbione> but yes.. fruits are allowed too
<zul> sorry just in a bad mood
<fabbione> zul: don't worry dude...
<zul> nothing to do with you guys...people at work are the suxor
<fabbione> zul: still.. don't worry..
<fabbione> if something is no good with us we should just talk
<fabbione> i am still up for the "Orgasmic Onion" :)
<zul> oh if there was something you would hear about it ;)
<fabbione> it sounds really nasty :)
<zul> pervert 
<zul> :)
<jbailey> It's still April 1, you could dedicate it to jdub and name it 'and a pair of testicles' or whatever his last gnome one was....
<fabbione> no jdub in my changelos
<fabbione> he already flooded them with that idiotify patch
<jbailey> =)
<jbailey> Then the onions one sounds fun. =)
<zul> zooarific zuchini
* fabbione applies an auto dict on zul
<jbailey> If you want a sex theme, followed by succulent strawberries
<jbailey> big bannana
<jbailey> And then just "mellons"
<fabbione> AHAHHA
<fabbione> The "Big Banana on Succulent Strawberries" Release ?
<zul> hehe..the a to z of adjectives http://community.channel4.com/eve/ubb.x/a/tpc/f/7986032211/m/5340038231
<fabbione> Gigantic Garlic ?
<zul> heh
<jbailey> Reminds me of my minister refering to people as 'pew potatoes' once. =)
<fabbione> let's go for big banana
<fabbione> and we will follow succulent stawberries on -34 or -33.1
<fabbione> which one will come first
<fabbione> or better.. which one will stay in hoary
<lamont> snappy spinach
<fabbione> lamont: too late :(
<lamont> kids leave for school at somewhere between 6:45 and 7:00 US/Mountain
<fabbione> i was signing the commits when you suggested
<zul> damn thats early
<zul> i dont leave for work until 7:30
<fabbione> i start to work between 5 and 6 am
<zul> yeah but you are crazy
<jbailey> zul: I start at 7. =)
<zul> jbailey: im government though :)
<lamont> school starts at 7:30 for the older one, and it's a 30+min drive to the school
<fabbione> -33 is in
* fabbione does the baz dance
<zul> did you add the futex stuff you and pitti were talking about this morning?
<fabbione> yes
<fabbione> futex and dri
<zul> futex from bk or security focus?
<zul> nevermind why dont i just go read the changelog
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre34--2.6.10 playground: kernel-debian--experimental--2.6.10 | There are no kernel bugs.. only broken hardware | It's friday 1st of Apr: STFU!
<fabbione> zul: bk
<fabbione> http://linux.bkbits.net:8080/linux-2.6/cset@421cfc11zFsK9gxvSJ2t__FCmuUd3Q
<fabbione> this one
<zul> yeah that was the one i was looking at
<zul> yay...antoher race
<fabbione> where+
<fabbione> ?
<zul> http://linux.bkbits.net:8080/linux-2.5/gnupatch@424cce15dqRorp5LwCSspurmm1KAsQ
<fabbione> fuck
<zul> heh
<zul> what would you do without me :)
<fabbione> zul: HAVE A LIFE!
<zul> true...but that isnt any fun
<fabbione> i guess we will have a very fast release cycle
<T-Bone> howdy buddies
<zul> jambo
<fabbione> life sux thanks to zul
<T-Bone> ah!
<zul> if im in a bad mood then everybody else has to be
<T-Bone> i knew life sucked but i didn't know who to blame
<T-Bone> thx fabbione for solving that point ;] 
<zul> fabbione: dont worry ill find a couple of more races for you
<fabbione> zul: thanks :)
<zul> no probs...spreading misery is my goal today
<fabbione> zul: i can send you my wife, if that can be of any help
<zul> nah...one wife is enough im not a mormon
<zul> fabbione: got this one? http://linux.bkbits.net:8080/linux-2.5/gnupatch@4248d87aETPJX79hVXl4owAUwu2SmQ
<T-Bone> zul: i thought one wife was too much already? ;] 
<zul> oh it is
<zul> fabbione, enjoy..http://linux.bkbits.net:8080/linux-2.5/cset@1.2181.41.242?nav=index.html|ChangeSet@-4d
<fabbione> zul: meh STOP
<fabbione> i can't even open links so fast
<zul> doing a search for "race" on bk is so much fun :)
<zul> ok im done ;)
<fabbione> zul: please take all this shit and send a mail to pitti with me in cc
<fabbione> i plan to get SEX this night
<fabbione> that includes spending time with my wife
<zul> should have done it last night like some people
<zul> like T-Bone 
<T-Bone> fabbione: i pity you
<zul> if you want i can add the patches to my baz 
<T-Bone> fabbione: i didn't know that getting married implied "planning sex" ;] 
<zul> oh it does
* T-Bone laughs 3v1l and runs
<zul> you say to your wife can i pencil you in for such and such a date..
<fabbione> zul: i need pitti to check that stuff. patching isn't an issue
<zul> ok
<T-Bone> zul: lol, what a nightmare
<zul> meh...it works
<T-Bone> zul: i guess i don't want to get married (yet) :)
<zul> anyways
<T-Bone> life sucks
<T-Bone> =] 
<jbailey> Getting married doesn't imply having to plan dates for sex, working for Canonical does ;)
<T-Bone> ewww ;P
<fabbione>   The "Succulent Strawberries" Release.
<fabbione> jbailey: :)
<T-Bone> no way i'll work for them then. Missa not planning sex, missa having sex. Much cooler ;] 
<jbailey> Still April 1st, do you think we can get the web page to say 'Whorey'? =)
<T-Bone> LOL
<T-Bone> that'd be *really* nasty :)
<zul> its how i pronounce it
<fabbione> you are sick
<zul> hehe
<zul> time to fill my belly
<fabbione> zul: can you please mail pitti and me with that 3 links?
<zul> sure
<zul> what's pitti's address?
<fabbione> if you can do it now it would be better
<zul> ok
<fabbione> martin@piware.de
<fabbione> i can't remember his @ubuntu.crack.com
<fabbione> and i am off for dinner
<fabbione> i will pass by later to see what's the situation
<T-Bone> fabbione: SNAFU ;)
<fabbione> SNAFU = Shutup Nerd And Fuck You ?
<fabbione> ok i am gonna for real :)
<zul> done
<zul> lunch
<lamont> fabbione: Situation Normal, All F'ed up.
<lamont> martin.pitt@ubuntu.com
* T-Bone -> concert, bbl
<T-None> fabbione: that's an idea. Generally it's "Situation Normal: All Fucked Up" ;] 
<T-None> lamont: i'll have to talk to you l8er. ggg's cluster arrived, *POWER* on the way ;] 
<lamont> heh
* lamont wanders off for a few minutes
* T-None should be back in 2h+, guitar concert in paris
<zul> cool
* T-None is gone
<fabbione> wow lamont is signing keys :)
<lamont> fabbione: feh
<lamont> figured it was about time...
<kylem> april fools?
<lamont> kylem: nah, from mataro
<lamont> so still < 4 months old
<kylem> :)
<kylem> iirc you were pretty quick with ols2003
<lamont> yeah.
<lamont> it varies
<fabbione> bum
<fabbione> you just made thunderbird crashing again
<fabbione> i don't understand why it keeps dieing importing keys
<zul> kylem: i take it you are going to ols?
<fabbione> everything seems to be ok..
<fabbione> i am off
<fabbione> cya tomorrow
<kylem> zul, yup
<lamont> kylem: gonna actually stay at the hotel?
<kylem> nope.
<kylem> unless someone lets me crash in their room.
* lamont hopes to make ols this year. dunnpo
<zul> lamont: it would be cool...then you can sign my key and then wait another 4 months
<lamont> heh
<kylem> :)
<zul> later
#ubuntu-kernel 2005-04-13
* T-Bone wonders whether we have preliminary hppa installer he could test on his brand new hw
<zul> hey
<crimsun> oh man.
<crimsun> even newer Nvidia drivers.
<crimsun> (http://www.nvidia.com/object/linux_display_ia32_1.0-7174.html)
<crimsun> (and http://www.nvidia.com/object/linux_display_amd64_1.0-7174.html)
<zul> fabio isnt going to like that :)
<crimsun> nope, he sure isn't.
<fabbione> morning
<crimsun> morning
<fabbione> dilinger: ping?
<dilinger> pong
<fabbione> dilinger: you should probably get -33 and grab the security fixes
<fabbione> sorry i had no time to push them to you yesterday
<fabbione> they also assigned a CAN for your patch 143
<fabbione> the sysfs signess whatever fix
<dilinger> thanks; already looked at -33
<fabbione> zul found another 3 race condition fixes
<dilinger> for 2.6.11, anyways
<fabbione> he posted the bk commits in here
<dilinger> still need to deal w/ older kernels
<dilinger> oh?
<fabbione> just a sec.. i will forward the mail
<fabbione> on the way
<fabbione> one for sure needs to be applied
<fabbione> it's Herbert fix to his previous fix
<fabbione> they have not been classified as security yet
<fabbione> pitti is investigating the other 2 i think
<dilinger> ok
<zul> morning
<T-None> ugh
<T-Bone> -33 hppa64 doesn't boot :P
<T-Bone> Unable to identify CD-ROM format.
<T-Bone> cramfs: wrong magic
<T-Bone> piKernel panic - not syncing: Attempted to kill init!
* T-Bone reads backlog, notices XFS isn't tried, screams
<lamont> we planning a -34?
<T-Bone> hey lamont
<lamont> morning t-bone
<T-Bone> lamont: i've been flooding you in pv window ;}
<lamont> yeah - saw it
<lamont> get a good kernel
<T-Bone> the good thing is that it's getting better
<T-Bone> the bad thing is that your archive is corrupted
<lamont> ??
<T-Bone> yeah, if you look a few lines above, i just tried -33 which doesn't know XFS, seemingly
<lamont>  /boot/config-2.6.10-2-64:# CONFIG_XFS_FS is not set
<T-Bone> lamont: the Dubious version messages came from your archive
<lamont> that'd be correct
<T-Bone> lamont: that's bad, let's change that for -34
<T-Bone> lamont: your archive seems to contain packages taken from Debian. Their version numbers are newer than those in Ubuntu
<lamont> (and yes, it's been disabled since the beginning of time...)
<T-Bone> that's especially true for perl, which is incomplete, and thus not installable
<T-Bone> lamont: please enable it in -34 ;] 
<lamont> "my archive" == ubuntu-hppa/tree or ubuntu-hppa/lamont?
<T-Bone> /lamont
<T-Bone> tree is just fine
<T-Bone> except that it lacks up-to-date python2.4, which makes d-i unbuildable
<T-Bone> that's why i'm trying to build python2.4 asap ;}
* T-Bone larts lamont for bad archive management ;^)
<lamont> ah, yeah.
<lamont> that makes sense
<zul> heh.../me is working on the bk stuff
* lamont makes a note to move all the stage[12]  stuff out of /lamont
<lamont> T-Bone: I only created that packages file because you wanted it... :))
<T-Bone> LOL
<T-Bone> bad bad you :)
<T-Bone> in any case, i've removed that archive from my sources.list and w-b merge, and i'm building all that's missing
<T-Bone> xorg updated to -9
<T-Bone> currently building gcc
<zul> how do you create a new baz archive?
<T-Bone> lamont: we're getting there. Down to 20% uncompiled
<T-Bone> ;)
<lamont> zul: bas make-archive -s ...
<lamont> baz make-archive --help
<zul> okie dokie
<T-Bone> most of it is kde shit not building because of yet uninstalable kdelibs4
<zul> you mean kde poopie dont you?
<T-Bone> i guess so ;)
<T-Bone> lamont: i have a modified d-i source that i expect to install fine now. Need to build it (that requires python2.4 up-to-date) to confirm :)
<lamont> T-Bone: xfs as a module, or =y?
<T-Bone> module
<lamont> and does it create any additional questions?
<T-Bone> ?
<lamont> nm - I'll go test it
<T-Bone> lamont: look how it's done in debian or in other archs in ubuntu?
* T-Bone needs to find a recent enough kernel that'd boot his j6k
<T-Bone> lamont: btw, xresprobe builds fine now, kudos (as of 0.4.18)
<lamont> # CONFIG_XFS_RT is not set
<lamont> CONFIG_XFS_QUOTA=y
<lamont> # CONFIG_XFS_SECURITY is not set
<lamont> CONFIG_XFS_POSIX_ACL=y
<lamont> that'll be a yes
<lamont> yeah - daniel included my patch
<T-Bone> ah, you mean "that" kind of questions :)
<lamont> yeah
<T-Bone> i thought you were talking about d-i :)
<lamont> well, you still won't have XFS for install, since there's no module for it ...  that's a kernel and d-i change
<T-Bone> correct
<lamont> guess I could have the kernel deliver the udeb 
<T-Bone> that'd be nice
<T-Bone> i mean, let's do it as other archs do. My changes in d-i source were mostly copying what was done for ia64
<lamont> yeah
* T-Bone wishes there were a way to tell the kernel build process "I only want that flavour please"...
<zul> T-Bone: there is but you have to modify the rules file
<T-Bone> how big is that change?
<zul> one line
<T-Bone> give it! :)
<zul> only if you say please
<T-Bone> oh dear zul, please hand over your immense knowledge and kernel-build-fu to the poor beggar I am =] 
<zul> better..
<T-Bone> ;}
<zul> comment out the flavours line in the rules file and replace it with flavours := hppa
<lamont> zul: better watch out, or he'll find a tall iron building in new york and invoke you
<zul> heh
<T-Bone> LOL
<zul> back to pope watch 2005
<zul> yay...2.6.12-rc1-bk4
<T-Bone> 8GB RAM does *speed* up builds *alot*
<zul> its all in your head
<T-Bone> i wonder :)
<fabbione> hmm
<fabbione> lamont, T-Bone: i have no issue in adding XFS for hppa in 34
<fabbione> and yes there will be a -34 (99.9999%)
<fabbione> just be sure that it is propagated properly
<zul> because of me? :)
<fabbione> if you care
<fabbione> zul: yes. DIE!
<fabbione> :P
<T-Bone> fabbione: cool
<T-Bone> fabbione: do you know what's in ide-core-modules ?
<fabbione> lamont: do you have time to check something for me?
<zul> hmmm...how do i tell a user that he sucks...taticfully
<T-Bone> we do not generate that udeb on hppa
<lamont> fabbione: sure
<fabbione> T-Bone: you can check it yourself. install kernel-wedge and check
<lamont> btw, mind if we dink around with what modules get built on hppa for -34?
<fabbione> lamont: can you try to test build kdebindings (last version) and see how much memory it sucks?
<fabbione> lamont: as i said about it is fine with me
<T-Bone> drivers/ide/ide-core.o
<lamont> zul: you either have to refine the meaning of 'sucks' to something objective, or accept the fact that he won't take it peacefully
<T-Bone> something tells me we want that on hppa
<fabbione> just prebuild it to see if everything goes at it should
<lamont> fabbione: cool
<fabbione> lamont: if you can run that build it would be really appreciated. here on sparc is sucking almost 1.2GB for one file
<zul> lamont: #8426
<fabbione>  g++ -DHAVE_CONFIG_H -I. -I/build/sparcbuildd/kdebindings-3.4.0/./smoke/kde -I../.. -I/build/sparcbuildd/kdebindings-3.4.0/./smoke/kde/.. -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-s
<fabbione> this one specifically
<fabbione> lamont: i am afraid of some memory leak somewhere, but the point is that it might pass our buildd, but not normal machines
<lamont> i386 took 600+MB and 37 minutes
<T-Bone> lamont: how shall i kill you?
<fabbione> i am talkign about RAM
<T-Bone> WARNING: The following packages cannot be authenticated!
<T-Bone>   cdebconf-udeb archdetect anna casper-check cdebconf-priority
<T-Bone> ...
<fabbione> it's up to 1.3GB now
<lamont> fabbione: right
<T-Bone> E: There are problems and -y was used without --force-yes
* T-Bone hates that signed shit
<lamont> T-Bone: add the key
<lamont> and it's mvo/mdz you want to kill for it
<T-Bone> lamont: how/where?
<lamont> fabbione: right
<T-Bone> lamont: my archive isn't signed
<T-Bone> that's not the problem of the key
<lamont> T-Bone: ah, well sign it
<fabbione> lamont: no rush, but i am just curios to understand wtf it is doing
<T-Bone> it just can't cope with unsigned archive
<T-Bone> lamont: how?
<lamont> create a Release file, gpg --detach-sig Release; mv Release.sig Release.gpg
<fabbione> T-Bone: or use the workaround:
<lamont> and make sure that the key you used is in /etc/apt/trusted.gpg in the chroot
<fabbione> cat chroot-hoary/etc/apt/apt.conf
<fabbione> APT::Get::AllowUnauthenticated "1";
<lamont> or do that
<T-Bone> fabbione: ah! THANKS!
<T-Bone> ;}
<lamont> in /etc/apt/apt.conf
<T-Bone> lamont: i'm 90% certain we need to produce ide-core-modules udeb btw
<lamont> fabbione: I don't have kdebindings in my local mirror... and probably not the build-deps either
<lamont> T-Bone: we do generate the modules, at least... :0)
<fabbione> lamont: perhaps you can run it at the DC?
<lamont> fabbione: yeah - I'll do a build on concordia or some such
<T-Bone> lamont: heh :)
<fabbione> lamont: danke
<T-Bone> lamont: you see, in the ongoing port war, it is not acceptable that fabbione has d-i ready on sparc and we don't have it on hppa ;] 
<fabbione> T-Bone: you will never have it for hoary anyway :)
* fabbione rocks 
<T-Bone> fabbione: lol
<T-Bone> fabbione: hoary releases next week?
<fabbione> sparc > hppa
<kylem> fabbione, them's fighting words.
<T-Bone> fabbione: not in number of built packages :)
<fabbione> T-Bone: how many buildds do you have? and with how many cpu's + gb of ram?
<T-Bone> fabbione: i expect to have the installer ready by tomorrow, given a proper kernel
<lamont> T-Bone: we had a booting miniiso before he did
<T-Bone> fabbione: *LOADS* ;] 
<T-Bone> lamont: hehe cool! hppa > sparc ;)
<lamont> mind you, you couldn't do anything with it.
<fabbione> T-Bone: than divide the num of your packages by (num of buildd * num cpu * Gb of RAM)
<T-Bone> lol
<fabbione> T-Bone: and i will do the same
<lamont> fabbione: I think we fixed xresprobe for you with 0.4.18 as well
<fabbione> the one with the higher num, wins
<T-Bone> fabbione: i don't do maths :}
<lamont> or was sparc already in the makefile the wrong (old) way?
<T-Bone> Failed to fetch http://people.ubuntu.com/~lamont/ubuntu-hppa/tree/pool/main/c/console-data/console-keymaps-usb_2002.12.04dbs-48ubuntu5_all.udeb  404 Not Found
<fabbione> lamont: nope.. i did fix xresprobe for hppa
* T-Bone curses lamont
<fabbione> lamont: and i did give you a kernel :)
<lamont> when did you fix xresprobe for hppa?
<lamont> because it hasn't built until 0.4.18, when daniels took my patch
<fabbione> lamont: i fixed xresprobe for hppa the same time i uploaded the fix for sparc
<lamont> ftbfs
<fabbione> using the dummy_thing.x
<fabbione> well, you never told me
* fabbione doesn't have a crystal ball yet
<fabbione> :)
<fabbione> ah no
<fabbione> xresprobe (0.4.12) hoary; urgency=low
<fabbione>   * Fix ia64 and sparc port.
<fabbione>  -- Fabio M. Di Nitto <fabbione@fabbione.net>  Sun, 21 Nov 2004 12:46:23 +0100
<lamont> that's because it's been ftbfs all along, and I'd sent daniels the patch to just make it use dummy _EVERYWHERE_ that it didn't use one of the other two, instead of hardcoding each *()^*_& architecture one at a time
<fabbione> i fixed ia64
<T-Bone> lamont: missing udebs are casper-check, di-utils, di-utils-reboot, di-utils-terminfo, hotplug-udeb, kickseed-common, localechooser, console-keymaps-at, console-keymaps-usb and initrd-kickseed
<lamont> fabbione: ah, and I fixed everything else, and removed your ia64/sparc fix by subsuming it.
<fabbione> lamont: my bad.. it was ia64
<lamont> fabbione: heh
<fabbione> lamont: right
<T-Bone> lamont: can you fix that in an easy way or should i build something?
<fabbione> well mdz is not around
<fabbione> i am going to help my wife to cook dinner
* T-Bone begs lamont
<fabbione> later guys
<T-Bone> fabbione: cya
<zul> toodles
<T-Bone> linux-source-2.6.11_2.6.11-0.2: currently building
<T-Bone> ARG!
<lamont> T-Bone: bide
<T-Bone> lamont: yeah sorry :}
<T-Bone> lamont: so, what should I do?
<lamont> T-Bone: those are all newer than what I have in my archive...
<lamont> you may just need to build them
<lamont> for quick-turn that is
<T-Bone> what package builds them?
<lamont> T-Bone: casper, debian-installer-utils, hotplug, kickseed, console-data
<T-Bone> lamont: it's strange. The only package != universe I have left to be built are:
<T-Bone> devel/debian-installer_20041227ubuntu23 [extra:uncompiled] 
<T-Bone> debian-installer/kbd-chooser_1.09ubuntu16 [-:uncompiled] 
<T-Bone> misc/archive-copier_0.1.3 [-:uncompiled] 
<T-Bone> unknown/palo-installer_0.0.6 [-:uncompiled] 
<T-Bone> which means that they are supposedly up to date in your archive...
<lamont> it's possible that udebs aren't current in my archive..
<T-Bone> gah
<T-Bone> i hate you :P
<lamont> the target was 'debootstrapable' at the time, if you recall
<T-Bone> lamont: problem is i don't have your changes to console-data to get it build
<lamont> sec
<T-Bone> not to mention that telling w-b to force rebuild those packages isn't gonna be cool
<T-Bone> unless there is a magic command?
* lamont pushes things around a bit
<T-Bone> ah! Thanks you sooooooo much ;}
<lamont> w-b --forget, w-b --take, echo "foo_ver hoary" > build/REDO
<lamont> for each foo_ver
<T-Bone> yumm
<lamont> and finish that before the next time you run merge-quinn
<T-Bone> more yumm
<lamont> baz register-archive http://people.ubuntu.com/~lamont/Archives/lamont@ubuntu.com--hppa-2005
<lamont> is mirroring there now
<lamont> lamont@ubuntu.com--hppa-2005/console-data--hppa--2002.12.04
<lamont> is the current console-data
<T-Bone> baz get that I suppose?
<lamont> on the bright side, once hoary releases, we won't have to keep merging the patch forward.
<lamont> yeah
<lamont> although it's not popultaed yet
<T-Bone> No such package (console-data--hppa)
<T-Bone> heh :P
* lamont types his passphrase a few hundred times
* T-Bone parses quinn-diff to figure out the version numbers of corresponding packages
<T-Bone> i must really be damn willing to get that thing to work, cause it's kinda boring ;] 
<lamont> heh
<lamont> you sound like my 9 year old. :-)
<T-Bone> lol
<T-Bone> i hate you soooooo much :}
<lamont> "but it's _BOORIIINNNNGGGG"
<T-Bone> that's the idea, yeah :)
<zul> T-Bone: do you want a lolly?
* T-Bone ponders building missing udebs out of the buildds using his local sbuild
<lamont> the only lolly I know is married
<T-Bone> zul: you, i kill you, you!
<lamont> T-Bone: that would be simplest
* lamont starts an rsync of his local mirror up to p.u.c
<T-Bone> lamont: definitely. Just need to find versions
* T-Bone greps and greps more
<T-Bone> hmm
<T-Bone> i knew this wasn't that easy
<T-Bone>  /usr/bin/fakeroot debian/rules binary-arch
<T-Bone> make: Nothing to be done for `binary-arch'.
<T-Bone>  dpkg-genchanges -B -mUbuntu hppa unofficial buildd <buildd@buildd.slashdirt.org>
<T-Bone> dpkg-genchanges: arch-specific upload - not including arch-independent packages
<T-Bone> dpkg-genchanges: failure: cannot read files list file: No such file or directory
<T-Bone> lamont: that's casper
<lamont> ew
<T-Bone> yeah, that's what I said too :P
<T-Bone> isn't casper "all"?
<T-Bone> Architecture: all
* T-Bone giggles
<T-Bone> same goes for hotplug
<T-Bone> and kickseed
<lamont> well, in that case, add that horrible hack to pull them from the real archive
<T-Bone> i'm left with console data, and another tweak to sources.list.udeb.local to add something that will make it get all udebs
<T-Bone> deb http://archive.ubuntu.com/ubuntu dists/hoary/main/debian-installer/binary-i386 ?
<lamont> console-data source and debs in ubuntu-hppa/lamont if you want to go that route
<T-Bone> much easier
<T-Bone> lamont: 403
<lamont> grumble
<T-Bone> i guess so :)
<lamont> fixed
<T-Bone> thx
<lamont> btw, baz mirror of console-data done, working through ubuntu-meta now
<T-Bone> ok
<T-Bone> building console data
<lamont> udebs were there too, you know...
<T-Bone> yeah, but i can ;}
<T-Bone> i don't trust that archive no more, you see... =] 
<lamont> mind you, it could be completely wrong, since it just clones the i386/ppc/whatever keymaps into hppa...
<T-Bone> huhuhu
<T-Bone> gonna be fun
<lamont> funny part is that those debs you found aren't in changes files anywhere...
<lamont> which is just plain wierd
<T-Bone> for my current usage i don't need it anyway (serial console), but we'll have to look at that
<lamont> yeah
<T-Bone> my top priority is getting a netbootable installer image sufficient to net install machine using serial console, for next friday
<T-Bone> once I have that, it'll be time to look at something more suitable :)
<lamont> that's 99% of the way there, of course...
<T-Bone> indeed
<T-Bone> console-data successfully built
* T-Bone tries again to build d-i
<T-Bone> E: Malformed line 3 in source list /build/varenet/debian-installer-20041227ubuntu24/build/sources.list.udeb.local (dist parse)
<T-Bone> shit
<T-Bone> it doesn't like the hack
<T-Bone> lamont: can you move the all.udebs in place or can you tell me how to do that?
<lamont> fetch the packages.gz file from the right place, and lots of wgets
<T-Bone> sigh
<lamont> or edit the local sources list like it says
<T-Bone> that's what i did
<T-Bone> and it didn't like it
<T-Bone> cat sources.list.udeb.local
<T-Bone> deb http://archive.slashdirt.org/udebs ./
<T-Bone> deb http://people.ubuntu.com/~lamont/ubuntu-hppa/tree hoary main/debian-installer
<T-Bone> deb http://archive.ubuntu.com/ubuntu dists/hoary/main/debian-installer/binary-i386
<lamont> sigh.
<T-Bone> indeed :P
<lamont> yeah - just grab the binary-i368/Packages.gz, grep for _all.udeb, and wget those lines
<lamont> then apt-ftparchive that tree
<T-Bone> will do
<lamont> baz mirror complete
* T-Bone attempts again to build d-i
<T-Bone> lamont: btw, i'm quite worried at how gcc-3.4 build failed...
<T-Bone> yay, all udebs were downloaded fine
* T-Bone wanders away for a short while (dinner time)
<zul> meh..
<T-Bone> yatta, d-i built successfully
<zul> yatta? is that french french ;)
<T-Bone> iieh
<T-Bone> sole wa nihongo dessu ;] 
* T-Bone tries to figure zul's face, laughs ;] 
<zul> mama toifea kusotare
<T-Bone> lol
<T-Bone> Freeing unused kernel memory: 316k freed
<T-Bone> Setting up filesystem, pattempt to access beyond end of device
<T-Bone> lram0: rw=0, want=16520, limit=16384
<T-Bone> eaKernel panic - not syncing: Attempted to kill init!
<T-Bone> s e wait ...
<T-Bone> Can't find /proc in /etc/fstab
<zul> hah hah
* T-Bone looks at lamont, points at known problem, looks for a fix in d-i source
* T-Bone larts zul ;] 
<zul> its called karma
* T-Bone notes he wants 64bit kernel, given the amount of RAM
<lamont> T-Bone: huh?
<lamont> T-Bone: sore wa nihongo desu
<T-Bone> lamont: our initrd is too big
<lamont> hrm.. fix that
<T-Bone> how?
<lamont> oh, there's the ramdisk thing
<lamont> see what ia64 does for default args
<lamont> boot with ramdisk=<number of KB>iirc
<lamont> or ramdisk_size
<lamont> or some such
<T-Bone> that's what i'm trying
<T-Bone> and it doesn't work
<lamont> btw, u-h/lamont cleaned up to just have current versions of stuff in it
<T-Bone> using ramdisk_size=16800 hangs the boot
<T-Bone> isn't palo limited in the amount of memory it can use for loading kernel/initrd?
* lamont would be asking Kamion about that, if it weren't 1 week before release
<lamont> could be
<T-Bone> SNAFU
<lamont> nah, normally it works...
<lamont> you could look at what debian/hppa does
<T-Bone> debian/hppa has a much smaller initrd
<T-Bone> kylem's last post about that was explicit
<lamont> so what don't they include that we are?
<T-Bone> pdc_iodc_bootin() died during seekread
<T-Bone> it's not dead!
<T-Bone> it just prompted me that
<T-Bone> lamont: any clue what that means?
<T-Bone> i suspect palo limitation wrt size of initial boot material
* T-Bone wonders what's on the ramdisk
<T-Bone> 14M     build/udebs/
<T-Bone> lamont: where should i look at, supposing i want to remove a bunch of stuff from the initrd?
* lamont shrugs
* T-Bone hates initrds
<T-Bone>  12M Mar  7 00:46 debian-di.img
<kylem> i concur.
<T-Bone>  13M Apr  2 21:13 ubuntu-di.img
* T-Bone wonders
<kylem> i hate cd images.
* T-Bone removes ide support, hopes that'll makes things a bit better
<T-Bone> let's remove usb as well
* T-Bone contemplates removing cdrom support, all in all
* T-Bone wonders how the ia64 installer works, given what he sees in the source tree, wonders if said installer *still* works
<lamont> lessee... 112MB at 1KB/sec... that's gonna take a while
<T-Bone> lamont: if i'm still able to do maths, if you're shapped at 56kbps, you should be able to do 7kBps (say round it at 5) :)
<lamont> yeah - but there's another rsync, and this is unshaped (since I don't shape ssh)
<T-Bone> tssks ;)
<lamont> nah - interactive perfomance is needful, dammit
* T-Bone votes for seemingly broken ia64 installer, adds random bits
* lamont test-builds -34 on hppa
<lamont> well, the config changes in -34
<T-Bone> lamont: i think there's a bunch of config options missing
<T-Bone> and another bunch of d-i udebs missing
<zul> pope is dead
<lamont> zul: you mean the machine, or that pagan leader/
<lamont> ?
<T-Bone> the machine?
<lamont> is a common name for computers
* lamont rather expected more response to the other option... :))
<T-Bone> lol
<lamont> "and no, bears aren't catholic"
* T-Bone wonders what lamont is talking about :}
<lamont> mixing around american rhetorical questions
<T-Bone> oh
<zul> as in the dude
<T-Bone> i'm completely airtight to these ;}
<T-Bone> zul: ah yes!
<T-Bone> now i remember
* T-Bone makes note to watch The Big Lebowski again soon
<lamont> zul: bummer
<zul> yep
<lamont> you catholic then?
<lamont> Setting up tetex-extra (2.0.2c-3) ...
<lamont> dpkg: error processing tetex-extra (--configure):
<lamont>  subprocess post-installation script killed by signal (Illegal instruction)
<lamont> S
<lamont> woot
<zul> lamont: for the past 2 years yep
* lamont makes a note to curb his rude sense of humor
<lamont> s/rude/black/
<zul> lamont: heh...i appreciated rude sense of humor
<lamont> heh
* lamont is around dead/hurt people way too much, you see.
<zul> im not dead...im catholic ;)
<zul> but i know what you mean
* T-Bone clobbers d-i to death, while at it
* lamont hands t-bone an urban broadsword^W^Wbaseball bat
<T-Bone> hehehehe
<T-Bone> very handy ;] 
* T-Bone grumbles
<zul> whee...bk rocks...not
<T-Bone> though i removed a whole bunch of stuff, the .img is exactly the same size as before
<T-Bone> zul: no big news ;] 
<T-Bone> hmm
<T-Bone> and the overflow is exactly as much
<T-Bone> RAMDISK: Compressed image found at block 0
<T-Bone> RAMDISK: incomplete write (-28 != 32768) 8388608
<T-Bone> VFS: Mounted root (ext2 filesystem) readonly.
<T-Bone> Freeing unused kernel memory: 316k freed
<T-Bone> Setting up filesystem, pattempt to access beyond end of device
<T-Bone> lram0: rw=0, want=16520, limit=16384
<T-Bone> '-28' heh
* T-Bone wonders whether the problem is elsewhere
<T-Bone> kylem: seen that kind of issues already?
* lamont takes daughter to the gym and probably a movie or something. back later
<T-Bone> lamont: 
<T-Bone> last question before you leave (if possible)
<lamont> si?
<kylem> T-Bone, yes, that was reported on the d-hppa mailing list a little while ago.
<T-Bone> lamont: where do you tell d-i to look for an archive? (since we don't prompt that question at install time, iirc)
<T-Bone> kylem: sigh
* T-Bone guesses he needs Kamion-fu
<kylem> T-Bone, it means your initrd doesn't fit in 16384, bump it up some more :(
<lamont> I believe that it reads /etc/apt/sources.list (and munges it...)
<lamont> that is, the copy in the chroot wins
<T-Bone> kylem: i tried, and when i do that the box doesn't boot
<kylem> maybe it needs to be a multiple of some power?
<T-Bone> lamont: hmm ok
<T-Bone> kylem: i tried 32768
<kylem> hmm.
* T-Bone contemplates the other installation option: install debian on one disk, debootstrap ubuntu on the other, reboot...
<T-Bone> yet, that doesn't fix that fucking rd issue
<lamont> T-Bone: uh, figure out what all is in the ramdisk, and how much has to go... figure out from there what to jetison?
<lamont> or shrink.
<kylem> i'm starting to get very apathetic to this whole thing.
<T-Bone> lamont: if only i understood what goes in the ramdisk
<lamont> kylem: which whole thing?
<kylem> d-i
<lamont> T-Bone: would be a research project for me too.
<T-Bone> kylem: you're not alone
<lamont> kylem: there is something to be said for just untaring a base image onto the disk...
<kylem> lamont, as long as netboot works, i'm pretty unconcerned with the rest.
<T-Bone> lamont: i dunno for kyle, but that kind of undocumented blackhole shit pisses me off *immensely*
<kylem> T-Bone, yes, that's exactly it.
<T-Bone> kylem: heh, you see, you're not alone :}
<lamont> undocumented blackhole?
<kylem> i want to fix something tiny, without spending 30 hours figuring out how everything fits together.
<T-Bone> lamont: buildd/d-i/dak and all the like
<kylem> because i don't have 30 hours to invest in it, in fact, i rarely have more than 1.
<T-Bone> that's exactly as kylem said
<lamont> ah, yes.... Networking truth #5.
<T-Bone> lamont: i'm getting more and more tired to hear "find it out by yourself"
<T-Bone> lamont: that's exactly why i left ia64: i don't like ia64, so i wouldn't fight for it
<lamont> T-Bone: heh.  at the same time, you're covering ground I haven't trodden on yet...
<T-Bone> lamont: i'm fighting for hppa, yet, it's not fun
<lamont> anyway, really must run for a while
<T-Bone> lamont: sure, but it would be so much easier if the guys who wrote that shit wrote some doc to go along
<lamont> test build of -34 kernel (with ext3 perf, and your xfs modules), running
<T-Bone> and i mean *efficient* doc, not "do this this and that to do that"
<T-Bone> because currently i'm not trying to do "that". I'm trying to understand how it works to bend it to my needs. That's what FOSS is about, if i'm right...
<T-Bone> lamont: cool thx
<zul> kylem: pinteric's platform lot of ranting little nothing
* T-Bone remembers he hasn't chosen a DPL yet
<kylem> zul, heheh.
<T-Bone> unsurprisingly, gcc-4.0 failed to build because of libtool mess. Sigh.
<kylem> :(
<T-Bone> i can't count the number of packages that failed to build because of libtool mess. I'm so glad I never used libtool in my life :P
<kylem> consider yourself fortunate.
<T-Bone> heh
* T-Bone notices he spent yet another saturday doing nothing but ubuntu stuff, loathes
<zul> welcome to my world...hope you stay a while
<zul> its uh...snowing in april
<kylem> :)
<calc> CONFIG_IDEDMA_ONLYDISK=y
<calc> that doesn't do what i think it does?
<calc> anyone awake?
<calc> config IDEDMA_ONLYDISK
<calc>         bool "Enable DMA only for disks "
<calc>         depends on IDEDMA_PCI_AUTO
<calc>         help
<calc>           This is used if you know your ATAPI Devices are going to fail DMA
<calc>           Transfers.
<calc>           Generally say N here.
<calc> erm ISN'T THAT VERY BAD?
<calc> means no optical drives will have DMA enabled, etc
<calc> seems to have been enabled in 2.6.8.1-17 (2 Nov 2004)
#ubuntu-kernel 2005-04-14
<calc> not only do they not get dma at bootup, but they can never be enabled afterwards either, the kernel disallows it
<calc> https://bugzilla.ubuntu.com/show_bug.cgi?id=2773
<calc> fixing one box to install should not result in making optical drives useless for eg burning disks for 100% of users
<zul> debian has it disabled as well 
<zul> and it has been brought up before
<calc> disabled or enabled
<calc> in ubuntu CONFIG_IDEDMA_ONLYDISK=y
<dilinger> hm
<calc> which breaks optical drives for 100% of users instead of the few that don't work with dma
<calc> since without dma the only thing that works reliably is copying files
<dilinger> i haven't seen IDEDMA_ONLYDISK cause problems w/ cdroms yet
<zul> calc take it up with fabbione he is going to tell you the same thing
<calc> https://bugzilla.ubuntu.com/show_bug.cgi?id=4809
<calc> https://bugzilla.ubuntu.com/show_bug.cgi?id=4681
<calc> it claims in here to run hdparm -d1 /dev/foo
<calc> but with that option enabled in the kernel it won't let you run that
<calc> root@calc-amd64:~ # hdparm -d1 /dev/hda
<calc> /dev/hda:
<calc>  setting using_dma to 1 (on)
<calc>  HDIO_SET_DMA failed: Operation not permitted
<calc>  using_dma    =  0 (off)
<dilinger> calc: as a matter of fact, it's enabled (dma, that is) on my cdrw/dvd drive on my laptop, and works fine
<dilinger> so it certainly doesn't break optical drives for 100% of users
<calc> well it definitely doesn't work on ppc according to bug 4809
<calc> and doesn't work on amd64 either
<calc> i could try downloading a i386 iso and see if works on that i suppose
<calc> note above says operation not permitted instead of failed
<calc> like when you pass invalid stuff to optical drives like -m16
<dilinger> sorry, i misread your initial thing
* calc will double check with a knoppix disk
<calc> but it appears to be caused by that option in the kernel
<dilinger> you're saying IDEDMA_ONLYDISK should be disabled; i'd agree w/ that
<calc> yea
<calc> it was enabled due to one persons hardware not working with dma
<calc> according to what i see in bugzilla
<calc> and it was enabled on all archs
<calc> i don't use my optical drive very often which is why i haven't noticed this earlier
<dilinger> hrm
* calc bbl, testing the drive
<dilinger> the original bug reporter doesn't mention which ide chipset driver he's using
<zul> bbl
<dilinger> the correct way to have fixed #2773, imo, would've been to either add the guy's cdrom to the list of blacklisted cdroms (drive_blacklist in ide-dma.c), or make sure there's not something screwy w/ his ide chipset driver (and make sure he's not using the generic driver)
<zul> talk to fabbione 
<calc> back
<zul> he'll be doing the upload
<calc> ok
<calc> fabbione: whats up?
<zul> dont think he is here though
<calc> ok
<calc> i verified it works fine under knoppix with 2.6.9 i386 without ONLYDISK set
<dilinger> calc: you probably missed that
<dilinger> <dilinger> the original bug reporter doesn't mention which ide chipset driver he's using
<calc> dilinger: yea i left too early
<dilinger> <dilinger> the correct way to have fixed #2773, imo, would've been to either add the guy's cdrom to the list of blacklisted cdroms (drive_blacklist in ide-dma.c), or make sure there's not something screwy w/ his ide chipset driver (and make sure he's not using the generic driver)
<calc> dilinger: yea
<calc> instead of blacklisting all ATAPI devices completely ;)
<calc> fabbione: thanks for fixing it :)
<calc> i have to go for now, but i'll be back later tonight (10-12hr probably)
* T-Bone gets back from anime watching, reads backlog, agrees that IDEDMA_ONLYDISK is a bad thing
<T-Bone> console-data is fux0red on ia64, how sweet :P
<lamont> T-Bone: sigh
<T-Bone> lamont: heh
<T-Bone> lamont: "nobody cares"
<T-Bone> :P
<lamont> not until april 9th
<T-Bone> i doubt it'll change then anyway :P
* lamont ponders d-i/hppa/package-list, feels it may be a bit lacking...
<lamont> fabbione: you around yet?
* lamont would like someone to review the changes in [http://people.ubuntu.com/~lamont/Archives/]  lamont@ubuntu.com--2005/kernel-debian--pre34--2.6.10
<lamont> before I commit them to the kernel-team branch, that is.
<fabbione> morning
<fabbione> lamont: sure i can look at it
<lamont> fabbione: the ext3 thing would be RC if we supported hppa.  and the fix is localized to hppa.  and we didn't bump the abi believe it or not.
<fabbione> lamont: i still need to checkout :)
<lamont> yeah
<lamont> should be able to just baz diff lamont@ubuntu.com--2005/kernel-debian--pre34--2.6.10--patch-2
<fabbione> baz register-archive http://people.ubuntu.com/~lamont/Archives/
<fabbione> unable to access URL: /~lamont/Archives/.listing
<fabbione> webdav error: 404 Not Found
<lamont> fabbione: baz register-archive http://people.ubuntu.com/~lamont/Archives/lamont@ubuntu.com--2005
<lamont> that was a prefix, not the complete path...
<fabbione> right
<fabbione> lamont: the patch looks fine for me
<fabbione> just go ahead and merge it in pre34
<fabbione> i only need to check one thing on .lnk files
<fabbione> because from the patch they look empty
<fabbione> but they should be
<lamont> ok
<fabbione> and the DPATCH header ;)
<lamont> heh
<lamont> yeah - I'll fix that
<lamont> ## DP: Description: Speed up some atomic ops for ext3 performance
<lamont> ## DP: Patch author: Grant Grundler
<lamont> ## DP: Upstream status: unknown
<lamont> committted
<fabbione> updating now :)
<fabbione> A   patches/parisc-ext3-perf.dpatch
<fabbione> i guess this is the famous I/O fix?
<lamont> that's the make ext3 not suck molasses
<lamont> paqtch
<lamont> so,  yes.
<fabbione> eheh
<fabbione> let's merge pre34 into experimental
<fabbione> just because i need to wake up
<lamont> modules/hppa/ide-core-modules is a broken link
<lamont> oops
<lamont> I could just move ide-core-modules back out of existance...
<lamont> wasn't sure what all that was about...
<lamont> (and that was part of why I didn't want to merge it quite yet...
<lamont> duh.
<fabbione> lamont: just commit the fix :)
<fabbione> a .lnk file uses what is provided by kernel-wedge
<fabbione> while a normal file picks up modules one by one
<lamont> right
<fabbione> just commit the fixes when you have them
<fabbione> i still didn't hear anything from pitti about the 3 race conditions
<fabbione> so there is time for -34
<fabbione> lamont: mind if i do a cosmetic change to the changelog?
<lamont> go for it./
* lamont creams
<lamont> screams, even
<lamont>  ls -la modules/hppa/ide-core-modules
<lamont> lrwxr-xr-x  1 lamont lamont 49 Apr  2 21:54 modules/hppa/ide-core-modules -> /usr/share/kernel-wedge/modules/ide-core-modules 
<lamont> lamont@smallone:~/kernel/linux-source-2.6.10-2.6.10$ more  modules/hppa/ide-core-modules
<lamont> modules/hppa/ide-core-modules: No such file or directory
<lamont> lamont@smallone:~/kernel/linux-source-2.6.10-2.6.10$ more /usr/share/kernel-wedge/modules/ide-core-modules 
<lamont> drivers/ide/ide-core.o
<lamont> what am I not seeing?
<fabbione> that the file cannot be a symlink
<lamont> that's what kernel-wedge created
<lamont> but why won't more follow the symlink?"
<lamont> s/more/open(2)/
* lamont considers just putting ide-core-modules back into ide-modules and forgetting about it
<fabbione> did you just changed the file and than rerun ./debian/rules binary-udebs?
<fabbione> in that case the change needs to be propagated in 2 places instead of one
<lamont> I changed the file and did fakeroot debian/rules clean
<fabbione> oh
<fabbione> hmm
<lamont> or rather, I tried to debuild -S and that failed in the clean target.
<fabbione> just a sec.. i am looking
<fabbione> cat ide-core-modules.lnk 
<fabbione> drivers/ide/ide-core.ko
<lamont> ext3-modules and cdrom-core-modules are both valid..
<fabbione> this is wrong
<lamont> yeah - I fixed that
<lamont> that's what I was trying to test
<lamont> lrwxr-xr-x  1 lamont lamont   50 Apr  2 21:54 cdrom-core-modules -> /usr/share/kernel-wedge/modules/cdrom-core-modules
<lamont> lrwxr-xr-x  1 lamont lamont   44 Apr  2 21:54 ext3-modules -> /usr/share/kernel-wedge/modules/ext3-modules
<lamont> lrwxr-xr-x  1 lamont lamont   49 Apr  2 21:54 ide-core-modules -> /usr/share/kernel-wedge/modules/ide-core-modules 
<lamont> the first 2 work, the last one doesn't
<lamont> but I can use the target of the symlink
<lamont> that's just wacko
<lamont> let me try something
<fabbione> it's weird
* lamont kicks himself
<lamont> so, count the characters in that link...
<lamont> note that you only see 48 characters
* lamont removes the trailing space in the file
<fabbione> doh
<lamont> that's a kernel-wedge bug
<fabbione> hmm somebody would say that it is a feature :)
<lamont> uh, yeah
* lamont will verify that things build at least part way before he commits this fix
<fabbione> let it go all the way...
<fabbione> there is no need to get it fixed within 10 minutes :)
<lamont> yeah
<fabbione> dilinger: ping?
<dilinger> pong
<fabbione> dilinger: did you review the 3 race conditions i did forward to you, by any chance?
<dilinger> no, i've been fighting w/ other stuff
<fabbione> no problem
<dilinger> (i'll get 2.6.11 out someday.  probably after i kill herbert for writing this crap)
<fabbione> ehehhe
<fabbione> you will have the opportunity to talk with him at UDU 
<lamont> fabbione: herbert will be at UDU - cool.
<fabbione> i think he will.. that's what i heard at least
<fabbione> Bug #269: "Wrong merging on directories" added
<fabbione> ops
<lamont> ACPI: AC Adapter [ACAD]  (on-line)
<lamont> ACPI: Battery Slot [BAT1]  (battery absent)
<lamont> ACPI: Battery Slot [BAT2]  (battery absent)
<lamont> very confused ACP
<lamont> I
* lamont wants support for his AC97 modem
<lamont> fabbione: I'm going to commit the known fix, and go to bed..  it's building modules on the 3rd of 4 kernels right now
<fabbione> lamont: fine for me
<lamont> fabbione: is building the 4th kernel now
<fabbione> lamont: rocking
<lamont> Built successfully
<crimsun> lamont: which ac97 modem do you have?
<lamont> 0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem]  (rev 30)
<crimsun> there actually is support
<crimsun> snd-via82xx-modem
<crimsun> due to the alsa-related changes, it'll be cardX where X>0
<lamont> no snd-via82xx-modem* files in modules...
<lamont> which means we probably don't build it
<crimsun> ah, I see, I'm looking at the Debian stuff
<crimsun> yeah, you'll have to compile that yourself using 'alsa-source'
<lamont> wow. periods of 7K/sec over a dialup line
* fabbione attempts to use a xen 2.6.11 patch on top of our kernel
<fabbione> actually it doesn't look that nice at all
<fabbione> apparently xen is very sensible to extra patches on top of vanilla
<fabbione> that doesn't really help us
<lamont> sensible?
<lamont> or sensitive?
<crimsun> (the latter)
<lamont> bummer
<fabbione> yeah
<fabbione> hmmmm
<fabbione> i have the feeling i am doing something wrong at build time
<fabbione> let's try another approach
<lamont> crimsun: so what device file name am I looking for for the ac97 modem?
* lamont heads to bed before he gets key-prints on his face.
<crimsun> lamont: cat /proc/asound/devices
<crimsun> lamont: more than likely, it'll be hw:1
<fabbione> lamont: good night :)
<crimsun> so you'd use plughw:1,0
<fabbione> nope....
<fabbione> it's one of our patch :/
<crimsun> :/
<fabbione> let me try the xen patch from bk
<fabbione> at the end our kernel is more 2.6.11 than 2.6.10
<Lathiat> heheh
<dilinger> fabbione: heh, i'm trying to resist the temptation to turn 2.6.8 into 2.6.10 ;)
<fabbione> dilinger: eheheh
<fabbione> my main point is that if xen is so sensitiv
<fabbione> it might be the hell to maintain in time
<dilinger> what's the goal of getting it built with linux-source?
<fabbione> dilinger: one single source
<fabbione> meaning that one security upload is propagated to all images at once
<fabbione> the .11 patch doesn't build becuase of all the 4 level memory shit
<fabbione> extern pmd_t *FASTCALL(__pmd_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address));
<fabbione> i remember that pgd has been introduced with the 4Layer
<fabbione> do you remember what was before?
<fabbione> or pmd was introduced?
<dilinger> i thought pmd was always there?
<dilinger> part of the 3 level pagetables
<dilinger> pgd, pmd, pte
<dilinger> yea, pud was the thingy that was added
<fabbione> include/asm-xen/hypervisor.h:43:39: asm-generic/pgtable-nopmd.h: No such file or directory
<fabbione> bah
<dilinger> um..
<dilinger> oh, right
<fabbione> hmm intersting
<fabbione> just adding the 2 includes it compiles
<fabbione> or at least it starts compiling
<fabbione> but heck.. we can't keep it this way
<dilinger> include/asm-i386/pgalloc.h has the older empty pmd_free stuff
<fabbione> yeah i did try to add that one and it failed for other reasons
<fabbione> pointless to back port.. too much to fix around
<dilinger> you can't use an older xen patch?
<fabbione> the older xen patch builds fine, but it doesn't boot
* dilinger yawns.   6am, i'm gonna go to the grocery store
<fabbione> and now i just noticed that not even doogie did xen-images for 2.0.5
<dilinger> fabbione: oh yea, that booting thing is kind of important, huh?
<fabbione> dilinger: kinda :)
<fabbione> there are only old 1.2 images
<fabbione> i think he is having the same problems as i do
<fabbione> well i need to get some stuff done
<fabbione> and be ready for F1 :)
<zenwhen> Hey
<zenwhen> Is anyone working on getting monitor mode orinoco drivers into the Ubuntu kernel?
<zul> not right now since there is only a couple of days to release
<zenwhen> Oh
<zenwhen> Well yeah I can see that.
<zenwhen> I just hope it happens at some point. :)
<zul> perhaps...its in the list of todo
<dholbach> hey
<dholbach> i just want a final confirmation: we will only need the most recent kernel-packages from debian for universe, right?
<dholbach> (for our architectures)
<zul> yep
<dholbach> ok
<Mithrandir> hm
<Mithrandir> why the heck does mkinitrd try to find the LVM (!) device of my EVMS swap device?
<Mithrandir>     Finding all volume groups
<Mithrandir>     Finding volume group "vojei-sys0"
<Mithrandir> /usr/sbin/mkinitrd: /dev/evms/swap: Cannot find LVM device
<Mithrandir> Failed to create initrd image.
<T-Bone> ouch
<dholbach> good night
<Mithrandir> any idea why mkinitrd cares about my swap devices?
* T-Bone is clueless about initrds. you wanna ask jbailey when he's around
<Mithrandir> yeah, I filed an RC bug.
<Mithrandir> I can provide root-level access to the system just fine, though.
#ubuntu-kernel 2005-04-15
<T-Bone> lamont: please enable CONFIG_DISCONTIGMEM in all hppa configs (to support more than 4GB RAM). kylem says it's ok on all configs, debian has it
<T-Bone> (more than 3.75GB to be precise)
<lamont> Total Memory: 3840 Mb
<lamont> grukble
* lamont needs more RAM, dammit
<lamont> T-Bone: can 32-bit machines have > 4GB RAM?
<T-Bone> lamont: sure, if you run a 32bit kernel
<lamont> doh
<T-Bone> should ask in #parisc, they're discussin that issue
<lamont> actually get 2^44 bits of address space for physical
<T-Bone> but we *really* want it for -34 for the builders ;)
<lamont> fabbione: next ABI event, hppa should have CONFIG_DISCONTIGMEM=y in all 4 configurations. (causes an ABI event)
<lamont> fabbione: and is the abi checker smart enough that one can just change the abi version, and it just generates the new files and ignores the old?  that'd be cool.:-)
<mainer> hi: new to ubuntu: are there any people or sites that provide .deb pkgd kernel-images?
<mainer> anyone home?
<crimsun> goodness
<dilinger> hah
* kylem groans.
<calc> i found out the problem i was having yesterday with mdz's help
<calc> the initrd doesn't load the chipset specific ide driver so it ends up getting loaded after the generic one
<fabbione> morning
<lamont> morning fabbione
<zul> evening
<lamont> fabbione: we planning to keep the 2.6.10 tree alive for breezy, or roll to 2.6.11?
<zul> i thought it was 2.6.12
<lamont> 2.6.13!!
<lamont> or will they skip that one out of superstition?
<fabbione> lamont: if version X has an abi change, it ignores X-1, but we still need to generate the abi for X+1
<lamont> right
<fabbione> i was thinking to skip .11 completely
<fabbione> according to dilinger is a crappy kernel
<fabbione> and it would be heaps load of work to port to .11
<lamont> although I must admit that I'm tempted to let -34 be an hppa-abi event and bastardize things to keep it at 5.  It's not even in the archive and all that... :-)
<fabbione> specially the security fixes that are not in .11
<lamont> right
<lamont> 12 sounds good to me
<fabbione> lamont: i have no isseus if you want to modify hppa
<lamont> and that can go in as soon as breezy opens, yes?
<fabbione> nobody other than you and T-bone are using it right now
<lamont> fabbione: is ABI event...  I have to debate whether I care enough to worry about it.
<fabbione> and it has never been published
<lamont> right
<zul> lamont: heh its giong to be a party once breezy opens ;)
<lamont> zul: zact;y
<lamont> zactly, even
<fabbione> lamont: we will go .12 as soon as .12 is released
<lamont> doh
<fabbione> lamont: that will take us more or less 2/3 days to prepare
<lamont> no 2.6.11.really.2.6.12?
<fabbione> is there any reason why you need .12 so badly?
<dilinger> when does breezy open?
<lamont> I rather expect after UDU, truthfully
<fabbione> dilinger: a few days after hoary is released
<fabbione> lamont: i think james will be faster this time :)
<lamont> prior to really opening breezy, there are plans to rebuild everything with gcc-4.0...
<lamont> not sure if that's going to lockstep or not.
<fabbione> ah right
<fabbione> gcc-4 transition
<zul> iirc there are some kernel build issues with gcc-4
<lamont> so it's really a question of "what are the plans between hoary-release and breezy-start...
<lamont> otherwise, breezy could start _now_
<fabbione> zul: yes
<lamont> zul: there are build issues with lots of stuff..
<fabbione> zul: we can't stay with 2.6.10
<lamont> the full build wouldn't go into the actual archive
<fabbione> it will probably FTBFS
<zul> heh one of should try building with gcc-4 :)
<fabbione> i can do that right away :)
<zul> ahhh...i was going to do that...
<zul> :)
<fabbione> but iirc the miscompilations were on arch != i386
<lamont> given that the current gcc-3.4, gcc-4.0 are FTBFS on hppa..... :(
<fabbione> zul: go ahead and do it
<zul> goody
<fabbione> hppa sucks :)
<lamont> fabbione: feh
<fabbione> they build on sparc
<lamont> java assertions, doko thinks he knows what the fix is, won't go in before release
<zul> does ubuntu actually work on sparc now/
<lamont> if I get bored this week, I'll test his fix
* lamont has 3 ubuntu/hppa machines in his house
<lamont> (2 buildd's and a router)
<lamont> anyway, bed time for me.,
<fabbione> zul: yes it does
* dilinger slaves over a hot 2.6.11
<fabbione> lamont: don't rush.. i woke one hour earlier than usual :)
<zul> cool...i have an ultra1 lying around
<fabbione> zul: unfortunatly it won't install
<fabbione> because elmo stopped rsyncing sparc.u.c
<zul> blah
<fabbione> due to some server load problems
<fabbione> he promised me to move it somewhere else
<fabbione> but afaik he didn't yet
<zul> ok...well i can wait...somtimes patiently
<fabbione> perhaps i can convince elmo to do a pulse todya
<fabbione> let see
<fabbione> lamont: sometimes soon i will need some help to add breezy/hoary-security/hoary-updates to the buildd.
<fabbione> because tbh i never had the need to build more than one release
<fabbione> and i can't remember crap on how to do it :)
<zul> i think it might be time for me to go to bed...later folks
<fabbione> lamont: i was thinking that it could actually be an option to open a 2.6.12 branch
<fabbione> creating an orig from bk
<fabbione> but that means that the orig must be used internally and not published
<fabbione> becuase we will replace it with the real one once it's out
<zul> morning
<lamont> fabbione: other option is to open a 2.6.12 branch with a 2.6.11pre12.orig.tar.gz
<makx> lamont around?
<lamont> yo
<makx> i wanted to ask question how you'd think daily builds should be properly set up.
<makx> doing it d-k wise but it should be same, i guess.
<makx> fabbione hinted me that you may have usefull pointers on last u-k meeting.
<makx> i've played around a bit and have a skript that svn co d-k and builds images atm.
<lamont> if the plan is to have these in the archive, then it's simply a matter of uploading fresh source every day.  Ideally, it'd have an orig.tar.gz that had nearly everything, and then just a diff.gz for the day, until such time as the diff got large enough and we cut a new orig.tar.gz
<lamont> less bits to up/down load that wya
<lamont> fabbione: cutting even an internal-only orig.tar.gz that's incorrect is a bad plan...
<makx> lamont: aah you are building u-k directly out of source.
<makx> forgot that bit.
<makx> experimental still sounds like a nice target for those.
<makx> ok, so i'll have to work on the unifying of the d-k packaging.
<makx> lamont: ok thanks for the hint.
<lamont> kids->school
<zul> figgin xp
<zul> oh this sucks..ply a matter of uploading fresh source every day.  Ideally, it'd have an orig.tar.gz that had nearly everything, and then just a diff.gz for the day, until such time as the diff got large enough and we cut a new orig.tar.gz
<zul> lamont less bits to up/down load that wya
<zul> frig...stupid gnome...sorry
<zul> what i really wanted to say dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
<zul> uh...nevermind
<zul> ftbs with gcc-4.0
* lamont returns
<zul> hey lamont 
<lamont> fabbione: you around?
* lamont changes the abicheck code
<zul> heh that will get his attention
<lamont> grumble.  worse than I wanted it to be
<lamont> changing the ${arch}.ignore case to still do diffs
<lamont> if it can, that is.
<fabbione> lamont: i am now
<fabbione> i completely crashed
<lamont> heh
<lamont> added some code to the .ignore case to still do the diff if there's both an abi file and the .ignore file
<fabbione> lamont: i make no objections if it has been tested :)
<lamont> test build is running now
<fabbione> cool
<lamont> well, actually, the .dsc is packaging now.
<fabbione> if everybody is happy and the situation is normal i am off again to enjoy a bit of sunshine
<fabbione> and i will be back in an hour or so
<lamont> later
<fabbione> later :)
<zul> toodles
<lamont> fabbione: of course, the new code is so that hppa can have a well documented non-abi event. :-)  We're testing to see if there are more than 2 users, you see... :)
<zul> heh...its not like you would break something on i386 like i usually do and people notice these things
<lamont> zul: this is intentionally ignoring the abi change that really should create 2.6.10-6, but won't.
<zul> ah i c
<lamont> yeah.  both t-bone and I agree that we should, so that's 100% of the known user community of our non-existant port.
<lamont> well, s/non-existant port/non-advertised archive/
<lamont> which means that we have abi files, we're breaking abi compatibility on that archtecture only, and specifically ignoring that fact.
<lamont> lalalalalala
<zul> heh
<zul> crap..i have a dentist appointment today
<lamont> zul: that'd be protcologist. :-)
<zul> speaking of protcologist...nah...i dont think you wanna know :)
<lamont> really crappy work
<zul> hehe
<lamont> gotta wonder what makes  a med student _decide_ to specialize that direction...
<zul> fetish maybe
* lamont bets money
<zul> could be a little from column a, a little from column b
* lamont grumbles
<lamont> gotta figure out where the hppa.ignore file gets removed
<lamont> ok.  empty files and debuild -S don't seem to mix.
<fabbione> lamont: it's the kernel make clean target that kills empty files
<fabbione> Unpacking libmpfr-dev (from .../libmpfr-dev_2.1.0-2ubuntu1_sparc.deb) ...
<fabbione> dpkg: error processing /opt/sparcbuildd/chroots/chroot-hoary/var/cache/apt/archives/libmpfr-dev_2.1.0-2ubuntu1_sparc.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/info/dir.old.gz', which is also in package texinfo
<fabbione> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<fabbione> hmmm
<fabbione> i guess i have some crap in the buildd cache
<lamont> was old texinfo bug did that.
<fabbione> yeah i remember that
<fabbione> but gcc-4.0 has been built a while ago
<fabbione> i mean that i did build gcc-4 other times
<fabbione> without problems
<zul> fabbione: ccache me thinks
<fabbione> zul: nah. i am talking about building gcc-4.0
<fabbione> ccache can cope with a different compilare
<fabbione> compiler
<fabbione> it did build before today
<zul> fabbione: i got the same with export CC="ccache gcc-4.0"
<fabbione> zul: so 2.6.10 doesn't build with gcc-4.0
<zul> nope
<T-Bone> how suprising :P
* fabbione isn't
<T-Bone> neither am i, just being sarcastic ;}
<zul> sure sure
<fabbione> T-Bone: i could understand that... you are french :P
<T-Bone> fabbione: and? Aren't you italian? :)
<fabbione> yes i am
<T-Bone> what so different about us then? :)
<fabbione> that you are french and i am not?
<T-Bone> the way we cook spaghettis? :)
<fabbione> no.. you don't cook spaghettis
<T-Bone> LOL
<T-Bone> here we go =)
<fabbione> :)
* T-Bone must schedule yet another Italian trip for next summer. That country is probably the one I'd want to live in, should I have to leave .fr ;] 
<zul> fabbione: dies in drivers/acpi
<T-Bone> fabbione: that has to be a compliment! =] 
<zul> T-Bone: why would you leave .fr because you are too french?
<zul> hehe
<fabbione> T-Bone: i would never go back to live in italy.. why would you do that?
<T-Bone> zul: no. I was hypothetising :)
<fabbione> zul: ok
<zul> ah
<T-Bone> fabbione: why wouldn't you?
<fabbione> T-Bone: because Italy is only a very nice place to have holidays
<T-Bone> LOL
<fabbione> that's about it
<fabbione> working there.. sucks
<T-Bone> ah
<fabbione> internet there .. sucks
<T-Bone> can't tell
<fabbione> government.. questionable
<T-Bone> lol
<zul>  bersecloni?
<fabbione> all the rest != some resturant = the sucks
<fabbione> berlusconi
<T-Bone> yet, food is cool, weather is cool, ragazza cool, monuments cool, landscape cool... ;)
<zul> lazio cool ;)
<fabbione> T-Bone: aren't you married?
<fabbione> zul: ahahha
<T-Bone> fabbione: hell no!
<T-Bone> ;)
<fabbione> T-Bone: if you really want to get laid to death you should go and visit siciliy
<fabbione> just remember to get a fake id before going there
<T-Bone> i'm 24 dude. I'm not gonna emprison myself while I'm at the peak of my sex appeal ;)
<zul> not going to touch it..
<T-Bone> i went to sicily ;)
<fabbione> otherwise one of these hot chicks might show up at your door in france with a mini T-Bone
<T-Bone> LOL
<fabbione> dude... 24?
<fabbione> hell you are kid
<T-Bone> fabbione: that's what they say in movies, is that so true?
<zul> you are a young'un t-bone
<fabbione> T-Bone: i lived in sicily for 4 years...
<T-Bone> fabbione: sure. I'm trying to grow chest hair. Ask lamont-away =)
<fabbione> well it is true in certain parts of siciliy
<fabbione> ahahahaha
<T-Bone> i guess this might be true in certain parts of Corsica as well :)
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre34--2.6.10 playground: kernel-debian--experimental--2.6.10 | There are no kernel bugs.. only broken hardware | T-Bone: I'm trying to grow chest hair.
<zul> hah
<fabbione> well corsica is france territory and i have never been there
<T-Bone> fabbione: you're late on topic. Lamont has put that one in the very early days of #u-kernel ;] 
<T-Bone> fabbione: never been to france?
<fabbione> yeah but i wasn't here
<T-Bone> ah ok :)
<fabbione> T-Bone: oh yeah.. i have been to france several times
<T-Bone> ah!
<fabbione> specially in Paris
<fabbione> that's just because the best airshow in EU is/was there
<T-Bone> said to be the most beautiful city in the world...
<zul> i been to paris once
<fabbione> T-Bone: bullshit.. Rome > Paris
<T-Bone> airshow?
<T-Bone> fabbione: lol, no way :)
<fabbione> T-Bone: yeah.. Le Bourget
<T-Bone> fabbione: you don't have the Eiffel tower in Rome ;)
<fabbione> (sorry for the spelling)
<T-Bone> fabbione: ah! I see
<T-Bone> spelling is correct btw :)
<fabbione> T-Bone: you don't have the colosseum in Paris
<T-Bone> fabbione: right. we don't collect ruins ;)
* T-Bone ducks!
<fabbione> T-Bone: that's why it is still up and rocking after 2000 years....
<fabbione> ehhe
<fabbione> anyway let's cut the speech france <-> italy here
<fabbione> otherwise i will get T-Bone to commit suicide for being born there
<T-Bone> LOL
<T-Bone> in your widest dreams... =)
<T-Bone> +l
<fabbione> T-Bone: ok.. listen to this story as a starter
<fabbione> you are probably too young to remember
<T-Bone> ?
<fabbione> you know that Italy and France always fight for who has the best wine?
<fabbione> it's kinda of a friendly war ...
<fabbione> but you can smell it
<T-Bone> fabbione: I don't. The answer is obvious. I wasn't aware there was a debate 8)
* T-Bone laughs like evil =] 
<fabbione> well we always accused France to steal Italian wine, mix it with some local flavour and sell it with a different name
<fabbione> France of course always negated that
<T-Bone> berk
<T-Bone> should some people do that in France, that's not wine they're selling :P
<zul> local flavour would be anti-freeze
<fabbione> all of a sudden, in Italy, they found a big amount of poison in italian wine
<fabbione> due to some kinda of infection...
<fabbione> probably generated by some chemical shit
<T-Bone> fabbione: it is obvious some producers sell something that should barely be called cat piss. What's even more unfortunate is that there are people buying it as "French wine" :P
<fabbione> well.. of course we closed down the selling of wine
<T-Bone> fabbione: no kidding?
<fabbione> now.. how come some of the major France wine producers did the same? :)
<fabbione> T-Bone: no i am really serious
<fabbione> i am not kidding
<T-Bone> wow
<fabbione> oh as a side note
<T-Bone> looks pretty much unbelievable to me
<fabbione> the part of italy that was damaged
<T-Bone> at least for the "Grands Crus"
<fabbione> was the north-west.. close to the french border line
<T-Bone> Piemont?
<fabbione> now.. really *CASUALLY*
<fabbione> all the southern-east french wine were not distributed
<fabbione> yeah Piemonte
<fabbione> ;)
<T-Bone> good wine in Piemonte, that's for sure :)
<fabbione> oh.. of course.. France did NEVER import wine from italy....
<T-Bone> heh
<fabbione> anyway
<fabbione> i think it's time to go and help my wife
<fabbione> and get some food
<fabbione> cya tomorrow guys
<T-Bone> fabbione: well i don't know much about that story, but the best wines in France aren't southern-east ones. Bordeaux and Bourgognes are respectively southern west and middle-east, so to speak
<T-Bone> fabbione: heh, cya. I'm not done with you yet ;)
<fabbione> T-Bone: well still pretty close to france :)
<fabbione> T-Bone: next one will be italian kitchen vs french cousine
<fabbione> :P
<T-Bone> LOL
<zul> french football vs italian football?
<T-Bone> lol
<T-Bone> i don't like football, i'd be a bad advocate :)
<T-Bone> OTOH, french rugby vs italian rugby would prove interesting... 8)
<zul> i dont really pay attention to rugby anymore
<zul> fabbione: there is alot of warnings like this include/linux/skbuff.h:1017: warning: pointer targets in passing argument 2 of 'csum_and_copy_from_user' differ in signedness
<zul>  that should probably be fixed as well
<lamont_r> WARNING! ABI check override for hppa has been detected, and there were changes!
<lamont_r> woot!
<T-Bone> lol
<lamont_r> T-Bone: that means that my check changes worked....
<T-Bone> indeed
<lamont_r> fabbione: actually, I have another quesion about the abi check....
<lamont_r> normal use case is going to be that the user installs the new kernel and then doesn't reboot...
<lamont_r> hence adding symbols should mean that the new modules won't load in the old kernel, no?
<lamont_r> :q
* lamont_r needs focus_mode: eyes
<zul> wohoo...helium balloons
<lamont_r> zul: get a real job, slacker
<zul> i tell you i work for the government..
<lamont_r> zactly! :0-)
<T-Bone> lol
<zul> however i wouldnt mind being paid to work on ubuntu full time :)
<lamont_r> CONFIG_DISCONTIGMEM committed.  I feel so dirty
<T-Bone> lamont_r: i like you very much, you know? Especially when you're dirty ;)
<zul> ok...take it to #ubuntuhppaorgy
<lamont_r> what better way to find the 3rd user, eh?
<T-Bone> lol
<T-Bone> lamont_r: i've finished reviewing my howto, and will advertise it soon
<lamont_r> mjg59: why does the kernel think ACPI says I have no batteries?
<lamont_r> T-Bone: and you fixed your /boot vs / issue?
<T-Bone> lamont_r: I can't tell. I'll tell you in next upload
<T-Bone> s/upload/upgrade/
<T-Bone> lamont_r: all i can say is that it doesn't work within the chroot, that's for sure
<T-Bone> which brings us the question of "how is it supposed to work in the (yet hypothetical) installer"
<lamont_r> grep link_in /etc/kernel-img.conf 
<lamont_r> link_in_boot = yes
<lamont_r> have that?
<T-Bone> yes
<T-Bone> link_in_boot = Yes
<zul> hey jbailey 
<jbailey> Heya Chuck
<zul> how is it going?
<T-Bone> lamont_r: is there any way to educate popcon about an http proxy?
<lamont_r> http_proxy=?
<jbailey> zul: Good!  I got a place. =)
<T-Bone> lamont_r: in popularity-contest.conf?
<lamont_r> dunno
<T-Bone> ah
<zul> jbailey: oh yeah wehre?
<T-Bone> because i can't get it to work behind a proxy, you see...
<jbailey> zul: In the plateau/
<zul> cool
<T-Bone> jbailey: dude, i've started reading "WYFL", it's fuckin amusing! ;)
<T-Bone> jbailey: i'm learning a handful of useful expressions ;)
<zul> later
<lamont_r> WYFL?
* lamont_r saw a t-shirt this past weekend that simply said 'WTFWJD?'
<T-Bone> Watch Your Fucking Language
<T-Bone> subtitled "How to swear effectively, explained in explicit detail and enhanced by numerous examples taken from everyday life"
<lamont_r> URL?
<T-Bone> lamont_r: btw, seen what I said in #parisc? I wonder how bad it would be to run a debian 2.6.8 kernel on Ubuntu for the time being?
<T-Bone> lamont_r: that's a fuckin book! ;)
<T-Bone> lamont_r: amazon.com ;)
<lamont_r> heh
<lamont_r> T-Bone: probably no worse than any other.
<T-Bone> lamont_r: ok. I guess that i'll do that then, because the j6k don't have GSP and i don't feel like going to school every 4 days or so to power cycle them
<lamont_r> T-Bone: alternatively, figure out what we broke in 2.6.10SMP
<T-Bone> lamont_r: btw, we're down to 2 builders until friday, since one of them died :P
<lamont_r> xorg builds just fine on a UP kernel.
<T-Bone> lamont_r: everything built fine
<T-Bone> lamont_r: i'm almost certain that's the cache_grow panic that stroke
<T-Bone> lamont_r: unfortunately that box is headless
<lamont_r> xorg build died twice on 2.6.10-33.1-hppa64-smp
<lamont_r> T-Bone: crossover serial cables, dude.
<T-Bone> lamont_r: that's what's there. Except minicom isn't always running on the other end of the cable :P
<T-Bone> lamont_r: i've been building xorg on 2.6.12 64bit smp
<lamont_r> well, yeah
* T-Bone does a test install of bastardized kernel on ubuntu to check how it behaves
<T-Bone> lamont_r: unfortunately, as i kept bashing on #parisc, our kernel is in a very awful state since 2.6.8.1 :(
<lamont_r> T-Bone: modulo the "expect bug"
<T-Bone> lamont_r: alas
* lamont_r thinks maybe -34 with discontigmem will make it die less often...
<T-Bone> lamont_r: all in all i can keep the buildd setup on the A500 to build sensitive packages, unless you manage to get the A500 in DC, and that one to build these
<T-Bone> lamont_r: install procedure advertised on #parisc and linked on the website ;)
<lamont_r> just in time for the abi event.  cool. :=(
<T-Bone> who cares, they all know :)
<lamont_r> yeah
<T-Bone> i haven't m-l'd it yet :)
<lamont_r> well, if you do, include the fact that -34 will have abi breakage, so they'll need to reboot after they install
<lamont_r> (hppa, for our listeners here)
<T-Bone> i won't m-l anything before we get the archive in the right place and -34 in it
* lamont_r likes that plan
<T-Bone> i knew you would :)
<T-Bone> k so ubuntu seems to behave well with debian 2.6.8.2
<T-Bone> s/.2/-2/
<lamont_r> coolnesss - that has all of kyle's backport of 2.6.12?
<T-Bone> no clue
<T-Bone> strange thing is that we have a -5 in universe, but it doesn't build. I just asked kylem about that in #parisc
<T-Bone> lamont_r: it dies with "depmod: ELF file /build/buildd/kernel-image-2.6.8-hppa-2.6.8/install-32-smp/debian/tmp-image/lib/modules/2.6.8-1-32-smp/kernel/drivers/net/hamachi.ko not for this architecture"
<lamont_r> T-Bone: you mean 2.6.8-2-32_2.6.8-5?
<T-Bone> tons of messages like this
<T-Bone> kernel-image-2.6.8-hppa_2.6.8-5
<lamont_r> 64 vs 32 bit modutils issues
<T-Bone> how comes we can't build it?
<T-Bone> or should i say, how comes it builds fine in Debian?
* lamont_r tries to remember what that bug was
<T-Bone> (i suppose it does)
<lamont_r> uname hack in the kernel returned the wrong thing the last time
<T-Bone> huhu
<T-Bone> gah i hate the idea of bastardizing the Ubuntu setup on the builders :P
<T-Bone> at least if i could have installed kernel packages from universe it'd have been almost acceptable :P
<T-Bone> lamont_r: i'll let the machine run Ubuntu with debian kernel for a while just to make sure. Seems to work fine in any case
<T-Bone> lamont_r: i'll add some 200 more signed changes a bit later. Time for me to get some food
#ubuntu-kernel 2005-04-16
<jbailey> Am I reading the encrypted filesystems wiki page right that losetup will go away in favour of device-mapper?
<zul> evening
<dilinger> jbailey: i'm told dmcrypt is quite easy to set up
<dilinger> i should really set that up w/in the next week or so
<lamont> jbailey: no one has told the maintainer of losetup about it going away... :-)
<lamont> but devicemapper is better
<dilinger> jbailey: you still around?
<jbailey> dilinger: I'm back.
<jbailey> dilinger: The dmcrypt stuff does look easy enough to setup.
<jbailey> The initrd-tools bits make some assumptions around devince-mapper bits that appear to be wrong.  It's mostly new stuff to me.
<jbailey> lamont: Cool, thanks/.
<dilinger> jbailey: yea, it gets triggered in cases when root is not dmcrypt, apparently
<dilinger> also, it has libdevmapper1.00 hardcoded in mkinitrd, which is just plain wrong
<dilinger> for breezy and sid, anyways (possibly sarge too, not sure).  warty still has libdevmapper1.00; other stuff has libdevmapper1.01
<jbailey> Ah lovely.  That'll be useful knowledge for troubleshooting.
<jbailey> It's one of the dusty corners of initrd that I haven't explored yet.
* dilinger nods
<jbailey> Woohoo, just called the cops to file a noise complaint against the construction site across the street.
<jbailey> 23:21 is awful late for running a jack hammer.
<dilinger> stick it to 'em
<fabbione> morning
<dilinger> hiya
<lamont> fabbione: you got the thing you were pinging me for?
* lamont begins an interesting practical excercise in the kevin bacon game
<fabbione> lamont: you mean the dir.old.gz?
<lamont> yeah
<lamont> != bacon game
<fabbione> yeah i am checking it
* lamont lost contact info for someone who has gone to pain to become unreachable.
<fabbione> the point is that for me is libmpfr-dev_2.1.0-2ubuntu1_sparc.deb
<fabbione> i wonder why it did show up again.
<fabbione> this package has been built the 12th of Feb
<fabbione> and i did other gcc-4.0 built since than
<fabbione> with no problems
<fabbione> so i guess it was not a Build-Dep before?
<lamont> dunno
<fabbione> neither do i
<fabbione> i can't keep old logs for too long
<zul> morning
<zul> hah...defeated palm yet again
<zul> fabbione: you should take 2.6.10 patch it up to 2.6.11 and then all the release candidates
<lamont> zul: evil
<lamont> take 2.6.12rc2 and bring forward the not-from-cvs patches
<lamont> s/from-cvs/in-bk-head/
<zul> it works
<zul> bbl...lunch..
<lamont> and is much easier
<fabbione> re
<fabbione> zul: no no ... clean orig and portforward the patches
<fabbione> plus we might have to check all of the non-stolen-from-head
<lamont> and brings hppa's diff down to (according to that channel topic): 2.6.12-rc2-pa0 is <200k: 55k ad1889, 47k input, 26k compat, 50k split for Linus, 22k remaining
<fabbione> some of them have been merged upstream across the time
<fabbione> update all the drivers
<lamont> fabbione: right - many of the non-"stolen-from-head" patches have since made it into head.
<fabbione> and so on...
<fabbione> i was thinking to enfore a policy name
<fabbione> stolen-from-head is there and ok
<fabbione> edriver-
<lamont> ah, right
<fabbione> for external drivers
<lamont> oh, yes.  we have the patch-name policy documented on the wiki soon, yes?
<fabbione> not that i remember....
* lamont delegates the task to fabbione
<fabbione> but also.. i want to get rid of dpatch
<fabbione> that's a must
<fabbione> lamont: yeah that's fine for me...
<lamont> replace it with what?
<fabbione> lamont: i was considering either dbs-ng 
<fabbione> or patch the code directly. BUT keeping track of all the applied patches in debian/patches
<lamont> cdbs, maybe
<fabbione> i don't think cdbs can help us at all
<lamont> dbs gives me the 'run screaming from doogie code' stuff
<fabbione> we have a too customized build system
<lamont> right
<fabbione> lamont: no no.. not dbs
<fabbione> dbs-ng...
<jbailey> fabbione: dilinger seemed to think that cdbs could do it.
<lamont> calling it dbs-ng was a really stupid thing to do then
<fabbione> jbailey: i really don't think it can, but if you want to look at our rules file and get an idea
<jbailey> fabbione: 'kay.  Mind if I do that this weekend?
<fabbione> lamont: i think xen 2.0.5 in experimental is packaged with dbs-ng
<jbailey> Or are you guys looking at it sooner?
* lamont is kinda busy with other stuff this week. :-)
<fabbione> jbailey: well.. asap is the better
<lamont> fabbione: and he said that this weekend was asap for him... :-)
<fabbione> lamont: yeah.. we will be busy releasing anyway
<zul> for the bk cutting edge tree my suggestion would be weekly snapshot
<zul> and turn all debugging features on
<zul> it could be too much uploading for one person if we did a daily snapshot
<fabbione> nah.. we were talking about weekly
<fabbione> or every 2 weeks
<zul> weekly would be better
<T-Bone> lamont: we've gone over 90% up-to-date! :)
<zul> holy crap gcc4 sucks
<fabbione> zul: why?
<zul> all of these warnings like every second line about pointer targets
<fabbione> T-Bone: but i can't see a single hppa.deb in the archive.. am i looking at the wrong place??? oh probably they are only on the .fr mirror :P
<T-Bone> fabbione: we're not in the archive
<fabbione> T-Bone: i know..
<T-Bone> fabbione: if you look at http://archive.slashdirt.org/ you'll find them
<zul> heh...im french why do you think i have this outrageous access you silly king
<T-Bone> fabbione: your sarcasm doesn't reach me :)
* fabbione sends a real bottle of wine to T-Bone 
* T-Bone teaches fabbione real rugby ;)
<zul> well at least i fixed where acpi bombs using gcc4
<fabbione> oh god.. today archive is really slow
<fabbione> i only need to mirror and upgrade from warty to hoary
<fabbione> it's taking AGES
<T-Bone> fabbione: tried the fr mirror?
<T-Bone> fabbione: felt pretty fast last time i tested it
<fabbione> no.. it's lagged
<zul> gah...
<fabbione> everything != archive is lagged
<zul> drivers/acpi/processor_idle.c:57: error: static declaration of 'pm_idle_save' follows non-static declaration
<zul> include/acpi/processor.h:181: error: previous declaration of 'pm_idle_save' was here
<zul> make[2] : *** [drivers/acpi/processor_idle.o]  Error 1
<zul> make[1] : *** [drivers/acpi]  Error 2
<zul> make: *** [drivers]  Error 2
<fabbione> and for a buildd and my tests i need to be in sync as much as possible
<lamont> zul: is error
<fabbione> zul: what are you trying to build?
<T-Bone> fabbione: i use archive.u.c for the buildd source, works just fine
<lamont> mirror-missing| grep -v _ia64 | wc
<lamont>      59      61    4249
<lamont> and then there's xorg and l-s-2.6.10 :-(
<T-Bone> fabbione: i get around 20Mb/s out of it at min
<lamont> that's from the run I started yesterday
<fabbione> T-Bone: not from here
<T-Bone> fabbione: get a real ISP :)
<fabbione> T-Bone: you get 20Mb from home?
<T-Bone> lamont: i had to give-back l-s, segfaulted during the build of ppp modules
<T-Bone> fabbione: from school
<fabbione> tsk
<fabbione> i am home with my standard 2Mb line
<fabbione> it still slow
<T-Bone> from home i get 7-8Mb/s
<T-Bone> fabbione: get a real ISP :)
<fabbione> T-Bone: i don't have fibers here yet...
<fabbione> too far away from decent centrals
<fabbione> but we are voting next week to get them
<T-Bone> fabbione: i have adsl at home, not fibers. EC-45 is good for school :)
<fabbione> inside the block/area counsil
<fabbione> EC-45 is peanuts....
<fabbione> T-Bone: www.seabone.net <- that's where i was working in italy
<T-Bone> my adsl is to be upgraded to 15Mb/s soon though
<T-Bone> huh, I-Tim
<fabbione> adsl can't go over 8Mb. it has to be some kind of other technology
<T-Bone> adslv2
<T-Bone> you're out of date dude
<fabbione> "<T -Bone> my adsl"
<T-Bone> you see, we may not have the best wine, but we have the best ADSL provider
<fabbione> you are imprecise
<T-Bone> www.free.fr
<T-Bone> if you can read french
<T-Bone> and i'm not imprecise
<T-Bone> it is "ADSL v2", 20Mbps ATM throughput, 15Mbps IP
<fabbione> yeah right.. adsl != adslv2
<T-Bone> it can use longer range from the DSLAM as well, which is cool for remote people
<fabbione> if we will get the fiber.. sorry.. no EC45 or adslv2...
<fabbione> 1xFE
<T-Bone> i think we are somewhat world leaders on the ADSL market. At least european leaders :)
<T-Bone> fabbione: how much do you pay for that? :)
<fabbione> T-Bone: if we get fibers (again it depends from the vote on thursday) it will cost probably less than my actual adsl
<fabbione> ISP here are very cheap
<T-Bone> doh
<T-Bone> how much do you pay for ADSL?
<fabbione> hmmmm
<fabbione> let me check.. i can't remember :)
<T-Bone> lol
<fabbione> around 78 euro/month
<T-Bone> UGH!
<T-Bone> hell that's expensive
<fabbione> not here
<T-Bone> that's about 3x what I pay
<fabbione> life in dk is more expensive that in 90% of EU countries
<T-Bone> i pay 29 euro/month
<T-Bone> for 8Mbps
* lamont would pay 78 euro/month
<fabbione> T-Bone: yes but you probably get 1/4 of the wage i get on average and so on
<T-Bone> and will pay 29e/m for 15Mbps when upgraded
<fabbione> T-Bone: it is really impossible to compare prices
<fabbione> trust me
<fabbione> there are too many factors that influence the price of an ISP between 2 different countries
<lamont> fabbione: that's because the french government owns everything in the country
<T-Bone> fabbione: so what's the point of living in .dk if everything is 4x more expensive? Might as well live in London... ;)
<fabbione> T-Bone: she was blonde :)
<lamont> good reason
<fabbione> lamont: eheh
<T-Bone> lamont: actually the state provider sucks hell compared to the provider called "Free", which is world leader (.eu at least) on ADSL technology
<T-Bone> fabbione: ROTFL
<lamont> T-Bone: he's dead serious
<T-Bone> lamont: I got that, yet i'm ROTFLMAO ;] 
* T-Bone fortunes btw
<fabbione> i don't joke when it goes to blondes 
<fabbione> hahaha
<T-Bone> c'mon ;] 
<T-Bone> everybody jokes about blondes. Even my blonde female friends do ;)
<zul> fabbione: 2.6.10 with gcc4
<fabbione> i know.. that was the real joke T-bone
<fabbione> zul: it's not worth spending time on it.. really
<zul> heh...i was bored :)
<T-Bone> fabbione: i was playing Dumber ;}
<zul> T-Bone: that cant be too hard for you :)
<fabbione> T-Bone: ah sorry.. i couldn't make the difference from the other days
* fabbione runs away
<T-Bone> fabbione: that was easy heh? :}
<T-Bone> fabbione: i really offered you that one =)
<fabbione> T-Bone: you just slamed it in front of me :)
<T-Bone> fabbione: cause I knew you'd jump on it, damned Italian big mouth 8-))
<fabbione> T-Bone: ain't my fault if you want to play dumb :)
<fabbione> oh god guys.. i really love this channel
<T-Bone> fabbione: you're such a good audience ;] 
<T-Bone> fabbione: I think we all do. zul might tell, seems that with lamont you and I on the same chan, one must have fun ;)
<fabbione> ehehhe
<zul> i never have fun
<fabbione> zul: that's because you are french :P
<T-Bone> zul: poor little thing. Feel left alone? :}
<zul> fabbione: shut your mouth!
* T-Bone ducks!
<fabbione> ahahahha
* T-Bone wonders what makes zul french :)
<zul> T-Bone: yeah your gentoo haters..
<T-Bone> lol
<zul> there is nothing lower than being french...well maybe italians
<T-Bone> ROTFL
<T-Bone> i guess that one is well deserved ;)
* T-Bone ^5s zul
<zul> heh...burn..:)
<fabbione> ahahha
* T-Bone notices that all that is logged and will soon be parsed by Googlebots
<fabbione> let them parse....
<fabbione> who cares..
* zul does his italian imitation...
<T-Bone> now if someone has a little script that converts irc nicks to realname, and makes that available to said googlebots, well... ;}
<fabbione> i am still in time to erase the logs
<zul> that is one spicy meatball
<fabbione> and let them hit a bunch of 404 :)
<T-Bone> lol
<fabbione> now.. let me think..
<T-Bone> fabbione: don't do that
<fabbione> should i start adding random entries like:
<T-Bone> fabbione: it's said to damage italian brains ;)
<fabbione> <T-Bone> I SUCK..I REALLY DO :)
<T-Bone> LOL
<zul> hehe
<fabbione> that would kinda own you :P
<T-Bone> fabbione: you don't need to add these, I usually add them myself ;)
<zul> its called T-Bone...sublimial...sucks...messages
<fabbione> ahahha
<T-Bone> zul: you're not funny
<fabbione> my wife is asking me wth i am laughing so much...
<zul> im all for equal opprtunity :)
<T-Bone> 8)
<T-Bone> fabbione: better not tell :)
<fabbione> i am not...
<T-Bone> fabbione: tell her you're working hard! :)
<fabbione> i am :)
<T-Bone> 8)
<fabbione> looking at the ubuntu mirror that is rsync
<fabbione> that's a hard job
<fabbione> specially when you need to wait for it to do the last test before closing the day
<fabbione> at least she is cooking dinner :)
<T-Bone> lol
<T-Bone> i hate you :)
<fabbione> time for food.. the mirror hasn't finished yet
<zul> so umm...
<zul> like e_whatevercrappydriver.dpatch?
<fabbione> edriver-crappydevice
<zul> k
<zul> are you going to do the baz dance for breezy...
<fabbione> yeah after hoary is released
<zul> ok..
<zul> i could wait until then...maybe..
<fabbione> but we need to decide first how we want to proceed
<fabbione> lamont: is it confirmed that breezy will be gcc-4.0?
<zul> yeppers
<fabbione> than i would say that first we need to get an orig.tar.gz :)
<fabbione> from 2.6.11pre2.6.12rc2 or whatever lamont suggested
<fabbione> and to test if everything is ok
<zul> 2.6.12-rc i can scrunge one up tonight
<zul> ketchup is good ;)
<fabbione> zul: easy :)
<fabbione> my suggestion is:
<zul> i know...i was volunteering :)
<fabbione> a) unpack linux-source-2.6.10.orig.tar.gz
<fabbione> b) rename the dir to be 2.6.12
<fabbione> c) repackit
<fabbione> d) i will let you figure this one out :)
<fabbione> e) mv our debian/ to the 2.6.12
<fabbione> f) edit control.stub and changelog
<fabbione> and build it
<fabbione> see if all the packages get the right versions and so on
<fabbione> for one simple reason
<fabbione> make-kpkg doesn't like fancy names in the versions
<fabbione> and even if it builds, it will fail later to create the debs
<fabbione> and the udebs
<fabbione> once you have this undercontrol
<fabbione> you can use the .11 from vanilla
<zul> the patch file?
<fabbione> and add the patches to debian/patches to go up to 2.6.12rc2 via stolen-from-head that you really want as the first patch
<fabbione> zul: yeah well go up to 2.6.12 rc in someways
<fabbione> once you are there...
<fabbione> you can have fun...
<zul> or an ulcer
<fabbione> but just create the orig.tar.gz
<zul> okie dokie
<fabbione> we will work in rediffing the patches in baz
<fabbione> we need to keep track of what we do and why
<zul> archive is slooooow
<lamont> fabbione: I'd be inclined to go with linux-source-2.6.12_2.6.11.90.orig.tar.gz
<fabbione> lamont: that works for me
<lamont> and use 2.6.11.90-1 as the head of changelog
<lamont> least amount of pain.
<fabbione> lamont: it is ok, but we need to see how and if make-kpkg breaks
<lamont> and if it _won't_ eat that for some reason, then well.... linux-source-2.6.12_2.6.11.orig.tar.gz has some flavor... :)
<fabbione> i remember some horror from Mataro' when i did try to create packages for bk
<fabbione> ehehhe
<zul> uh that sucks...i seem to have used up 13 GB on my /home partition
<lamont>  /dev/hda8             96124904  83814404   7427548  92% /home
<lamont> uh, yeah.  13GB.
<zul> ppphpth
<fabbione> Alloc PE / Size       137223 / 536.03 GB
<fabbione> Free  PE / Size       20144 / 78.69 GB
<fabbione> hmm
<fabbione> i am almost running out of space
* fabbione ducks
<lamont> fabbione: it doesn't matter how much space you start with, it fills up almost immediately.
<lamont> and then we start pruning
<fabbione> lamont: that's why i got 600 DVD for my weeding
<fabbione> wedding even
<fabbione> to backup that mess :)
<fabbione> and reinstall
<lamont> heh
<fabbione> i have in mind more or less what i want
<T-Bone> lamont: that only happens when you don't know how to sort data. My desk and main machine has 15GB total diskspace
<T-Bone> and it's not full :)
<lamont> T-Bone: no, that only happens when you add more disk everytime you run out of space.. :-)
<fabbione> ehhehe
<T-Bone> lamont: fair enough. Though i have about 780GB on my secondary machine, of which a good 40% is free :)
<T-Bone> fabbione: you see, mine is bigger ;] 
<lamont> hrm.. who was the openfirmware guru
<lamont> ?
<T-Bone> lamont: svenl
<T-Bone> lamont: i can help a little maybe
<fabbione> T-Bone: is that a raid5 ?
<T-Bone> fabbione: no
<fabbione> or just plain JOD?
<lamont> T-Bone: I just want to have it spew out the paths on the machine
<fabbione> eh mine is raid5
<T-Bone> JBOD
<fabbione> yeah JBOD
<T-Bone> and even more evil
<fabbione> T-Bone: i am over that if i unroll the raids
<T-Bone> IDE JBOD ;)
<fabbione> yeah mine is IDE too
<T-Bone> lamont: depends on the of version
<T-Bone> lamont: usually you'd try 'ls'
<lamont> "no active package"
<T-Bone> fabbione: lol, what's the point of RAID over IDE? :)
<T-Bone> lamont: macintosh or pegasos?
<lamont> T-Bone: OF 3.0.f2 built  4/23/99
<lamont> Mac G34
<lamont> G3
<T-Bone> hold on
<T-Bone> erg
* T-Bone is doing nasty things with OF
* T-Bone curses yaboot stage 1 that interferes with his attempt to get OF to talk nicely to him :P
<fabbione> night guys
<fabbione> cya tomorrow morning
<fabbione> oh i forgot the topic
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: kernel-debian--experimental--2.6.10 | There are no kernel bugs.. only broken hardware
<fabbione> there
<zul> c ya
<T-Bone> lamont: hmm i'm confused, pegasos and macs OF are quite different. You want to ask svenl, definitely
<lamont> ok
<T-Bone> lamont: fyi, -34 currently building, as well as xorg -10
<T-Bone> and we're 91% up-to-date :)
<zul> wtf?
<zul> dh_clean: cannot read debian/control: No such file or directory
<zul> and then my debian directory gets blown away...frigging 
* zul smacks T-Bone 
<T-Bone> hey!
<T-Bone> i did nothing :P
<zul> i know but today you are my bitch :)
<T-Bone> i'm a computer whore ;}
<T-Gone> dinner time
<zul> ye...yes you are
<dilinger> jbailey: cdbs2, maybe.  cdbs1 would be a mess
<dilinger> jbailey: i use it for kernel modules, which is fairly simple, and it gets ugly
<jbailey> dilinger: 'kay.  I've promised seb a prototype for udu.
<jbailey> Like self hosting and able to do nano.
<dilinger> http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-nonfree-2.6.11-2.6.11/debian/rules?op=file&rev=0&sc=0
<dilinger> jbailey: neat
<jbailey> dilinger: This isn't too bad.  A few of these things could get safely tossed into a kernel.mk file.
<dilinger> jbailey: picture that multipled by 5
<dilinger> or something like that
<dilinger> as it needs to build multiple images
<jbailey> dilinger: Right, but is the result still better than it would be with other build helpers?
<jbailey> This is only a page and easy to read.  With a helper and some clear commenting, it growing wouldn't necessarily be that bad.
<dilinger> jbailey: well, what really sucks is that it uses kernel-package
<dilinger> which doesn't really go well w/ cdbs
<dilinger> you end up having to do the debhelper stuff through hooks
<jbailey> Oh ugh.
<dilinger> so, debhelper.mk is next to useles
<dilinger> not a cdbs problem, but a kernel-package.. um.. misfeature, i guess.
<jbailey> 'kay then.  I had been thinking in terms of the rules file actually doing the configure/make dep/ make/ make install passes itself.
<jbailey> In which case a helper could do that, and then you're just missing a basic multipass.
<jbailey> dilinger: In other news, I've discovered that cat'ing multiple .gz'ed initramfs' works, so now all we need is better bootloaders, and it's trivially to have the bootloaded assmebler the modules you want for loading. ;)
<jbailey> In the meantime, just have to do that step by hand from the running system.
<jbailey> But when/if bootloaders grow that ability it would be nice to just have those as nice add-ons and just need to generate a config CPIO file that gets added on to drop the configurations onto the initramfs.
<dilinger> nice
<dilinger> jbailey: actually, it would be nice to replace kernel-package w/ a cdbs build
<jbailey> dilinger: Does it get more complicated than I described above?  I haven't done a kernel compiler in.. erm.  a long time.
<jbailey> Like from scratch.
<jbailey> I've mostly just tweaked .config files and built new packages.
<dilinger> it does, but all the complexity can be popped into headers
<dilinger> and a lot of the complexity is backwards compat crap
<dilinger> which we don't have to worry about for 2.6+
<jbailey> Nice, that's handy.
<jbailey> dilinger: How simple do you think it ought to wind up being in the end?  Some variables to refer to the config passes, and have debhelper pluck out all the bits for the various packages?
#ubuntu-kernel 2005-04-17
<jbailey> Hey - post Hoary, what compiler version should be used for the kernel?  Have folks moved to 3.4/4.0 yet?
<dilinger> oh, you guys might be interested in this also
<dilinger> http://wiki.debian.net/?KernelFirmwareLicensing
<dilinger> i know you're also stripping out stuff like qla22xx
<dilinger> looks like a few of them can be put back in, so long as you don't mind the firmware licenses being non-DSFG (of which numerous other firmware bits in the kernel aren't)
<dilinger> jbailey: as far as how simple it would be to implement, i'd need to go through kernel-package a bit more closely
<dilinger> and as far as the compiler, i recall people talking about using 4.0, but 4.0 is known to miscompile parts of the kernel
<dilinger> (haven't actually tried 4.0 myself, yet)
<jbailey> Ah, okay.  doko and I are writing the toolchain transition document, and need to figure out what compiler has to be around for the kernel.
<jbailey> is 3.4 generally considered to work?
<dilinger> you can probably assume whatever the latest released version of gcc will work ok
<dilinger> if it doesn't, people will probably fix it quickly
<zul> hey
<fabbione> morning
<fabbione> oh zul already left...
<fabbione> ehhehe
<fabbione> i know why his debian dir is blown away :)
<fabbione> that's why added the point d) i leave this up to you :)
<fabbione> there is the trick ;)
<lamont> lol
<fabbione> lamont: there is only file that is patched in the diff.gz
<fabbione> exactly to avoid that hehhe
<lamont> you evil man you
<fabbione> well I got caught in the same problem when i did 2.6.9 :)
<fabbione> lamont: so. do you know if he prepared the .orig.tar.gz?
<lamont> dunnop
* lamont was at a meeting for the last couple hours
<lamont> had just gotten home about the time he went to bed
<fabbione> ehe ok
<lamont> eth0: no IPv6 routers present
<lamont> gonna have to do something about that one of these days
<lamont> :)
<fabbione> do you remember what is the dpkg-buildpackage option to override the distro?
<lamont> does 2.6.12 have related in ip6tables, I wonder?
<fabbione> so that dpkg-genchanges will report hoary
<fabbione> lamont: not that i know off, but we will make it part of it
<lamont> -D
<fabbione> -Dhoary ?
<lamont> yeah
<lamont> see people.ubuntu.com/~lamont/uch
<lamont> works hard to do the right thing for both native ubuntu, and debian packages
<lamont> with uch -i support
<fabbione> oh that wasn't it
<fabbione> i lost libcairo because it was uploaded to ubuntu with the wrong distro
<fabbione> i only need to rebuild without messing to much
<fabbione> but i guess i can just edit the changes before signing them
<lamont> how the hell did it get the wrong distro?  sbuild -dhoary would give you a hoary changes file...
<fabbione> lamont: probably bvecause i builded it manually
<fabbione> i try to fork buildd when it goes to gcc & co since they take really a long time
<fabbione> and it must have been a Build-Dep i needed on the fly
<fabbione> still gcc-4.0 has bad Build-Dep
<fabbione> it should be versioned
<fabbione> and i told doko
<dilinger> hm
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: | There are no kernel bugs.. only broken hardware | bk is dead
<dholbach> heya
<dilinger> fabbione: long live baz? :)
<fabbione> ehhee
<dholbach> i have to ask about the universe kernels again - don't want to do anything wrong
<dholbach> i made up a list of packages to sync from debian for universe. would alsa-modules-i386, kernel-image-2.4.27-i386, kernel-patch-powerpc-2.4.27, kernel-source-2.4.27, pcmcia-modules-2.4.27-i386 -- kernel-image-2.6.10-amd64, kernel-image-2.6.10-i386, kernel-image-2.6.10-ia64, kernel-patch-powerpc-2.6.10, kernel-source-2.6.10 be ok? and what about kernel-image-2.4.27-ia64, kernel-source-2.6.11?
<fabbione> dholbach: dude... SNMP :)
<dholbach> *cry*
<dholbach> i'm absolutely happy with the main kernels too
<dholbach> i just want to have the universe kernel stuff SOMEHOW under control
<dholbach> i'd be happy to chuck everything with *kernel* in the name completely out
<dilinger> why include the universe kernels at all?
<fabbione> dilinger: 2.4
<dholbach> we'll need 2.4 - it was fabbione's wish! so fabbione: it IS your F.CKING problem
<dilinger> ah
<dholbach> so please advise me
<dholbach> :-)
<fabbione> dholbach: skip 2.6 please
<fabbione> three is no need to
<dholbach> fabbione: zul told me to include them
<fabbione> and keep the minumum for 2.4
<fabbione> aka no external modules like alsa
<fabbione> dholbach: why?
<dholbach> *shrug*
<dholbach> what about pcmcia, alsa? ia64 as well?
<fabbione> no pcmcia, no alsa.. ia64 ask T-Bone
<fabbione> only a bare kernel
<dholbach> ok, so kernel-image-2.4.27-i386, kernel-patch-powerpc-2.4.27, kernel-source-2.4.27
<dholbach> nice, thanks
<fabbione> we want to provide a minimum 2.4
<fabbione> that's all the user need
<dholbach> and i'll get back to T-None for 2.4-ia64
<fabbione> otherwise it's their problem
<dholbach> yeah
<dholbach> i'll have a brief look over the kernel-patch-CRACK packages as well
<dholbach> maybe we can get rid of them in one swish as well
<dholbach> thanks fabbione 
<fabbione> no problem
<fabbione> or better. SNMP
<jbailey> fabbione: Mmm.  Will you be really upset if the Breezy glibc doesn't run on 2.4?
<fabbione> jbailey: not at all
<jbailey> And any applications compiled with it...
<fabbione> i am ok to kill 2.4 in breezy
<jbailey> Cool. =)
<fabbione> at that point they had 1 year to convert
<fabbione> that is a reasonable amount of time
<jbailey> doko and I were hashing out the breezy toolchain plan last night, and I've proposed making nptl the default set of threading headers.  If we're doing that, we may as well the set the minimum kernel version at 2.6.8 or so.
<dholbach> jbailey: you know what will happen to gcc-2.95?
<dholbach> jbailey: i'd love to chuck it out at some stage
<dholbach> jbailey: but there are unfortunately packages that hard depend on it
<jbailey> dholbach: Ask the kernel folks here.  I assume that gcc-2.5 is only kept around for them.
<fabbione> dholbach: afaik i know the only thing that still requires (officially) gcc 2.95 is silo
<fabbione> that i am anyway compiling with gcc-3.3 and seems to work
<jbailey> silo does?  Ugh.
<fabbione> jbailey: there is a note about compiling silo with more recent compilers...
<jbailey> Maybe a nice summer project will be to port grub2 to sparc.
<dholbach> i'm currently working on MorgueCandidates and checking all the reverse depends
<fabbione> jbailey: if you want to blow away some dust from that code.. 
<fabbione> jbailey: have fun.. really :)
<fabbione> i am already scared enough to change bootloader on i386
<jbailey> fabbione: 'kay.  I'd have to think about that from a copyright point of view.  If I dig into silo internals, I'm not clean for hacking grub2 anymore, although I could work with someone else to do it.
<fabbione> jbailey: wtf????????
<fabbione> is that somekind of retarded licence?
<jbailey> No, it's the recommended steps for GNU maintainers on keeping copyrights clean.
<jbailey> Not the license at all, but the code ownership.
<dilinger> fabbione: i dunno about requiring gcc-2.95.  the theory is that recompiling it w/ gcc-2.95 reduces bugs
<dilinger> fabbione: i'm not convinced it actually does, as i see the same bugs regardless of compiler
<fabbione> dilinger: the problem with silo is slightly different
<fabbione> jbailey: i will need to translate the Italian Bible of Code Obfuscation
<fabbione> and hand a copy over to you
<jbailey> *lol*
<fabbione> well i think BenC wrote silo
<fabbione> you could simply ask him
<jbailey> fabbione: It's usually not that bad.  Mostly it's a matter of someone reading the code and then explaining in English how it works in a document.  Then someone else can take the very detailed english document and turn it into code.
<jbailey> The final implementation will vary enough to be clean.
<jbailey> And as a side effect, there's documentation. =)
<dilinger> vil
<dilinger> evil
<fabbione> right.. but if BenC allows copy of the code...
<fabbione> it will be faster
<fabbione> also because BenC would have to write the documentation anyway
<Mithrandir> jbailey: uhm, but silo is GPL?
<Mithrandir> oh, code ownership, as you say.
<jbailey> fabbione: True, but my luck getting anything useful out of benc.. (Like, say, even a reply by email) is not high.
<jbailey> He'll even drop out of an email conversation..  And not reply for 6 months.
<jbailey> Mithrandir: Yeah.  It's the part that sucks about GNU hacking, but has the nice result that when the lawyers come knocking, it's not at my door.
<fabbione> jbailey: ok, i can try to contact him, since i know him for reasons outside Debian 
<Mithrandir> jbailey: so you shouldn't ever look at non-FSF code if you ever want to write something similar?
<dilinger> jbailey: yea, but how often do the lawyers come knocking?
<jbailey> Mithrandir: Ideally, yes.  Or you need to radically alter the implementation.  The examples they give are things like if it's a two pass parser implementation, do it in one.  If they do all of the work in core, do it as a stream.
<Mithrandir> jbailey: well, that can be just the shell, the algorithms may still be the same.
<Mithrandir> though, I'm not sure you can actually have copyright on such small parts as "a linked list implementation", since it's not new in any way.
<jbailey> fabbione: Cool.  If he's interested, I can ask for a disclaimer to be sent to him.  So just something saying that if we copy the stuff, it's not a big deal.  Weaker than a copyright assignment.
<fabbione> jbailey: sure..
<fabbione> i can try.. and let see..
<jbailey> Mithrandir: Right.  In Canada and the US, you can't copyright the algorithm anyway.  It's just a way of making sure the code is sufficiently different.
<jbailey> Mithrandir: I try not to think about European law too much, it's fundamentally different in enough ways that I don't pretend to know it.
<Mithrandir> jbailey: heh, :)
<fabbione> jbailey: do you remember his NON Debian email address?
<fabbione> i think it was something like phunnyfarm.org?
<jbailey> That sounds familiar.  /me tries to think if he's subscribed to a list where benc would've posted to.
<jbailey> ISTR he lists his email addys in his .sig
<fabbione> debian-sparc?
<jbailey> I checked -private, and they're weblinks in his .sig.
<fabbione> here is
<fabbione> Sender: Ben Collins <bmc@phunnypharm.org>
<fabbione> i was pretty close :)
<fabbione> jbailey: ok mailed...
<fabbione> let see if he answer back
<zul> hey
<fabbione> hey zul
<zul> fabbione: :P
<fabbione> 2.6.11.90 building here now...
<zul> good good..
<fabbione> zul: btw.. read the chan logs from this morning
<fabbione> i arrived a few minutes after you left :)
<zul> yeah i saw that im missing step 3 :)
<fabbione> ehhee
<zul> bastard
<fabbione> btw.. bk is dead forever
<zul> :)
<zul> huh?
<fabbione> no.. i told you: I will let you figure it out
<zul> why is bk dead?
<fabbione> http://kerneltrap.org/node/4966
<dholbach> does our kernel come with kernel-patch-bluez applied?
<fabbione> dholbach: 2.6 has bluez and we also added some more recent snapshot
<dholbach> fabbione: thanks, will chuck out
<zul> heh...i wake up and bitkeeper still sucks ;)
<fabbione> eheh
<zul> heh...all i get on my gentoo email is spam
<Mithrandir> zul: same goes for Debian mails.  Spam and bug reports. :P
<zul> i know..
<zul> i just like to bitch about stuff :)
<fabbione> amen.. building the last flavour...
<zul> cool...then do the monkey dance :)
* lamont crawls back into bed after checking his shadow.
<fabbione> lamont: ehhee
<fabbione> later
<lamont> about an hour or so
<lamont> can't arrive on the neighbor's doorstep this early in the day...
<fabbione> ehhehe
<fabbione> i am going for a nap too
<zul> lazy sods :)
<fabbione> bah
<fabbione> couldn't sleep
<zul> you had dreams of pointers and arrays in your head right
<fabbione> i just figured how to steal 3 IP addresses from my ISP instead :)
<zul> im telling
<Lathiat> fabbione: h aha
<Lathiat> fabbione: the isps here notice when you do that
<Lathiat> fabbione: riend of mine stoll half a class C once :)
<fabbione> well basically they have an offer for a /30
<fabbione> but they assume to configure that on the router eth
<fabbione> that means that they leave to you only one ip
<fabbione> wrong...
<fabbione> i can reconfigure the router to use a pvt class on the eth
<fabbione> route the /30 to the server
<fabbione> and route each single ip to different machines in terms of /32
<fabbione> bang
<fabbione> 4 ips instead of 1
<fabbione> traceroute would skip on hop...
<fabbione> tough luck
<Lathiat> just run a iptables queue script to fake the extra hop :)
<fabbione> jbailey: i got an answer back from Ben
<jbailey> fabbione: w00t!
<jbailey> fabbione: and, and, and....? =)
<fabbione> jbailey: and now i am explaining him the problem.. it was just a "hey dude.. are you still alive?"
<jbailey> I'm guessing the answer was yes, rather than an automated "I'm spending a year dead for tax purposes". =)
<fabbione> second mail with the info requests on the way
<dilinger> alright, davem doesn't get his isos until he makes 280 support stop sucking
<dilinger> bleh, ECHAN.  too many #*-kernel
<zul> there is only 2 you have to worry about...well one really ;)
<fabbione> dilinger: i am surprised nobody started a flame on LKML yet
<fabbione> are they talking on irc?
<zul> for bitkeeper?
<fabbione> yeah
<zul> heh i think everything has been said before ;)
<dilinger> i think everyone's quietly celebrating ;)
<dilinger> except linus & co
<dilinger> hm, i should sleep, i need to be up in like 7 hours
<fabbione> eheh good night
<dilinger> night
<zul> fabbione: at least the flames are going on slashdot
<fabbione> zul: i don't really read /.
<fabbione> it's too full of lusers
<zul> hehe...well you wanted a flame war ;)
(Mithrandir/#ubuntu-kernel) lamont_r: the local star cluster?
(Mithrandir/#ubuntu-kernel) as in, galaxy cluster
(lamont_r/#ubuntu-kernel) yeah... by itself, cluster tends to bring to my mind the military/fire term....
(lamont_r/#ubuntu-kernel) but like dholbach  says, unlikely to happen anyway
<lamont_r> that's the beauty of derivatives - they can have their own archive... :-)
<Mithrandir> so what should ubuntu name the maintained parts of universe?  Mars?
<dholbach> lamont_r: yeah i look forward to Ancient-buntu, they can have a lot of stuff out of universe
<lamont_r> dholbach: yeah - we really need to get through a policy that packages that haven't been uploaded in 6 years really need to justify their continued existance, or they at least move into the 'blackhole' component
<lamont_r> supernova?
<zul> hey fabbione 
<fabbione> yo
<T-Bone> lamont_r: that could be an idea. Yet we may need an answer quickly for hoary :)
<lamont_r> T-Bone: I believe 6 years would just about start to apply to 2.0 kernels now...
<T-Bone> lamont_r: lol
<T-Bone> maybe an absolute timeline isn't good. Some packages might be tagged "DEPRECATED" in other and more obvious ways
<lamont_r> T-Bone: the question really is, what (if any) quality standards are the MOTU allowed to require for packages to remain in universe.  And that's an MOTU/sabdfl question, not a kernel-team question
<T-Bone> lamont_r: true
<lamont_r> although the answer does seem to be that dead/dying packages can be moved to the morgue
<T-Bone> lamont_r: but then, kernel packages shouldn't be discriminated
<T-Bone> depending on said QA, all or none should be removed
<T-Bone> lamont_r: as long as you don't consider kernel as something special, which i do, btw
<T-Bone> imo, kernel packages are very distribution specific, and since we have our own kernels, i don't think we should ship debian ones on the ground we're shipping all that debian has. This is confusing to users. Some might chose to use these packages which we don't support, end up with security issues and the like, and blame us for it
* kylem agrees with you.
* T-Bone ^5s kylem :)
<T-Bone> lamont_r: *that* question should be sorted out among us before poking sabdfl about it, imho
<jbailey> lamont_r: The 2.0 kernel maintainer is a DD, I should suggest that he upload an update just to reset the counter ;)
<T-Bone> jbailey: lol
<zul> yay...i had to help up setting cvxs
<zul> er...cvs
<zul> the horrors i have seen.
<lamont_r> jbailey: motu did an upload (I think), speciifcally to fix a katie reject because there was a file in the .deb with a 1980 timestamp or so
<zul> heheh
<jbailey> But..  But..
<jbailey> I'm sure it was just some dark and dustry corner of emacs...
<dholbach> fabbione: the powerpc-2.4-kernel failed to build - i'm not sure what to do about it...
* T-Bone notices he has an impressive count of packages with wrong build-dep, supposes that might interest the MOTUs for breezy (probably they're already aware of the issues though)
<dholbach> T-Bone: fire away - anything not listed on wiki.ubuntu.com/UniverseUnmetDeps?
<T-Bone> lemme look
<dholbach> althought the kernel-stuff should be out, after elmo purged
<T-Bone> dholbach: hmm, i'm not talking about that
<T-Bone> i'm talking about *build* dependencies actually
<dholbach> ahhhhh
<dholbach> yes
<dholbach> sorry
<T-Bone> eg, i have a xmms pluggin trying to build itself without debhelper
<dholbach> oh nice
<T-Bone> gives you the very funny failure "dpkg-buildpackage: command not found"
* dholbach hears himself say: chuck it out, nobody needs it
<dholbach> erm... which one?
<dholbach> i'd be delighted to fix it
<T-Bone> lemme look
<dholbach> we're just composing UniverseLastMinuteFixes
<dholbach> so if you have some ultra-urgent stuff, tell us
<dholbach> haha: dietlibc has libcruft/ - nice :-)
<T-Bone> ------------------------------------------------------------------------------
<T-Bone> dpkg-source: extracting xmms-infopipe in xmms-infopipe-1.3
<T-Bone> sh: line 0: exec: dpkg-buildpackage: not found
<T-Bone> dholbach: ^^^ that one :)
<dholbach> nice
<dholbach> will look into it
<T-Bone> dholbach: http://buildd.slashdirt.org/logs/previous/k2000/xmms-infopipe_1.3-4_20050402-0734
<T-Bone> dholbach: i have loads of issues that can probably be easily fixed, yet i don't know whether they affect only hppa or not. It seems that a good half of them should affect all archs, but i haven't found time to look on other builders' logs
<dholbach> i'd like to get the ultra-urgent ones listed somewhere
<T-Bone> dholbach: when breezy opens, you might want to educate me about the proper way to fix them, eg either simply uploading the fix or sending it to whoever care. I don't mind doing a bunch of simple uploads if that can help you guys
<dholbach> so people know where to head first, when trying to help out
<T-Bone> well i can't really tell you what's ultra urgent and what's not, since i'm running hppa autobuilders, and hppa isn't supported (yet) :)
<dholbach> :-)
<dholbach> package-wise
<dholbach> stuff out of universe you need every day :-)
<T-Bone> heh
<T-Bone> well, unless lamont sends me his nice parsing scripts, i have limited pre-parsing done at http://buildd.slashdirt.org/*html
<T-Bone> lemme clean these a bit so that they only show the last round of builds
<dholbach> T-Bone: build-dep added
<T-Bone> hehe
<T-Bone> you're going to spend the night here if i start listing them all :)
#ubuntu-kernel 2006-04-10
* crimsun frowns at git
<crimsun> fatal: packfile .git/objects/pack/pack-3524f1c76b188d5a8e36c5acbe481f03ae5dcbff.pack does not match index.
<infinity> BenC: Do you know much (if anything) about ACPI on Thinkpads?
<infinity> BenC: Specifically, why my TP's fan never seems to want to spin up to "windtunnel speed", even when the CPU is in the process of overheating?
<infinity> BenC: In Windows, if you overheat it (say, by playing a 3D game), it'll spin up to deafening speeds and cool the thing right back down again.  Even on reboot, the first thing it does when doing POST checks is to spin the fan way up.  But it never does so in Linux.
<infinity> BenC: (The punchline to this is that compiling on my machine will often lead to it overheating to the point of random video/cache/RAM corrpuption, and shortly after that, crashing hard)
<BenC> infinity: no idea really
<BenC> infinity: try the latest kernel, and see if it helps
<BenC> there's lots of shit in there
<infinity> Ahh, the lots of shit" release.
<infinity> Excellent.
<infinity> s/the l/the "l/
<lamont> hrm... so when I hotplug a scsi drive, how come it doesn't automagically show up ofr me?
<fabbione> lamont: it does here..
<fabbione> can you check with udevmonitor if the kernel sees the even?
<lamont> will do
<phaidros> how to update alsa kernel-modules to latest? (i have the latest alsa-driver & ubuntu kernel headers in /usr/src and installed make-kpkg)
<phaidros> i'm using dapper, btw. :)
<phaidros> have some troubles with moy soundcard and the advice from the alsa-devs is to use latest src :/
<phaidros> so now I'm trying to comile latest alsa-src onto running kernel (2.6.15-19-686 )
<phaidros> how to do that with kpkg ?
* pappan looking for BenC
<pappan> hi BenC
<BenC> hello
<pappan> i was the one who had filed bug 33265
<pappan> (17:55:49) Ubugtu: Malone bug 33265 in linux-source-2.6.15 "reboot does not do a reboot in sony laptop" [Normal,Unconfirmed]  http://launchpad.net/bugs/33265
<pappan> bug 33265
<pappan> the bot is not here ?
<BenC> Try booting with reboot=h and then also reboot=r
<BenC> see if either of those allow it to reboot properly
<pappan> ok i will try it later today.. i am now working in a RHL box
<pappan> so if one fails i have to try the other ?
<BenC> correct
<pappan> i also want to get involved in fixing it if possible :)
<BenC> fixing it requires knowing the outcome of the reboot= stuff
<BenC> Send results to the bug report, please
<zul> heylo
<BenC> hey zul
<zul> hey BenC how is it going?
<pappan> BenC: will do that
<pappan> thanks
<BenC> zul: pretty good
<zul> thats good to hear...did you have a look at my patches?
<BenC> zul: yeah, I have them queued for next release
<zul> sweet..
<mjg59> Now we have to see how many people have broken wireless cards...
<mjg59> (Since the softmac prism54 driver will now bind to a pile of them instead of ndiswrapper)
<NAiL> How would I go about getting a small patch into the ubuntu kernel? Blacklist c2/c3 on ibm thinkpad bios 1set70ww (Thinkpad R40e).
<NAiL> other revisions of the same bios is already blacklisted in processor_idle.c, but the bios I'm using is apparently newer.
<zul> NAiL: open a bug in launchpad
<NAiL> What are the chances of a fix like that going into the dapper release?
<NAiL> (#38228)
<zul> pretty good ill make a patch for it tonight
<NAiL> thanks :)
#ubuntu-kernel 2006-04-11
<mjg59> BenC: The Broadcom stuff seems really quite solid now
<cjb> BenC: Do you maintain binary compatibility with upstream, or could I try to persuade someone to carry the fs events connector/netlink patch?
<mjg59> cjb: Userspace or kernelspace?
<mjg59> (Compatibility)
<cjb> Kernelspace; new netlink entries are analogous to new syscalls.
<mjg59> Then there's no real effort
<mjg59> So you just need to talk Ben into believing it's useful :)
<cjb> Cool.  I wonder what kind of convincing one makes about whole fs event notifications being useful.  Seems like a you-get-it-or-you-don't thing.
<cjb> rlove doesn't like the patch; he dislikes that you need to have a daemon up to catch the events, so he wants an event log to go into ext3/jbd instead.
<infinity> I'm with rml, but only because I'm a frothing fanboy.
<infinity> (And I hate having 372 helper daemons running just so my kernel can talk to itself)
<cjb> infinity: Stephen/tytso are never going to accept such a patch to ext3, though.  And I don't think the jbd gives early enough context for it to stay in there without hitting ext3.
<cjb> I'm a frothing fanboy too, and did take the time to write up rml's thoughts:  http://blog.printf.net/articles/2006/03/31/filesystem-notifications-revisited
<cjb> But that doesn't mean I want to give up on the feature because neither set of maintainers think it's quite right for their subsystem.  The netlink version requires you to keep the daemon running in order not to miss events, but doesn't break anything?  I'm for that, then.
* lamont wonders why nfs-modules-2.6.15-20-hppa32-di doesn't exist
<lamont> (since debian-installer wants it and all that...)
<infinity> lamont: Already discussed with Kamion, who claimed he'd sort out whose bug it is. :)
<lamont> oh, even better.  danke
<dholbach> hey guys!
<dholbach> BenC: what could we put on a wiki page to make bug triage for Kernel bugs easier?
<dholbach> http://wiki.ubuntu.com/DebuggingUSBStorage http://wiki.ubuntu.com/DebuggingIRQProblems http://wiki.ubuntu.com/DebuggingHardwareDetection are not really it, are they? :/
<zul> heylo
<BenC> dholbach: Check the CategoryKernel stuff
<dholbach> i see
<dholbach> um...
<dholbach> i don't want to build a kernel... i was more looking for information for bug triagers
<dholbach> questions they can ask, stuff we can point people to, if they have kernel problems
<dholbach> if you want people to triage kernel bugs next week's friday - it'd be great to have something like that
<BenC> there's a lot of that under CategoryKernel
<BenC> debugging stuff
* dholbach has another look
<BenC> the main thing that needs is questions like "Was this under dapper"
<dholbach> what else? lspci -v, lshal, dmesg - is that kind of stuff of any use?
<BenC> lspci -vv
<BenC> lspci -vvn
<BenC> dmesg
<BenC> https://wiki.ubuntu.com/MemoryTest
<BenC> https://wiki.ubuntu.com/DebuggingSystemCrash
<BenC> https://wiki.ubuntu.com/DebuggingIRQProblems
<BenC> https://wiki.ubuntu.com/DebuggingProcedures
<BenC> those are the four URL's I use to point people
<BenC> also, bug submitters need to be explicitly told "attach the output to these commands, do not paste them into a comment"
<BenC> otherwise we get a huge unreadable comment listing
<BenC> Sound problems need to have alsa-team subscribed
<BenC> 100 new emails in my bug folder just since last night
<BenC> The problem for me is, a lot of those are bugs getting closed, but I still have to read all the emails to find out
<BenC> a lot of them can be closed, but I still have to go through the emails to verify it is a problem I fixed
<dholbach> same here
<dholbach> for gnome land we get millions of bug reports :/
<dholbach> but i'll knock up a webpage with the stuff you mentioned
<dholbach> DebuggingKernelProblems?
<dholbach> does that sound good?
<BenC> yeah
<infinity> Would be nice if Malone could put the bug status in the Subject line, now that I think about it.
<infinity> So you could skip mails with "[Fix Released]  foo bar baz" if you're in a hurry and catch up on them later.
<mjg59> Hrm.
<mjg59> Why is hibernate really really really slow on battery and fast on ac?
<mjg59> And why has it just worked properly for me? IT BURNS
<BenC> mjg59: where's the script that allows people to add modules that should get unloaded/reloaded on suspend/resume?
<BenC> s/script/config/
<mjg59> BenC: /etc/default/acpi-support
<BenC> thanks
<mjg59> Hm. Now I seem to have fixed it, but I'm not sure how...
<zul> BenC: ping..
<zul> bored bored bored..
* cjb gets back from telling the people in the LinuxWorld FSF booth that he wishes they could sue nVidia.
#ubuntu-kernel 2006-04-12
<bojohan> hello, i'm looking at Bug #29789: tv card audio not working
<bojohan> in fact, it seems that what i need is to load tda9887 before bttv (snd_bt87x isn't involved)
<bojohan> bad: $ insmod tuner.ko ; insmod bttv.ko autoload=0 ; insmod tda9887.ko
<bojohan> good: $ insmod tuner.ko ; insmod tda9887.ko ; insmod bttv.ko autoload=0
<bojohan> (bttv autoloads tda9887)
<bojohan> is this useful to anyone?
<bojohan> Pinnacle PCTV using line-out
<NAiL> zul: Thanks (If it was you committing the fix) :)
<zul> NAiL: no probs the patch was pushed to benc this morning
<NAiL> So it'll get built and put in the feeds eventually?
<zul> yeah
<NAiL> Cool :-)
<NAiL> Will it eventually be pushed upstream too?
<zul> maybe..
<joelbryan> Is it just me or the kernel 2.15-20 feels much faster?
<crimsun> it feels the same as 19 to me
<joelbryan> it's faster doing grep regexp search
<crimsun> got a test case?
<joelbryan> grep -i -R "word" *
<crimsun> joelbryan: can't see any differenc.
<crimsun> +e
<infinity> joelbryan: If "*" is a really large list of files, maybe you're just seeing some good disk caching going on.
<infinity> joelbryan: If not, then the kernel has nothing to do with it, and you'd look to grep or glibc for having made that faster.
* infinity decides to plan a patch to put a full POSIX and PCRE regex implementation in kernel space, and post it to LKML next April 1.
<zul> heylo
<zul> BenC: ping
<zul> doh...unping
<jkakar> BenC: jbailey suggested I ask you this question--Do you know what the difference between "free" and "available" inodes is?
<cjb> jkakar: What's presenting "available" inodes?
<jkakar> cjb: Python's os.statvfs() returns a bunch of values, two of them are F_BFREE and F_BAVAIL... it says that avail are "total available to non-super user"; I'm trying to understand why the numbers would be different.
<cjb> I think the B means they're talking about blocks, not inodes.
<infinity> jkakar: Because filesystems have a set number of blocks and inodes reserved for root use.
<infinity> jkakar: So regular users can't accidentally fill up the filesystem completely.
<jkakar> infinity: Ah, thanks.  That makes sense.
<infinity> (base)adconrad@cthulhu:~$ sudo tune2fs -l /dev/sda3 | grep Reserved
<infinity> Reserved block count:     122094
<infinity> Reserved blocks uid:      0 (user root)
<infinity> Reserved blocks gid:      0 (group root)
<infinity> (for example)
<jkakar> infinity: Awesome, thanks.
#ubuntu-kernel 2006-04-13
<zul> heylo
<pappan> hi
#ubuntu-kernel 2006-04-14
<bluefoxicy> does anyone happen to have an ubuntu 2.6.16 kernel?
<crimsun> ...no?
<bluefoxicy> not even hidden away, from the repos, in a dark secret dapper+1 server room?
<crimsun> there is no cabal
* bluefoxicy is still having the null pointer deref etc etc problems... :(
<bluefoxicy> launchpad 29586, which I eventually tracked down to the kernel level DRM drivers for via :/
<bluefoxicy> I have no idea if this was ever fixed in mainline though
<crimsun> this may read stupidly, but have you actually booted with "irqpoll"?
<bluefoxicy> crimsun:  irqpoll not really.
<bluefoxicy> crimsun:  I tend to miss minor details like that :<
<bluefoxicy> crimsun:  well I'll try that in a minute, can you explain though what irqpoll does and what problems it may cause so I'm aware of what I'm actually doing?  :>
<crimsun> vi +673 Documentation/kernel-parameters.txt
<crimsun> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=7a74d4f916f6a9983b5e0de07849cc239c75702c;hb=4b0cbe9535c6aaae6937685c0d4c9e327a8a353c;f=Documentation/kernel-parameters.txt  if you're lazy.
<bluefoxicy> crimsun:  don't have the kernel source installed for once  :) thanks.
<bluefoxicy> wow
<bluefoxicy> that looks ugly as shit
<bluefoxicy> but okay
#ubuntu-kernel 2006-04-15
<dholbach> hey guys
<dholbach> ummm - how do I find bug reports for the kernel team?
<dholbach> if we want to make the HUGDAY on Thursday a special kernel hug day, we need to make sure that people can find those bugs
<infinity> Anything files on linux-source-2.6.15?
<infinity> filed, too.
<infinity> And god know what other interesting criteria.
<dholbach> it's a big chaotic
<dholbach> but i found something to work with
<dholbach> http://launchpad.net/people/kernel-bugs/+packagebugs
<dholbach> some are still for the ubuntu-kernel-team
<dholbach> a lot of stuff filed on Ubuntu, etc :/
<infinity> Wow, I'm brilliant.  I just deleted something I was uploading.
<dholbach> :-/
* dholbach hugs infinity
<dholbach> I managed that too :-(
* infinity is puzzled.
<infinity> Why do we need a team for kernel bugs, above and beyond the kernel team?
<infinity> How.. Confusing.
<dholbach> yeah, what I thought
<dholbach> we need to be able to remove teams again
<dholbach> or mark them inactive or something
<dholbach> does http://wiki.ubuntu.com/UbuntuBugDay/Draft look ok to the kernel team?
<ivoks> hi
<ivoks> there is small problem with kernel and input devices :/
<mjg59> ivoks: Mm?
<ivoks> mjg59: #38989
<ivoks> mjg59: just reported (and noticed)
<mjg59> ivoks: Uhm. You mean the device ordering is unstable?
<ivoks> yes
<mjg59> More likely to be a udev issue
<ivoks> could be that too...
<mjg59> Why's it a problem?
<ivoks> if you configure alps touchpad in X
<ivoks> as /dev/input/event2
<ivoks> after reboot it doesn't work
<mjg59> Why not just use the multiplexor?
<ivoks> huh?
<mjg59> Tell it to use /dev/psaux
<mjg59> That's what the default configuration is
<ivoks> ok. will try that
<ivoks> nope
<ivoks> (EE) Alps Touchpad no synaptics touchpad detected and no repeater device
<infinity> No joy on /dev/input/mice either?
<ivoks> infinity: IIRC no
<ivoks> well, touchpad works
<ivoks> but synaptic driver doesn't
<ivoks> so, touchpad works via /dev/input/mice, but not with dynaptic driver
<ivoks> it has to be /dev/input/eventX if I'm not mistaken
<infinity> How painfully fragile...
<mjg59> Uhm.,
<mjg59> I'm really not convinced by that.
<mjg59> My Alps pad is being read via /dev/psaux
<mjg59> (As far as I can tell)
<ivoks> and ALPS features work?
<ivoks> like, hor-ver scroll, middle button
<ivoks> tap and drag
<ivoks> cause, ALPS works without features as /dev/input/mice
<ivoks> i'll be back... just to try something else
<mjg59> Well, the alps driver has bound to it
<ivoks> ok, no, /dev/input/mice doesn't work with synaptics driver :/
<ivoks> if it's an udev issue, that could be fixed with a simple rule, right?
<ivoks> like apitek tablet it's fixed with /dev/input/aiptektablet 
<zul> hey BenC 
<BenC> zul: hey
* ivoks smashes with his head against the wall
<dilinger> fabbione: ping?
<dilinger> is there an ubuntu x-related channel?
<dholbach> does http://wiki.ubuntu.com/UbuntuBugDay/Draft look ok to the kernel team?
<dholbach> since you guys wanted to get people involved in kernel bugs triage :)
<cjb> Hi.  Is there a way to force SMP/UP with kernel arguments, with smp-alternatives?
<fabbione> dilinger: no
<dilinger> ok
<fabbione> dilinger: it's just me, infinity and heno
<fabbione> so we keep it on -devel for now
<dilinger> i figured it out anyways
<dilinger> @$#!$ /root/xorg.conf crap, instead of it using /etc/X11/xorg.conf
<cjb> dilinger: Augh, I hate that.
<fabbione> dilinger: eh?
<dilinger> fabbione: i had an xorg.conf in /root
<dilinger> and was trying to figure out why stuff was broken; i was modifying /etc/X11/xorg.conf trying to fix it w/out realizing it was loading /root/xorg.conf
<dilinger> according to xorg.conf(5x), it loads $HOME/xorg.conf
<dilinger> before /etc/X11/xorg.conf
<dilinger> s/loads/searches/
<fabbione> oh
<infinity> Yeah, that's a rather annoying misfeature when trying to debug WTF is going wrong with a user's setup.
<dilinger> i really can't imagine that ever being useful
<dilinger> i assume the intent was for non-root users
<fabbione> well that assume you can run X as user... that is only partially possible becuase it needs to be suid oot
<fabbione> root
<dilinger> yep
<dilinger> i recall being able to do it
<dilinger> startx
<fabbione> given that X access /dev/kmem to gather some system info :)
<dilinger> as non-root
<fabbione> yes
<fabbione> but it's suid root
<dilinger> hm
<fabbione> if not startx -> X is
<dilinger> are there any access checks there?
<fabbione> something.. yes..
<fabbione> there is even a debconf question for it iirc
<dilinger> it seems like a bad idea to have a setuid program that supports config files loading arbitrary modules from the (non-priv'd) users homedir
<dilinger>        ModulePath "path"
<dilinger>               sets  the  search  path  for loadable Xorg server modules.  This
<fabbione> there are probable some limitations on what you can load as user
<fabbione> but you can try
<dilinger> so what's to stop me from taking the radeon driver, adding a little bit of code that spawns a socket on port 10101 that launches a (root) shell when connected to, compiling it against hoary's xorg, making an xorg.conf that specifies a ModulePath of my custom radeon driver, and doing a startx?
<fabbione> that perhaps the ModulePath is not parsed for users?
<fabbione> -> bed
<fabbione> good night
<dilinger> 'night
<dholbach> night fabbione
<dilinger> RGH
<dilinger> (WW) RADEON: No matching Device section for instance (BusID PCI:1:9:0) found
<cjb> Hm.  The rt2400 wifi driver doesn't work with SMP (!).  Does it work with smp-alternatives, though?
#ubuntu-kernel 2006-04-16
<mjg59> cjb: Blurgh. What's the failure?
<mjg59> cjb: failure with SMP is generally due to lack of locking, rather than the fact that the kernel itself is SMP
<mjg59> So it should be fine with an SMP kernel on UP
<cjb> It's not my hardware, I'm just amazed that we have in-tree drivers that aren't SMP-safe.
<BenC_> there are a lot of them
<cjb> Crazy.  Is the hardware even required to fix them?  Seems like we should've got past that by now.
<pappan> hi BenC_
<pappan> this is regarding (15:35:57) Ubugtu: Malone bug 33265 in linux-source-2.6.15 "reboot does not do a reboot in sony laptop" [Normal,Unconfirmed]  http://launchpad.net/bugs/33265
<lamont> You already have a ELILO configuration in /etc/elilo.conf
<lamont> Install a boot block using the existing /etc/elilo.conf? [Yes]  
<lamont> BenC: ^^^  we need to fix the kernel postinstall script to not screach to a halt in a prompt...
<lamont> FWIW, that's from: Setting up linux-image-2.6.15-20-itanium-smp (2.6.15-20.30) ...
#ubuntu-kernel 2007-04-09
* lamont waves
<lamont> BenC: you around this mornign?
<BenC> lamont: yeah
<_ion> humanitables.
<zul> BenC: ping when are you going to move ubuntu-2.6 to upstream?
<BenC> zul: soon, maybe end of this week
<zul> okie dokies
<_ion> benc: % for mod in nvidia snd-usb-audio; ./hardware_connected -m $mod && echo $mod
<_ion> nvidia
<_ion> benc: I pushed the change.
<BenC> nice
<_ion> benc: I take it the "auto-select nvidia version" functionality isn't going to get to the RC? Will it get to the final release, though?
<Yorokobi> Is upstart's /sbin/init SELinux capable/compatible or should I use sysvinit for SELinux?
<Nafallo> Yorokobi: you might wanna ask #upstart :-)
<Yorokobi> True enough, thanks
<Mithrandir> BenC: any idea about https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/104232 ?
<BenC> Mithrandir: checking...
<BenC> Mithrandir: Looks to me like hd*->sd* changes bit someone
<rtg> BenC: He is using LVM. Could that be it?
<BenC> rtg: LVM shouldn't be affected by hd->sd changes at all
<rtg> How does LVM manage drive relationships?
<BenC> it reads all block devices+partitions listed in /proc/partitions, basically
<BenC> checks for LVM magic and meta data
<BenC> creates the LVM mapped devices based on the meta-data it finds
<rtg> OK, it sounds device name independent.
<BenC> Mithrandir: 104232 really sounds like user induced breakage
<BenC> and if he reads the bug, he'll be able to fix it
<Mithrandir> BenC: ok.. Let's hope so.
<BenC> Mithrandir: between -13 and -14 we basically moved some stuff that had been stuck in piix (ide) back to ata_piix where it belongs (libata-pata)
<Mithrandir> ok
<_ion> Now hardware_connected lists all matching device aliases with -v, so hardware_connected -v 'pci:*bc03*' would list all PCI display adapters, hardware_connected -v 'usb:*' would list all USB devices and hardware_connected -v -m usbhid would list all USB HIDs. Not that this feature is very useful when implementing the nvidia thing.
#ubuntu-kernel 2007-04-10
<orangey> hey all!
<orangey> I'm having an issue with suspend/resume on an NC6400
<orangey> the keyboard stops working until a command is issued..
<orangey> I was wondering how I could propose a patch for something like this without actually fixing the kernel problem..
<Mithrandir> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/97325 ; any idea about this?
<rtg> Mithrandir: bug 97325 is so convoluted its hard to tell what he has. Get him to just boot from the live CD and see what his disk arrangement looks like.
<Mithrandir> it would probably be better if some kernel person talks to him and gets the needed information from him; he's andersja@gmail.com on jabber.
<mjg59_> rtg: I've been looking at the wireless/n-m issue again. As far as I can tell, wpa_supplicant never gets the association message from netlink, despite iwevent showing it
<rtg> So, since I touched it last, I'm stuck :)
<zul> rtg: pretty much :)
<orangey> hey all!
<BenC> rtg: Get dmesg from -14, and lspci -vvn
<Mithrandir> would anybody mind if I nuke any kernel modules < 2.6.20 (< 2.6.19 for xen modules) from feisty?
<Mithrandir> we seem to ship stuff like the vmware-player-modules for 2.6.15
<zul> xen-source uses 2.6.19
<maks_> xen is pretty unstable on 2.6.20
<zul> but I would kill linux-source-2.6.19 ;)
<_ion> benc: It was intentional to put nvidia_new as the last item in the nvidia_supported line in debian/rules, right?
<BenC> _ion: Is ordering importing?
<BenC> err, important
<BenC> I need another lrm upload to fix the ppc ftbfs anyway
<BenC> _ion: should I make _new first?
<BenC> Mithrandir: for feisty, there should be only 2.6.20
<BenC> well, and 2.6.19 for xen I guess
<Mithrandir> BenC: yup, just wanted to make sure
<orangey> hmmm. I know it's a basic question, but this is the first time I use linux on a multi-core.. do I use -generic for it? or 686-smp?
<Mithrandir> orangey: -generic
<zul> BenC: the 2.6.20 xen patch from fedora doesnt work too well
<BenC> Mithrandir: in regards to the kernel plans for release, I was hoping the kernel-team could work on release-critical bugs this week, and we could do a non-abi changing upload this weekend post-RC
<BenC> Mithrandir: That sound ok?
<_ion> benc: I should have commented it more, but there was a comment in nvidia_supported itself. The first argument describes the preferred driver and the ones that follow are fallbacks. With the current state, nvidia_new is only used if neither nvidia or nvidia_legacy support a given PCI ID. To prefer nvidia_new whenever it supports the card, use nvidia_supported $(rbuilddir)/$$i/nv-new/nv-kernel.o nvidia_new $(rbuilddir)/$$i/nv/nv-kernel.o nvidia ...
<BenC> orangey: -generic is SMP
<_ion> ... $(rbuilddir)/$$i/nv-legacy/nv-kernel.o nvidia_legacy
<BenC> _ion: That's not so bad really
<Mithrandir> BenC: ugh, not very happy about that.
<Mithrandir> BenC: give me a bit of time to discuss it?
<mjg59_> Mithrandir: Right now the HPA stuff is still a serious regression
<BenC> Mithrandir: well, we have some fixes to get out, and getting an upload done in time for RC is just not possible
<_ion> benc: Kind of true, since 97xx hasn't received as much testing as 96xx.
<BenC> Mithrandir: we will make every effort to ensure it wont change ABI though, so we can pretty much guarantee that -14 will be the released ABI...with an upload this weekend, it still gives us plenty of time to CD test the new kernel
<_ion> benc: But at least for feisty+1, the drivers probably should be prefered in the order of descending version number.
<orangey> Mithrandir and BenC: Thank you.
<orangey> now to try to fix Bug #105155 : )
<BenC> _ion: right...for not, I'll leave it, and just let 9755 be chosen for cards so new they need it
<BenC> erg, "for now"
<_ion> benc: All right.
<BenC> _ion: guess it was a decent mistake to make...oh, and thanks for all your help with it
<BenC> pity it took me so long to get things out
<BenC> it's was a horrid mess
<_ion> Thanks for your trouble. I realize you have a lot to do, especially just before a release. :-)
<_ion> I take it the patch that actually modifies the modules' alias lists is also going to get to feisty+1?
<_ion> Just installing the override files to /usr/share/l-r-m is okay, restricted-manager has already been modified to read them.
<_ion> But it would naturally be quite nice to get the accurate lists from the modules themselves.
<BenC> _ion: I'm not sure of the side effects of putting actual module aliases in there
<BenC> worried about autoloading and such
<BenC> kylem: Do you have a comparison handy of the ABI changes from the HPA patch?
<kylem> yeah
<_ion> benc: The current aliases in the modules are only *broader*. If the modules are being autoloaded with the modified patterns, they're *definitely* being autoloaded with the current patterns.
<cjwatson> not massively happy about overriding abichecker warnings - nearly every time we've done that before it's bitten us, and we swore not to do it again
<BenC> cjwatson: well, before we ignored actual ABI changes
<kylem> iirc this one only effects libata-core symbols
<kylem> there should be no binary modules like that...
<BenC> cjwatson: the problem with the checker is that it is not smart enough to tell when a function moves without change
<BenC> cjwatson: moving without change really isn't a problem so long as all the symbols stay in the same package
<_ion> benc: But anyway, the current way is fine for feisty.
<BenC> but I worry that HPA does more than move the symbols
<kylem> BenC, it doesn't change function prototypes or anything
<BenC> _ion: I'm following KISS right now :)
<_ion> benc: Yeah. :-)
<rtg> mjg59_: I'm not ignoring you. I just have too many balls in the air. I'm also looking at wpasupplicant source. 
<mjg59_> rtg: No problem
<kylem> BenC, kyle.mcmartin.ca/abi
<mjg59_> kylem: Good to go with the HPA code and the lba48 fix
<kylem> you're sure?
<mjg59_> Yes
<kylem> and it's using piix?
<mjg59_> It's coming up with ata_piix and I'm getting good values
<kylem> can you try a cold boot?
<mjg59_> That was a cold boot
<mjg59_> Want me to try a warm one?
<kylem> sure.
<mjg59_> kylem: Still good. Ship it.
<kylem> thanks.
* Starting logfile irclogs/ubuntu-kernel.log
* Starting logfile irclogs/ubuntu-kernel.log
(rtg/#ubuntu-kernel) BenC: looking...
<zul> yay..
<BenC> maks_: ping
<maks_> BenC: around
<maks_> btw i switched initramfs-tools repo to git
<BenC> maks_: Hey, where's the patch that makes update-initramfs pull the .bak when it fails for kernel version?
<maks_> yes
<maks_> directly out of LP, let me dig the bug nr
<maks_> -> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commitdiff;h=5dfd85f416a10b1c41ca7005de38b58715c04472;hp=c4343742b3bf028e467ac8a58ead95c9bfefc628
<BenC> maks_: thanks
<kylem> mjg59_, do we want to keep my reprogram piix as ahci patch anyway or should i turf it?
<kylem> ok good
<kylem> it wasn't me who broke the abi now. ;-)
<kylem> something is friggity fucked, i'm getting the same abi differences with the patches reverted.
<kylem> and i know they actually reverted since i'm getting the kvm diff too
<rtg> BenC: I just emailed a proposed patch for bug #96480. Lemme know if it seems reasonable.
<maks_> BenC: np, patch works for given testcase :)
<BenC> rtg: reviewing
<BenC> rtg: I think the missing element is setting adapter.name...all the other i2c_add_adapter() uses I see don't need to call device_initialize(), but they do set .name
<rtg> BenC: You might be right. device_register() calls device_initialize().
<pkl_> The "**WARNING** I2C adapter driver []  forgot to specify physical device; fix it!" message itself is harmless
<rtg> pkl: except for the name which is NULL.
<pkl_> yeah
<pkl_> I've chery-picked a patch from 2.6.21-rc1 that remove that warning.
<BenC> that shows up for nvidia too
<pkl_> s/chery/cherry/
<BenC> or maybe it was ati
<BenC> rtg: Could you see about getting a built kernel to that person for testing?
<BenC> rtg: Might be able to get away with just sending them the module compiled for -generic if they seem capable enough to add it in /lib/modules/...
<rtg> BenC: Yes. I'm still trying to figure out what the name should be.
<BenC> "ACPI EC HC smbus driver"
<BenC> seems ok
<rtg> Isn't there an instance number?
<BenC> snprintf(smbus->adapter.name, I2C_NAME_SIZE,
<BenC>                 "SMBus nForce2 adapter at %04x", smbus->base);
<BenC> guess you can do something like that
<rtg> BenC: I'm looking upstream to see what they have done.
<BenC> ok
<mjg59_> kylem: Eh, depends if you think it's worth it. It's certainly not high-risk.
<mjg59_> Sorry, certainly not high-priority
<kylem> yeah
<BenC> ok, I've had my morning burn in time, need lunch
<BenC> Looks like today might be a good day to start on feisty+1 kernel tree
<zul> yay!
<BenC> looking forward to dumping kernel-package from build-deps
<zul> BenC: I think everybody is
* kylem really thinks we should re-evaluate the effectiveness of git though...
<zul> *cough* mercurcial *cough*
<BenC> kylem: I think removing the ubuntu/* stuff from our main tree will help alleviate most of our problems
<kylem> no. but it really makes it quite difficult to see precisely what code we changed.
<BenC> git-diff-tree upstream-linux..HEAD
<zul> BenC: the cp build/vanilla build/ubuntu-xen idea is still ok isnt it?
<kylem> that doesn't work nearly as well as you'd think
<kylem> and provides no context
<BenC> kylem: I think if I also started enforcing a rebase instead of just merging, it would go a long way to help that too
<kylem> keeping all patches in quilt and keeping the quilt-with-all-patches tree in git would not be too bad...
<kylem> but yea, i agree
<kylem> ubuntu/ out of the maintree would help phenomenally.
<cjwatson> building in .diff.gz mode way earlier would help
<BenC> cjwatson: we might be able to do that for feisty+1 with ubuntu/* in a separate package
<BenC> it's all our third part drivers that kept that from being sane
<BenC> *party
<cjwatson> well, also basing on 2.6.20 before it was out
<zul> keeping an ubuntu/patches list would be cool for 3rd party crack (ie: xen openvz)
<BenC> the other problem is the amount of actual patches we have to the main repo
<BenC> we have patches we've been carrying around since breezy because upstream wont take it, or the real fixes are "being worked on"
<kylem> well, with a bigger kernel team, it's possible we'll actually be able to do proper fixes for some of them, no?
<BenC> yeah, I'm hoping that's what happens :)
<zul> community can help as well ;)
<BenC> once I get feisty+1 tree open, we can identify them, and work to have them upstream for next kernel
<BenC> based on release times, I think feisty+1 will end up being 2.6.22, so that gives us that merge window to send things to linus et al
<BenC> it's cool that feisty will end up releasing with the latest stable kernel version instead of a 1 or 2 out version :)
<cjwatson> I think that's worked out relatively well and will work well for feisty+1 too, but maybe not for feisty+2
<cjwatson> or whichever ends up being LTS (but current projection is feisty+2 I think)
<kylem> so next october would be LTS?
<BenC> yeah, we'll need more cooking time on that one
<cjwatson> feisty+2 == April 2008
<kylem> ah, right
<BenC> FYI, I'll be moving ubuntu-2.6.git over to ubuntu-feisty.git sometime in the next few days
<BenC> so if ubuntu-2.6 goes missing, or shows up as not of the same parent, you'll know why :)
<kylem> would it not be easier just to name them ubuntu-${mascot} from the beginning :)
* kylem ducks & runs.
<BenC> that would be like intuitive or something...not really my style
<zul> hah
<kylem> :P
<BenC> problem is I don't know $mascot for feisty+1 yet :P
<kylem> i don't think it's been announced yet, so you have a point there, :\
<zul> how about ubuntu-dev
<BenC> not really much better than ubuntu-2.6
<zul> ubuntu-im-going-to-break-it-nyeah-nyeah.git
<BenC> ubuntu-good-bear.git
<kylem> BenC, *shudder*
<BenC> And anyone that corrects me on why that isn't a good bear, gets the award for being most pedantic :)
<rtg> BenC: I still think bug #96480 is because of an uninitialized device structure. I'm betting it is an uninitialized parent in device_add():464. Could this be a race with platform_bus_init()? I'm almost sure that could be the case in 2.6.20-20.12 when folks get the "forgot to specify physical device" message.
<jbailey> BenC: Around?
<BenC> jbailey: yeah
<anti_pop> sorry, i know its not a support channel. but i cant find an answer: should i use the -generic kernel oder -386 (my cpu is amd athlon xp)
<jbailey> BenC: Heya, I don't think we ever finished talking about the best way for out-of-tree modules to get updated.
<jbailey> BenC: Is now a good time?
<BenC> jbailey: given the recent experience with vbox, I'm leaning toward not putting them in the kernel :)
<Nafallo> anti_pop: generic, as the description says.
<jbailey> BenC: Right, so I think we were last stuck at the fact that I was concerned that building them on boot meant that boot time wouldn't be deterministic after an upgrade.
<BenC> jbailey: ah, right
<BenC> jbailey: should we reserve some topic time at UDS?
<anti_pop> ok, thats what i used to. but somehow im running -386 now, will return to generic. thanks to the team for providing nvidias 9631 driver now (!)
<BenC> will you be there?
<jbailey> I won't be.  I'm giving a talk at JavaOne this year.
<BenC> jbailey: will anyone from support be there?
<jbailey> Besides, after the stories of the last trip to Spain, I think this vegan can stay home. =)
<jbailey> Yup, Etienne and Fabian will both be there.
<BenC> Ok, from what I understand the kernel team will have a room reserved for adhoc discussions, so maybe this is a good topic for rounding those two up
<jbailey> Etienne will certainly want it fixed, I'm not sure if he cares much what the solution is, so long as there's something standard he can plug into.
<jbailey> Ah, nice.
<jbailey> If you're gobbied up and I'm not on the west coast at that particular moment,  I'll try to tune in.
<jbailey> I suspect I will be.  I'm in the bay area for a week.
<BenC> the feisty+1 kernel build system will be built from scratch and we plan to implement some hooks for different things
<jbailey> Ooo.  Are we doing the no-more-make-kpkg dance?
<BenC> yes, amen
<jbailey> 'cause making those hppa patches was really miserable. =)
<BenC> I have an hppa here that I need to get back up, so I should be able to keep it building this time
<BenC> I stopped messing with it after edgy stopped booting for me :)
<jbailey> Nice.  Hppa should generally work well for feisty+1 I think.
#ubuntu-kernel 2007-04-11
<kylem> BenC, ok, i dunno what's up with the ABI.
<kylem> i have the same ABI breakage with / without these patches it seems.
<BenC> odd...there's no ABI breakage in current git that I saw
<BenC> unless there's some stuff I didn't pull yet
<BenC> just two commits from pkl that aren't even related to libata
<kylem> kvm seems to have jumbled about
<BenC> yeah, I overrode kvm ABI
<BenC> grep -v drivers/kvm/ from debian/abi/*/* :)
<kylem> heh ouch.
<BenC> pretty much a no-op if anything in there changes
<kylem> http://people.ubuntu.com/~kyle/feisty/
<BenC> that G965 fix rings a bell, pretty sure we have a bug about that, right?
<BenC> +	u64			n_sectors_boot;	/* size of ATA device at startup */
<BenC> there's the HPA ABI change...struct ata_device
<BenC> lba48 bug looks important
<kylem> yeah
<kylem> 1sec, i'll fix the abi change there.
<kylem> hmm, no way to avoid this really. doh.
<kylem> can't we just force the abi until release and tell people who built their modules against in-devel feisty tough luck?
<jbailey> kylem: I'd say that's probably possible until kernel freeze. =)
<jbailey> But ISVs and such will probably start following along at that poitn.
<defendguin> I was looking for some help with a bug that crept in between -12 and -13
<defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/99648
<defendguin> there was an MMC update in -13 referencing bug 93171
<capiira> hi all i tried to compile my own kernel and downloaded the linux-source 2.6.20 and used the config-2.6.20-14-generic from /boot and now i have a big 230mb kernel :) and wonder why
<capiira> that's my content http://paste.ubuntu-nl.org/15006/
<capiira> i see that there is too much stuff compiled but i used the original .config file
<capiira> so nobody a life?
<ilmari> the mmc merge in 2.6.20-13 "broke" HAL (bug 99648)
<capiira> :/ hmm my kernel did become 230mb big again
<capiira> and i need USB_SUSPEND disabled for my scanner
<capiira> still no nobody a life?
<ilmari> no, we're all lifeless corpses
<capiira> can you help me with my kernel compilation prob ?
<capiira> maybe i forgot to do something important
<capiira> i downloaded the ubuntu linux-source-2.6.20, untared, did a ln -s to /usr/src/linux, copied a lastest generic config to /usr/src/linux/.config, did a sudo make clean and menuconfig and loaded the config, saved it and compiled
<capiira> it always become 230mb big
<capiira> compiled using make-kpkg
<capiira> no one know ?
<cjwatson> capiira: looks like the modules aren't stripped
<capiira> how so? can i change that in menuconfig?
<capiira> its my first kernel compilation and im just doing it because i need USB_SUSPEND off
<cjwatson> make INSTALL_MOD_STRIP=1
<cjwatson> see Documentation/kbuild/makefiles.txt
<capiira> thx
<capiira> you know how to use that with make-kpkg?
<capiira> or if its possible to simply write it into the makefile
<capiira> i wrote INSTALL_MOD_STRIP := 1 into the makefile variable section lets see what will happen
<defendguin> ilmari, have you had any luck lucking for the cause of the regression?
<ilmari> defendguin: no, but I did get hold of a -12 kernel and have attached the udevmonitor output
<defendguin> i saw that
<ilmari> it's definitely the mmc merge that caused it, but I haven't had time to go through the details of the changes
<ilmari> (at work ATM)
<defendguin> ilmari, me too
<defendguin> i had to install xchat here at work so i could try to steer someone into looking at it
<defendguin> bug 99648 if anyone is watching
<crimsun> defendguin: it doesn't seem like a critical regression from edgy or dapper, so it likely won't be addressed in the next week.
<defendguin> it breaks everyone's card reader ....
<crimsun> everyone's?
<zul> or just yours?
<mjg59> Everyone's
<ilmari> hal doesn't pick up MMC card readers any more
<ilmari> because it can't find the parent device from the class-based DEVPATH 
<ilmari> it needs to be /devices/-based
<cjwatson> MMC is fixable in a post-release update, I think
<defendguin> if ubuntu were release and all card readers were not working that would most certainly be a black mark on and reviews that it gets
<defendguin> any reviews*
<BenC> the bug is convoluted...is there a suggested patch we can review?
<BenC> defendguin: have you tried any patches to fix it?
<defendguin> BenC, no i have not.  I am not aware of any patches that are available to fix this particular problem. 
<BenC> mjg59: do you have any ideas on the issue?
<mjg59> BenC: When you pulled the mmc tree, did you pull the for_linus branch or the main one?
<BenC> mjg59: I'm pretty sure I pulled for-linus
<BenC> and I was pretty sure I tested it afterwards because I have mmc on several laptops here
<mjg59> Well, it's clearly changed the device structure in such a way that hal no longer picks it up
<mjg59> Options are either alter hal or alter the kernel
<BenC> altering hal may be easier to do
<BenC> question is, can we alter hal in such as a way as to be compatible?
<mjg59> No clue.
<BenC> you got any pointers to what needs to change in hal for this to work?
<mjg59> The udev output ought to give a pretty clear indication
<BenC> I think I can afford enough beer for Tollef to let hal changes through before I can get a new kernel through
<Mithrandir> heh
<BenC> Mithrandir: what's the chances I can get this in for RC, or should I just worry about post-RC?
<BenC> Mithrandir: I'll post a diff for you and cjwatson once I get it done, so you can review it
<\sh> BenC: can you give me some details on https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/55495 ?
<Mithrandir> BenC: RC, I don't think so.  post-RC, if the patch isn't too scary.
<BenC> ok
<BenC> \sh: Ug, 8 months ago, hard to say
<BenC> \sh: No mention in dapper/edgy changelog for that bug #?
<\sh> BenC: well, dapper / edgy are still having problems with it...(install media kernel)
<BenC> it's only marked fix committed, so it may be in -proposed
<BenC> which means no install media available
<\sh> BenC: that's the problem...
<\sh> and I can't test it, without having a running installation on this dl320s...;)
<Mithrandir> \sh: netboot it?
<\sh> Mithrandir: could be a solution if I had any network where the machine is. I really need to do a manual install...:( how can I tweak the server CD? ,-)
<Mithrandir> \sh: documented on the wiki, just search for custom
<BenC> this seriously looks like a bug in hal of some kind
<BenC> DEVNAME=/dev/mmcblk0p1
<BenC> DEVLINKS=/dev/disk/by-uuid/3639-3635 /dev/disk/by-label/ilMobile
<BenC> it gets that far in -14, but doesn't do the mount
<\sh> Mithrandir: for the alternate, old d-i cd?
<Mithrandir> yes
<\sh> Mithrandir: found it thx a lot :)
<\sh> BenC: found it in 2.6.15-26.47 ... actually we need to create 6.06.2 ;)
<\sh> Mithrandir: sorry to ask, but when I need to change the default (isolinux) boot kernel in /install/ , I only have to replace it with the kernel I need, right? what about initrd.gz, what is needed for initrd.gz of the alternate installer cd ?
<Mithrandir> \sh: yes, you can just replace it with the kernel you need, but you should ideally grab both the kernel and the initrd from a build of d-i
<\sh> Mithrandir: thinking about dapper, I just want to "update" the installer kernel..nothing else. and I think there is no d-i build for 2.6.15-26.47 or higher
<\sh> or is there a d-i rebuild for every kernel update?
<Mithrandir> no, but you can do one yourself
<\sh> Mithrandir: standard pbuilder run of d-i, I think
<Mithrandir> yes, just make sure you have the necessary repositories enabled
<\sh> Mithrandir: main and restricted 
<Mithrandir> well, and -updates and -proposed?
<\sh> Mithrandir: -security is the right one ;) the kernel is in the -security repos
<Mithrandir> well, that then.
<\sh> Mithrandir: thx...trying
<\sh> Mithrandir: forgot to update amd64.cfg to use 2.6.15-28-amd64-server kernel
<ilmari> go BenC!
<mjg59> BenC: I can give you a one line fix for the kernel re 99648
<BenC> mjg59: Ok
<mjg59> http://www.codon.org.uk/~mjg59/tmp/fix_sd.diff
<mjg59> The alternative looks like quite a lot of work on hal
<BenC> Mithrandir: would you be against a post-RC upload of the kernel with that one-liner fix (nothing from git)?
<ilmari> mjg59: yay!
<cjwatson> I would really quite like the squashfs fix from git, although I realise it's a bit scary at this point
<mjg59> What's happening with the HPA stuff?
<mjg59> That's sort of required
<BenC> mjg59: right now, it's not even in our git repo, so it's doing nothing
<mjg59> BenC: We can't release without it
<kylem> i posted the patches yesterday, not wanting to step on people's toes
<kylem> since everyone is trying to get bug fixes in right now..
<BenC> kylem: if you feel they are tested well enough, then please put them in git
<mjg59> They're not tested anywhere near well enough, but the alternative is to revert back to drivers/ide
<BenC> mjg59: what exactly are the implications of not having it?
<mjg59> Various machines refuse to boot
<kylem> basically all thinkpads
<BenC> what's the symptoms of the failure?
<mjg59> Reads beyond end of device
<BenC> are there any bug reports that reflect this problem?
<kylem> ... yes, the whole impetus for doing this in the first place.
<BenC> I didn't mean it to say there weren't, just need something to bounce off of to justify the patch
<BenC> got a bug number?
<kylem> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/82314
<rtg> mjg59: I have a laptop that exhibits the mmc problem with an SD card. I'm building with your patch and will test it shortly.
<mjg59> rtg: It's trivially correct - the wireless stuff is rather more of a blocker
<Mithrandir> BenC: wasn't the idea to do a kernel upload post-rc with the HPA and other really critical fixes?  If so, it can go in with those.
<rtg> mjg59: I know, but I've been working on a I2C fault.
<BenC> mjg59: what wireless stuff?
<Mithrandir> mjg59: is there actually a bug report about the hpa stuff?
<BenC> Mithrandir: see kyle's link
<Mithrandir> ah, cheers
<kylem> there's probably more, but that's the report that precipitated me actually writing the code in the first place.
<mjg59> BenC: The fact that softmac drivers don't work with n-m
<BenC> I've bumped that bug to critical, marked it inprogress and milestone for release
<BenC> mjg59: ah, right, any real resolution for that?
<BenC> or is it still in "we don't know why it wont work" phase?
<rtg> BenC: "we don't know why it wont work"
<mjg59> wpa_supplicant never receives the netlink messages
<mjg59> Which is weird, since iwevent /does/
<BenC> we're talking ieee80211_softmac, stock drivers, like bcm43xx, right?
<mjg59> Yes
<mjg59> bcm43xx and zd1211rw
<BenC> I bet I can point to where to look
<mjg59> That'd be a good start
<BenC> ubuntu/net/wireless/wext-old.c
<BenC> it replaces the stock net/ core wireless extensions
<BenC> so that mac80211 stuff can have a compatibility layer
<BenC> probably something in there that isn't quite compatible with softmac stuff
<BenC> might be missing some nl stuff
<rtg> BenC: Its not 100% failure. mjg59 can reproduce it, but I could not using the same model AP and a BCM43xx.
<BenC> I was going to update the mac80211 stuff, but I ditched it because it's a large update
<defendguin> you guys are awesome i hope someone is paying you for all this
<mjg59> defendguin: Me? No.
<defendguin> damn!
<BenC> mjg59 gets paid in laptops and beer
<defendguin> mmmm
<mjg59> No new laptops for some time
<mjg59> I'm starting to feel unloved
<BenC> mjg59: might help if you identified some models that tend to give us the most problems and we can go from there :)
<defendguin> mjg59, i got a bunch of old latitude D series laptops :-D
<defendguin> that may or may not have good hardware
<mjg59> BenC: TBH, I really don't have the time right now
<BenC> oh, one bad thing about HPA
<BenC> changes ABI
<mjg59> Like I said, it's basically that or go back to drivers/ide
<BenC> kylem: Can you show me the patches for HPA again?
<kylem> http://people.ubuntu.com/~kyle/feisty/
<BenC> kylem: Can you go ahead and commit 0001 and 0005?
<kylem> 0002 is important too
<kylem> and a one liner
<BenC> yeah, that one too please
<kylem> k.
<BenC> kylem, mjg59: Is there any way to do this patch without the addition of n_sectors_boot?
<BenC> that's the only thing changing the ABI
<kylem> BenC, i think not doing that would break suspend/resume in some instances.
<BenC> just wondering if there's some other way to store it
<BenC> maybe (ab)use some other part of the struct ata_device
<kylem> it's 8-bytes, so hard.
<kylem> i'm testbuilding a patch, but even on my crestline it's kind of slow :P
<kylem> i think if i abuse padding i can not break ABI on i386/amd64
<kylem> and we can override it on the other architectures.
<Mithrandir> I'd rather have you break the ABI and we take the pain than find random bugs later.
<Mithrandir> even if it's bloody painful
<BenC> kylem, mjg59: Why can't we use ata_hpa_resize() in ata_dev_same_device() and avoid the need for n_sectors_boot?
<BenC> does it write to the device in some way?
<kylem> n_sectors_boot is the very first size returned by IDENTIFY
<kylem> the check is basically ensuring that if the drive firmware resets the size, that we make sure it's the same disk
<kylem> but if it hasn't, then the size in the ata_id will still be the post-HPA size
<mjg59> Yeah, you need both sizes to do the "Is this the same disk" check
<kylem> the problem is, it may or may not be the same.
<kylem> could probably do something really ugly like put it on an external linked list tagged by ata_id or something.
<BenC> trying to understand the logic in this check
<BenC> if the n_sectors_boot is the same, it really doesn't mean the device will show the same after HPA is applied, right?
<BenC> trying to find the ide code
<mjg59> IDE doesn't bother with the "Is this disk the same" check
<mjg59> drivers/ide is very naive
<Mithrandir> IDE doesn't have hotplug, though?
<capiira> anyone know where i can get a proper .config version of the newest ubuntu kernel?
<kylem> Mithrandir, drivers/ide has a few sata drivers.
<Mithrandir> ok
<BenC> capiira: /boot/config-`uname -r`
<capiira> i used the one from /boot and noticed that my package is 228mb but not becuase of the kernel but becuase of all the modules
<mjg59> capiira: strip the modules
<BenC> right, we enable -g compilation
<capiira> but how to do that ? i used make-kpkg
<BenC> capiira: best bet is to disable CONFIG_DEBUG_INFO in the config
<capiira> yeah but i used the config from /boot why its not equal the original ubuntu kernel ?
<capiira> do they differs?
<BenC> mjg59: In what context is the "same device check" important? Will it break things if the HPA size is different? Is it enough that the boot size is the same for things to work ok?
<capiira> hmm found
<capiira> CONFIG_DEBUG_BUGVERBOSE=y and CONFIG_DEBUG_INFO=y
<cjwatson> the Ubuntu kernel package is built using debian/rules (in the standard way as for any package), not just make-kpkg
<BenC> it just seems to me that for the same device check to be worth while, the post-hpa-resize size is the important one
<capiira> ahh ok
<Mithrandir> capiira: reading some of the wiki pages referenced in the topic is probably a good idea.
<capiira> yeah thats what i did
<capiira> https://wiki.ubuntu.com/KernelCustomBuild
<capiira> they use make-kpkg too
<mjg59> BenC: What's the code flow? ie, has the hpa resizing been re-performed before the "Is this disk the same" check?
<capiira> Alternate Build Method: The Old-Fashioned Debian Way that's what i did
<mjg59> The drive will have been reset over suspend/resume, so will have dropped back to the original size
<kylem> could just blat it unconditionally, i suppose
<mjg59> capiira: If you want to build a kernel identical to the shipped one, use dpkg-buildpackage and not make-kpkg
<mjg59> BenC: l-r-m has to be reuploaded anyway, so is breaking the ABI really a huge issue?
<capiira> yes that's what i want thx
<capiira> mjg59, you  know a link that explains how to do with dpkg-buildpackage ?
<BenC> mjg59: ABI breakage isn't merely a matter of uploads at this point
<BenC> capiira: yes, the URL above has links to building the kernel
<BenC> check the KnowledgeBase page
<BenC> mjg59: there are other reasons why I don't want the ABI to change before release :)
<mjg59> BenC: I'm a bit reluctant about modifying the patch beyond the testing it's already got
<BenC> ignoring the ABI change, I'm still trying to wrap my head around if this check is correct or not
<BenC> ata_dev_configure() is called after ata_dev_same_device() in ata_dev_revalidate()
<BenC> the hpa resize occurs in ata_dev_configure
<capiira> thx
<kylem> http://marc.info/?l=linux-ide&m=117630937432256&w=2
<BenC> kylem: Ah, good point...might be proper to set new_n_sectors to the native_max if hpa is enabled on the id
<BenC> avoids all the ata_hpa_resize stuff, since it actually writes to the device, which is probably bad
<mjg59> You have to do the ata_hpa_resize on resume
<mjg59> Or do you mean avoid doing it unconditionally?
<kylem> i mean, doing it unconditionally is probably the way to go. just entirely forget about the pre-HPA disk size
<BenC> I was thinking more like breaking out the read_native_max into a helper and use that for the resume case to get new_n_sectors for hpa enabled id's
<BenC> remove the whole block for "Are we the boot time size..."
* kylem nods.
<BenC> kylem: do you have hw to test the hpa stuff?
<kylem> well, anyone with an ata disk can test the most critical half of it
<kylem> but no, i don't have any symptomatic hw.
<kylem> my thinkpad predates using HPA, it just had the bios partition at the end of the disk unprotected
<BenC> wonder how quick the people on the bug report can turn around a test run
<BenC> guess I'll build a kernel and post it
<rtg_> BenC: I'm committing the mmc fix. It appears to work. Thanks to mjg59.
<BenC> I have it in my tree already
<kylem> rtg_, rock!
<BenC> rtg_: thanks for testing though
<rtg_> BenC: Well then, I'll just let you commit it.
<blueyed> BenC: Bug 84965 has been set to "Fix released" by you on 18 Mar ("Added to my git tree.), but does not seem to have hit the archives yet!?
<blueyed> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84965/
<BenC> kylem: http://people.ubuntu.com/~bcollins/libata-hpa-support.diff
<BenC> kylem: that's a redo of your 0003 patch, can you look it over?
<BenC> I added ata_hpa_native_size() and used it
<kylem> looks ok
<BenC> I'm not absolutely sure of it...I don't know what the expected state of *dev is in this function, so reading it via *dev and deciding if *new_id is the same device may not be the right thing
<BenC> we may need to use the n_sectors_boot after all
<BenC> not too happy about an ABI bump, but might not be able to avoid it :/
<BenC> blueyed: heh, was marked fix committed by chuck, but I never got the commit
<BenC> zul: Do you have that patch still?
<zul> BenC: looking
<BenC> zul: Marked it in progress and assigned back to you
<zul> dont think so unfortunately
<zul> it might be on my backup drive, ill check again when im home
<blueyed> BenC, zul: Thanks for looking into it!
<BenC> rtg_: Hey, don't let me forget to bring the 5160 cpu's with me to Austin
<BenC> I keep forgetting to send them out, but I can definitely carry them with me
<rtg_> BenC: Gotta bug mdz about the MB price list.
<BenC> he's probably pushing things like that off until UDS, so might be best to talk to him there
<rtg_> I'm rooming with him, so I'll probably have opportunity.
<BenC> ah, cool
<ivoks> qemu still can't use CDROM on 20070411 :/
<defendguin> BenC, what was the decision on that mmc bug from earlier is that going in before release or after it?
<BenC> defendguin: before release
<BenC> we have a one-liner fix for it
<defendguin> yeah i saw that
<defendguin> should i go and close out the bug saying a fix has been released or just wait till everyone gets it and we test it out to make sure?
<mjg59> defendguin: fix-committed
<mjg59> Not released as yet
<defendguin> ahh
<defendguin> anyone in here on the acpi team?
<mjg59> Yes
<kylem> mjg59, you /are/ the acpi team. ;P
<mjg59> :(
<pkl_> I thought rtg has also done some stuff on acpi :)
<kylem> pkl_, less fun to tease mjg59 that way. :)
<defendguin> hehe
<mjg59> defendguin: What's up?
<pkl_> I haven't, for which I'm eternally glad.
<kylem> pkl_, hehe.
<defendguin> i've had a bug outstanding since before edgy's release and i was wondering if someone could take a quick look at it 
<mjg59> defendguin: I can take a look, but promise little
<defendguin> i understand i don't think it would warrant going in anytime soon but it would be nice to see it finally work
<mjg59> defendguin: Bug number would be helpful :)
<defendguin> launchpad is being slow
<mjg59> s/being/
<defendguin> bug 44615
<defendguin> where did ubotu go?
<Nafallo> defendguin: never been here :-)
<defendguin> sure he has
<Nafallo> nope
<defendguin> ok i'm crazy
<Nafallo> not aslong as I've been anyway :-)
<defendguin> mjg59, i remorted thsi back before dapper was released
<mjg59> What does sudo acpi_fakekey 142 do?
<defendguin> i'll have to write that down and get back to you
<mjg59> Ok
<defendguin> there is a very strict policy around here about bringing personal computers to work
<mjg59> Heh. Not a problem.
<defendguin> any other info i can collect?
<mjg59> Working out whether that works would be a good start
<defendguin> ok only 2 + hours
<capiira> hmm hi what does that error mean ? make: *** No rule to make target `binary-debs'. Stop.
<shawarma> Has anyone taken a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96857 ? It renders Feisty uninstallable in qemu. :-(
<BenC> shawarma: I did a livecd install under qemu just two days ago...I wonder what the difference is
<Mithrandir> BenC: on amd64?
<Mithrandir> iirc, it's amd64-specific
<BenC> 64-bit Intel
<Mithrandir> well, same thing.
<Mithrandir> with a 64 bit install too?
<shawarma> I'm using the 386 iso.
<BenC> yeah, 64-bit install
<shawarma> Mithrandir: I'm almost certain that you used an i386 iso as well, when you tested it?
<shawarma> The initial reporter doesn't specify which host arch he's on. :-(
<capiira> hmmmm :/ there is something wrong or something missing in that debian/rules tutorial from the topic site
<Mithrandir> shawarma: oh, the cdrom bug, yes, that was i386, iirc.
<capiira> i did exactly wht it's written there and get that make error
<capiira> that error make: *** No rule to make target `binary-debs'. Stop.
<BenC> capiira: sounds to me like you install linux-source-2.6.20 package instead of getting the linux-source-2.6.20 sources
<BenC> there is a difference
<capiira> i got the tar.gz
<capiira> or bz
<capiira> let me see
<capiira> tar.bz2
<capiira> linux-source-2.6.20.tar.bz2
<shawarma> capiira: Instead of "apt-get install linux-source-2.6.20" you should "apt-get source linux-source-2.6.20"
<capiira> ahh
<capiira> do you think that's why i get a 230mb package after make-kpkg, too ?
<shawarma> BenC: Actually, I don't seem to have any ide devices available at all in my qemu.
<mjg59> capiira: No
<capiira> then it must be right one if it works with make-kpkg or not ?
<mjg59> capiira: No
<capiira> ok
<BenC> let me test real quick
<capiira> complicated, sorry for disturbing just want to get my scanner to work :/
<shawarma> BenC: I'm using 0.9.0 right now, but 0.8.3 (or whatever's in Edgy) does the same thing.
<BenC> shawarma: trying now with a i386 cd from last night
<BenC> I'm using qemu 0.8.2+dfsg
<shawarma> BenC: Ok, cool. I'm using the server cd, but that shouldn't matter here, I suppose.
<BenC> shouldn't
<capiira> that bug https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/85488
<shawarma> BenC: Just retested with latest daily both with and without kqemu (qemu 0.9.0). Same thing. No hard drive, no cd-rom.
<shawarma> BenC: Not that kqemu should matter at all.
<BenC> I see hd (sda), but no cdrom
<shawarma> /sys/block only shows ram0-ram9
<shawarma> Strange. I can try downgrading my qemu..
<BenC> actually I see the cdrom, but it's failing to follow though with it
<shawarma> BenC: You're using the qemu from feisty?
<mjg59> Well, the lack of hdc is hardly surprising
<mjg59> The provided dmesg in the bug log isn't useful
<mjg59> We need the next page as well
<shawarma> How would I extract that from a running qemu without net access between guest and host?
<BenC> well, I can reproduce it, so all it does it reproduce the same exception
<shawarma> I'm not sure when it last worked, unfortunately. In January it did, that's for sure..
<shawarma> I cleverly overwrote the daily image I had an after that it stopped working.
<mjg59> It's likely that it worked before that device was being run by libata
<shawarma> Any idea when that happened?
<shawarma> late february perhaps?
<BenC> shawarma: you can try "modprobe -r ata_piix; modprobe piix" and see what happens
<BenC> that just worked for me
<shawarma> Nothing.
<mjg59> Well, if that doesn't work, it's almost certainly some sort of qemu issue
<shawarma> In fact, I'm not sure ata_piix was loaded in the first place..
<mjg59> The piix driver hasn't changed
<shawarma> I'll recheck.
<BenC> I'm quite sure it did
<BenC> since it shows "scsi1: ata_piix"
<shawarma> mjg59: Well, it *used* to work in qemu.. 
<mjg59> Yes and then we changed drivers
<shawarma> True.
<shawarma> Yes, ata_piix and piix are both indeed loaded.
<mjg59> If loading piix did nothing, it's probably still bound to ata_piix
<BenC> yeah, check dmesg after rmmod ata_piix
<shawarma> according to lsmod nothing is using either.
<BenC> make sure it released both ata devices
<shawarma> There's no change in dmesg after remove ata_piix.
<mjg59> And make sure that ide-generic isn't loaded
<mjg59> Or ata-generic
<mjg59> If none of this works, your problem bears no resemblance to the one that the bug's demsg dump is from
<shawarma> ide-generic is busy, it seems.
<mjg59> Right. Reboot it.
<shawarma> ok.. and do what differently this time? unload {ide,ata}-generic first?
<mjg59> Don't load them in the first place
<shawarma> *I* didn't.
<BenC> most ide drivers cannot be unloaded
<shawarma> Can I blacklist it with a kernel parameter of som esort?
<mjg59> shawarma: If ide-generic is binding, then you have a different bug
<mjg59> Please provide everything in dmesg that's related to ata
<shawarma> here or a new bug?
<shawarma> or pastebin..
<mjg59> pastebin is good for now
<shawarma> Ok. I see no other way than typing it in, so I'll leave out the imestamps. they seem superfluous.
<mjg59> Or take screendumps
<mjg59> That's also fine
<shawarma> Clever. :-)
<shawarma> http://warma.dk/qemu.png
<shawarma> In fact, I can let you have access to it via vnc?
<shawarma> or not. Either way is good.
<mjg59> Right, yes, that's clearly different.
<shawarma> bugger.
<BenC> no idea what that is
<BenC> looks like a qemu bug though
<mjg59> ata_std_prereset() is returning an error
<mjg59> Though that should never happen
<shawarma> I'll try 0.8.2+dfsg in a sec. I'm compiling it right now.
<mjg59> Oh, I see
<mjg59>        if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] ))
<mjg59>                 return -ENOENT;
<capiira> hmm where does apt-get source saved the packages? there is nothing in /usr/src
<shawarma> http://warma.dk/qemu2.png   <--- don't know if that helps?
<shawarma> capiira: current directory
<mjg59> ata_piix is binding and finding that the chip caims to be disabled
<capiira> ohh i was in a temporally broken symlink dir
<mjg59> capiira: These questions are probably better suited for #ubuntu than in here
<capiira> yeah
<shawarma> If it helps at all http://warma.dk/qemudmesg[1-7] .png has the complete dmesg output..
<BenC> I just tried kqemu (0.9.0) and it works, but shows the same exceptions
<BenC> but as I said, it actually works
<BenC> just booted livecd
<shawarma> weirdness.
<shawarma> BenC: Homerolled qemu or the debian one? 
<BenC> kvm-18 from feisty
<shawarma> BenC: I used the qemu 0.9.0 source from debian experimental and compiled it for my edgy server.
<shawarma> BenC: Oh. I don't have kvm-able hardware. :-(
<BenC> kvm is qemu based, just add the -no-kvm option to it
<BenC> and it's pretty much the same as qemu
<shawarma> But you got it to work with vanilla qemu?
<shawarma> Well, 0.8.2+dfsg..
<BenC> with 0.8.2+dfsg it works if I rmmod ata_piix, and modprobe piix
<shawarma> BenC: That's also necessary with the livecd, I expect?
<BenC> yeah
<shawarma> It drops you to a shell at some point, you do your thing, and .. what? exit out of the shell and the world continues?
<mjg59> yes
<mjg59> BenC: If it's failing with qemu, I suspect that it's quite possibly also failing with real hardware
<mjg59> (And we do have a few bugs where people are losing CD drives and the like)
<BenC> yeah, but this is the only way I have to duplicate it :)
<BenC> I need to get it fixed before Friday
<BenC> I'm wondering if the acpi stuff is breaking it
<BenC> it's the main difference between what we have and jeff's stable tree
<mjg59> We don't execute the acpi stuff on startup, do we?
<mjg59> (No, we don't seem to)
<mjg59> Does Jeff's stable tree work?
<shawarma> Hmm... There's no dmesg in the initramfs.. How can I see what's in the buffer?
<shawarma> Alright, retesting with qemu 0.8.2+dmesg
<shawarma> Er... You know what I meant. :-)
<BenC> same thing happens with nopataacpi=1
<BenC> shawarma: dd if=/proc/kmsg of=/tmp/dmesg bs=1 &
<BenC> shawarma: then you can "more /tmp/dmesg"
<shawarma> BenC: Ah, I'll reboot and try again.
<shawarma> Oh, that also contains the buffer?
<shawarma> Yes, now I get the exceptions as well.
<BenC> modprobe ata_generic all_generic_ide=1
<BenC> that works too
<capiira> ok compiling  :) i hope things work better using debian/rules :) let me go watch tv for 3h's
<BenC> after rmmod ata_piix
<BenC> so something is wrong with ata_piix
<mjg59> DMA is hard
<capiira> oh i did no "sudo" before AUTOBUILD=1 fakeroot debian/rules binary-debs ! it's needed ?
<shawarma> No.
<capiira> good thx :)
<shawarma> That's that fakeroot is for.
<capiira> ahh ok thx bbl
<capiira> but you was right it was because of the apt install and apt source
<capiira> its a little bit mixed in the tutorial
<BenC> mjg59: do you know a way to force PIO with ata_piix?
#ubuntu-kernel 2007-04-12
<BenC> -       if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] )) {
<BenC> -               ata_port_printk(ap, KERN_INFO, "port disabled. ignoring.\n");
<BenC> -               ap->eh_context.i.action &= ~ATA_EH_RESET_MASK;
<BenC> -               return 0;
<BenC> -       }
<BenC> -
<BenC> +       if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] ))
<BenC> +               return -ENOENT;
<BenC> I wonder if that's part of our problem
<BenC> the clearing of ATA_EH_RESET_MASK is interesting
<defendguin> mjg59: what are you expecting to happen when i do sudo acpi_fakekey 142 ?
<mjg59> I don't kniw
<mjg59> What does happen?
<defendguin> it suspends
<mjg59> Ok
<mjg59> In that case, something in /etc/acpi is broken
<defendguin> the touchpad isn't working now though
<defendguin> :-P
<mjg59> Have you just been upgrading this machine from dapper?
<mjg59> If so, at some point you've altered a conffile in /etc/acpi
<defendguin> no this was a fresh install of feisty herd 3 and i just upgraded from there
<defendguin> i have 3 5gb partitions and i just keep installing fresh when the time comes to upgrade
<mjg59> Well, check that sudo /etc/acpi/sleepbtn.sh also works
<defendguin> mjg59: i thought it had to do with the system not realizing that that particular button press even was supposed to do
<mjg59> When you press the sleep button, what appears in /var/log/acpid?
<BenC> the eh clearing got moved to libata-core is all :/
<kylem> eh?
<kylem> ;)
<mjg59> BenC: Has it ever worked with ata_piix?
<BenC> mjg59: I've no idea...I've done some checking and the same problem happens under vmware
<BenC> it continues to work, but the exception is printed several times
<BenC> it only messed up the CDROM
<BenC> the disk is fine
<defendguin> mjg59: suspending causes all sorts of problems with wireless returning properly
<defendguin> i never had the touchpad problems before with suspending but that crept in somewhere 
<mjg59> defendguin: I'll worry about that at some later point
<mjg59> Can we fix this bug first?
<defendguin> yeah
<defendguin> absolutely 
<mjg59> So the acpid log stuff is what's relevant
<BenC> I wonder if I should switch PIIX3/4 back to piix.ko
<defendguin> acpid.log?
<mjg59> /var/log/acpid
<BenC> or maybe just move all piix pata back to piix.ko
<defendguin> pastebin?
<mjg59> Yes
<defendguin> hmm its screwing up the formatting
<defendguin> mjg59: http://pastebin.ca/435401
<mjg59> defendguin: Which of those entries corresponds to you pressing the sleep button?
<defendguin> i am guessing there is no entry for when i press Fn + F4
<mjg59> What do you have in /proc/acpi/button ?
<defendguin> lid and power
<mjg59> Ok.
<mjg59> So you don't have an ACPI sleep button.
<defendguin> lid and power Fn + F4 button and no even was made in /var/log/acpid
<mjg59> Can't go any further
<defendguin> ok
<defendguin> mjg59: whats my next step?
<mjg59> Work out why you have no sleep button
<defendguin> should there be a hibernate button there too?
<mjg59> In /proc/acpi? No.
<defendguin> mjg59: is there anything i can do to help?
<defendguin> :-(
<mjg59> defendguin: Right now, it's probably limited to me getting one of those laptops
<defendguin> hmmm
<defendguin> i could let you remote the laptop
<defendguin> that might be a problem when you try to suspend it though
<BenC> defendguin: the basic issue is that your laptop is crappy and doesn't produce proper acpi events for the lid and button
<mjg59> Well, it doesn't seem to provide an acpi object for the button
<defendguin> well closing the lid works fine
<mjg59> So the lack of events is unsurprising
<BenC> well, for the button I mean
<BenC> defendguin: check the linux acpi website for a possible DSDT to fix it, or perhaps a BIOS update, or something
<mjg59> If you can pastebin the full dmesg, that would probably help
<defendguin> i updated the bios a few weeks back
<defendguin> mjg59: i have several dmesg posts on the bug which show the output after me doing several things,  lid close, telling to suspend from dialog box, and button press
<mjg59> What was the bug number, again?
<defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/44615
<defendguin> hmm i guess i was wrong about that i have lots of lspci output
<mjg59> There's no dmesg there
<defendguin> would you like me to do some action before giving you the dmesg output?
<mjg59> No
<mjg59> Full dmesg after a clean boot
<defendguin> can i past 4 lines here?
<defendguin> paste
<mjg59> Sure
<defendguin> http://pastebin.ca/435507
<defendguin> i'm going to reboot and give you a clean dmesg output
<defendguin> that looked particularly interesting
<defendguin> mjg59: http://pastebin.ca/435520  here is a fresh dmesg right after boot
<mjg59> Do you get that setkeycodes message whenever you press the sleep key?
<defendguin> 2 for 2 so far
<mjg59> Can you try sudo setkeycodes e017 142
<mjg59> And then see if it works?
<defendguin> suspend like magic
<defendguin> whoot and i still have a wireless network connection
<defendguin> no touchpad though
<defendguin> [  514.704000]  atkbd.c: Use 'setkeycodes e018 <keycode>' to make it known.
<defendguin> [  514.712000]  atkbd.c: Unknown key released (translated set 2, code 0x98 on isa0060/serio0).   I get this error message when i try to hibernate my laptop if you want to knock out 2 birds with one stone
<defendguin> not when i try to hibernate but when i press Fn +F12 which should hibernate the laptop
<kylem> BenC, i pushed that stuff.
<kylem> reviewing stable atm.
<BenC> kylem: Ok, I'll merge and prepare a summary
<mjg59> defendguin: Can you install http://www.codon.org.uk/~mjg59/tmp/hotkey-setup_0.1-17ubuntu8_i386.deb and see if that helps?
<defendguin> ok lets see
<defendguin> ok that worked
<defendguin> ok that worked
<mjg59> Hibernate and suspend?
<defendguin> both worked
<mjg59> Excellent
<defendguin> you da man
<mjg59> Not sure it'll hit feisty
<mjg59> Though it's fixed for you now
<defendguin> mjg59: as long as i know that at some point that patch will find its way into ubuntu
<mjg59> Well, it's written
<mjg59> The issue is just whether it can be accepted
<defendguin> [ 2598.024000]  atkbd.c: Unknown key pressed (translated set 2, code 0x96 on isa0060/serio0).
<defendguin> [ 2598.024000]  atkbd.c: Use 'setkeycodes e016 <keycode>' to make it known.   this one is supposed to turn wireless off
<defendguin> sorry i forgot about that one
<mjg59> Which key is that?
<mjg59> fn+f5?
<defendguin> yup
<mjg59> Any others?
<defendguin> nope
<mjg59> Ok
<defendguin> 44616  44615 and 44614 you may want to make comments on these 3 bugs  
<BenC> mjg59: There's actually a chance we'll need a hotkeys-setup update for feisty, so if you plan to upload, let me know so we can coordinate
<defendguin> awesome!
<mjg59> BenC: Ok. What needs adding?
<defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86820/   i'm also suffering from this bug if anyone is interested
<mjg59> defendguin: If you're able to build your own kernel, could you see if http://www.codon.org.uk/~mjg59/tmp/i8042.diff works?
<defendguin> mjg59: for what bug?
<mjg59> The missing touchpad
<defendguin> i've only done it once before a while back
<defendguin> did you have that diff already?
<mjg59> I've been looking for changes that could have affected this codepath
<mjg59> That's the only one that looks relevant
<defendguin> would this also effect the num lock being turned on?
<mjg59> Dunno
<defendguin> let me find some directions on compiling a kernel
<defendguin> its been way too long\
<mjg59> Ok, I may be able to do this for you
<mjg59> You're on 2.6.20-14-generic?
<BenC> I can pump out kernels in about 20 minutes if you need to
<defendguin> yeah thats the kernel
* mjg59 builds a kernel
<defendguin> this is the problem with a linux distro appealing to the masses
<defendguin> i've been using since RH 7.0 and i've built a kernel once
<mjg59> defendguin: Ok, nearly done
<mjg59> defendguin: Do you still have -13-generic installed as well?
<defendguin> yup
<mjg59> Good
<mjg59> This may break things :)
<defendguin> i've got 12 too
<defendguin> since that was the last one that worked with my card reader
<mjg59> Ok. Grab http://www.codon.org.uk/~mjg59/tmp/vmlinuz-2.6.20-14-generic
<mjg59> And put it in /boot, then reboot
<orangey> hey all!
<orangey> I'm having an interesting problem here..
<orangey> I have an NC6400, which has a non-working keyboard on resume (bug filed)
<defendguin> link again please
<orangey> Now, when I try to do the fix suggested, removing i8042 and making it a module (CONFIG_SERIO_I8042=m), when I make kpkg, it reverts it!
<orangey> defendguin: link to what?
<mjg59> orangey: Unlikely to help, but could you grab http://www.codon.org.uk/~mjg59/tmp/vmlinuz-2.6.20-14-generic
<mjg59> Put it in /boot and try with that?
<mjg59> defendguin: ^
<orangey> mjg59: Is this -14.12?
<defendguin> mjg59: the file is only 1.5mb?
<mjg59> defendguin: Yes, it's only the kernel
<mjg59> Not the modules
<defendguin> ahhh
<mjg59> orangey: Yes
<mjg59> With a patch
<defendguin> should i be able to rename the old kernel to *.old so i can revert?
<orangey> mjg59: Ah. Which patch? I've already patched my i8042 to latest in the git tree.
<orangey> Hmm. incidentally, where are the default config files kept?
<defendguin> ok rebooting
<mjg59> orangey: A reversion of something introduced in 2.6.19
<orangey> mjg59: I'm sorry. I don't follow. What is our goal here?
<mjg59> To see whether it works
<defendguin> well my mouse doesn't work when i booted back up
<mjg59> defendguin: dmesg, please?
<orangey> mjg59: OK. I'll try it out just as soon as I get this computer's suspend working : )
<orangey> found the defconfig!
<mjg59> Well, the aim is to see if it fixes your suspend
<mjg59> So, y'know
<defendguin> http://pastebin.ca/435680
<orangey> mjg59: Ah. Gotcha.
<BenC> mjg59: Do you know where to find the linux-to-X keycode conversions?
<mjg59> BenC: Seriously, do not go there
<BenC> or X macros
<kylem> heehee.
<mjg59> Run xev and see what it says when you hit the keys
<BenC> ah, ok
<mjg59> defendguin: Hm, looks absolutely fine. That's with the new kernel?
<defendguin> uh huh
<mjg59> And your keyboard doesn't work?
<defendguin> looks fine?
<defendguin> keyboard is fine
<defendguin> mouse doesn't even light up
<mjg59> Oh, sorry, mouse
<mjg59> Light up?
<defendguin> optical
<mjg59> Uhm.
<mjg59> How about the touchpad?
<defendguin> touchpad works
<mjg59> Over suspend/resume?
<defendguin> i have not gotten to suspend 
<mjg59> I suspect I've broken some of the symbol versioning
<mjg59> So your usb modules probably aren't loading properly, or something
<mjg59> Please try suspend 
<defendguin> ok i'll do that now
<BenC> mjg59: I don't see anything remotely useful when I hit the key
<defendguin> ok mouse no worky 
<BenC> KeymapNotify event, serial 29, synthetic NO, window 0x0,
<BenC>     keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
<BenC>            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
<defendguin> touchpad no worky
<mjg59> defendguin: dmesg after suspend, please
<defendguin> lol no mouse to move windows around
<mjg59> dmesg > ~/dmesg.stillnotworking
<mjg59> reboot
<BenC> ctrl+alt+f1 got to terminal and do it
<defendguin> ahh yes
<orangey> mjg: Incidentally, what are you testing on?
<mjg59> A range of systems
<orangey> mjg59: Mine appears to be hanging at ipv6:
<mjg59> None of them with these problems
<mjg59> Yeah, ignore that
<mjg59> It ought to get past there eventually
<orangey> righto.. finally past that now.
<orangey> on inital boot, everything looks to work.
<orangey> neither keyboard nor mouse are working on resume.
<orangey> mouse=toucpad
<mjg59> Ok
<mjg59> So unhelpful
<mjg59> dmesg from post-resume would be good
<orangey> : )
<orangey> well, usually my USB mouse works where I might actually get that.. alright, moment.
<orangey> actually, a few more keys work now than before.. For example, the power button used to produce nothing, but now acts responsibly. Same with my other hotkeys. But not the keyboard.
<defendguin> http://pastebin.ca/435689
<mjg59> defendguin: Ok, I've got nothing immediately helpful there
<mjg59> You may want to reinstall the standard kernel package to get your mouse back
<orangey> mjg59: Can I recover my dmesg after a reboot?
<mjg59> orangey: Ah. Not easily.
<defendguin> mjg59: i booted up to -13
<mjg59> Try this:
<mjg59> from a shell in X, do
<mjg59> sudo /etc/acpi/sleep.sh force; dmesg >~/dmesg.nokeyboard; sync
<mjg59> That should suspend, resume, write the file and then make sure it's on disk
<mjg59> Then when you reboot, it'll be there
<orangey> what about turning on pm_trace?
<orangey> I didn't find it helpful while initially debugging, but do you want me to do that?
<rtg_> orangey: It only helps to debug resume hangs.
<defendguin> ok one moment
<orangey> rtg_: Isn't that what this is?
<mjg59> orangey: No, it's resuming but your keyboard isn't working
<rtg_> orangey: I thought it was just the mouse not working. You must have other symptoms I'm not aware of.
<defendguin> mjg59: is this still gonna work since i booted into a different kernel from the one you patched?
<mjg59> defendguin: Sorry, that was directed at orangey, not you
<mjg59> I've got all I need from you for now, thanks!
<defendguin> ohh ok
<defendguin> great
<orangey> I must say, I pity you guys for relying on people like me to test your work : )
<defendguin> hehehe
<BenC> mjg59: was xev really supposed to give me something useful? :)
<mjg59> BenC: There ought to be a keycode there
<mjg59> Assuming you've already mapped it with setkeycodes
<BenC> KeymapNotify event, serial 29, synthetic NO, window 0x0,
<BenC>     keys:  4294967174 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
<BenC>            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
<BenC> I did, and that's all I get from it
<BenC> I mapped it to $KEY_PLAYPAUSE
<mjg59> There should be a KeyPress event
<BenC> do I need to restart X if I change hotkeys and run /etc/init.d/hotkey-setup start?
<mjg59> No
<BenC> I don't get a KeyPress or KeyRelease event
<mjg59> Oh if this is another of those cases where Dell think "Oh, hey, let's make keys that send DOWN keycodes but never send UP keycodes" I'm going to be really upset
<mjg59> Y'know, sort of implausibly upset
<defendguin> lol
<mjg59> From a console, if you run showkey do you get both a make and a break event?
<mjg59> Or just the down?
<BenC> I get up/down events from showkey
<mjg59> Right, so not that
<mjg59> Hm
<BenC> I get events from xev on up/down, just not KeyPress/KeyRelease ones
<mjg59> Can you grab evtest from somewhere, run that and see what it's sending?
<BenC> wait, no, just even on down
<BenC> ok, I think I have it lying around somewhere
<mjg59> And you're focused in the xev window, right?
<mjg59> I can't reproduce this behaviour at all
<BenC> yep, it's focused on the xev window
<BenC> regular keys produce press/release events, just not these media keys
<mjg59> Whack.
<mjg59> See what evtest says, I guess
<BenC> wow, I have a broadcom keyboard
<defendguin> mjg59: did you also get that Fn+F5 wireless bug fixed?
<mjg59> Yes
<mjg59> Well
<mjg59> It sends a keycode
<mjg59> But it'll do nothing
<BenC> Event: time 1176345196.584872, -------------- Report Sync ------------
<BenC> Event: time 1176345198.487478, type 4 (Misc), code 4 (ScanCode), value a2
<BenC> Event: time 1176345198.487488, type 1 (Key), code 164 (PlayPause), value 1
<BenC> Event: time 1176345198.487491, -------------- Report Sync ------------
<BenC> Event: time 1176345198.625543, type 4 (Misc), code 4 (ScanCode), value a2
<BenC> Event: time 1176345198.625553, type 1 (Key), code 164 (PlayPause), value 0
<BenC> evtest shows goodness
<mjg59> Yeah
<mjg59> Hm
<kylem> GOD DAMN
<kylem> -ECHAN
<mjg59> Ok. Can you poke things into the gnome keyboard shortcuts panel?
<kylem> cough.
<BenC> lol
<defendguin> huh?
<kylem> five keyboards in front of me, bound to happen sooner or later.
<BenC> mjg59: already done...will the values in there stay constant based on the code (e.g. 164 in this case)?
<BenC> the value in keybindings is 0xa4...will 0xa2 linux code always produce 0xa4 for X keybindings?
<mjg59> Yes
<mjg59> The mapping is in drivers/char/keyboard.c
<mjg59> And then X munges it further
<mjg59> You so desperately don't want to try to understand this stuff
<mjg59> I tried, and I went odd
<kylem> mjg59, was this pre or post acpi?
<mjg59> Pretty contempory
<BenC> if x key mappings lead to wanting to mess with acpi, I'll pass
<defendguin> if any of you guys are ever in Houston let me know so i can buy yall a beer
<orangey> mjg59: sorry about that.. long phone call.
<orangey> mjg59: is there a new version of that file?
<orangey> mjg59: Also, I'm not sure where to post the dmesg file.. pastebin won't take it.
<eman_> hey all!
<eman_> I'm trying to edit my .config, and make-kpkg after that..
<eman_> but it keeps overwriting the .config with oldconfig
<eman_> what gives?
<fabbione> BenC: ping?
<BenC> fabbione: yo
<fabbione> BenC: hey dude,, did you happen to pull those 4 OCFS2 changes in our tree?
<fabbione> i know you are going to upload another kernel for final
<BenC> I did, so they will probably go in Friday
<fabbione> perfect.. from the 2.6.20_fixes branch
<fabbione> great
<eman_> hmmm.
<eman_> any hints as to how to make it so that this i8042 module isn't compiled directly into the kernel?
<BenC> eman_: This isn't a support channel, it's for ubuntu kernel development
<BenC> eman_: I think there might be a #kernelnewbies channel
<fabbione> argh.. now i know why git pull was taking this long
<fabbione> BenC: did you fork ubuntu-feisty-2.6 and pulled in from linus?
<BenC> you didn't do the ubuntu-feisty.git ? :)
<BenC> ubuntu-2.6 is basically stock linus kernel right now
<fabbione> ok :)
<BenC> 2.6.20 moved to ubuntu-feisty.git
<eman_> BenC: I'm trying to remove a module from the kernel. When I change it in .config, make-kpkg restores it. I do see why it may not be for here, but it's not an egregious offence to pursue it here.
<fabbione> eman_: blacklist the module. if something pulls it in it's because it's required
<eman_> fabbione: the module doesn't play nicely with suspend / resume, but is necessary to power my kb and touchpad.
<BenC> eman_: I didn't say it was a horrible offense, just that you'd have better luck getting help somewhere else...I don't have an immediate answer to your question, so my next best help was to point you to some place else
<eman_> others have reported that when i8042 was a module, suspend/resume worked fine.
<eman_> BenC: sorry. My misinterpretation, probably due to the lack of body language or whatnot.
<BenC> eman_: On x86 hw, it's forced to be compiled into the kernel
<BenC> you can override that by editing drivers/input/serio/Kconfig
<eman_> BenC: hmm. That's unfortunate.. 
<eman_> ok.
<BenC>         tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
<BenC> change that line to
<BenC>         tristate "i8042 PC Keyboard controller"
<BenC> if you need it, you'll have to add it to /etc/modules.conf
<eman_> BenC: Thank you. I'll test to see if it works, then update my bug report on it.
<eman_> BenC: I put it to: tristate "i8042 PC Keyboard controller"\        default m
<eman_> but it still seems like make-kpkg is taking oldconfig, even though I'm doing --config=menuconfig
<cjwatson> pkl_: do you know if the HPA stuff is in git?
<pkl_> cjwatson: I'll check, Kyle did he'd checked them in...
<cjwatson> don't see anything relevant from Kyle
<pkl_> hmm, git-pull hangs for some reason at the moment...
<Mithrandir> cjwatson: http://people.ubuntu.com/~kyle/feisty/
<Mithrandir> ben pulled in a couple of patches yesterday
<cjwatson> crestline went in
<cjwatson> as did 0002-2.6.21-fix-lba48-bug-in-libata-fill_result_tf.txt (but I dunno, doesn't seem feisty-ish now)
<cjwatson> the rest didn't hit git AFAIK
<cjwatson> though I suppose it's possible that 0002 is a prereq for the others
<pkl_> doesn't look like it...
<pkl_> cjwatson:  I got the impression something was going to be checked in by Kyle, but obviously nothing did.
<elementz> hi guys
<elementz> i was trying to patch my kernel with the 16k patch from linuxant - since i need it for my pcmcia wlan - seems to not work - i got a foo.patch file but can't apply it
<elementz> should i just recompile?
<mjg59> elementz: This channel is for development of the Ubuntu kernel, not support for third-party patches
<mjg59> elementz: #ubuntu may be a better bet, or alternatively talk to Linuxant (since you've presumably bought their product)
<elementz> jg59 kk - no the patch is free
* mjg59 shrugs
<elementz> jg69 do you give support on how to recompile my kernel with 16k stack though? or should i go to #ubuntu for this as well?
<mjg59> Yes
<mjg59> That is, you should ask in #ubuntu
<elementz> kk thx
<zul_> or check the wiki
<\sh> BenC: I just exchanged the old dapper server cd installer kernel with the -proposed 2.6.15-50.61 dapper kernel to our install cd...rebuild debian installer with all necessary udebs from -proposed archive and now d-i complains about problems with usb-storage udeb...
<\sh> BenC: now I don't know if it's me and a broken debian-installer kernel or if it's something with the 50.61 -proposed dapper kernel
<\sh> BenC: oh damn...i found my mistake
<elementz> i am really sorry to ask in here - but maybe you guys can give me a quick reply - is there an easy way to obtain a patch (maybe even in the repos) that patches the kernel to use a 16k stack? i use 2.6.20-14-generic
<mjg59> No
<elementz> thx
<aurelianito> hi all
<aurelianito> I'm using kubuntu since dapper
<aurelianito> and I  having a problem with the edgy-eft kernel
<aurelianito> I'm using the Huawei SmartAX MT882 ADSL USB modem
<mjg59> aurelianito: Bug number?
<aurelianito> and this device is recogniced by kernel 2.6.15 (dapper) but no 2.6.17 (edgy-eft)
<aurelianito> I don't have a bug number
<mjg59> Please file a bug
<aurelianito> where?
<mjg59> bugs.ubuntu.com
<aurelianito> do I need a login?
<mjg59> Yes
<aurelianito> I don't have one
<elementz> sorry guys - i really don't mean to be annoying! asked in other channels - to no avail though! maybe you guys can tell me how to apply this to my kernel? http://www.linuxant.com/driverloader/wlan/full/archive/linux-2.6.20-16kstacks.patch
<zul> then you can make one
<mjg59> elementz: No
<elementz> kk
<mjg59> elementz: Sorry, we really don't have time to support people attempting to add third-party patches to break their kernel
<mjg59> Feisty is due to release next week
<elementz> yes i understand - it's just that i am desperately i need of my wireless - even if it involves a dirty solution at the moment
<elementz> but i understand where you're coming from
<zul> elmentz: as we said before check the wiki
<zul> BenC: can we kill bug #96430?
<aurelianito> I'm trying to file a bug, but the site is soooo slow......
<aurelianito> Do you know if it's having any problems?
<fabbione> aurelianito: known issue (lp being slow)
<Keybuk> why does the kernel continually spit ata errors under vmware ?
<kylem> because vmware's emulation sucks?
<Nafallo> Keybuk: if user = keybuk etc... ;-)
<arkora> is there any file server that still holds the 2.6.20-*13* debs? In the apt repositories, these build do not exist any more.
<Nafallo> arkora: launchpad :-)
<Nafallo> arkora: but it slow as *beep* today
<aurelianito> amazingly, I've been able to file my bug report
<arkora> Nafallo: thanks, I should have known :o)
<aurelianito> the number is 105883
<nictuku_i386> hello.
<_MMA_> BenC: I have someone that wants to help us (Ubuntu Studio) with a RT.
<_MMA_> *RT kernel.
<_MMA_> If you not too swamped is there a place to see what patches Ubuntu applies?
<fabbione> _MMA_: we are busy trying to get feisty out next week.. 
<Mithrandir> _MMA_: far too late to feisty; Look at git for the patches.
<mjg59> _MMA_: All the patches are in the ubuntu tree on git.kernel.org
<_MMA_> fabbione: I figured. Hence the "If you not too swamped"
<_MMA_> mjg59: Thanx
<_MMA_> Mithrandir: I know. We might use it in our repo and get it in if its necessary for +1.
<rtg_> arkora: See the comment at the end of bug #96480.
<arkora> rtg: great, thanks!
<fabbione> kylem, BenC, rtg_, pkl_: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/105888
<fabbione> ^^ cjwatson, Mithrandir FYI..
<fabbione> coming from hwcert
<kylem> can you summarize it?
<kylem> privately
<andre_pl> with the latest feisty kernel my tifm card reader doesn't work at all.  the modules load, but otherwise theres nothing in dmesg.. i had read on launchpad that the latest kernel had included a newer tifm driver that was supposed to solve most of these problems but in my case it is worse.
<kylem> launchpad is uselessly slow.
<fabbione> summarize?
<kylem> fabbione, i can't load the page.
<fabbione> i was able to open it..
<fabbione> oh
<fabbione> sure
<andre_pl> kylem: same here, launchpad is totally useless right now
<mjg59> Apr 11 20:51:40 ubuntu kernel: [    1.253614]  ACPI: Wrong _BBN value, reboot and use option 'pci=noacpi' is arguably more disturbing
<mjg59> fabbione: Get them to boot with pci=noacpi and see if it works. If so, buggy BIOS.
<fabbione> mjg59: older kernels didn't show the problem on that machine.. regression perhaps?
<mjg59> Which older kernels/
<fabbione> down to Herd 2
<fabbione> all milestones.. etc.
<mjg59> ?
<fabbione> mjg59: that machine is tested on each milestone release
<mjg59> So everything pre-RC worked?
<fabbione> yes
<mjg59> Herd 6 was fine?
<Nafallo> Herd 6 was cancelled? :-)
<mjg59> Uh, yeah.
<mjg59> I meant 5
<mjg59> Which kernel did we ship in Herd 5?
<mjg59> I'm pretty sure that there have been no even vaguely relevant changes since then
<Nafallo> beta is the latest milestone I think
<mjg59> Ah, true
<mjg59> Very easy to lose track
<Nafallo> maybe -12 there? from the top of my head :-)
<Nafallo> indeed it is :-)
<mjg59> fabbione: Anyway, I don't believe that it's possible for this to have appeared between beta and now
<fabbione> mjg59: well ok.. i will ask to check
<pkl_> andre_pl: are you expecting the card to automount?
<andre_pl> pkl_: I'm expecting to see something in dmesg telling me that it at least realizes tha ti've inserted or removed a card.
<mjg59> andre_pl: Is tifm_sd loaded?
<andre_pl> mjg59: yep
<andre_pl> and tifm_core
<pkl_> andre_pl: yeah it should do that...  A change in -13 with mmc-core broke automounting, but you should be able to manually mount it.
<mjg59> And tifm_7xx1?
<andre_pl> and tifm7xx1
<andre_pl> is there another module i might be missing? 
<pkl_> mmc_core mmc_block
<mjg59> SD card or MMC?
<pkl_> andre_pl: what kernel version did this work?
<andre_pl> pkl in -13 i got alot of garbage whenever i inserted or removed a card.  but it hasn't worked Properly" since edgy
<mjg59> andre_pl: Are you doing anything funny with setpci?
<andre_pl> mjg59: nothing at all.
<mjg59> Right. Well, it works fine here.
<pkl_> The .8 tifm drivers should have fixed things for most people.  Unfortunately, there's still people for which it doesn't work.
<andre_pl> pkl_ I dont think I get ANYTHING at all in dmesg, even if i remove all the modules and reload them.
<mjg59> Not even PCI interrupt disabled/enabled messages?
<andre_pl> let me try removing all the modules and see what comes up.
<andre_pl> is there an order they should be inserted in?
<mjg59> Load tifm_7xx1 and mmc-core
<mjg59> Everything else will be loaded on demand
<pkl_> andre_pl: have a look at bug 53923, that's got a number of tifm issues.
<andre_pl> I get 2 lines 
<andre_pl> [ 3835.864000]  ACPI: PCI interrupt for device 0000:08:06.2 disabled
<andre_pl> [ 3943.088000]  ACPI: PCI Interrupt 0000:08:06.2[C]  -> GSI 22 (level, low) -> IRQ 22
<mjg59> Ok.
<mjg59> And if you insert an sd card, what happens?
<andre_pl> zilch
<mjg59> Nothing at all?
<mjg59> Is tifm_sd now loaded?
<andre_pl> no, just core and 7xx1
<mjg59> Right
<andre_pl> load it?
<mjg59> No
<mjg59> And this is an SD card?
<mjg59> Not an MMC?
<andre_pl> Says SD on it :)
<mjg59> Ok
<mjg59> I'm sorry, I've no idea what the problem is
<pkl_> nor do I, which is why I've done nothing about it :)
<andre_pl> this is a huge problem. lol
<mjg59> andre_pl: For you, yes
<mjg59> As I said, it's working on the tifm machines I have here
<mjg59> So figuring out the problem is awkward...
<pkl_> I can't reproduce it (not having the hardware), and AFAIK 0.8 is the latest version.
<andre_pl> neither mmc_block nor tifm_sd loaded automatically. are they supposed to?
<mjg59> They'd only be loaded automatically if the card insertion was detected
<andre_pl> should I see anything in dmesg just by loading the modules with no card inserted?
<mjg59> No
<andre_pl> so what are these 2 PCI Interrupt lines telling me?
<andre_pl> besides bad news?
<mjg59> That the device was detected and activated
<andre_pl> really?
<andre_pl> thats messed up
<andre_pl> maybe the card is messed up?
<mjg59> Maybe
<capiira> hi,hi, I compiled my kernel with debian/rules and everything worked fine but how can i define the name/version of the kernel? Now its called "linux-image-2.6.20-14-1a1-generic_2.6.20-14.22_i386.deb" i would like to have it named like the original one "linux-image-2.6.20-14-generic" with that "2.6.29-14.22" under latest version.
<capiira> that was my compilation command AUTOBUILD=1 fakeroot debian/rules binary-debs flavours=generic
<rtg_> mjg59: I'm getting some serious heat for bug #96480. What are the side effects of reverting db2f0f088a056c4ccf9054747169802db2f9ae9a 'Declare more i2c_adapter parent devices'? I'm sure this is what broke ACER and Mac Pro. They all say 2.6.12-20 works, 2.6.20-13 doesn't.
<mjg59> I've no clue - wasn't my patch
<rtg_> mjg59: I thought you might know 'cause it is related to ACPI. 
<BenC> rtg_: IIRC, that was pulled in to fix something else
<BenC> one of the i2c drivers was crashing before that was pulled in
<rtg_> BenC: That is why I'm asking about side effects.
<BenC> and that fixed it
<mjg59> Looks like an i2c issue, not an acpi one
<rtg_> mjg59: No, I believe its the way ACPI starts up its bus driver for I2C.
<rtg_> So it looks like catch-22.
<mjg59> It's an i2c driver
<mjg59> The only ACPI-related aspect is that it gets a couple of bits of information from an ACPI table
<BenC> cjwatson: edgy's ata_piix driver was only handling 3 pata chipsets, for reference
<mjg59> BenC: I've made no effort to determine whether any of the acpi/pata code for drivers/ide still works this cycle
<mjg59> Since all my test hardware transitioned over to ata_piix
<BenC> mjg59: Willing to run through some tests when I get this kernel compiled?
<mjg59> The HPA stuff has nothing to do with the chipset
<mjg59> If any pata chipsets are driven by libata, we need the HPA patch
<cjwatson> sure, but which manufacturers actually used HPA?
<mjg59> Impossible to determine
<mjg59> We've seen it on some desktop machines
<cjwatson> the HPA patch has, as far as I can tell, had no testing on any other distribution
<mjg59> Correct
<cjwatson> it is SEVEN DAYS BEFORE RELEASE
<mjg59> As I've said repeatedly, we either ship it or we revert all of pata back to drivers/ide
<BenC> we had pata in edgy, without this HPA patch
<cjwatson> or release-note that some people are going to have to use edgy
<cjwatson> the alternative is to delay the release by upwards of a week
<BenC> s/pata/libata-pata/
<mjg59> BenC: On a tiny, tiny number of chipsets
<BenC> it was a good chunk of chipsets, just not the popular ones, like ata_piix
<cjwatson> this has a really nasty knock-on effect on all sorts of things
<mjg59> cjwatson: It's very, very non-trivial for a user to determine whether they'd be bitten by this before upgrade
<BenC> wouldn't their dmesg show "Host Protected Area ..." ?
<mjg59> Yes, but asking most of our users to check dmesg before performing an upgrade is a non-starter
<cjwatson> update-manager could be made to do it ...
<BenC>         printk(KERN_INFO "%s: Host Protected Area detected.\n"
<Mithrandir> cjwatson: ew.
<cjwatson> (ew, yes, but)
<Mithrandir> cjwatson: yes, it can, but, ew.
<cjwatson> reverting all of pata is a non-starter
<Mithrandir> how much testing do we need to establish that the HPA patch doesn't break stuff?
<mjg59> It doesn't break anything here.
<mjg59> Beyond that, I obviously can't say
<BenC> Mithrandir: actually, I've had 4 people report that it fixes things
<fabbione> we can't guarantee that dmesg has enough buffer to have that printk in queue either
<BenC> and it hasn't broken anything on my system
<BenC> systems
<cjwatson> BenC: (we need to get the kernel with those drivers reverted up first regardless of this discussion; time is slipping away)
<BenC> cjwatson: it's in progress
<cjwatson> yup, just being clear
<mjg59> cjwatson: Reverting anything back to drivers/ide also needs further testing
<BenC> mjg59: we have to revert some piix ones anyway
<cjwatson> mjg59: indeed so
<mjg59> It means more people hitting codepaths that haven't seen significant use since edgy
<BenC> because they are broken with ata_piix
<cjwatson> right now, we need concrete evidence of HPAs existing on hardware other than the ones we're talking about reverting to drivers/ide
<mjg59> cjwatson: The issue is the drive, not the chipset
<cjwatson> HPAs are only set up by system manufacturers, right?
<mjg59> Yes, but people may then swap motherboards
<mjg59> And we have no clue which vendors may have used HPAs at different stages
<mjg59> Yes, this is all a bit handwavy, but it's not possible for us to say "Nobody will be affected by this decision"
<mdz> I've heard conflicting reports about the failure mode here
<mdz> what goes wrong?
<mjg59> mdz: Part of the hard drive becomes inaccessible. This may contain filesystem.
<mdz> that seems backwards to me; I thought the failure was that extra bits of disk were accessible which shouldn't be
<mjg59> No
<mjg59> HPAs are enforced by the drive
<BenC> Linux chooses to ignore HPA by default in the ide-disk driver
<mjg59> Old situation: Drive has HPA. Linux ignores this. User deletes rescue partition, installs into HPA. Everything works.
<mjg59> New situation: Drive has HPA. Linux doesn't ignore this. User can no longer access data that is in HPA.
<mjg59> User sad.
<mdz> so this is a problem for users who installed a Feisty snapshot over an HPA
<BenC> or, User upgrades, system that is installed in HPA, and now can't read the partition
<cjwatson> or <= Edgy
<Mithrandir> or any previous version
<cjwatson> since drivers/ide ignores the HPA (which means that the entire disk, including the HPA, is accessible)
<cjwatson> the terminology is very confusing
<mdz> which versions of Ubuntu does "Linux chooses to ignore HPA By default in the ide-disk driver" refer to?
<mjg59> mdz: All of them
<mjg59> Except feisty
<BenC> no, ide-disk driver still ignores it
<BenC> it always has
<mjg59> Well, but we now drive much less with ide-disk
<mdz> if HPA is enforced by the drive, how can we install into them?
<Mithrandir> the problem is for drivers which used to be ide-disk and are now libata.
<mjg59> mdz: You can't
<BenC> it's sd_mod that doesn't, and libata never took it into account
<mjg59> It's an upgrade issue
<mdz> how can we *ever* have installed into an HPA?
<mjg59> Because all versions before feisty allowed you to do so
<mdz> you said the disk disallowed it
<mjg59> The disk disallowed it. The kernel then asked the disk to allow it.
<cjwatson> mdz: no, the disk says what the max size is, but it's the OS' choice whether to honour that
<mdz> which is inconsistent with the rest of the description I've heard
<cjwatson> http://en.wikipedia.org/wiki/Host_Protected_Area
<maswan> mjg59: did you mean "driver" in "HPAs are enforced by the drive"?
<mjg59> maswan: No
<maswan> Ok, so I don't understand it either then.
<mjg59> There is a region of the drive.
<mdz> I do now
<mjg59> If you attempt to access it, the drive says "no"
<BenC> HPA is suggested by the drive, the driver can override it to get the native size
<mjg59> ide-disk pokes the drive to remove that restriction
<mjg59> libata doesn't
<maswan> Ah, ok.
<mdz> but if I do understand correctly, the safest thing is to stick with the same behaviour we have always had
<cjwatson> yes
<mjg59> mdz: Correct. Which requires either reverting to drivers/ide or adding the patch.
<kylem> so the same behaviour is to revert *ALL* ide drivers back to drivers/ide code.
<mdz> which means my understanding of the patch was reversed
<cjwatson> reverting *all* drivers seems insanely risky at this point
<mdz> I thought it was "adding HPA support", not "explicitly ignore HPA"
<cjwatson> a few PCI IDs I can handle, but ...
<cjwatson> (particularly if they have other problems)
<BenC> mdz: It's adding the ability to recognize and ignore the HPA :)
<mjg59> mdz: Adding HPA support means teaching the driver what an HPA is
<kylem> it's an ATA command, not poking a IDE controller.
<kylem> so it doesn't matter which chipset you have, it's drive dependent...
<mjg59> Right. I can take an HPAed drive and put it in another system with a different IDE chipset
<BenC> I didn't understand that either...I thought it was something done by the controller at the BIOS's request
<mjg59> BenC: No, the drive firmware will have been modified to set it up
<BenC> I guess the code being in libata-core confused that for me
<BenC> in IDE, it is in ide-disk specifically
<cjwatson> does anyone sell bare HPAed drives?
<mjg59> cjwatson: No, but you can set one up
<cjwatson> I mean not as part of some other system
<BenC> cjwatson: it's all provisioning for hw vendors
<cjwatson> I'm not interested in theoretical cases at this point
<mjg59> Oh,a ctually, yes
<mdz> mjg59: do I understand correctly that unless the OS takes specific action related to HPA, it's transparent and the drive simply appears to be smaller?
<mjg59> Various drives are limited to 32GB with a large HPA
<BenC> mdz: right
<mjg59> This is to avoid BIOS bugs
<mdz> and so the intent of the patch is to recognize the existence of an HPA and instruct the drive to ignore it?
<mjg59> mdz: Correct
<mjg59> cjwatson: Many drives have a "Limit to 32GB" jumper that actually sets an HPA
<BenC> yeah, one person in the bug report seems to have that case
<mjg59> Award shipped BIOSes that crashed if they saw a >32GB drive
<cjwatson> ok, first I've heard of that
<Mithrandir> ah, I always wondered how that worked.. and why Linux saw the full size of the disk.
<BenC> 32G -> 160G was the HPA message
<mjg59> Hits machines up to ~2000
<mjg59> Ok. And we've got a real case of that in the wild.
<cjwatson> sigh, my prior understanding was that it was basically laptops
<cjwatson> since everybody who talked about this bug seemed to do so in the same sentence as "Thinkpad"
<mjg59> Thinkpads are the most common case where developers are going to hit it
<Mithrandir> is that because it's more common on thinkpads or because 90% of our developers have their machines?
<mdz> and we've switched the driver that most thinkpads use to one which doesn't know about HPA?
<mjg59> mdz: Yes
<mdz> why?
<mjg59> Because we moved pata over to libata
<mdz> why?
<BenC> we followed upstream
<mdz> so this is a horrendous regression in 2.6.20?
<BenC> mdz: Moving to libata has been a spec since back in dapper
<cjwatson> at that time, nobody knew about this HPA thing
<mjg59> mdz: If using libata rather than drivers/ide, yes
<mdz> or does 'upstream' mean a git repository that hasn't been pushed to linus yet?
<cjwatson> at least nobody who actually said anything
<BenC> it was generally considered a rolling spec, moving to drivers as they become stable
<mjg59> cjwatson: I've been mentioning it repeatedly throughout the entire release cycle
<cjwatson> the first I heard of it was beta, and I was most certainly not aware of its extent
<BenC> mdz: It means every kernel release, the libata pata drivers mature and change to "stable", and so I've moved support for those chipsets from ide to libata
<cjwatson> but that's not particularly relevant, what I mean is that nobody said anything when the plans were being discussed
<BenC> in the kernel, you can choose either drive
<mdz> BenC: which drivers are we talking about in this case, which are relevant to the cases of HPA badness we've seen?
<BenC> mdz: It's not driver specific, it just means we are exposing more and more users to libata over time, and eventually hitting ones that have HPA drives
<BenC> it was just a matter of time before this turned into what we have now
<mdz> BenC: I understand, but we've been doing that for a while, and only recently has it become a big problem
<BenC> mdz: With the early march move of about 3 major drivers, I think that was the tipping point
<mdz> BenC: which drivers were those?
<BenC> pata_sis, quite a few more for ata_piix, one other legacy type driver that I'd have to check changelog for
<mjg59> mdz: It's likely that it's merely hit small numbers of users with previous drivers
<BenC> but I know that there were three drivers changed to "stable" by jgarzik
<mdz> PATA_SIS is marked experimental
<mjg59> In pure 2.6.20, I believe it's stable in the libata tree
<BenC> yeah, and I just looked, and it's because SATA_SIS depends on it
<BenC> pata_sis exports two tables, for sata/pata combined controllers
<BenC> s/two tables/pci tables/
<nictuku_i386> may i ask for help finding the list of patches applyed to the ubuntu kernel in the git site?
<BenC> we can't support sata_sis without pata_sis driver
<mdz> 2.6.20 was released in early Feb, and we made this change in March, so it doesn't sound like it came from Linus' tree
<zul> nictuku_i386: not now
<BenC> mdz: I talked to jeff Garzik about his stable tree, and he agreed that it was safe to pull into our tree
<nictuku_i386> ok thnx
<BenC> his stable tree is for the 2.6.22 window, not experimental stuff, well tested patches
<cjwatson> what other distributions are using his stable tree?
<BenC> it was needed to get DMA support for ata_piix driver, and get a few new chipsets supported that we didn't have drivers for at all
<mjg59> cjwatson: Fedora
<mjg59> But Jeff works for RH
<cjwatson> FC6?
<mjg59> No
<mjg59> FC7 will ship with it
<mdz> we need to talk about when and why we pull from various trees, but now is not the time
<mdz> so to come back to the immediate problem
<BenC> well, it was either that, or we release feisty that is not installable on some major hw that we sort of have to support
<mdz> I hear from mjg59 that this is a showstopper and needs to be fixed
<mjg59> mdz: I've been saying that for the past three months
<mdz> BenC: do you argee or disagree?
<mdz> or, perhaps, agree
<BenC> mdz: yeah, it would seem so
<mdz> then we have consensus
<mdz> let's get the fix in
<mdz> mjg59: I'm not arguing that point.  this is all news to me.
<mdz> I am in the moment
<BenC> ok, so I'll revert the 4 oldest PIIX chipsets back to piix.ko (from ata_piix.ko) to fix 82314, and add the HPA patch in
<cjwatson> and skip the SIS change?
<BenC> kernel will be uploaded soon, and I'll have images available for people to test prior to buildd
<BenC> cjwatson: right, I can't revert pata_sis anyway because of sata_sis needing it
<mjg59> Ok.
<mjg59> One of the other effects of this is that we need to be very careful about what update-manager does with the cd-rom entry in fstab
<BenC> you mean the /dev/hdc-/dev/scd0 reference?
<BenC> I think we already know about that one
<mjg59> BenC: Right, but lots of machines will be sticking with /dev/hdc
<BenC> I think the idea was to switch to /dev/cdrom, since udev updates that link
<mjg59> There's potential for that still to lose, but yeah, that's probably sane
<mdz> it's the best we can do; it's at least more future-proof
<cjwatson> BenC: that's what u-m does now
<cjwatson>         " convert /dev/{hd?,scd0} to /dev/cdrom for the feisty upgrade "
<mjg59> Ok, that shouldn't be a problem
<mjg59> I can't think of any other issues
<cjwatson> and it does so only if /dev/cdrom currently points to whatever the device in fstab is
<cjwatson> (seeing as it's doing the rewrite on the old kernel)
<BenC> I guess now is a good time to do a .orig.tar.gz
<BenC> cjwatson, mdz: package is uploading
<mdz> BenC: thank you
<Mithrandir> mdz: do you want to review and approve the kernel upload or should I?
<BenC> I can provide a diff from the current kernel if need be
<mdz> Mithrandir: I'm happy to help with review; Colin is likely interested as well
<mdz> Mithrandir: and perhaps mjg59
<Mithrandir> I'll put it on rookery.
<Mithrandir> BenC: I'm generating it on drescher, but thanks.
<mdz> better to generate the exact diff from the upload
<Mithrandir> yes, I'm doing that.
<cjwatson> Mithrandir: could you make your queue publish stuff do mdebdiff? might need to cache it
<Mithrandir> cjwatson: it runs every hour, so I don't really see the point in caching, but yes, I could do that.
<cjwatson> just say openoffice.org
<cjwatson> new upstream
<cjwatson> (for example :-))
<Mithrandir> I wonder how you guys survived without mdebdiff.
<Mithrandir> well, point.
<Mithrandir> still not a magnitude bigger than the kernel which takes a minute or two.
<mjg59> BenC: Did you get a chance to check those scancodes?
<cjwatson> lots of .gitignore stuff
<BenC> mjg59: Yeah, but have not uploaded it yet
<cjwatson> is the removal of debian/abi/2.6.20-13.21/ significant?
<BenC> no, the ABI for 2.6.20-14.22 was added
<cjwatson> oh, -14.22 got added, ok
<BenC> -13.21 isn't needed
<Mithrandir> http://people.ubuntu.com/~ubuntu-archive/queue/linux-source.debdiff is the diff
<mjg59> BenC: Ah - if that was going in, there's a couple of others that could do with it as well
<BenC> 10.4Meg...hugeness
<BenC> I foobar'd the .orig.tar.gz...left all the .gitignore files in
<BenC> not a big deal, just oversized .diff.gz's
<mjg59> Looks good to me
<mjg59> I'll test it once binaries exist
<BenC> build now
<mjg59> BenC: This is meant to purely be the ATA stuff, rather than the other one-liners, right?
<BenC> mjg59: pay close attention to the logic in ata_same_device, since that's what I changed from the patch that kyle had
<fabbione> BenC: you also left some other random stuff like scripts/kconfig/zconf.tab.c in the orig but cleaned for diff.gz
<BenC> mjg59: this is HPA, and moving a few older PIIX chipsets back to piix.ko
<BenC> fabbione: Yeah, my tree must be pretty crufty
<BenC> shame git-status doesn't show that stuff
<BenC> harmless though
<mjg59> BenC: So this isn't the final kernel upload?
<fabbione> BenC: i just spoke with Sunil from Oracle. he says that's ok to skip these 4 patches, but to pull again for the first update. there are more fixes in their queue for .20_fixes that are passing QA now
<BenC> git-ls-files --others
<BenC> that's what I needed
<fabbione> BenC: the most important ones are the ones i applied manually anyway
<BenC> mjg59: This is just to get us past release
<mdz> mjg59: this is meant to be the showstopper fixes
<BenC> mjg59: the HPA patch in here was tested and confirmed by 4 different people on that bug report (82314)
<mjg59> I thought we were targetting the MMC fix for release
<mdz> minor stuff can go in a stable update with less hurry
<mjg59> (At least, I thought that was what got agreed on yesterday)
<BenC> I'm more worried about the install stoppers
<BenC> we'll have an updates kernel withing days of release
<mjg59> Ok. Which one's going to end up on the shipit CDs?
<mdz> I'm not opposed to the MMC fixes as such, but given the weight of the other stuff, I'd prefer to keep this as simple as possible and roll an early SRU
<mdz> mjg59: the CDs will get this kernel Ben has just prepared, barring further showstoppers
<mdz> anything else will be a network update
<mjg59> I think losing MMC on the Live CDs would be an error
<mjg59> Given the trivialness of the fix
<mdz> BenC: this diff is unreadable
<Mithrandir> mdz: filterdiff -x '*/.gitignore' 
<BenC> mdz: egrep -v '(gitignore|debian/abi)'
<mdz> lots of big removals too
<BenC> my .orig.tar.gz had some build cruft too, but it's harmless stuff that will get deleted on build
<BenC> mdz: debian/abi/ changes can be ignored
<BenC> standard update from last build
<Mithrandir> /tmp/Y9bNBOLdlm/linux-source-2.6.20-2.6.20/drivers/cpufreq/.tmp_versions/cpufreq_conservative.mod and friends, you mean?
<BenC> yeah, those things are cruft that git-status didn't show
<mdz> I can't do more than eyeball the HPA stuff; it's too big and requires context
<cjwatson> I also thought we had agreed the MMC fix earlier
<mdz> BenC: looks like that stray .swp is still there in the new version
<BenC> yeah, I just removed all the cruft in my tree
<mjg59> BenC: I'd be happier if we went with the MMC fix as well
<BenC> do you guys want to hold that last upload and include the mmc fix?
<mdz> I found no fault with the diff other than the clutter, though there's a lot of new code there I can't possibly assess
<BenC> take me 15-30 minutes
<Mithrandir> if the mmc fix is as trivial as you say and has been tested, I'm fine with it.
<mjg59> It's trivial and it's been tested
<BenC> I can ditch the cruft at the same time
<mdz> mjg59: you do realize that you're asking other people to work even later for the sake of that change
<Mithrandir> why are there five added items to the piix_pci_tbl_aliases, but only three ifdef-ed out of ata_piix.c in the pci table there?
<mjg59> mdz: I realise that yesterday we decided to include it and have been telling users that since then
<zdzichuBG> anyone remeber edgy kernel patches to enable more thinkpads in hdaps driver? I couldn't find any
<Mithrandir> zdzichuBG: now is a bad time; please try later.
<mdz> mjg59: I don't recall a grand announcement about it; it's a minor bug
<zdzichuBG> Mithrandir: ok.
<mjg59> mdz: It's an entire class of hardware that doesn't work
<mdz> mjg59: it's an entire class of hardware that few people use, and it doesn't affect their ability to install or upgrade at all
<mjg59> mdz: If you'd made that argument yesterday when the decision was made, sure
<Mithrandir> mdz: if we hold up release for this kernel build anyway, it won't make a difference; building the kernel takes enough time that .eu won't be awake when it's done.
<Mithrandir> as in, hold up the RC for it.
<mdz> mjg59: and if it were in the upload Ben prepared, I wouldn't have objected to it, but here we are
<mdz> BenC: up to you
<cjwatson> I would like to ditch the cruft, mind you
<mjg59> When it's a single line fix that has a significant effect on the hardware experence on the live CDs that are going to be mailed out by their thousands, I think it's relevant
<fabbione> cjwatson: ++
<BenC> Ok, already working on it, so give me 10 minutes
<mdz> mjg59: I agree
<mdz> mjg59: which is why I OK'd it earlier today
<BenC> Mithrandir: can you just ditch that upload, or do I need to bump the version?
<Mithrandir> BenC: I can reject it.
<BenC> thanks
<mdz> mjg59: what I'm asking from you is sensitivity to the fact that we're already under pressure here, and we still have a long way to go
<Mithrandir> unless mdz tells me not to.  I think we should ditch it and get the mmc fix + the cleanups in.  If nothing else because it'll make me scream less when reading debdiffs for -proposed.
<mdz> I am not
<mdz> but this is it
<mdz> we have already blown the release candidate
<Mithrandir> Rejecting ubuntu/None (UNAPPROVED) 1/15
<Mithrandir> ---------------------------------------------------------------------------
<mdz> it's time for a measure of restraint
<Mithrandir> Rejecting linux-source-2.6.20
<Mithrandir> mdz: should we release the current set of images as herd-6 and skip RC, do RC on Monday or RC later (and then absolutely delay the release)?
<fabbione> BenC: do you also have lrm / meta / backports ready?
<BenC> fabbione: This is non-ABI changing
<fabbione> ah cool
<fabbione> so we just need a new d-i to pull in the kernel
<fabbione> and new images
<fabbione> much faster :)
<mdz> Mithrandir: let's get this round of fixes in (kernel and n-m), then see where we stand tomorrow and decide then
<cjwatson> I'll upload d-i nowish and Mithrandir can accept it when it's time
<mdz> I'm leaning toward giving RC a miss and driving on to final
<cjwatson> if that's ok with everyone?
<mdz> but if we make good time, we could potentially do a late RC
<Mithrandir> mdz: should I start spinning images tomorrow morning?  Experience shows I'm around a bit earlier than you both because of the TZ and because I can just roll out of bed and crawl to the room next door.
<mdz> cjwatson: no objection here
<Mithrandir> cjwatson: yes, thanks.
<cjwatson> there was a sparc module addition in my tree for fabbione
<fabbione> cjwatson: that's a blocker that needs fixing or people won't get keyboard working in d-i
<fabbione> hem
<mdz> Mithrandir: we want images ASAP, doesn't matter to me who does it so long as nobody steps on any toes
<fabbione> you know that
<fabbione> it was for mdz and Mithrandir 
<cjwatson> it's in my upload; mdz/Mithrandir's call
<Mithrandir> mdz: ok, I'm doing it first thing tomorrow then.
<Mithrandir> cjwatson: diff?
<cjwatson> diff -Nru /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg
<mdz> cjwatson: if it's demonstrably a noop on !sparc, I am happy
<cjwatson> --- /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg   2007-03-22 09:19:40.000000000 +0000
<cjwatson> +++ /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg   2007-04-11 13:39:42.000000000 +0100
<cjwatson> @@ -9,6 +9,7 @@ ide-modules-${kernel:Version} ? pata-modules-${kernel:Version} ? usb-modules-${kernel:Version} ?
<cjwatson> +input-modules-${kernel:Version} ? usb-discover
<cjwatson> scsi-modules-${kernel:Version}
<cjwatson> geez, IRC totally mangled that
<cjwatson> --- /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg   2007-03-22 09:19:40.000000000 +0000
<cjwatson> +++ /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg   2007-04-11 13:39:42.000000000 +0100
<cjwatson> @@ -9,6 +9,7 @@
<cjwatson>  pata-modules-${kernel:Version} ?
<cjwatson>  usb-modules-${kernel:Version} ?
<cjwatson> +input-modules-${kernel:Version} ?
<fabbione> mdz: no op on !sparc
<cjwatson>  ide-modules-${kernel:Version} ?
<cjwatson> and more random context
<cjwatson> uploaded
<Mithrandir> cjwatson: looks good to me.
<BenC> upload in progress, I'll let you know when it's done
<cjwatson> Mithrandir: I'm going to the pub shortly for some much-needed social interaction, but I'll be back later; I'm on my own in the house so couldn't really care less if I'm up late
<mdz> Mithrandir: have you been in contact with Keybuk regarding the n-m fix?  it was looking good the last time I checked in with him
<cjwatson> so I can drive image building and such if it happens before I fall asleep
<Mithrandir> cjwatson: ok.  I'll try to make the kernel end up on palmer at least, but we're still talking 6-ish hours for the kernel, iirc.
<BenC> be aware that the debdiff is still going to look crufty, because -13.21 had the cruft, this one doesn't
<Mithrandir> BenC: ok.
<BenC> the only change in this one is the one-liner mmx fix
<BenC> mmc
<Mithrandir> mdz: no, I'll speak with him now
<mdz> Mithrandir: that needs to go in the final build, he's been organizing some testing but I'm unsure where it stands so far
<Mithrandir> mdz: yes, I just prodded him on IRC and am sending him an email too.
<BenC> Mithrandir: Done
* cjwatson -> gone for a while
* BenC is getting some coffee
* mdz -> dinner, carrying my mobile
<Mithrandir> ok, linux-source accepted
<salty-horse> hi. noticing the topic, where's the best to look get support for the new nvidia-glx package?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-14.23 Uploaded - If you have a BUG, it's too late to get it in for release.
<BenC> salty-horse: Upgrade your system to latest feisty
<BenC> salty-horse: what sort of support do you need?
<salty-horse> BenC, I *am* using feisty. Until the "new legacy" nvidia-glx package was created, I manually installed NVIDIA-Linux-x86_64-1.0-9631. then I --uninstalled it (and made sure no files remained) and installed nvidia-glx. When I run the nvidia driver I get the "Error: API mismatch: the NVIDIA kernel module has the version 1.0-7184, but this X module has the version 1.0-9631" error (as seen on https://bugs.launchpad.net/ubuntu/+sourc
<salty-horse> e/linux-restricted-modules-2.6.20/+bug/96430 )
<BenC> salty-horse: sounds like you have some local skew
<BenC> salty-horse: Make sure you remove the nvidia-glx-legacy package, and install nvidia-glx, then restart your system
<BenC> try "sudo apt-get --reinstall install linux-restricted-modules-2.6.20-14-generic nvidia-glx nvidia-glx-legacy-"
<BenC> note the "-" on the end of nvidia-glx-legacy
<salty-horse> according to dpkg -l "*nvidia*" only nvidia-glx is installed. I did notice that linux-restricted-modules contain all 3 nvidia kernel modules - that's intentional, right?
<BenC> yes, but it should choose the right one to load
<BenC> it's possible you have a left over file...hold a sec
<BenC> sudo rm -f /lib/linux-restricted-modules/.nvidia_*
<BenC> try that, and reboot
<salty-horse> $ modprobe -l | fgrep nvidia
<salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia.ko
<salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia_legacy.ko
<salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia_new.ko
<salty-horse> /lib/modules/2.6.20-14-generic/kernel/drivers/video/nvidia/nvidiafb.ko
<BenC> there's nothing wrong there, it's lrm-video that is loading the wrong driver, most likely because that file /lib/linux-restricted-modules/.nvidia_legacy_installed, is still there
<salty-horse> i have only .nvidia_new_installed - deleted it and restarting
<salty-horse> btw, what does the restricted manager GUI do when I click on the checkbox to enable the driver? does it just update xorg.conf?
<BenC> Yes, basically, and lrm-video will only load modules based on xorg.conf having it enabled
<BenC> how do you have .nvidia_new_installed in there?
<BenC> It would only be there if you install nvidia-glx-new
<salty-horse> yes. and I deleted it just now.
<BenC> just wondering how it got there
<salty-horse> i have before.. when I nvidia-glx didn't work - glx-new hasn't as well and I tried to remove it. I think I got some conflicts then.. there was a conflict with dpkg-divert as well.. could it be that these packages' uninstallation methods are missing something? or is it more likely that i borked things manually?
<salty-horse> ok, I'm restarting - is it enough to restart gdm?
<BenC> kernel modules needs to be reloaded
<mjg59> BenC: Did you have any additions to make to that dell.hk?
<salty-horse> roger that
<salty-horse> thanks BenC!
<BenC> salty-horse: working?
<salty-horse> glxgears works well
<salty-horse> btw, nvidia-glx-legacy doesn't have nvidia-glx-new in "Conflicts:"
<BenC> For anyone wanting to test HPA and PIIX changes, http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> mmc fix is not in that build, but it's not as important
<BenC> mjg59: ^^
<BenC> salty-horse: Thanks, I'll get that fixed up
<salty-horse> not sure if it matters, because the other two have glx-legacy :)
<BenC> I think nvidia-glx-new has a conflicts with nvidia-glx-legacy, which should be enough
<salty-horse> BenC, what's up with the bug report? each day there are new replies, mostly for support (out of the scope of the bug) - think they can be diverted to the new "Answers" section or to a post on the forums?
<BenC> salty-horse: Sure, anything not related to 9631-being-available should be redirected
<defendguin> mjg59, did you get a chance to look at that touchpad issue i was having?
<mjg59> No
<mjg59> BenC: Did the i2c issue get fixed?
<BenC> mjg59: it's in-progress, IIRC
<mjg59> So there'll have to be another upload anyway?
<BenC> rtg was working on it
<mjg59> Since it renders a load of machines unbootable?
<mjg59> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480/comments/30
<mjg59> Uh
<mjg59> Given that it renders some machines unbootable, how are they supposed to install?
<mjg59> BenC: I'm really not happy with that bug being downgraded
<BenC> mjg59: that's incorrect...but unless I get a tested or obvious patch in my hands in the next 60 minutes, it will have to get fixed in a post-release update
<mjg59> BenC: It can't be fixed in a post-release update. The machines don't boot.
<BenC> I can't say for sure, but I suspect we'll have a real quick point release
<mjg59> The shipit CDs are going to be the originals
<BenC> which means CD images and installers
<mjg59> (Apparently)
<BenC> I don't know what the plans are for shipit...it's possible that they may hold off for a point release, but I can't speak for that end of things
<BenC> I wish we had gotten blacklist=foo,bar support into initramfs for things like i2c_ec :/
<BenC> then again, it might not be too late
<kylem> i think i need to yell louder, i asked for that in january...
<kylem> we own initramfs-tools now though, don't we?
<kylem> maybe i can hack something up when i get home tonight...
<BenC> yeah, but no one ever took the time to implement it...not even the yellers :)
<BenC> kylem: the script will have to make sure to copy it to /etc/modprobe.d/ on the root fs, even deleting the file if no blacklist is asked for
<maks_> BenC blacklist in /etc/modprobe.d that is in the initramfs
<BenC> maks_: For it to make sense, it has to blacklist in the rootfs too, else the module might get loaded later
<maks_> BenC sorry i'm lost please explain
<rtg_> BenC, mjg59: There are really 2 issues to the I2C bug. The i2c_ec module crash, and a much earlier crash that is a separate problem. The i2c_ec module now checks for a bogus parent and bails out, avoiding the fault.
<BenC> rtg_: what is the earlier crash...like an oops, or a caught failure?
<macd> are people experiencing the acpi bug (96480) on 2.6.17-11-generic also? 2.6.17-11-386 boots fine.
<rtg_> Its not clear. The bug reporters aren't all that disciplined in their reporting.
<maks_> BenC oh you want a bootparam blacklist
<BenC> maks_: if someone wants to blacklist i2c_ec because it oopses on the install CD, then device probing later during install will reload it if the blacklist isn't kept in the rootfs
<rtg_> BenC: I think its an ACPI fault early in the boot cycle on some platforms.
<BenC> maks_: Right, something you can put on the command line for install
<macd> rtg_, right right, I'll get a detailed bug posted.
<mjg59> rtg_: Which upload contains the partial fix, then?
<kylem> heh, i should go and buy a Mac Pro to get this i2c thing fixed, i can't reproduce it on my 4 ubuntu machines...
<rtg_> mjg59: I committed yesterday, so it should be there. Ben?
<mjg59> Because Ben's upload changelog doesn't mention it
#ubuntu-kernel 2007-04-13
<rtg_> kylem: I have 3 that all load i2c_ec, but nonoe of them oops.
<mjg59> On the vast majority of machines, i2c_ec will never bind
<mjg59> So loading it is uninteresting
<maks_> BenC we can easily write a blacklist dir in /dev/.initramfs
<maks_> some m-i-t would need to pick that up
<BenC> is i2c_ec autoloaded somehow?
<rtg_> Yep.
<rtg_> Well, maybe. I'm not sure.
<rtg_> I think its a result of sms
<rtg_> sms --> sbs
<mjg59_> rtg_: Uh. http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=commitdiff;h=82580efcd0224a29a9bef1b4ce53f7a4d4611b09 is really, really not a good idea.
<mjg59_> Oh, wait, hang on.
<mjg59_> Sorry, I see what you were doing there.
<maks_> BenC qemu test complain about not beeing able to write to ${rootmnt}/etc/modprobe.d/initramfs as ro mounted
<maks_> can post the patch if you want
<BenC> maks_: Ah, right, it's mounted ro until after the init scripts run fsck and such
<BenC> so maybe there should be a dangling symlink for /etc/modprobe.d/initramfs-blacklist -> /some/tmpfs/initramfs-blacklist
<BenC> initramfs could create /some/tmpfs/initramfs-blacklist
<mjg59_> BenC: It looks astonishingly likely that db2f0f088a056c4ccf9054747169802db2f9ae9a is what broke the i2c_ec stuff
<mjg59_> Any idea what dragged that in?
<maks_> BenC currently we like to write usplash stuff into /dev/.initramfs so there could be the modprobe.d blacklist there
<BenC> mjg59_: right, rtg found that out too...that got dragged in either by devres stuff, or to fix some other bug, but I can't recall which now
<BenC> I should really edit cherry-picks as to why they got picked, especially ones like that
<mjg59_> Well, just lose that line 
<BenC> we are still seeing a bug with HPA patch, even reverted back to original ABI breaking code
<BenC> reverting it just covered up the ata_dev_same_device() failure
<mjg59_> BenC: Well, that's not the fix that he committed
<pkl_> BenC: is there a reason why c25cfc3ad3cb8cac3474febfe66cff8ee0bfba18a was applied reverting the tifm driver from 0.8 to 0.7?
<BenC> mjg59_: I'll look at that in a second...if it works with the i2c change reverted, I can maybe get it in
<BenC> I need to get HPA working
<mjg59_> BenC: I can't guarantee that it works, and I recommend not reverting the entire thing
<BenC> [   67.208231]  ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = -1342616656
<mjg59_> Just change that one line
<mjg59_> It certainly can't make anything worse
<BenC> mjg59_: which line?
<mjg59_> +       smbus->adapter.dev.parent = &device->dev;
<mjg59_> Delete it
<BenC> for i2c_ec?
<mjg59_> Yes
<BenC> Ok
<mjg59_> You can't legally do that with the acpi in 2.6.20
<BenC> mjg59_: back to HPA, there seems to be some 64-bit issue with the lba to sectors code
<BenC> I can see it on my xeon now
<BenC> I need to check the values in that function
<mjg59_> Ok
<mjg59_> I'm unlikely to have a 64-bit install done in time to help you
<BenC> mjg59_: be around for general poking if I find anything?
<BenC> now that I can reproduce it, I can at least find out where it's coming from, but if I get any ata questions, I'm at a loss for quick answers
<mjg59_> Yup
<BenC>         printk("%02x %02x %02x %02x %02x %02x: %016llx \n",
<BenC>                tf->hob_lbah, tf->hob_lbam, tf->hob_lbal,
<BenC>                tf->lbah, tf->lbam, tf->lbal, sectors);
<BenC> [   67.124009]  f9 4b af f9 4b af: ffffffffaff94baf 
<BenC> prints that
<BenC> that can't be right
<BenC> this is what gets printed for another drive
<BenC> [   67.112044]  00 00 00 f9 4b af: 0000000000f94baf 
<BenC> the f94baf looks awful familiar :/
<BenC> the first read is from ata_read_native_max_address_ext()
<BenC> the second is from the return value of ata_set_native_max_address_ext()
<BenC> I think I see the problem with this
<cjwatson> BenC: what's the status? I see scrollback ...
<BenC> cjwatson: things are working, I just have a slight problem of 64-bit ness it seems
<BenC> cjwatson: it's a problem I can reproduce so just a matter of figuring out the thinko that is hiding in here somewhere
<cjwatson> ok, I'm going to doze here,
<cjwatson> if you phone my landline it stands some chance of waking me up
<BenC> cjwatson: Ok, elmo said he'd be around to process an upload, unless you prefer I contact you
<cjwatson> use me as a first resort and elmo as a backup, please
<BenC> cjwatson: will do
<jml> t.
<jml> (sorry, ultra-tappy touchpad)
<defendguin> hey how do i mount the mmc device?
<defendguin> now my mmc card wont work in -12 and it used to and my camera doesn't connect as a mass storage device
<Mithrandir> defendguin: please try the absolute latest kernel, it should fix it.
<defendguin> Mithrandir: what is the latest? -14?
<defendguin> or did they release something else with the mmc fix?
<fabbione> defendguin: yes. about 8 hours ago and should be in the archive.ubuntu.com as we speak
<fabbione> probably the mirrors didn't catch it up yet
<Mithrandir> 2.6.20.14.12
<defendguin> ahh i see it in update
<defendguin> 2.6.20-14.23
<defendguin> i hope that fixes the issue with the camera too
<defendguin> doesn't look like it is working
<defendguin> how can i tell that im in .23?   it just says generic
<Mithrandir> make sure uname -a says 2.6.20-14-generic
<defendguin> Linux houston 2.6.20-14-generic #2 SMP Thu Apr 12 22:53:19 UTC 2007 i686 GNU/Linux
<Mithrandir> and neither your camera (which I presume is mass-storage) nor your mmc reader works correctly?
<defendguin> correct
<defendguin> it is most probably mass storage but i can't guarantee that
<defendguin> i wish i had gotten a chance to test this fix out a few days ago
<Mithrandir> I think it's too late to fix this now, we might be able to do it in a post-release update
<defendguin> Mithrandir: i really need to mount this disk
<defendguin> i used to remember my fstab stuff but its been so long since i needed to 
<defendguin> what sucks is that it used to work in -12 but now that doesn't even work
<cjwatson> BenC: this isn't sounding good. What's up?
<Mithrandir> what breaks if we just blacklist that i2c-ec driver?
<Mithrandir> hm, the smart battery module breaks then..
<Mithrandir> ugh, it's 1:30 for Ben, a bit on the late side to call him.
<fabbione> i don't think he will mind too much if you call him
<fabbione> probably the wife will mind more
<Mithrandir> I've sent him an SMS and will send him an email too, hopefully he'll see either if he's up
<mc44> the new kernel seems to be broken for me
<mc44> should I file a bug?
<Mithrandir> no
<Mithrandir> there are about five hundred zillion dupes filed already
<mc44> haha
<mc44> ok sorry
<Mithrandir> the SD/MMC reader on my x40 seems to work again, at least.
<Keybuk> I've yet to find a use for the SD/MMC reader
<Keybuk> since every single device I own has a different profile card
<Mithrandir> I wish I had a CF reader instead.  SD is one of the few I actually don't have.
<zdzichuBG> so I must be lucky. card reader in my z61t is compatibile with my sistet's Minolta camera
<Keybuk> the 770 takes a little card that's half the size of the cards the N800 takes
<Mithrandir> zdzichuBG: my camera uses CF cards, since it's a tad more expensive than the cheap ones you can get.
<Mithrandir> at least I don't know of any prosumer DSLRs which use !CF.
<Keybuk> successive sony phones have left me with a small pile of Memory Stick Duo, Memory Stick Pro Duo and now Scandisk M2 cards
<Keybuk> none of which fit in any other device
<Mithrandir> yes, I have MS Pro Duo as well, for my old camera.
<Mithrandir> it's easier just to chuck a 250-thousand-different-kinds-of-cards reader in the bag and use that
<Keybuk> I just use bluetooth
<Keybuk> or USB
<JanC> Mithrandir: 1000-in-1 usb card readers are cheap  :)
<Mithrandir> they cost about 2.5 cents, so yes.
* JanC just bought one
<JanC> I don't understand why they don't just cram one of these in laptops instead of all those things that need special drivers
<JanC> would probably be easier to support for manufacturers too
* ..[topic/#ubuntu-kernel:cjwatson] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.24 Uploaded - If you have a BUG, it's too late to get it in for release.
<mjg59_> Keybuk: The ones in the N70 (RSMMC) are electrically compatible with MMC and SD
<mjg59_> There's a little adapter that clips on
<Keybuk> N70?
<Keybuk> don't have one of those
<Keybuk> I have a 770 and N800
<mjg59_> 770, rather
<Keybuk> the ones in the N800 are bigger versions of the ones in the 770, right?
<mjg59_> The N800 comes with SD, not MMC
<mjg59_> SD readers can read MMC, but not vice-versa
<BenC> zul: ping
<zul> BenC: pong
<zul> whats up
<BenC> zul: are you able to do anything with openvz? I sort of need to give Malc a heads up on what may or may not happen
<zul> yeah I have x86 kind of working kind of broken on amd64
<zul> I keep timing out when Im trying to upload it with dput
<BenC> IMO, just apply the patches and getting it building if you can
<BenC> let them worry about whether it works or not
<zul> sure..
<BenC> zul: could you reply to the email they sent?
<zul> sure
<BenC> zul: great thanks. I know you got a lot of other things going on more important, I'm just trying to follow up and make sure the communication doesn't go stale
<zul> not a problem, thanks
<zul> done
<zul> Ill try to upload the kernel to the archive again
<zul> and get the userland stuff uploaded at lunch
<Keybuk> mjg59_: all I remember is that I tried to put the 770 card into my laptop
<Keybuk> and couldn't get it out for weeks
<mjg59_> Yes. You need the clip-on adapter.
<kylem> wtf, could not resolve us.archive.ubuntu.com
<Keybuk> I don't think I got an adapter
<Keybuk> the M2 thing in the W880i is damned nifty though
<Keybuk> it's 1GB and smaller than a thumb-nail
<mjg59_> Keybuk: The 770 ships with the card in an adapter
<mjg59_> You have to unclip it before you can put it in the machine
<Keybuk> oh
<Keybuk> wonder where I put that then
<Keybuk> probably threw it away :)
<gnomefreak> Keybuk: thank you for the n-m fix it worked great :)
<EtienneG> hey guys ... I'm getting 403 Forbidden when trying to install linux-image-2.6.20-14-generic 
<EtienneG> before I look for someone to bug, am I th eonly one that noticed this ?
<stgraber> EtienneG: this kernel is buggy, so the access is currently blocked
<EtienneG> ha, ok then
<stgraber> EtienneG: some people have crash with it another one is being built at the moment
<EtienneG> thanks for the info, I'll be waiting for the next upload
<zul> BenC: ping bu
<zul> er... openvz-kernel-2.6.20_2.6.20-1_source.changes is NEW 
<BenC> mjg59, kylem: We need to figure out the correct fix for this
<mjg59> Yes.
<BenC> I'm leaning toward just not doing hpa if the driver is sata_nv...if it's even possible to do that check
<mjg59> Not trivially.
<mjg59> What other code paths are there that execute ata_exec_internal?
<mjg59> Ah, hang on. Alan at one point suggested doing the resizing after the drive/controller timing had been set up.
<mjg59> Can you move the call to...
<mjg59> (Let me find this)
<BenC> let me check...
<BenC> we should do this for ATAPI, right?
<mjg59> Ok, after the call to ata_set_mode() in ata_eh_recover()
<mjg59> No, ATAPI isn't a problem
<kylem> no.
<mjg59> Or, rather, I don't think ATAPI devices can implement HPAs
<kylem> doing HPA on ATAPI devices is illegal.
<BenC> they should report no hpa support though right?
<kylem> it won't claim ata_id_hpa_enabled
<kylem> right
<BenC> right
<kylem> - Mandatory when the Host Protected Area feature set and the 48-bit Address feature set are
<kylem>   implemented.
<kylem> - Use prohibited when the Removable Media feature set is implemented.
<kylem> - Use prohibited when PACKET Command feature set is implemented.
<mjg59> kylem: Can you give that a go?
<BenC> let me try mjg59's suggestion
<mjg59> There's two codepaths where ata_set_mode() gets called, depending on whether the eh code is in use or not
<mjg59> It may need adding to both
<mjg59> Actually, yeah, it needs adding to both (if it works)
<mjg59> But I guess we'll find out
<kylem> mjg59, i've moved it somewhere myself trying.
<BenC> mjg59: maybe put it in ata_set_mode?
<mjg59> BenC: Could do, but no real need
<mjg59> It's trivial to add to both
<kylem> trying.
<BenC> recompiling
<kylem> worked.
<kylem> mjg59, didn't fail that time.
<kylem> ah. didn't fail because it didn't execute, fun.
<kylem> ohhhh. hmm. maybe because hpa_id_enabled wasn't true there.
<mjg59> kylem: Where did you add it?
<kylem> mjg59, after ata_set_mode in bus_probe.
<mjg59> kylem: That won't be executed if there's an error handler
<mjg59> Put it in ata_eh_recover()
<BenC> I've put it in both places, rebooting
<BenC> boots
<kylem> i still think we should add an avoid_all_hpa_code flag.
<mjg59> Does it execute?
<BenC> but I want to put a printk back in there to make sure it is getting called
<BenC> kylem: I changed the ignore_hpa=0 to actually do that
<kylem> at least that way, we don't brownpaperbag the pressed cds completley and utterly.
<kylem> ok.
<mjg59> I can sort of understand sata_nv getting upset if you're executing ata commands before actually making sure the disk and controller timings agree
<BenC> it's not getting called
<BenC> let me post my diff
<BenC> people.ubuntu.com/~bcollins/libata.diff
<BenC> I'm thinking about moving the checks for (ata_ignore_hpa && ata_id_hpa_enabled(dev->id) to the top of ata_hpa_resize to clean things up a bit
<mjg59> Would also work
<kylem> ok.
<mjg59> BenC: It's not obvious why it's not getting called. You rebuilt the initramfs as well, right?
<kylem> i have an idea.
<kylem> we buy everyone scsi disks.
<kylem> and pretend ATA doesn't exist. :)
<BenC> yes
<kylem> ergh.
<kylem> ok.
<kylem> i think ata_dev_revalidate is the right place to put it.
<kylem> since it's called from both the _eh and bus_probe paths.
<mjg59> After set_mode?
<cjwatson> BenC: (is that another ABI bump, BTW?)
<BenC> ok, it's getting called now
<BenC> cjwatson: No
<cjwatson> ok, just checkin'
<cjwatson> I'm not going to say no if that's what it takes
<mjg59> BenC: Getting called and breaking?
<BenC> mjg59: I need to check that it is actually going down the code path
<mjg59> Ok
<BenC> but the function got called
<notts> sorry to jump in, but there a major bug with the new updated kernel this morning
<notts> got error message: error loading os"
<mjg59> notts: Yes, it's broken for various people
<mjg59> It's being worked on
<kylem> hey hey.
<kylem> garzik to the rescue.
<notts> major thanks, any word on when
<mjg59> When it works
<kylem> WOOOOOO
<kylem> I WIN
<rpereira> hi everybody.
<BenC> mjg59: neither of my drives says they support hpa when ata_resize_hpa() is called
<kylem> BenC, boot with sata_nv.adma=0
<BenC> kylem: with old patch?
<kylem> ata4.00: ata_hpa_resize 1: sectors = 390721968, hpa_sectors = 390721968
<mjg59> BenC: Hm. Odd.
<kylem> BenC, yeah
<kylem> want my defconfig'd kernel instead of rebuilding?
<mjg59> kylem: Figures.
<kylem> yes.
<kylem> fuck nvidia.
<kylem> right in the skull.
<BenC> it doesn't take me long to rebuild libata.ko
<kylem> ok.
<BenC> kylem: so should we disable adma by default?
<kylem> i think so.
<mjg59> Fine. Dropping adma just costs us ncq
<mjg59> But it's clearly broken in some respect
<BenC> kylem: can you do a patch for that, and I'll include a patch so that ignore_hpa steers clear of all hpa code?
<BenC> email it to me and I'll test it and prepare a -15.25
<kylem> 1sec, trying to figure out if we can shortcircuit adma mode so we can leave it on.
<BenC> kylem: just default the module param to 0 :)
<BenC> if people want it they can enable it manually
<kylem> NCQ is fairly hit or miss too.
<BenC> do you think making module parm adma=0 by default is enough?
<kylem> yes.
<BenC> if that's all that's needed I can do that locally
<kylem> ok.
<kylem> it's static int adma_enabled
<BenC> ok, I'll rebuild a kernel and see if danielk is still around to test
<cjwatson> any idea when sata_nv.adma was turned on?
<kylem> cjwatson, recently.
<cjwatson> nod
<kylem> commit 382a6652e91b34d5480cfc0ed840c196650493d4
<kylem> Author: Robert Hancock <hancockr@shaw.ca>
<kylem> Date:   Mon Feb 5 16:26:02 2007 -0800
<kylem>     sata_nv: use ADMA for NODATA commands
<kylem> turning it off wholesale is fine for now. i'll look into a real fix when we have some idle cycles.
<cjwatson> hmm, git-blame says 2006-10-27
<cjwatson> oh, it's only one bit of adma?
<kylem> yeah.
<kylem> basically instead of transitioning from adma mode to normal mode, they decided to submit NODATA with ADMA.
<cjwatson> git log drivers/ata/sata_nv.c doesn't show the commit above?
<cjwatson> (just trying to find it)
<kylem> probably came in one of our imports
<BenC> it was a chunk patch to sync with libata
<cjwatson> $ git diff-tree -p 382a6652e91b34d5480cfc0ed840c196650493d4
<cjwatson> fatal: bad object 382a6652e91b34d5480cfc0ed840c196650493d4
<cjwatson> ah
<BenC> cjwatson: git-diff-tree -p --pretty SHA
<kylem> cjwatson, git show
<BenC> cjwatson: ah, you don't have upstream in there
<BenC> should we just revert that one patch?
<cjwatson> ah, I have a different tree for that
<kylem> BenC, testing.
<BenC> if we can leave adma on for default transactions we can avoid the "my driver performance sucks" crew
<kylem> yup.
<kylem> reverts cleanly, testing now.
<cjwatson> it does say it fixed some timeouts ...
<kylem> boots.
<cjwatson> oh, no, maybe not
<kylem> yeah, the language is murky.
<BenC> cjwatson: it fixes some previously fixed ones in a different way
<BenC> from the sound of it
<mjg59> Well, worst case is that we revert back to edgy levels of support for that hardware
<cjwatson> mm
<cjwatson> can we bonnie++ the resulting system or something? :)
<mjg59> BenC: The i2c_ec patch went in, right?
<kylem> NCQ isn't always a win.
<BenC> kylem: so reverting that patch with current code works?
<cjwatson> bit concerned that just booting might be a weak test there
<BenC> mjg59: yes
<mjg59> Excellent, thanks
<cjwatson> (I don't care about performance, more that it doesn't fall over under load)
<kylem> BenC, yes in my testing tree (which is .21-rc6) building ubuntu images now
<cjwatson> mjg59: anything else you know about?
<cjwatson> of the release-critical ohmygod kind
<mjg59> Nothing from me
<cjwatson> I thought it might be worth an explicit check :)
<cjwatson> thanks
<mjg59> Yeah, I forgot about that one because it got downgraded to medium for some reason
<mjg59> Basic problem was just that something we'd ended up pulling in expected the ACPI device semantics from 2.6.21
<cjwatson> it was critical when I first saw it
<mjg59> I bumped it back up yesterday
<cjwatson> kylem: can you arrange for as many people on the team as possible who use sata_nv to try this out?
<kylem> cjwatson, just ping them in #c?
<kylem> or check the hw db?
<cjwatson> #c, #distro, distro-team@
<kylem> yup.
<BenC> I'll have kernels built with this in about 30 minutes
<BenC> i386 and amd64
<kylem> ok
<kylem> BenC, this should be a suitably large hammer for now. I'm going to try and snoop the taskfile and unset ADMA for these commands and submit the patch upstream when i get a bit of free time.
<BenC> kylem: ok
<BenC> kylem, mjg59: thanks for the time...maybe we get a suitable kernel for release
<kylem> heh
<BenC> at least -15.24 is almost done building to free up the buildd's
<BenC> builds started
<cjwatson> let me know when it's ready (by whatever means necessary) and I'll contact Tollef if he isn't around
<cjwatson> so we can make sure it builds on palmer again
<BenC> is palmer the faster machine?
<kylem> BenC, patch hitting your mailbox.
<kylem> alternate fix, reverting that commit is fine too though.
<BenC> I've already got the revert in here and building/preparing :)
<kylem> beauty.
<kylem> i fired the fix upstream since it was so simple to filter.
<BenC> kylem: your fix will filter into gutsy, so for feisty we'll stick with edgy type performance
* kylem nods.
<kylem> BenC, worst case scenario is we fix it right in -updates, with this, everyone should be able to at least boot.
<cjwatson> sounds like the right decision
<kylem> with ben's ignore_hpa patch, if this crops up in another controller we aren't able to test on, we should can at least tell them to disable it to get it installed.
<kylem> but from a cursory glance, i don't think it will be.
<lfittl> kvm, seems broken (kvm-api-9 dependency can't be fulfilled), any time when this will be fixed?
<cjwatson> somebody oughta fix that, I agree; is it just a rebuild?
<cjwatson> * refs/heads/Ubuntu-2.6.20-12.20: fast forward to branch 'Ubuntu-2.6.20-12.20' of git+ssh://rookery/srv/kernel-team/private/ubuntu-feisty old..new: 3ffd70d..3ffd70d
<cjwatson> error: Ref refs/heads/Ubuntu-2.6.20-12.20 is at 3ffd70ddba9d846eefd2d201404ad4c8a99d2899 but expected d02602542ef5ceb2af1765a179a9af6224136afe
<cjwatson> does anyone know what I'm supposed to do about that?
<rtg_> cjwatson: I just edited .git/refs/heads/Ubuntu-2.6.20-12.20 and made it d02602542ef5ceb2af1765a179a9af6224136afe. It was happy after that.
<cjwatson> huh :-)
<cjwatson> nope, two git pulls later and it's unhappy again
<rtg_> cjwatson: Yeah, it does it to me too. Serious git training is something I'm going to extract from Ben and Kyle at UDS so I can understand some of these bizarre problems.
<kylem> we could do a git bootcamp at uds if you wish? i could make slides
<rtg_> Man, I would hug you for that, but it might wig you out :)
<kylem> haha.
<cjwatson> bootcamp> I'd like that, if I have any time
<kylem> i suspect a few other people in the company would like it too
<kylem> i'd like someone to give me a bzr boot-to-the-head heh
<kylem> cjwatson, are any of our bzr team coming?
<cjwatson> not sure, but plenty of distro are very capable with bz
<cjwatson> r
* kylem wants to bug them about the backend too, hehe
<zul> bug or annoy?
<PhinnFort> where can I find a list/download the patches that are applied against the ubuntu kernel?
<PhinnFort> i'm especially interested in the usplash patch
* PhinnFort notices that the special thing about usplash is that it is completely userspace
<PhinnFort> :S
<cjwatson> that's one of the things the "u" stands for, yes :-)
<PhinnFort> :D
<PhinnFort> that means I won't have to worry about ck stepping on other patches' toes
<nott2> have they up loaded the new fix for kernel 2.6.20-14 ?
<cjwatson> 21:10 <cjwatson> -15.24 is in the archive and built everywhere
<cjwatson> 21:11 <cjwatson> except possibly ia64, and if not that's on its way
<cjwatson> 21:11 <cjwatson> -15.24 should work for everyone except people using sata_nv
<cjwatson> 21:11 <cjwatson> for sata_nv, -15.25 has been uploaded
<cjwatson> 21:11 <cjwatson> but it has not yet built
<cjwatson> 21:11 <cjwatson> (in progress, hamsters running as fast as they can)
<cjwatson> 21:12 <cjwatson> so sata_nv users should stay on -13 until -15.25 is available, and everyone else should use -15.24
<cjwatson> 21:12 <cjwatson> and REPORT REGRESSIONS ASAP
<cjwatson> nott2: ^--
<nott2> cjwatson: so the new kernel is uploaded ?
<nott2> got a error "403" from the website when trying to update about hour ago....
<nott2> just try to get a update, nothing YET....
#ubuntu-kernel 2007-04-14
<persia> linux-image-2.6.20-15-lowlatency  2.6.20-15.25 fails to boot on my hardware.  Are there still known issues with drive detection (at which you are all hard at work), or should I file a bug?
<mjg59> Please file a bug, especially if you can reproduce it with the non-lowlatency kernel
<persia> mjg59: OK.  Thanks.
<cjwatson> publishing -15.25/i386 now; ETA half an hour or so
<mjg59> cjwatson: I hope you get to have some sleep soon?
<cjwatson> it's a point of view
<cjwatson> oops, meant to publish d-i source at the same time
<cjwatson> oh well, more runs needed anyway
* ..[topic/#ubuntu-kernel:cjwatson] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded - If you have a BUG, it's too late to get it in for release.
<cjwatson> I kind of need to test alternate/ps3 too which means waiting for d-i to be available
<cjwatson> might do that tomorrow though
<mjg59> cjwatson: You got a work PS3?
<mjg59> Man. I don't get the cool hardware any more.
<cjwatson> it's less cool when you don't have an HDTV
<cjwatson> and have to hook it up to vlc in tiny-resolution mode ;)
<kylem> hehe
<mjg59> You need a work HDTV
<cjwatson> I do
<kylem> me too? :P
<kylem> though i'd rather a 30" dell kthnxbye
<kylem> :)
<cjwatson> -15.25/i386 up and on all archive.ubuntu.com mirrors
<kylem> cjwatson, thanks so much.
<cjwatson> hey, you guys did the real work ...
<mjg59> You're the one awake at 3AM
<cjwatson> now it's just language packs and hotkey-setup and then I can build livefses
<cjwatson> when I've kicked that off I'll almost certainly crash
<cjwatson> won't take all that much longer with three buildds munching on it
<defendguin> mjg59: i think that last kernel update today fixed my issue
<mjg59> defendguin: Excellent
<mjg59> It /should/ fix all of them
<defendguin> i thought yesterday's update was the one with the patch?
<defendguin> mjg59: did something change in hal that made the original update not work properly?
<mjg59> No
<mjg59> But the first upload yesterday may have been missing that line
<defendguin> heh
<defendguin> i remember reading the changes in the update manager and seeing the patch was in.  needless to say i was disappointed when the card didn't work
<cjwatson> http://librarian.launchpad.net/7325843/buildlog_ubuntu-feisty-ia64.linux-source-2.6.20_2.6.20-15.25_FAILEDTOBUILD.txt.gz
<cjwatson> argh!
<cjwatson> -15.24 is there
* cjwatson is kinda tempted to ignore this for release now
<cjwatson> -14 kernels removed
<defendguin> i think you guys cleared up all the issues i had with this laptop being supported under linux this cycle
<cjwatson> BenC: 04:21 <cjwatson> http://librarian.launchpad.net/7325843/buildlog_ubuntu-feisty-ia64.linux-source-2.6.20_2.6.20-15.25_FAILEDTOBUILD.txt.gz
<cjwatson> BenC: I propose to ignore that for release, but FYI
<cjwatson> looks like the ABI-ignore hack failed
<BenC> cjwatson: Yeah, I mentioned earlier, it's fixed in git now that I have the ABIs from -15.24
<BenC> fix it first update
<fabbione> BenC, cjwatson it will still make ia64 uninstallable because of the ABI change in d-i
<fabbione> would be much easier to keep it in sync
<fabbione> oh actually ABI is the same
<fabbione> just version
<fabbione> hmm
<fabbione> yeah
<fabbione> can work
<orangey> hey all!
<orangey> I'm trying to figure out a bug that appears to be a regression in the kernel.
<orangey> the sound on this NC6230 used to work after suspend, but stopped working around the -13 mark?
<orangey> However, I'm honestly not even sure a) if it was intentional that the bug was fixed; or b) how to track down which kernel module broke it.
<crimsun> orangey: boot into the kernel with working suspend; check out upstream hg alsa-{driver,kernel}; execute hgcompile from alsa-driver; install it; confirm that it's still working with current upstream alsa
<orangey> crimsun: stupidly, I wiped the old kernel ; ) I'll remake it and go from there. Thank you.
<defendguin> the hotkey-setup update that got released does it include those bugs mjg59 fixed the other night?
<orangey> crimsun: what do you mean by hg alsa-driver ?
<defendguin> i remember BenC said they could be included 
<defendguin> orangey: do you know how i can view the changelog of the hotkey-setup update?
<crimsun> defendguin: https://lists.ubuntu.com/archives/feisty-changes/2007-April/008524.html
<crimsun> defendguin: also, https://lists.ubuntu.com/archives/feisty-changes/2007-April/008483.html
<defendguin> perfect
<defendguin> i just wanted to make sure i didn't screw it up with the update :-)
<crimsun> orangey: what's unclear?
<crimsun> orangey: also, this discussion is veering into support instead of development. Contact me in #ubuntu+1 if you have further questions.
<defendguin> thanks crimsun
<orangey> crimsun: pretty much the whole workflow. upstream hg alsa-driver ? I'm actually not sure what that is, other than that possibly I should get the deb from debian unstable and install it or some such..
<orangey> crimsun: I'm on +1 now.
<Mithrandir> zul: have you gotten a new packages exception for openvz?
<kylem> heh, it's 3am for him.
<Mithrandir> sleep is for the weak
<joejaxx> :P
<kylem> weak from exhaustion, yes.
<joejaxx> so openvz is going to be in the archive?
<joejaxx> or might*
<Mithrandir> joejaxx: I didn't say that.
* ajmitch would guess he hasn't got an exception - first I've heard of it
<_ion> benc: linux-source-.../debian/firmware/ipw2200/LICENSE says "Your rights to redistribute the Software shall be contingent upon your installation of this Agreement in its entirety in the same directory as the Software". Should the license be installed to /lib/firmware/...?
<_ion> Also, considering the limitations the license seems to put to the redistribution of the firmware, would restricted be a better place for it? I might be wrong, i didn't read the license carefully.
<afflux> I installed the kernelupdated to 2.6.20-14.23 yesterday, which broke my system (something with ata)... but I removed the older kernels that were still installed for cleaning up.
<afflux> now i'm in a livecd
<afflux> chrooted into feisty and updated to -15.25
<afflux> and I still have the same ata error (revalidation failed, n_sectors mismatch)
<bdgraue> same here updated and now   http://www.ubuntuusers.de/paste/9217/
<afflux> another confirmation here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063/comments/80
<bdgraue> if someone need more specific, please ask---
<heno> I expect the kernel devs are still asleep, but please hang around until they return
<heno> BenC, kylem, mjg59: ^ still problems with 15.25 it seems
<cjwatson> bdgraue: could you try putting libata.ignore_hpa=0 on the kernel command line, please?
<cjwatson> afflux: you too
<afflux> going to have a try, will be back in about 10-20 minutes
<bdgraue> cjwatson: ok, i'll try, moment please
<cjwatson> if that works, dmesg and lspci -vvnn would be greatly appreciated
<cjwatson> possibly a new bug each to avoid confusion
* cjwatson <- not a kernel developer, merely a manager of kernel developers, but since most of them are asleep right now ...
<cjwatson> http://librarian.launchpad.net/7329378/00001.jpg is interesting, definitely suggests libata.ignore_hpa=0 should work, but seems to be applying the wrong hpa_sectors size
<afflux> doesn't work for me
<afflux> going to have a shower, will be back in 20 mins
<cjwatson> a photo of the error would be good
<bdgraue> cjwatson: doesn't work for me too
<cjwatson> just to be clear, http://www.ubuntuusers.de/paste/9217/ is just a consequence, not the real error
<cjwatson> we need the sort of ata debugging messages you see in http://librarian.launchpad.net/7329378/00001.jpg
<cjwatson> might have to boot without 'quiet' on the kernel command line to get that
<cjwatson> probably without 'splash' too
<ivoks_> could 'debug' help?
<cjwatson> no
<cjwatson> looks like the module parameter stuff isn't working right :-/
<cjwatson> lspci -vvnn from a live CD might help
<bdgraue> cjwatson: i'll give u the photo 
<bdgraue> gimme some time please :-)
<cjwatson> kylem: why don't the ata_set_native_max_address* functions set ATA_TFLAG_LBA?
<cjwatson> (not sure if that's relevant though)
<afflux> cjwatson: http://phpfi.com/226658
<afflux> cjwatson: will make a photo later
<bdgraue> cjwatson: lspci -wnn give me an   lspci: invalid option --  w
<afflux> bdgraue: twice a v, not a w please
<cjwatson> lspci -vvnn
<cjwatson> ok, afflux is using sata_nv
<bdgraue> cjwatson: http://img383.imageshack.us/img383/5466/pict0002cs9.jpg  there is the photo
* cjwatson has to go out now; if you could hang around until actual kernel developers show up, that'd be good
<afflux> i'll leave in 30 mins too...
<mrec> hi, I'm really curious I upgraded my notebook to ubuntu, also recompiled the kernel but it's not possible to start Xgl the whole screen just starts to flicker around ... so I guess the livecd includes some specials for that device?
<cjwatson> bdgraue: hmm, there don't appear to be any of the hpa handling messages I was expecting; that just looks like normal boot
<cjwatson> possibly you have enough disks that it scrolls off
<bdgraue> cjwatson: so whats then the problem?
<bdgraue> cjwatson: the cdrom-drives are ide
<bdgraue> cjwatson:  http://www.ubuntuusers.de/paste/9222/   hte lspci -vvnn
<mrec> is there any documentation about the ubuntu i855gm setup available? for any reason I suspect that some intel engineers did some specials there
<cjwatson> bdgraue: like I say, I'm not a kernel developer, I'm just trying to gather as much information as possible
<cjwatson> the problem for afflux is that the HPA suppression logic appears to be setting the drive size to the wrong value on NVIDIA ATA chipsets
<bdgraue> i hope my informations could help to solve the problem
<cjwatson> it's not entirely clear that yours is the same problem, although you're also using NVIDIA
<cjwatson> haven't heard any concrete non-NVIDIA reports yet
<bdgraue> cjwatson: an other photo is here:  http://img150.imageshack.us/my.php?image=pict0004gr3.jpg
<cjwatson> kylem: converting the sector counts to hex in http://librarian.launchpad.net/7329378/00001.jpg is very interesting
<cjwatson> kylem: it's 0x0D00000E instead of 0x0DF94BB0, and 0x2E00002F instead of 0x2E9390B0
<cjwatson> seems like an obvious pattern
<mjg59> mrec: No, we don't have any special 855 code
<cjwatson> bdgraue: thanks, that's more useful
<cjwatson> that's exhibiting the same pattern of corruption
<mrec> I see, I booted from the CD and started the local X, I have the same effects
<cjwatson> 0x1D1C5970 -> 0x1D00001E
<mrec> seems like the upgrade wasn't clean
<cjwatson> looks like sata_nv is very consistently buggering the sector count
<cjwatson> bdgraue: could you try booting with sata_nv.adma=0 on the kernel command line?
<bdgraue> i can
<bdgraue> mom please
<bdgraue> cjwatson: don't work
<cjwatson> hmm, what exactly was your kernel command line?
<bdgraue> mom
<cjwatson> and could you take photos of the output with hpa messages in it again? I'd like to confirm that it's the same problem
<mrec> ok I manually removed the xorg directories and reinstalled them, now it seems to work
<bdgraue> cjwatson:  kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=01b05012-0b6d-4ac6-8c72-cb146fd64f9f ro locale=de_DE sata_nv.adma=0
<mjg59> cjwatson: sata_nv and libata are modules - do we have sensible code in initramfs-tools to deal with that? (I remember it being wishlist, I don't remember whether we did or not)
<bdgraue> cjwatson: http://img219.imageshack.us/my.php?image=pict0007ro7.jpg
<mjg59> That's very weird.
<Nafallo> with -15 everything is sd?. thanks :-)
<mjg59> cjwatson: Exactly the same pattern with bdgraue's drive
<mjg59> Something's squashing most of the bits
<bdgraue> i wish i had an older kernel left on the sys  :-(
<mjg59> (Oh, sorry, you'd already commented on that)
<bdgraue> :-)
<Mithrandir> ah
<cjwatson> mjg59: initramfs-tools> I'm not sure
<cjwatson> bdgraue: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/2.6.20-14.22 - "Builds of" drop-down in the top-left, you can get old packages from that
<cjwatson> mjg59: can you tell whether it's sata_nv or pata_amd in use? I couldn't quite tell
<cjwatson> I think it's sata_nv in bdgraue's case at least
<cjwatson> BenC: could you push the various -15 git branches?
<cjwatson> mjg59: I don't quite know how module options work. What would initramfs-tools need to do?
<cjwatson> mjg59: the way that the top three bytes are being consistently copied to the bottom three bytes (kernel code then adds one to it) is particularly suspicious
<cjwatson> I'm assuming it's LBA48 since at least some of the sizes in question exceed 28 bits
<Mithrandir> it says "lba48" in the screenshot too
<Mithrandir> shouldn't there be a 0x0f masking in the set_native_max_address_ext?  That bit looks suspicious.
<cjwatson> Mithrandir: where?
<Mithrandir> libata-core.c
<cjwatson> no I mean where 0x0f
<Mithrandir> tf.lbah = new_sectors, etc
<Mithrandir> I thought lbah would only get four of the bits set there?
<Mithrandir> or is lba48 sane?
<cjwatson> Mithrandir: the reason set_native_max_address has a 0x0f mask is because it's the top 4 bits of the LBA28
<cjwatson> but LBA48 divides exactly by 8
<Mithrandir> ok, false alarm then.
<cjwatson> I still very strongly suspect adma here
<cjwatson> quite tempted to build a kernel with adma disabled
<cjwatson> in fact, yeah, why don't I kick that off on ronne
<Mithrandir> try that, then?  You have the ccache from yesterday, so it should be fast enough?
* Mithrandir goes out for a little bit.
<cjwatson> I'm not sure it was ccached unfortunately
<cjwatson> one build shouldn't take all that long even from scratch though
* cjwatson looks suspiciously at nv_adma_tf_to_cpb
<bdgraue> cjwatson: hoe can i get the old kernel in the chrooted system?
<bdgraue> how
<cjwatson> get => download or get => install?
<bdgraue> download and install with dpkg or something else or install via apt if possible, cjwatson
<cjwatson> find URL, use wget to fetch it, dpkg -i
<bdgraue> ok, thx
<cjwatson> bdgraue: would you be able to help out with testing unofficial fixes at some later point?
<mrec> hmm I noticed that ubuntu feisty doesn't support the highest resolution on my notebook, how about trying to detect the notebook and patching the bios to get it work?
<bdgraue> cjwatson: if i have time, yes
<mrec> (I tested it with the temporary biospatch, and it seems to work fine.. and it looks way better)
<bdgraue> i would be an honor to help
<cjwatson> I'm still trying to figure out what the hell's going on, and I'm planning to be out this afternoon
<cjwatson> kylem may stand a better chance once he wakes up
<bdgraue> 3 ours from now i have to go... then i have no more time :-(
<bdgraue> then only tomorrow
<bdgraue> cjwatson: do i have to install some of the modules too, or only image and headers?
<bdgraue> from the older kernel...
<cjwatson> bdgraue: just the image, and you may need to go and hunt down a matching linux-restricted-modules too if you rely on non-free video drivers or whatever
<bdgraue> hunt down a matching linux-restricted-modules?
<bdgraue> cjwatson: what does that mean, i have to find one, somewhere?
<bdgraue_> cjwatson: thx, i have the old 2.6.20-14.22 running
<kylem> cjwatson, test kernel building
<cjwatson> kylem: cool, what are you trying?
<kylem> cjwatson, what you pointed out above (setting TFLAG_LBA)
<cjwatson> ok
<cjwatson> I've got a build running that turns off adma
<cjwatson> (in sata_nv)
<kylem> we're still seeing issues there?
<kylem> the only bug i saw in my mbox in this dumping was the dude lying about running 15.25 :/
<cjwatson> kylem: yes, consistently with sata_nv
<kylem> bug#?
<cjwatson> something is blatting the high-order-bytes of the LBA48 over the top of the low-order three bytes
<cjwatson> er dunno about a bug number, but see e.g. http://librarian.launchpad.net/7329378/00001.jpg
<kylem> ok.
<cjwatson> it's all in scrollback here
<cjwatson> there was another example as well - in both cases LBA48 0000AABBCCDD was transformed into 0000AA0000AA (+1)
<cjwatson> in the middle of ata_exec_internal so presumably by the driver
<kylem> hm, ok.
<cjwatson> I've only heard of it with nv so far
<cjwatson> but I'm not fully up to date on bugs
<kylem> ergh.
<cjwatson> I also think module options passed on the kernel command line just plain don't work in feisty
<cjwatson> damnit, my build failed for no obvious reason
<cjwatson> + xargs strip --strip-debug
<cjwatson> make[1] : *** [install/linux-image-2.6.20-15-generic]  Error 1
<cjwatson> + xargs strip --strip-debug
<cjwatson> make[1] : *** [install/linux-image-2.6.20-15-generic]  Error 1
<cjwatson> (sorry for dup)
<cjwatson> ok, screw this, I'm going out. call me if it's urgent
<Aikurn> hi
<BenC> kylem: do we have an issue with -15.25?
<BenC> still reading scrollback
<kylem> looks like it
<kylem> and it looks like libata.ignore_hpa isn't making it to the module in some cases.
<BenC> how does the kernel handle cmdline opts to modules?
<kylem> no clue. it didn't change.
<BenC> I thought module.XXX would only work for built in modules
<Mithrandir> that was fixed in 2.6, AIUI.
<kylem> i thought the modprobe handled it by inspecting /proc/cmdline
<Mithrandir> at least I remember rlove and rusty claiming so at LCA 2004 during the kernel hacking tutorial.
<BenC> Module parameters for modules that are built into the kernel image
<BenC> are specified on the kernel command line with the module name plus
<BenC> '.' plus parameter name, with '=' and value if appropriate, such as:
<BenC> I don't think cmdline for actual modules is supported
<BenC> It used to be you couldn't pass options to built-in modules, and that's probably what they fixed
<kylem> there's more than two ways you can do it, i have no idea how universally stupid it is if they haven't implemented it.
<BenC> kylem: so what's the extent of this bug?
<kylem> BenC, some controllers (nv apparently?) are reporting bogus sizes back from ata_set_max_address{,_ext}
<BenC> what's with these 1Meg HPAs
<kylem> appears to be fairly common on sata disks.
<BenC> it's weird, the size shows in "native size increased" is not the same size as the one read in ata_hpa_resize
<BenC> which means it's not the one set in n_sectors_boot
<kylem> the native sized increased size is the one returned value read out of the taskfile
<BenC> whatever size it was increased to is the one we need to put in n_sectors_boot
<BenC> then we need to use that value to store the n_sectors_boot
<BenC> err, I mean the n_sectors
<kylem> not until we figure out why it's all friggity fucked.
<BenC> Not sure why we are getting a different result than what we ask for
<BenC> kylem: maybe we should fail to change n_sectors if the results for the set isn't what we asked for?
<kylem> colin pointed out that the code wasn't setting ATA_TFLAG_LBA
<kylem> in set_max
<BenC> I thought you said that was ok because of 0x40?
<kylem> i know.
<BenC> worth a try I guess
<BenC> I wish I had a drive with HPA to test this better
<kylem> my guess is that some of the taskfile dispatch paths are setting it, and some aren't depending on the value in that field
<kylem> which is why it works fine on so many systems
<BenC> well the set obvious works...the n_sectors mismatch shows that ata_id_n_sectors() is returning the value of the size we did in set
<kylem> yeah.
<BenC> kylem: Is it ever possible that if our set succeeds we should get a different value that what we asked it to set?
<BenC> or I mean, should it be possible
<BenC> can we assume that since the set succeeds, and from these reports we can see that it succeeds, could we just set n_sectors to the value we set instead of relying on this return value?
<Mithrandir> ew
<BenC> assuming this TFLAG_LBA doesn't work
<Mithrandir> that sounds risky.
<kylem> i don't think so, perhaps we should set it to the value in ata_id_n_sectors afterwards
<BenC> kylem: Does that get updated immediately?
<kylem> aside from setting the max sectors limit, that's all that really changes
<kylem> yes
<BenC> then that might be best
<BenC> the only thing we've seen not to be reliable so far is the return value from the set call...it seems we can definitely rely on everything else
<kylem> yeah, the 0x40 definitely is the bit needing set unless some deeper bit is unsetting it based on the value of tf->flags
<BenC> I don't like it, but it may be the way to go, if we can't find the problem with the return value of set
<kylem> oh.
<kylem> we have to re-identify the drive of course.
<kylem> since the id is cached.
<kylem> that's why we used the return value.
<BenC> that's what I thought....else the whole n_sectors_boot thing is pretty bogus :)
<BenC> what's the call to id the drive?
<kylem>                 rc = ata_dev_read_id(dev, &dev->class, ATA_READID_POSTRESET,
<kylem>                                      dev->id);
<kylem> builds almost done (concurrently for i386 and amd64)
<BenC> Do we have testers?
* heno tries to round up some testers in the Feisty section of the forums
<trejack> I was told to check in here if I was having problems with the 2.6.20-15 kernel
<BenC> only if it's -15.25
<trejack> It is
<lazka> me2..
<BenC> cat /proc/version_signature
<BenC> or dpkg -l linux-image-2.6.20-15-generic
<sertmann> heya, just responding to a call for sata_nv users with 2.6.20-15 kernel problems come here
<trejack> ii  linux-image-2. 2.6.20-15.25   Linux kernel image for version 2.6.20 on x86
<kylem> amd64 or i386?
<BenC> what's the problems you are having?
<sertmann> amd64
<trejack> Haven't been able to boot since upgrade from -13 to -14
<sertmann> ditto
<BenC> do you have screenshots of the problems so we can make sure it is the same thing?
<sertmann> well, i can boot into the -13 kernel still
<BenC> or maybe gain more info?
<heno> sertmann: do you have the latest -15.25?
<trejack> Get ata2.00:qc timeout(cmd0xef)
<BenC> trejack: is this macbook?
<sertmann> the latest one available from apt anyway
<trejack> Then ata 2.00: failed to set xfermode (err_mask=0x4)
<lazka> do you guys need anyone with "failed to set xfermode"? no nv_whatever here :P
<trejack> No its ASUS P5NSLI
<BenC> sertmann: please make sure it is -15.25, so we don't waste time on a bug that may already be fixed
<trejack> Finally get to busybox shell
<sertmann> BenC: that's what it says menu.lst anyway
<trejack> sda and sdb are listed in /dev
<trejack> but not sda1,sda2,etc
<BenC> sertmann: menu.lst shows -15, it doesn't say it's -15.24 or -15.25
<BenC> sertmann: please check, it's very important
<sertmann> transcribed this from recovery mode: from https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063/comments/88
<sertmann> /boot/initrd.img-2.6.20-15-generic
<sertmann> how do i check the exact version?
<BenC> sertmann: I gave you two commands already :/
<BenC> sertmann: dpkg -l linux-image-2.6.20-15-generic
<trejack> my drives are ide, not SATA, but motherboard does have SATA controllers.
<sertmann> BenC: from that output it does look installed, it lists it anyway
<BenC> sertmann: can you paste it please
<BenC> sertmann: I need to see the version, not whether it is installed or not
<sertmann> Desired=Unknown/Install/Remove/Purge/Hold
<sertmann> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
<sertmann> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
<sertmann> ||/ Name           Version        Description
<sertmann> +++-==============-==============-============================================
<sertmann> ii  linux-image-2. 2.6.20-15.25   Linux kernel image for version 2.6.20 on x
<BenC> ok, that's the info we needed
<BenC> thanks, so you have the latest and are still having problems
<sertmann> yes
<trejack> yes
<BenC> can you guys pastebin dmesg from the last kernel that worked for you
<BenC> and also your lspci -vvn output
<kylem> http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.25_amd64.deb
<BenC> that's for anyone having "mismatch" messages in your dmesg
<BenC> please test kyle's images
<trejack> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106418 has it the dmesg, hang on while I do lspci
<heno> sertmann: see http://paste.ubuntu-nl.org/
<BenC> trejack: please test kyle's kernel image(s)
<sertmann> http://paste.ubuntu-nl.org/15606/
<felip1> i have a sata_nv controller in this box, but it's not used, and my ide hd are being seen as sd*
<BenC> felip1: then you don't have a bug
<felip1> ok BenC :)
<Nafallo> I wish I had a SATA so I could help debugging :-)
<felip1> except my feisty isn't booting
<trejack> http://paste.ubuntu-nl.org/15607/ for my lspci
<sertmann> bah, lspci output is to long for the terminal
<sertmann> should i just paste the lines i do get?
<BenC> felip1: then let's get down to the real bug
<felip1> BenC: do you already know of any issues with edgy->feisty and non-sata hd? 
<BenC> felip1: if your drives show up, why aren't they mounting
<trejack> BenC: I'm not using amd64, try it anyway?
<heno> sertmann: send it to a text file with > output.txt
<kylem> trejack, no
<BenC> felip1: does your root= in /boot/grub/menu.lst shows /dev/... or UUID=...?
<kylem> http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.25_i386.deb
<BenC> trejack: No, use the one kyle just pasted
<felip1> BenC: UUID
<kylem> trejack, ^-- i386 image is there
<trejack> OK - I'll report back
<BenC> felip1: does your /etc/fstab reference any /dev/hdX devices?
<felip1> uhm good point, i guess so... let me check ;)
<BenC> felip1: they should use UUID= as well
<felip1> yes theys are
<BenC> sertmann: lspci -vvn > lspci.txt, and post that
<sertmann> got it here: http://paste.ubuntu-nl.org/15608/
<mdz> BenC: how are we doing?
<BenC> sertmann: Please try kyle's images
<mdz> I've just had to spend the past several hours buying a new laptop because mine has quit
<felip1> BenC: they use UUID in fact
<BenC> felip1: Boot to recovery mode and see if you can get a digital photo of the final screen
<felip1> BenC: ok 
<Nafallo> mdz: white smoke and blue flames? :-)
<Nafallo> mine did, was kind of scary :-P
<sertmann> ok; downloading now
<mdz> no, the display is failing
<Nafallo> ouch
<BenC> mdz: we are chasing more sata_nv bugs :/
<BenC> mdz: I'm almost to the point of saying that sata_nv just doesn't get hpa resize rights
<kylem> heh, it's *not* the driver
<kylem> that's not how these things work...
<BenC> it's the controller that is giving us bogus info during hpa workaround
<BenC> kylem: http://people.ubuntu.com/~bcollins/libata.diff
<BenC> that's my initial patch for updating id and using it to get the set size
<BenC> I actually like it better than what we have now because it detects these sorts of problems and reports them and continues along happily
<trejack> kyle's kernel gave me same problems
<kylem> trejack, are you booted into the machine now?
<BenC> in these cases it will either ignore hpa, or will resort to the original sectors
<trejack> Package installer said I already had same version installed, but I installed it anyway
<BenC> I'll do some builds with this patch
<kylem> trejack, edit /etc/modprobe.d/options and append the line "options sata_nv adma=0"
<BenC> trejack: the installer was right, but that's not what matters
<kylem> trejack, and try again please.
<trejack> Yes, booted int -13
<kylem> trejack, is your disk sata or pata btw?
<trejack> pata
<kylem> alright.
<trejack> I'll try the modprobe thing and report back
* kylem goes to look in his closet for a pata disk
<BenC> kylem: you forgot to tell him to run update-initramfs :)
<kylem> doh.
<Nafallo> haha
<Nafallo> BenC: you just had to wait until he rebooted ;-)
<Nafallo> aha. sata_nv and pata_amd :-)
<Nafallo> that explain things :-)
<BenC> BTW, anyone here helping to track down these problems, we really appreciate your time
<BenC> if we sound short, or aggrevated, it's only because we've been chasing problems for 3 days now, and we're delaying RC/release because of them
<BenC> well RC for sure, don't know about release
<kylem> pretty much 3 straight days... there's not been much sleep. :P
<Nafallo> kylem, BenC: you guys rock! :-)
<sertmann> Kylem's kernel didn't work for me either..
<BenC> ok, hold up for a few minutes, I have a kernel building to test
<kylem> sertmann, you're also sata_nv? i forgot to tell you to update-initramfs :/
<sertmann> yeah, im on sata_nv
<sertmann> update-initramfs -k ?
<sertmann> or what option?
<Nafallo> -k 2.6.20-15 -u
<Nafallo> right?
<sertmann> yeah...
<sertmann> so ill try that and reboot
<sertmann> Cannot find /lib/modules/2.6.20-15 <-- eh?
<BenC> sudo update-initramfs -u
<BenC> that'll do it
<trejack> Still same after editing modprobe.d/options
<kylem> trejack, sorry, forgot to tell you to sudo update-initramfs -u
<BenC> trejack: try "options libata ignore_hpa=0"
<kylem> so it didn't take effect
<BenC> oh, and that :)
<trejack> removed added line now
<BenC> trejack: no no, do the adma line, but run update-initramfs -u then reboot
<trejack> where to I put the options libata ignore_hpa ?  In the same options file (someone suggested I do this earlier, & I couldn't figure it out...)
<BenC> trejack: try that after just adma
<BenC> one at a time so we know which one works
<trejack> OK, give me the adma line again, I deleted it.
<trejack> I'll do it first, then the libata
<BenC> options sata_nv adma=0
<BenC> Then sudo update-initramfs -u
<BenC> then reboot
<trejack> got it. thanks
<sertmann> back, that didn't do it either :-/
<sertmann> so let me know when the new build is done :)
<BenC> should be 20-30 minutes, so if you have a southpark episode to catch up on, now's a good time :)
<Mithrandir> BenC: if you want me to build anything, I have machines which are a) bored and b) eight-core amd64.
<Nafallo> hehe
<kylem> tell elmo to buy a few of those...
<BenC> Mithrandir: I'm doing the builds on 2xquad-core right now with ccache, so it should be quick
<Mithrandir> yes, they have primed ccaches too. :-P
<macd> unf. unf.
<BenC> Mithrandir: ah, ok, I'll keep that in mind :)
<Mithrandir> but your machine appears to be of the same class, so I'll leave it to you fttb.
<BenC> I need to add linux-debug and linux-headers to the list of things not to build when NOEXTRAS=1
<Mithrandir> yes, for gutsy. :-)
<Nafallo> hehe
<kylem> Mithrandir, wuss. ;-P
<Nafallo> I'm still trying to get used to my new world the next six months ;-)
<sertmann> btw, out of curiosity, why am i having issues with a SATA controller drivers, when I'm on a ATA disk? 
<john_brown_jr> Hi guys, i'm still having problems with 15.25 kernel - it spits out something about ata sectors mismatch. Is there anything I can do to help you to debug?
<kylem> because clearly i was a bad man in a past life.
<BenC> john_brown_jr: stick around, there's a new kernel building for testing
<john_brown_jr> okey
<BenC> kylem: a past life?
<kylem> BenC, this is a bad bear
<BenC> ok, this is a good bear
* kylem cracks up.
<BenC> lol
<defendguin> bear?
<kylem> inside joke from our allhands meeting this year
<BenC> defendguin: your sanity depends on you not pursuing this further
<kylem> s/this/last/
<defendguin> lol
<defendguin> you guys all done bug fixing for this release?
<BenC> unfortunately, no
<kylem> mostly it's regressions now.
<kylem>            ^- severe
<BenC> I think this patch will work around them nicely, let's just hope it doesn't introduce new ones
<BenC> wonder if pitti and dholbach are around
<kylem> this HPA shit is fucking tetchy.
<defendguin> bummer
<kylem> it took me a long time to get it to work properly.
<defendguin> anyone else here having problems returning from suspend?
<defendguin> at some between now and herd 3's release my touchpad stopped working when returing from suspend
<defendguin> s/returing/returning 
<capiira> hi
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging sata_nv and HPA related problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Test kernels coming shortly, will be posted here.
<trejack> Still nothing
<dorath> Hello, I saw a post from Henrik on ubuntuforums asking people who had problems with 2.6.20-15 to come here.  I've had such problems.
<BenC> trejack: the ignore_hpa=0 didn't work for you?
<trejack> I tried sata_nv adma=0, then update-initramfs
<BenC> trejack: just hang a second till I get this test kernel built
<BenC> trejack: you can remove that line now
<trejack> then libata ignore_hpa=0, then update-initramfs
<kylem> you included the "options " part too, right?
<trejack> yes
<trejack> sorry bout the shorthand
<kylem> ok.
<trejack> should I remove the sata line also?
<capiira> hmm do i need to do something special to compile the kernels that comes with diff.gz extra? the orig one get auto patched but i always get a build make error on final
<defendguin> hehe i guess i'll drop my current problem for the time being :-P
<BenC> capiira: right now we are working on some serious issues with the kernel, please take general questions like that to #ubuntu
<mdz> BenC: does someone on staff have access to sata_nv hardware?
<BenC> mdz: Kyle and I both
<mdz> oh, good
<capiira> ok :) no problem
<BenC> but neither of us has an HPA drive
<kylem> neither do these people
<mdz> well
<kylem> (some of these)
<BenC> some of them do, they have a 1Meg HPA :)
<mdz> as it happens, I just bought this new laptop, and I bet it has one
<mdz> but I don't think that helps
<kylem> BenC, do you have a pata disk you could toss onto the pata_amd controller?
<kylem> i don't appear to have *any* ide disks left alive :/
<BenC> mdz: if it has an hpa then you may have inadvertently volunteered for testing :)
<mdz> the vmware server here use sata_nv
<mdz> BenC: I don't think I have the necessary hardware to plug the laptop HDD into the sata_nv box though
<BenC> ah, I thought you meant the laptop had sata_nv
<mdz> laptop has HPA, server has sata_nv
<BenC> kylem: I have a 20G drive on my pata_amd already :/
<BenC> and it works just fine
<BenC> it's my rootfs...the 300G sata is a data partition
<kylem> ok.
<kylem> good datapoint then.
<mdz> is there anything I can do to assist with tracking down the problem?
<BenC> builds almost done
<BenC> mdz: Test boot the kernels when I get them done
<BenC> mdz: we have about half a dozen people in here that are having the problem, but it'd be nice to know we don't regress anything too
<mdz> this box is running Dapper, but I guess I can swap the kernel onto a live cd
<kylem> BenC, it's worth mentioning that drivers/ide just slurps the return value out of the taskfile.
<BenC> kylem: yeah, I've seen that...
<BenC> kylem: My patch doesn't ignore the return value, it just uses it to sanity check with what we wanted, what it returned and what the value is after re-id
<kylem> yeah.
<kylem> maybe we should just revert to drivers/ide and let fedora deal with this in two months...
<Nafallo> joy.
<Nafallo> kernel just crasched.
<Nafallo> http://paste.ubuntu-nl.org/15625/
<mdz> Nafallo: you're using ipv6?
<BenC> 571f6b2b29d01c3572d43a8058af1e9f  linux-image-2.6.20-15-generic_2.6.20-15.25_amd64.deb
<BenC> b9c8608567b386aecb4e94378da244c4  linux-image-2.6.20-15-generic_2.6.20-15.25_i386.deb
<Nafallo> mdz: yes
<BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> Everyone please try those kernels
<mdz> BenC: are you sure those are  finished uploading?
<Nafallo> BenC: for my bug to? :-)
<BenC> if it succeeds, pastebin dmesg so we can sanity check, please
<BenC> mdz: yes
<BenC> wait no, i386 still uploading
<mdz> it was only 9M when I downloaded it, and different md5sum
<BenC> 40 seconds till complete, sorry
<_ion> You can wget already, just use -c and rerun it when it finishes. :-)
<BenC> done
<BenC> please remember to boot WITHOUT quiet and splash on the kernel command line
<BenC> so if it fails you can get an immediate look at why
<trejack> downloading now
<sertmann> any commands I/We need to do after/before installing this?
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging sata_nv and HPA related problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Test kernels: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> sertmann: just dpkg -i, and reboot
<sertmann> oki
<BenC> remove _any_ modprobe.d options you've added before dpkg -i
<BenC> so we get a clean test
<_ion> benc: I don't have anything sata_nv or HPA and the current kernel in feisty works correctly. Should i test the kernel, too?
<sertmann> sorry, i hate to be useless, but i've no clue as how to that :/
<BenC> _ion: yes please, so we get regression testing
<_ion> benc: Alright.
<kylem> _ion, yes, we don't ... what ben said
<BenC> sertmann: how to do what?
<mdz> BenC: what's changed relative to current feisty? just sata_nv? or does this need regression testing on other hardware as well?
<sertmann> BenC: remove _any_ modprobe.d options you've added
<BenC> mdz: I added some sanity checks in ata_hpa_resize() so it's all devices
<mdz> ok
<mdz> I'm doing an install on the new laptop and will test once that's done
<BenC> sertmann: did you add any options to /etc/modprobe.d/? If not, ignore that part
<BenC> mdz: thanks
<sertmann> ok:)
<_ion> benc: Did you see the question about the ipw2200 firmware, btw?
<macd> BenC, http://people.ubuntu.com/~bcollins/kernels/feisty-release/linux-image-2.6.20-15-generic_2.6.20-15.25_i386.deb  works fine on sata_vs nvidia nforce2 chipset FYI.
<macd> sata_nv*
<BenC> macd: did you have a problem prior to that?
<macd> yes, 2 days ago.
<BenC> macd: does the -15.25 in the archive work for you?
<macd> I think that box is on its last leg, but I can grab the last kern.log and dmesg's from each boot
<macd> I can't get the one from the repos, I'm still getting a 403, the proxy here is horrible with expiry
<macd> so Im not even getting an apt-get update properly atm.
<kylem> BenC, appears to work here.
<BenC> macd: Ok, thanks for the report, but if you could verify (when possible) that the -15.25 in the archive does or doesn't work for you, I'd appreciate it
<macd> BenC, sure, you want me to leave that on LP?
<macd> ^if your not around
<BenC> macd: just ping kyle or myself here
<macd> k.
<BenC> Anyone else getting ready to test this, please tell me if -15.25 in the archive worked or didn't work for you when posting about the -15.25 I have built
<macd> Is the kernel in the repos on the daily iso build?
<BenC> macd: should be
<BenC> check the date, if it's older than 12 hours, probably not
<Mithrandir> macd: it is, yes.
<Mithrandir> on the 20070414 isos
<macd> yeah I just peeped it, thx.
<macd> I think all my domU's use sata_nv
<FelipeLerena> hi, I have the sata_nv problem. can anybody help me?
<BenC> FelipeLerena: topic
<FelipeLerena> BenC: oh, i'm really sorry. Didn't see it.
<ahirreddy> Just installed the -15.25 kernel up from -12. I have sata_nv, and nforce 400 chip set 
<BenC> ahirreddy: topic
<ahirreddy> I can't boot up
<ahirreddy> What is the latest stable kernel i can use
<BenC> ahirreddy: can you boot to an older kernel?
<ahirreddy> yes
<BenC> ahirreddy: use the kernel in the topic
<ahirreddy> what would that be?
<BenC> the one marked "Test kernel" right after describing the sata_nv problems
<ahirreddy> you mean boot in to -15.25
<ahirreddy> thanks
<ahirreddy> i'll do that and be back
<BenC> I mean boot the kernel you download from the URL in the topic
<ahirreddy> is it available in generic
<_ion> benc: Seems to work fine, http://johan.kiviniemi.name/tmp/dmesg.2.6.20-15-generic
<ahirreddy> I have an x2 and need smp
<BenC> ahirreddy: going to the link will review answers to your questions
<BenC> s/review/reveal/
<BenC> _ion: but you didn't have a problem before, right?
<BenC> _ion: so it just doesn't break anything new?
<_ion> benc: Nope, had no problem at all earlier.
<BenC> _ion: ok, thanks
<BenC> sertmann: success, failure?
<sertmann> not working for me
<BenC> sertmann: screen shot?
<trejack> Still no luck here, but different error messages at the end this time - see the pic uploaded at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106418
<BenC> sertmann: or at least copy the output you see
<sertmann> took one with my camera phone, can't read the text, so im looking for a usb wire for my digital camera
<sertmann> just hold on
<ahirreddy> how long until the fixes get integrated in to the one in the main repo
<BenC> sertmann: ok, thanks
<BenC> ahirreddy: never if we don't get testing
<ahirreddy> cool
<BenC> it's a test kernel, which means we don't know if it fixes the problem or not
<ahirreddy> i see,
<ahirreddy> does anyone know what the exact changes are
<trejack> BenC: do you want me to try the modprobe options with this kernel?
<BenC> trejack: I'm really only interested in getting this fixed without additional options, but you can try the "options libata ignore_hpa=0"
<BenC> kylem: looks like the re-id might be causing some foobar...
<BenC> http://librarian.launchpad.net/7330784/IMG_2979.JPG
<BenC> hard to tell with that run-off
<john_brown_jr> applied the new kernel (simply clicked on deb file and chose to overwrite) - still does not boot. screenshot - http://librarian.launchpad.net/7329378/00001.jpg
<kylem> BenC, i was afraid of that.
<kylem> the state machine probably isn't expecting it
<BenC> john_brown_jr: are you sure you are booting the new kernel?
<BenC> there's some expected output there that I don't see
<BenC> actually, no you aren't
<BenC> I'm sure of that
<BenC> john_brown_jr: download the .deb to disk, and run "sudo dpkg -i linux-image-2.6.20-15-generic_*.deb"
<john_brown_jr> well, yes, the errors were so similar (to me) that I pointed to the old screenshot. should I take a new one?
<john_brown_jr> (sorry )
<BenC> john_brown_jr: yes
<trejack> http://librarian.launchpad.net/7330784/IMG_2979.JPG
<BenC> trejack: eventually you should get to a busybox prompt (3 minute wait), do you have a USB disk/keychain?
<trejack> sorry dropped out by mistake
<trejack> yes picture is just before it dropped into busybox
<BenC> trejack: If so, can you (at the busbox prompt), mount the usb drive, and dd if=/proc/kmsg of=/mnt/dmesg.txt bs=1 &
<trejack> I do have a USB disk
<BenC> then unplug the device, and get me that file after rebooting
<BenC> wait about 10 seconds before unplugging
<trejack> Ok.  (scrambling for drive, writing down commands)
<BenC> trejack: thanks
<ivoks> BenC: fwiw, today's cd image works in qemu (two days before it didn't work)
<ivoks> (that would be; disk and cdrom are detected)
<BenC> ivoks: great, I had tested it myself, but good to know it works for others
<ivoks> oh... ok :)
<trejack> I'll be back
<BenC> if anyone wants to review the patch I am building with, it's at http://people.ubuntu.com/~bcollins/libata.diff
<BenC> would be good to get some eyeballs on it
<mdz> BenC: I just tried to clone a git tree, and got: receiving file list ... rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/objects/." (in pub) failed: No such file or directory (2)
<BenC> mdz: you need to re-parent to ubuntu-feisty.git
<BenC> ubuntu-2.6 only exists on rookery right now, and it's just a prep area for gutsy
<macd> BenC, Im not sure why you changed the function from ata_hpa_native_size to ata_hpa_get_native_size, or is that for readability?
<mdz> BenC: oh, KernelGitGuide is out of date then
<BenC> macd: because I added ata_hpa_set_native_size
<BenC> that's just a readability change...the main portion to worry about is in ata_hpa_resize()
<macd> yeah, Im looking in there now
<BenC> fuck
* BenC hits his head some more
<BenC> please put your downloads/boots on hold till I get some new images up
<kylem> BenC, what did you break? :)
<BenC> I broke patch apparently
<BenC> because I didn't build with the libata.diff
<kylem> oh.
<BenC> sorry for wasting everyone's time
<sertmann> sorry, i can't bloody find my usb-wire, isn't there anyway to make a log to txt file from boot?
<sertmann> ah
<sertmann> never mind i see :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging sata_nv and HPA related problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Last test kernels were bad, new ones being built.
<BenC> sertmann: hold off, I have new images building
<sertmann> ill just watch some discovery channel till the new ones are build :)
<macd> so Im safe to assume the problem I had was fixed in the repos version of -15.25
<macd> BenC, do you have the diff from -14 to -15?
<BenC> macd: yes, that was probably the -15.25 fix
<BenC> reverting a patch to sata_nv to fix bad lba48 nodata junk
<macd> k.
<trejack> Forgive my ignorance, I'm having difficulty mounting the USB drive from busybox
<BenC> trejack: No need now, the images were no good
<BenC> trejack: should have new ones in 15-20
<trejack> ok
<trejack> I'm on a windows box now, I'll exit and reboot into -13 on my other
<BenC> builds are just about done
<tijsco> I have problems with the 2.6.20-15.25 kernel and have the sata_nv i think. I reported my problem here (as Matthijs): https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106418
<BenC> tijsco: topic, test kernels being built now to see if we can fix it
<BenC> i386 -generic kernel is uploading now, amd64 to follow
<tijsco> okay, thanks!
<BenC> 864d9379b79e9430178412a3b84be9fd  linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging sata_nv and HPA related problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Last test kernels were bad, new ones at: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> So download from http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> these are marked -15.26 to avoid confusion
* BenC turns on the go-go feature to get this done quicker
<BenC> bc6ed30b95aecdc2369bd65394aba0f3  linux-image-2.6.20-15-generic_2.6.20-15.26_amd64.deb
<BenC> that one is still uploading
<BenC> 100 seconds to completion
<john_brown_jr> 15.26 works for me! (had to switch from nvidia to nv, though)
<BenC> john_brown_jr: yay, can you pastebin your dmesg please?
<john_brown_jr> pastebin?
<BenC> john_brown_jr: you should be able to get the linux-restricted-modules-2.6.20-15 and nvidia-glx packages for this kernel
<BenC> http://pastebin.ubuntu-nl.org 
<BenC> john_brown_jr: paste the resulting link here
<BenC> mdz: test kernels up
<BenC> sertmann: test kernels upload
<mdz> BenC: downloaded
<mdz> BenC: do you suppose this kernel would work on dapper, sufficient for testing purposes?
<mdz> installing feisty on the box with sata_nv isn't a good option right now
<BenC> mdz: eesh, probably wont like initramfs-tools and module-init-tools
<john_brown_jr> http://pastebin.ubuntu-nl.org/15637/
<BenC> kylem: sweet, the patch worked as expected
<macd> mdz, yeah I tried that yesterday, init system is diff b/t 2
<BenC> john_brown_jr: gracias, it worked as I had hoped
<john_brown_jr> :)
<BenC> amd64 image is done for anyone needing that
<trejack> Still a no-go for me
<keir_> hello, i cant boot into the newest fiesty kernel, it think it's the sata_nv issue
<trejack> I'm in my busybox session on other computer - if you can help me mount that usb drive, I'll get dmesg
<BenC> keir_: topic, please test the kernel in that URL
<BenC> trejack: should just be able to plug it in
<BenC> trejack: check "ls /dev/sd*" and tell me what is listed for that command
<BenC> see if we can figure out which device it is
<trejack> Be right back
<trejack> its sda1
<keir_> BenC, will do
<BenC> trejack: mkdir /mnt; modprobe vfat; mount /dev/sda1 /mnt
<BenC> keir_: thanks, please report success/failure
* keir_ waits for download
<trejack> modprobe vfat's what I'm missing
<trejack> FATAL module vfat not found
<BenC> err...shouldn't be
<BenC> trejack: any way to get an ext3 partition on there?
<BenC> either that or add vfat to /etc/initramfs-tools/modules and rerun "sudo update-initramfs -u"
<trejack> I think so on the ext3 question.  It'll take me a few minutes, though...
<BenC> anyone else able to test yet?
<mdz> not yet
<BenC> really hoping trejack's problem is different
<keir_> i can test the now
* keir_ reboots
<macd> BenC, if that box would get past POST I will
<BenC> kylem: the other cool thing about the re-id is we don't perform resize twice now
<mdz> BenC: my install in vmware is taking *ages* now, it used to run quite quickly
<keir_> BenC, that kernel works for me :)
<BenC> keir_: so you had the problem with -15.25 prior to this kernel, right?
<kylem> i hope this doesn't blow our feet off, but ok
<Mithrandir> mdz: check dmesg for the messages Scott was seeing?
<mdz> Mithrandir: did, nothing
<keir_> BenC, correct, -15 and -14 wouldnt boot for me
<mdz> I'm going to restart the whole thing and see what happens
<BenC> keir_: excellent, thanks
<tau650> -15.26 works for me too:) Thanks!
<BenC> mdz: is this with -15.26 or -15.25?
<keir_> BenC, is there anything else you need?
<BenC> tau650: excellent
<BenC> keir_: dmesg output please
<keir_> ok
<mdz> BenC: -15.25
<BenC> tau650: if you could pastebin dmesg for me too, I'd appreciate it
<BenC> mdz: check your host dmesg
<BenC> mdz: I seem to be getting rtc boogers while running virtualization on jus tthis one machine
<BenC> slows things up
<tau650> http://paste.ubuntu-nl.org/15640/plain/
<keir_> paste.ubuntu-nl.org/15643
<mdz> BenC: the usual spew of 'host clock rate change request's
<mdz> BenC: I think it got confused because I was doing a lot of I/O outside of vmware
<BenC> tau650, keir_: thanks, looks good
<BenC> mdz: possible that vmmon is doing whacky things...do you have paravirt enabled?
<mdz> BenC: no, this is a dapper host
<BenC> mdz: even on dapper host, the guest paravirt works
<BenC> for feisty kernel guest that is
<mdz> BenC: I don't know then; I'm just booting the desktop CD
<mdz> latest feisty daily
<BenC> mdz: if you didn't enable it in vmware prefs then it's disabled
<BenC> but it's easy to check, it's in the vm pref window
<mdz> this is workstation 5.5.2
<BenC> oh, then definitely not :)
<mdz> a beta VM seems to run more reasonably, which is worrisome
<BenC> are you installing off actual CD, or a CD image on disk?
<BenC> sertmann: good news or bad?
<sertmann> good :)
<BenC> yay
<BenC> sertmann: can you pastebin your dmesg please?
<sertmann> sure, momento
<mdz> BenC: iso on disk, this is my standard test setup I've been using since edgy
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging sata_nv and HPA related problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Kernel that should fix it: http://people.ubuntu.com/~bcollins/kernels/feisty-release/ | Please report success/failure along with dmesg output via pastebin.ubuntu-nl.org
<BenC> mdz: is the guest using piix.ko or ata_piix.ko?
<mdz> BenC: current feisty daily desktop iso
<BenC> is the disk hd or sd?
<mdz> SCSI disk, IDE CD-ROM
<mdz> I'm going to reboot the machine to make sure nothing is funny with vmware
<BenC> hmm...is it possible to blacklist piix and modprobe ata_piix?
<sertmann> http://paste.ubuntu-nl.org/15644/
<BenC> I've been wondering if the lba48 thing will fix the ata_piix exceptions
<sertmann> dmesg output
<mjg59> SET of native returned 218103822, expected 234441648
<BenC> sertmann: excellent, shows as expected. Thanks for your help
<mjg59> Winning.
<mjg59> Nvidia, your hardware is made of cheese
<kylem> this should be ok for feisty i think
<kylem> mjg59, sis too
<mjg59> Really? Score.
<kylem> yeah and probably uncommon ones too
<BenC> definitely a bandaid...a good quality one, but still one non-the-less
<sertmann> and my FAT32 formatted usbdisk is working aswell (Treetog wrote something about a fatal vfat crash)
<kylem> BenC, we can break a shell prior to loading libata right?
<BenC> kylem: yeah, I think just "break" stops before any module loading
<BenC> so that could be a workaround as well for ignore_hpa=0
<Mithrandir> break=top stops pre-udev
<kylem> good. we might need a workaround for that.
<kylem> i have a patch to strsep command_line[]  and pass options if mod->name matches
<BenC> I think this current patch will win in almost any situation, but it's good to have a fallback
<BenC> kylem: sweet
<kylem> but it needs heavy testing
<BenC> yeah, we can include it for 2.6.22 merges
<BenC> I don't recall if there's any real options that include a period in them
<kylem> doubt they'd match a module name
<kylem> and it wouldn't break that anyway, the module code would just fail the compare, no big deal
<BenC> let me get an upload prepared...being optimistic about this patch so far
<BenC> trejack seems to be the only one so far having issues
<BenC> I'm hoping it's not related, especially since ignore_hpa=0 in his modprobe.d didn't help to start
<tijsco> Is booting here also with 2.6.20-15.26, only nvidia-glx driver is not working now. Here dmesg: http://pastebin.ubuntu-nl.org/15647/
<BenC> tijsco: do you have linux-restricted-modules-2.6.20-15-generic?
<BenC> tijsco: dmesg looks good, thanks
<tijsco> yes, i have linux-restricted-modules-2.6.20-15-generic
<BenC> tijsco: I don't see any nvidia output in your dmesg, odd
<tijsco> My mistake I think, I'll try again
<tijsco> right back
<sertmann> just a quick side note - nvidia glx fails here too
<sertmann> probably not you guys handling that, but now you know :)
<keturn_> -15.26 fixes the sata hang...  nvidia I'm still confused about, since I had to back out nvidia-glx-new for a bit
<keturn_> (on amd64)
<BenC> I know we don't have an ABI change...guessing it's a quirk in the same ABI update
<BenC> keturn_: do you got it working?
<BenC> sudo /etc/init.d/linux-restricted-modules-common start
<BenC> sudo depmod -a
<BenC> then restart gdm/X and see if that resolves it
<sertmann> BenC: that did it - nvidia glx working now also
<tijsco> Here's a new dmesg: http://pastebin.ubuntu-nl.org/15650/ nvidia-xgl is installed, but driver seems not be recognised by restricted drivers manager
<BenC> sertmann: Ok, thanks
<BenC> tijsco: try these commands:
<BenC> sudo /etc/init.d/linux-restricted-modules-common start
<BenC>  sudo depmod -a
<BenC>  then restart gdm/X and see if that resolves it
<tijsco> okay, i'll try
<keturn_> BenC: ok, everything seems to be back in order now.  thanks for being on top of things.
<BenC> keturn_: np, thanks for testing
<BenC> new kernels are booting on all my machines
<BenC> sata_nv/pata_amd machine as well
* heno goes to rally some more testing volunteers
<macd> BenC, 2 people in #ubuntu+1 had success as well.
<BenC> macd: excellent, thanks
<trejack> back
<trejack> (had to take a lunch break)  Here is my dmesg from the failed boot.  http://librarian.launchpad.net/7331014/dmesg.txt
<trejack> hello?
<BenC> trejack: reading...
<BenC> trejack: your problems seems completely different from what we are working on
<BenC> trejack: what was the last kernel that worked for you?
<BenC> I know pata_amd is not broken in general, since I'm using it
<trejack> 2.6.20-13
<_4strO> heno: http://paste.ubuntu-nl.org/15655/
<trejack> I was starting to be afraid it was different
<heno> _4strO: thanks, BenC ^
<BenC> _4strO: can you install the above kernels and test them? (URL in topic)
<BenC> s/kernels/kernel/
<BenC> trejack: Not sure of anything that changed between -13 and now that would cause the problem you have
<_4strO> BenC: yep
<trejack> I would try a reinstall, but when I boot to a build that uses the 2.6.20-14 kernel, it can't see my partitions either...
<_4strO> BenC: I dpkg -i  download and install a new test kernel from here ??? is that right BenC or heno ?
<BenC> trejack: try a ISO from today, it has -15.25 kernel
<trejack> ok
<_4strO> BenC: I dpkg -i  linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb is that right BenC or heno ?
<BenC> _4strO: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> _4strO: yes
<BenC> then reboot
<_4strO> ok$
<trejack> ok
<trejack> thanks for your help...
<BenC> trejack: thank you for sticking through all this tedious testing :)
<_4strO> BenC: looks fine
<_4strO> BenC: you want my lspci -vvn ?
<BenC> _4strO: dmesg output is what I could use
<_4strO> ok 
<_4strO> BenC: http://paste.ubuntu-nl.org/15657/
<BenC> _4strO: great, thanks
<_4strO> pleasure to be helpfull :)
<_4strO> if you need something else ...
<tijsco> 2.6.20.15-26 is booting fine now but nvidia-glx is not working with it, x-server not starting anymore: failed to initialize nvidia kernel module, mismatch between nvidia (1.0-9755) and x module (1.0-9631)
<lazka> BenC, .26 broke the ivtv driver... is this normal?
<lazka> http://pastebin.ubuntu-nl.org/15659/
<lazka> also cdrom drive still isn't working :(
<moodydeath> hi ... still issues with .26 ... dmesg: http://pastebin.ubuntu-nl.org/15660/ (boot process is stuck from line 320 to 328) - and lspci: http://pastebin.ubuntu-nl.org/15661/
<jan_> @lazka: they built it without additional module support, maybe that's the cause ?
<lazka> jan_, ok thx
<lazka> I don't want be anoying... https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103410  have you guys tried the linked patch? I really wold like to have my drive back :(
<_4strO> lazka: did you try this ?
<_4strO> http://ubuntuforums.org/showpost.php?p=2453122&postcount=256
<lazka> _4strO, is the extra initramfs needed after install?
<Mithrandir> lazka: hm, that looks troublesome.
<Mithrandir> kylem: do you have any ideas about lazka's bug?
<lazka> its the same trexjack had, i think
<kylem> the patch in there doesn't help you if you have pata_amd...
<kylem> i'll see what we can do.
<lazka> kylem, thx, you are my heros :)
<Mithrandir> it's the slight problem of if people's CD drives are non-working they can't reasonably install
<kylem> i concur
<kylem> shit.
<kylem> BenC, ping?
<Mithrandir> call him, he's attending his birthday party.
<kylem> hmm. it's ok.
<kylem> lazka, amd64 or i386?
<lazka> kylem, i386 ... nforce 2, pata
<moodydeath> mmh, would there be a way to downgrade linux-image, restricted modules, etc. to 2.6.20-12 ... it's not in the repos anymore :(
<kylem> moodydeath, it's in launchpad
<lazka> kylem, there are 2 more patches: http://lkml.org/lkml/2007/2/27/157
<moodydeath> ah, right, thx :D
<kylem> yes, i'm about to spin you new packages to test
<lazka> ok, i'll be there all night if you want
<kylem> should only take ~10 mins to build
<kylem> building now
<BenC> kylem: ?
<BenC> kylem: the pata_amd problem seems different, but for me it doesn't reproduce
<BenC> kylem: according to the one report I saw, it seemed to regress between -13 and -14, which didn't make sense
<kylem> yeah
<kylem> fix building
<macd> is there a way I can build just a single module instead of all of them?
<BenC> based on -15.26 upload?
<kylem> BenC, i pinged you to get ahold of your sources, but i just repatched with what you had in your ~
<BenC> kylem: I'll push -15.26 real quick
<kylem> BenC, is there more diff?
<BenC> No, but it'll be easier to base on for an Ubuntu-2.6.20-15.27 branch
<BenC> either way works, I just want to push it anyway
<kylem> just a test kernel, i'll toss you the patch once lazka tests it
<kylem> on modpost now
<BenC> Ok, I'll start a .27 branch
<BenC> trejack had the problem too, but I guess he's gone
<kylem> i recommend cp master to $rand and blatting it over master
<kylem> i think lazka's fix is a 1-liner, i hope
<Nafallo> hi!
<Nafallo> http://paste.ubuntu-nl.org/15674/
<Nafallo> can someone tell me what's happening? :-)
<Nafallo> this is with -15.25
<kylem> "badness"
<kylem> someone held interrupts off for too long.
<Nafallo> hmm
<kylem> hmm.
<Nafallo> noapic and irqpoll are used on the kernel commandline.
<Nafallo> should I try to removing irqpoll maybe? :-)
<kylem> that may help, yes
<Nafallo> oki. I'll try that then :-)
<kylem> if your computer doesn't lock up, then it was simply a critical sectoin taking too long
<kylem> not a deadlock
<Nafallo> lockup and lockup... kept spawning the different messages over and over again until I pressed restart :-P
<kylem> odd.
<kylem> you'd think it would deadlock, heh
<kylem> lazka, ping
<lazka> k, i see it
<kylem> lazka, wait five minutes, then try this kernel, http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
<kylem> it's still uploading
<moodydeath> will this new image fix specially lazka's problem, or some other issues, too ?
<kylem> just lazka's it hink
<BenC> moodydeath: the ones in the topic will fix sata_nv and HPA issues
<kylem> kind of depends on what the other issues are. ;P
<moodydeath> already installed it
<moodydeath> http://ubuntuforums.org/showpost.php?p=2453833&postcount=265
<moodydeath> ata2.00: failed to set xfermode (err_mask=0x4)
<lazka> moodydeath, could be the same.
<lazka> since that is the error i get
<kylem> ok, it's uploaded
<kylem> please try it
<lazka> just dpkg -i?
<BenC> moodydeath: it is the one that kyle's kernel should fix
<BenC> moodydeath: http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
<moodydeath> i'll try it anyway ^^ ... nothing to lose on my testsystem :D
<BenC> kylem: I have a tree ready for -15.27, so just ping me when you get a patch
<Nafallo> http://paste.ubuntu-nl.org/15677/
<Mithrandir> BenC: I haven't accepted .26 yet.
<Nafallo> hehe. got that instead, but that's better I guess :-)
<kylem> BenC, if it works patch is at rookery/~kyle/force-setfeatures-polling.diff
<BenC> Mithrandir: easier for me to just make a .27, so no biggy
<lazka> ok, brb
<moodydeath> installed kyle's .27  ....
<kylem> oh fuckin gchrist.
<moodydeath> yeah
<moodydeath> works :D+
<kylem> yeah?
<kylem> cdrom works?
<moodydeath> uhm
<moodydeath> dunno
<moodydeath> but this is the first kernel today, that doesn't stuck at the ata2 stuff
<kylem> ok
<moodydeath> mom
<moodydeath> dvd and cdrom drives work now, too
<Mithrandir> BenC: sure, whatever works for you.
<kylem> good
<kylem> i'm glad
<moodydeath> with the older versions, only the asus drive works for me ... my liteon did'nt
<kylem> maybe they'll let me sleep tonight ;P
<BenC> kylem: let me try on my pata_amd to make sure it doesn't regress there
<kylem> k
<Mithrandir> kylem: can we get a bit broader testing of it?  I'm reluctant to bring in a patch which has been so lightly tested.
<kylem> Mithrandir, i completely agree
<kylem> it *should* be harmless
<lazka> soo
<kylem> since PIO is the default ATA mode ;-)
<lazka> boot was smooth
<Mithrandir> well, "should" being the operative word. :-P
<Mithrandir> I'm not saying you're wrong, I'm just trying to play defensively here. :-)
<BenC> good thing is, it's restricted to pata_amd
<kylem> Mithrandir, yeah, i completely agree with you
<kylem> just saying, is all
<BenC> bad thing is it's restricted to pata_amd, which makes finding real testers hard
<kylem> BenC, what's that?
<BenC> Oh, wait, no, it's in libata-core.c
<Nafallo> I have pata_amd
<Nafallo> seems -15.25 works for me though.
<kylem> BenC, can you respin with that patch for amd64 on your quadcore/
<BenC> yeah
<kylem> i'll boot it on my pata_amd too
<moodydeath> <-- pata_amd
<lazka> kylem, http://pastebin.ubuntu-nl.org/15678/
<BenC> kylem: what exactly is the result of this patch?
<kylem> BenC, afaict some drivers respond to SETFEATURES_XFER too slow
<kylem> BenC, this forces use of polling mode
<kylem> instead of interrupt mode
<kylem> lazka, does your drive work
<BenC> kylem: just for setting xfer mode?
<kylem> BenC, yeah
<lazka> it doesnt automount, do i need an entry in fstab? there is nothing in there
#ubuntu-kernel 2007-04-15
<BenC> kylem: works on my pata_amd
<kylem> lazka, er, maybe?
<lazka> kylem, what should be the dev name?
<kylem> mount -t iso9660 /dev/scd0 /mount
<trejack> FYI my problem persists with a new install from today's daily build.
<Nafallo> /dev/cdrom
<BenC> trejack: Try: http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
<kylem> trejack, what problem?
<BenC> kylem: trejack was also having the pata_amd issue
<kylem> ok
<lazka> no medium found..
<BenC> lazka: do you have a disk in there?
<trejack> I can't.  Wiped my working 2.6.20-17 install
<lazka> yeah, i will  look for a cleaner one..
<trejack> Wait a sec - I can chroot in from my edgy
<moodydeath> is it the correct device, laska? ... could be scd1, too, if you got more
<trejack> I'll be back
<lazka> ok, /dev/cdrom is my dvd-drive
<lazka> and its working
<lazka> but i cant find the lite-on
* heno goes to find more testers
<lazka> kylem, it makes some noise but doesnt spin up
<BenC> [   30.987575]  scsi 1:0:1:0: CD-ROM            PLEXTOR  DVD-ROM PX-116A2 1.00 PQ: 0 ANSI: 5
<BenC> that's the only thing I see connected
<kylem> it only found one ATAPI device
<BenC> There is only /dev/sr0, no /dev/sr1
<kylem> and didn't even whine about the rest
<kylem> are you sure it's cabled properly?
<heno> kylem: are you building an amd64 version for testing as well?
<lazka> kylem, should be, i'll check with 20.13 again if it still works there, k?
<BenC> heno: I am, I'll upload it when it's done
<kylem> ok
<heno> ok, cool
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging pata_amd problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Kernel that should fix it: http://people.ubuntu.com/~kyle/kernels/feisty/ | Kernel that is known to fix sata_nv and HPA problems: http://people.ubuntu.com/~bcollins/kernels/feisty-release/ | Please report success/fai
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging pata_amd problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Kernel that should fix it: http://people.ubuntu.com/~kyle/kernels/feisty/ | Kernel that is known to fix sata_nv and HPA problems: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<lazka> kylem, bad news, works ok with 20.13
<BenC> lazka: can you pastebin dmesg from .13?
<lazka> http://pastebin.ubuntu-nl.org/15681/
<lazka> [   32.828189]  hdc: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
<BenC> kylem: amd64 is uploading to my ~/, I'll let you put it next to yours
<BenC> hdc?!
<kylem> you must have shuffled pci ids?
<lazka> umh what?
<kylem> brb.
<BenC> -13 -> -14 == ata update
<BenC> probably moved from amd ide to pata_amd
<Nafallo> pata_amd still used hd? in -13 for me aswell
<Nafallo> or that :-)
<BenC> brb
<lazka> it did say that in the bugreport...
<BenC> kylem: if the problem we're having is just in pata_amd, maybe switching back to the amd IDE driver is best
<BenC> looks like the quick fix didn't take care of all the problems
<trejack> No good for me, either.  (Iused the -15.27 kernel).  The dmesg is at http://librarian.launchpad.net/7331329/dmesg2.txt
<BenC> still showing exceptions for trejack too
<trejack> Don't know if this will help or not, but when I booted into the live cd, it at first couldn't use any of my existing partitions.
<trejack> I reformated the sda3 one using gparted, and it completed in seconds, and my sda1 partition was suddenly available, as well
<BenC> trejack: doing a new build to revert back to amd74xx driver
<BenC> lazka, moodydeath: you guys willing to test another kernel in about 30 minutes?
<lazka> BenC: yep
<trejack> I'll check back in 30.  Thanks
<moodydeath> yep
<BenC> thanks, build started, will post here when it's done
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging pata_amd problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Test kernel is building, will be done at around 23:20 UTC | Kernel that is known to fix sata_nv and HPA problems: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<moodydeath> is this the new one ?
<lazka> moodydeath: no
<moodydeath> kk :)
<moodydeath> ah ... should read the whole topic ... -_-
<lazka> there is so much crap on TV at night :P omg
<BenC> builds are done, getting ready to upload
<defendguin> hey BenC
<defendguin> apparently the mmc card reader fix isn't working
<BenC> it was reported to work for many people
<defendguin> hmmm
<BenC> it doesn't resolve all mmc issues
<defendguin> i wish i had a card on me
<BenC> it was just one major regression
<BenC> 53b205c5fbe264a700454a4f5416d0a8  linux-image-2.6.20-15-generic_2.6.20-15.26_amd64.deb
<BenC> 7a5f4a0801be29c9c614b3d1a673edf2  linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.25 Uploaded | URGENT: Currently debugging pata_amd problems in 2.6.20-15.25 (do not report problems unless you have -15.25). Test kernel: http://people.ubuntu.com/~bcollins/kernels/feisty-release/ | Kernel that is known to fix sata_nv and HPA problems: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
<moodydeath> dl running :D
<BenC> note that kernel changes pata_amd back to amd74xx, so your devices will go to hdX
<BenC> moodydeath: it's still being uploaded
<moodydeath> hmm
<BenC> probably be completed in about 5 minutes
<BenC> probably less
<MrNOKIA> is it a 32 or a 64 bit version ?
<moodydeath> i'll f5 ;)
<MrNOKIA> i'm sorry, i must be missing something
<MrNOKIA> i'm using linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
<trex37> what's the file size?
<MrNOKIA> the new file is .26 ?
<MrNOKIA> 21 Mb
<lazka> it's ready
<MrNOKIA> yes,but...
<MrNOKIA> why is it .26 now ?
<MrNOKIA> i.m on .27 for about an hour
<moodydeath> .27 was a version from kyle
<MrNOKIA> kile ?
<MrNOKIA> kyle ?
<moodydeath> BenC: kernel boots ... as fast as -12 did
<moodydeath> testing drives
<MrNOKIA> moodydeath, what is kyle ? should i try the new kernel now ?
<moodydeath> scd0 & scd1 working :D
<moodydeath>  http://people.ubuntu.com/~kyle/kernels/feisty/ <-- here is the .27 ...  but i think the .26 which was released some minutes ago is the new one
<lazka> Ubuntu 2.6.20-15.26-generic
<lazka> http://pastebin.ubuntu-nl.org/15700/
<lazka> everything back to normal
<moodydeath>  http://pastebin.ubuntu-nl.org/15701
<moodydeath> me, too :D
<lazka> BenC: is it intentional that ivtv isn't working with your builds?
<lazka> it worked with kylem's build
<trejack> Yay!  That one did it
<trejack> what do you need from me?
<BenC> lazka: no, I didn't change that
<BenC> trejack: dmesg please
<lazka> BenC: what do you mean?
<BenC> lazka: ivtv
<cjwatson_> lazka: from your log earlier it looked like you were just missing the firmware
<cjwatson_> iirc
<lazka> BenC: your build is 2 MB smaller..
<BenC> lazka: could be a left out the firmware
<BenC> quirk in the build
<lazka> thats what i mean..
<BenC> lazka: try copying it from /lib/firmware/linux-image-2.6.20-13-generic/
<BenC> it wont happen in the final build
<lazka> ok, thanks
<BenC> I trimmed some things out of the build to speed things up
<BenC> mainly linux-headers, linux-debug, and apparently firmware
<lazka> ah, i see, however.. i'm going to bed now, already 2 am here.
<BenC> lazka: thanks
<lazka> gn8 all
<BenC> Mithrandir, cjwatson: The three testers we had that reported the problem have reported success
<BenC> the fix was reverting back to amd74xx IDE driver instead of pata_amd
<cjwatson> right, do you have the diff or is it in git?
<BenC> so it's a relatively safe and isolated fix
<BenC> amd74xx was actually being used up until about 5 weeks ago
<cjwatson> I'm actually just going to bed, but I am happy to be woken up once it's uploaded
<BenC> will be done in about 10 minutes
<cjwatson> ok
<cjwatson> send me an SMS on my mobile number?
<BenC> cjwatson: Ok
<BenC> cjwatson: wait, I can't send Intl SMS
<BenC> unless you have an email that redirects
<BenC> trejack, lazka, moodydeath: thanks for the testing!
<moodydeath> np :)
<MrNOKIA> np ?
<BenC> the past few days, we've been very fortunate to have folks coming around to bear the burden of our test builds
<BenC> MrNOKIA: np == no problem
<BenC> MrNOKIA: were you having the pata_amd problems?
<moodydeath> will there be something like a final version, that will need a test ?
<MrNOKIA> sorry
<MrNOKIA> i knew that
<BenC> moodydeath: by tomorrow there should be something in your update manager :)
<MrNOKIA> I guess
<BenC> MrNOKIA: could you test the kernel in the topic URL?
<BenC> I'm sure it will work for you, if that's in fact the issue you were having
<MrNOKIA> I could'nt boot the new kernel untill the .25 version came up
<trejack> http://librarian.launchpad.net/7331974/dmesg3.txt
<MrNOKIA> i posted info on the dedicated thread
<MrNOKIA> hope it helped
<MrNOKIA> my nick is pretty much the same as on ubuntuforums :)
<BenC> MrNOKIA: ok, thanks
<BenC> trejack: excellent, thanks
<BenC> cjwatson, Mithrandir: kernel away
<trejack> Thank you!
<trejack> I must say I was intimidated by all of this at first, but it's been a pleasure...
<MrNOKIA> BenC: a new kernel ?
<MrNOKIA> i see only the 15 april .26 version 
<defendguin> got it all fixed?
<BenC> defendguin: looks that way
<BenC> MrNOKIA: the one in my dir in the URL is the same as the one I uploaded (sans some firmware)
<gnufied> extended attributes are enabled on stock ubuntu dapper kernels?
<gnufied> if yes, then how do i find out?
<crimsun> grep -i xattr /boot/config-$(uname -r)
<gnufied> thanks, so its enabled.
<yoasif> i just saw the post on ubuntuforums about the sata_nv issue... how can i help?
<mjg59> Should be fixed now
<mjg59> See the topic
<yoasif> ty
<yoasif> hmm, 15-27 is listed on ubuntuforums, should i get that, or the one in the topic?
<yoasif> (i am experiencing the PATA issues)
<mjg59> 15.27 is the latest, I believe
<mjg59> It's worth a go
<yoasif> ok
<yoasif> mjg59: do you have any ideas what the problem might be if every once in a while, the screen goes all wonky (the screen gets compressed down, and a load of copies of the screen get patterned, and skewed)
<yoasif> ssh doesn't work, and i've tried just using vesa
<mjg59> No
<yoasif> heh... i'm really wondering how i can describe the issue properly. 
<keturn> sounds a little like your graphics card aesploded
<yoasif> it's onboard 
<yoasif> and a pretty new mobo
<cjwatson> -15.27 kernel belatedly accepted - builds will start running as soon as I can manage it
<kylem> thanks colin
<cjwatson> http://librarian.launchpad.net/7331974/dmesg3.txt (from trejack earlier) has some DriveReady SeekComplete Error stuff before the kernel finally gets hda going - is that unrelated?
<kylem> unlikely
<kylem> oh, yeah
<mjg59> Likely that it's unrealted, by the looks of it
<kylem> i thought hda was the missing cdrom
<mjg59> BadCRC is either complete timing fuckup, or bad cable
<kylem> likely a 40pin cable
<mjg59> But, hell, drivers/ide has never really worked
<cjwatson> hda has a partition table in that dmesg so it's not a cdrom
<kylem> right
<mjg59> It ends up coming up in pio mode
<kylem> works by magic
<kylem> sheer force of will
<mjg59> Not ideal, but it'll do
<cjwatson> ha
<kylem> hmm, mark lord lives in the same city as me
<kylem> i can walk over and beat him up if you want
<kylem> :P
<cjwatson> ok, publisher's running, I'm off back to sleep
<mjg59> Oh, that system looks shitted anyway
<kylem> cjwatson, night
<mjg59> [   20.079279]  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
<mjg59> [   20.079317]  ...trying to set up timer (IRQ0) through the 8259A ...  failed.
<mjg59> [   20.079320]  ...trying to set up timer as Virtual Wire IRQ... failed.
<mjg59> [   20.119013]  ...trying to set up timer as ExtINT IRQ... works.
<mjg59> Never seen that on an nvidia board before
<cjwatson> phone me if it all blows up, and I'll try not to fall straight back to sleep again :-/
<cjwatson> Mithrandir has it set up so that the kernel builds on palmer this time
<mjg59> cjwatson: The errors there don't look related to any of the HPA/libata stuff
<cjwatson> ok, thanks
<bdgraue> cjwatson: linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb  works for me
<Nafallo> kylem: my server seems to have kept itself from hanging after I removed irqpoll :-).
<crimsun> BenC: I've emailed you a tested and verified patch for #105582. Please consider applying it to avoid a regression from dapper.
<Mithrandir> crimsun: too late, but it should go into an SRU
<crimsun> Mithrandir: whatever you guys [have]  decide[d] 
<Mithrandir> crimsun: sorry. :-/
<benh> crimsun: here ? :-)
<crimsun> yep.
<benh> ok, so it's indeed Version: 2.6.20-15.25
<benh> and it blows up when moving the mouse
<benh> on a Quad G5
<benh> linux-image-2.6.20-15-powerpc64-smp, in console mode, minimum install (no X, no gpm)
<benh> I don't have a hardcopy of the crash yet, it crashes at irq time, so no log
<benh> backtrace shows that it comes from usb -> input -> evdev
<benh> and it might be blowing up in do_gettimeofday() which would be VERY strange
<benh> are there some known ubuntu patches in that area ?
<benh> crimsun: yup, I think BenC is asleep :-( pung him already on some other channel, didn't help
<benh> I'm a bit lost with launchpad, how do I look at the bugs reported for a given package ?
<benh> https://launchpad.net/ubuntu/+source/linux-source-2.6.20 seems to indicate that a .27 is out
<benh> though it hasn't hit au.archive.ubuntu.com
<benh> might be worth for me trying to dig that and check before filing a bug report
<crimsun> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
<benh> hrm.. I don't see it
<benh> me gets the source and have a look how on earch do_gettimeofday() could crash ...
<Mithrandir> -15.27 probably won't hit au.archive for another couple of hours, but you can get it off archive.ubuntu.com or launchpad.
<benh> yup, I'll try that too
<Mithrandir> https://launchpad.net/+builds/+build/318987/linux-image-2.6.20-15-powerpc64-smp
<benh> not on archive's Package file yet, I'll wait and look at hte source in the meantime
<benh> ok
<benh> that would do too I suppose :-0
<Mithrandir> I really can't believe we wouldn't have massive amounts of bug reports about that bug, unless there's something special with your hardware.
<benh> nothing special that I can see... just a fairly ordinary quad G5
<`sam`> does -25.27 need testing for sata_nv or is it known to work? because i'm installing now...
<benh> anyway, have to run, will be back later & investigate
<benh> have 2 disks though and using an lvm but heh... that shouldn't matter :-)
<bdgraue> 15-26 is running fine with sata_nv
<bdgraue> -15.26 i mean
<Mithrandir> `sam`: we want as much testing as we can get on the latest kernel (-15.27).  Even if previous ones worked fine, we want to make sure there are no regressions.
<Mithrandir> `sam`: so if you have a bit of time to spare, it's much appreciated.
<bdgraue> Mithrandir: i'll try the new -15.27 too
<`sam`> ok, i've had -15.25 installed but have still been running -14.23... going to reboot now and see
<`sam`> well -15.27 boots for me
<`sam`> took me a few minutes because i had changed my xorg.conf about 30 minutes ago and had messed it up
<Mithrandir> `sam`: good to hear, CD-ROM/DVD-ROM and all works too?
<`sam`> yeah i just tested a dvd and it started playing in totem
<Mithrandir> great
<Mithrandir> please tell us if you have other (kernel-related) regressions?
<bdgraue> Mithrandir: where can i get the 15-27?
<`sam`> like what? anything specific you want me to check out?
<bdgraue> are the 2.6.20-15.27 not available for i386 yet?
<`sam`> bdgraue, have you checked in update-manager? i just found it there about 25 minutes ago
<bdgraue> `sam`: not here i have archive.ubuntu.com
<Mithrandir> bdgraue: are you on i386?  If so, the kernel is not done yet.
<bdgraue> ok then
<bdgraue> i'll wait :-)
<macd> palmer is cooking hot ;)
<bdgraue> Status:	Currently building
<bdgraue> :-)
<`sam`> Mithrandir, was the drive detection the main problem? if there's anything else i could test i've got time... even though i don't know what all i'm looking for :)
<Mithrandir> `sam`: yes, the problems were all related to drive detection and also some HPA.
<Mithrandir> can you run dmesg | grep hpa in a shell and paste the contents somewhere?
<`sam`> it's only 2 lines, can i paste it here?
<Mithrandir> sure
<`sam`> [   24.478810]  ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000
<`sam`> [   24.490762]  ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000
<Mithrandir> ok, and no scary errors of any kind in dmesg?
<`sam`> i don't think so, but i don't know what this is:
<`sam`> [   25.958194]  ATA: abnormal status 0x7F on port 0x0000000000010967
<Mithrandir> hm
<Mithrandir> not great, but if it all works, I wouldn't worry too much
<`sam`> what is the hpa exactly? i'm just finding stuff about thinkpads...
<benh> Mithrandir: crash still happens with .27
<benh> Mithrandir: will investigate
<benh> Mithrandir: do you guys have extra patches on top of mainline like some of the -rt or clock sources stuff ? some of that is known to introduce fancy breakage on ppc
<benh> (still d/l the source on my crappy link here)
<cjwatson> `sam`: http://en.wikipedia.org/wiki/Host_Protected_Area
<Mithrandir> benh: we have lowlatency, but it's not enabled in the default kernels.
<benh> k
<cjwatson> our kernel's in git if that helps
<Mithrandir> benh: I'm not a kernel hacker, so I'm not sure what other patches have been brought in.
<benh> ok, because the scary thing is ... there is -no way- such an error could happen in gettimeofday on normal mainline
<benh> unless there have been kernel memory corruption :-(
<cjwatson> http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=summary
<benh>  ... or it's passed a crap argument
<benh> which is probably the likely cause... need to disasm to see where exactly the crash occurs
<cjwatson> Mithrandir: -15.27/i386 is in accepted, if you hadn't already noticed; feel like accepting d-i?
<benh> I wounder if stupid mousemu could be causing it
<Mithrandir> cjwatson: ah, just got there then, I'll accept it
<benh> Mithrandir: ok, if you kill mouseemu, it doesn't crash
<Mithrandir> is mouseemu kernel mode?
<benh> Mithrandir: at this point, I'm about 99% convinced it's some crap in uinput vs. 32 bits apps on 64 bits kernels
<benh> Mithrandir: no, but it uses some whacky kernel interfaces (uinput) which I wouldn't be surprised at all is broken
<benh> Mithrandir: there is a long tradition of brokenness in the input layer userland interfaces, especially vs 32/64 bits
<Mithrandir> hmkay.
<benh> Mithrandir: it's likely that running a 32 bits mouseemu on a 64 bits x86 will crash too
<benh> Mithrandir: I'll have to investigate in more details but can't do that tonight, in the meantime, it might be worth (if possible) to disable mouseemu by default on powerpc64
<Mithrandir> we don't support 64 bit kernels and 32 bit userland on x86_64, so that's not really that important.
<benh> Mithrandir: hehe, fair enough :-)
<Mithrandir> "you run this and it breaks?  You get to keep both pieces."
<benh> Mithrandir: well, I know powerpc isn't officially supported anymore.. but if you guys want to avoid that problem, the short term band-aid is to disable mouseemu on 64 bits powerpc's
<Mithrandir> cjwatson: ^^ ; your code, your call, I'm not sure what's a reasonable direction to go in from here.
<benh> Mithrandir: want me to file a launchpad entry ?
<Mithrandir> benh: yes, a bug would be good.
<benh> Mithrandir: I'll try to debug that properly later, I'll be away for most of next week though
<Mithrandir> benh: yes, I'm trying to think of a way to not end up saying "sorry, ppc is SOL".
<benh> Mithrandir: :-)
<benh> Mithrandir: well... it would hit ps3 
<Mithrandir> it would, which is bad.
<Mithrandir> I'm wondering if we can do it in an SRU or not..
<benh> I'd say just don't install mousemu by default on 64 bits ppc's ... I suppose you install it by default bcs of 1 buttons apple mice...
<benh> anyway, I'll file a launchpad entry tonight so it's at least tracked before I go
<benh> I'll try to find out what's wrong in the kernel later
* MrNOKIA Offtopic: update available for Ubuntu Forums Firefox extension /Offtopic
<cjwatson> Mithrandir: wah, need to do that before d-i goes in
<cjwatson> Mithrandir: can you reject it temporarily?
<cjwatson> benh: one-button mice> right, the old sysctl approach isn't available on x86 for Intel Macs and I wanted to have the same scheme across architectures
<cjwatson> it was working fine for me on 32-bit powerpc :-/
<benh> cjwatson: faiir enough
<benh> cjwatson: yeah, well, uinput is a pile of poo unfortunately
<benh> cjwatson: I'll check if the problem is still in upstream 2.6.21-whatever-git-of-the-day first
<cjwatson> Mithrandir: I've rejected debian-installer so that I can squeeze hw-detect in front
<cjwatson> benh: the powerpc64 option sounds reasonable
<benh> another option might be to build it as a 64 bits binary :-) if the bug is what I think, that might work
<cjwatson> can't do that at this point
<cjwatson> it's the same binary package on powerpc32 and powerpc64, would involve massive fiddling
<cjwatson> also we're right at the wire
<cjwatson> literally if this had been half an hour later it would have been too late ;)
<benh> heh
<benh> I knew it was a good idea to try out fesity on this g5 :-)
<cjwatson> meh, this means I have to figure out whether the running system is ppc64
<benh> I've been running it on the laptop for some time, had minor issues, but overall good
<cjwatson> arch_get_kernel_flavour () {
<cjwatson>         CPU=`grep '^cpu[[:space:] ] *:' "$CPUINFO" | head -n1 | cut -d: -f2 | sed 's/^ *//; s/[, ] .*//' | tr A-Z a-z`
<cjwatson>         case "$CPU" in
<benh> cjwatson: ugly way: check /proc/ppc64 :-)
<cjwatson>                 power3|i-star|s-star|power4|power4+|ppc970*|power5|power5+|cell)
<cjwatson>                         family=powerpc64
<benh> nah
<cjwatson> will have to duplicate crap like that I guess
<benh> don't test the cpu model
<cjwatson> benh: huh, that actually exists?
<benh> that's too ugly for words
<cjwatson> I know, but it's all we had
<benh> cjwatson: it does in 2.6.20 :-0
<cjwatson> neat
<benh> let me dbl check it does on your kernel...
<cjwatson> the code's there, but I'm no expert
<benh> it does
<benh> either that or you check for uname -a containing powerpc64
<benh> I'm sure there are better ways :-)
<benh> but you should never have to check for individual cpu models
<benh> anyway, anything that works for you...
<cjwatson> might change that at some point, cpuinfo testing is useful though because of the automatic test framework there
<cjwatson> could probably teach it about uname output if it doesn't know already
<cjwatson> anyway, I'll [ ! -d /proc/ppc64 ]  in hw-detect, thanks
<benh> yah, it's dir with various crap in it
<benh> we can't really remove it because of some stupid stuff relying on it
<benh> so it will stay a bit longer...
<benh> anyway, use whatever is best for you
<benh> btw, I was impressed how good the installer was vs. setting up yaboot
<benh> I was installing on sdb, with lvm & all, sda had my debian stuff etc..
<benh> and the installer figured it all out, and setup yaboot.conf entries for my sda stuff too, neat !
<cjwatson> Mithrandir: could you review hw-detect 1.45ubuntu5 to work around benh's bug?
<cjwatson> then binaries of that need to be accepted before re-accepting debian-installer
<Mithrandir> not in the queue yet, but yes, will do in two minutes
<cjwatson> benh: yeah, the os-prober stuff for detecting other systems is nice
<cjwatson> still keep getting the odd report of ofpath glitches
<benh> yeah, for some reason, I didn't hit those tho
<benh> (I was expecting to :-)
<benh> I think it re-used my boot partition on sda which is probably why it worked
<cjwatson> we do have a couple of ofpath patches, think I sent them to Debian a while back
<cjwatson> not entirely sure they're right on all systems though
<benh> I'm filing a launchpad entry for the kernel bug so we can track it
<cjwatson> had a report the other day which suggests not, though I haven't seen the /proc/device-tree/ tarball for it yet
<cjwatson> thanks. so you reckon it's lack of 64/32-bit thunking in the uinput ioctls?
<benh> it's either that or a bug in the thunking... either way, it shouldn't crash the kernel :-)
<Mithrandir> are those ioctls available to the user?  If so, we should get this fixed in a security upload.
<cjwatson> Mithrandir: yes, mouseemu is userspace
<cjwatson> oh to non-root you mean?
<Mithrandir> well, non-root user.  "root can crash the kernel" isn't very interesting.
<benh> I suspect it might use read/write instead of ioctl's ... but I'll confirm all that when I have time to dig, after I'm back from Perth next week
<cjwatson> probably to anyone who can read/write /dev/input/*
<benh> depends on the permission on uinput
<cjwatson> benh: ioctl to set up the virtual device, read/write to interact with it
<benh> uinput is a hack that allows to filter input events from userspace
<cjwatson> crw-rw---- 1 root root 10, 223 2007-04-12 10:28 uinput
<benh> yeah
<cjwatson> at the moment
<benh> ok, so it's not -too- bad... still worth fixing at one point
<Mithrandir> sure, it's worth fixing, but not getting into (another) panic about.
<benh> either a small fix if easy, or just forbid read/write on 32 bits if not a simple fix
<benh> sure
<benh> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106723
<cjwatson> thanks
<benh> the input layer 32/64 its thunking is known to be a total PITA
<benh> anyway, I'll dig when I can, not enabling mouseemu by default on powerpc64 is a good enough workaround for now as far as I'm concerned
<Mithrandir> hw-detect accepted.
<cjwatson> ta
<Mithrandir> cjwatson: is d-i going to run with the correct kernel (32/64 bit)?
<cjwatson> benh: yeah, the ghastly /etc/sysctl.conf-is-different-on-powerpc hack is still in place so 1-button mice won't break anyway
<cjwatson> Mithrandir: yes
<Mithrandir> ok
<cjwatson> one doesn't work on the other
<benh> we used to have G5 support on 32 bits ... along time ago :-) we ditched it at least 2 yrs ago
<benh> it was a pain to maintain
<cjwatson> very glad I didn't revert /etc/sysctl.conf to stock now ...
<benh> btw, out of curiosity, what is the policy for updates vs security ?
<benh> like feisty-updates vs. feisty-security repos
<benh> or more specifically, in what circumstances are things updated when it's not a security update ?
<Mithrandir> when there is "significant breakage".
<benh> I would suspect... bugs (things don't work) but what is the threshold for a bug to be actually fixed in a release vs. in the next version ?
<benh> ah ok
<benh> well, I suppose it's a matter of somebody to decide wether it's significant enough and the fix unintrusive enough then...
<benh> fair enough
<Mithrandir> it's always a matter of judgement, but it's for high-impact bugs which can be fixed in a localised fashion and we're reasonably sure it won't break anything else.
<benh> yup, makes sense
<benh> I wonder if mplayer not working on most 32 bits powerpc's will be fixed thn ;-)
<Mithrandir> https://wiki.ubuntu.com/StableReleaseUpdates under "When" has the criteria.
<benh> (it's apparently compiled with an option for using instructions that don't exist on most 32 bits cpus)
<benh> oh well, we'll see
<Mithrandir> mplayer is multiverse, so less stringent about updates to it.
<benh> yeah
<Mithrandir> it's also not a core component; updates to glibc have to be much more serious than updates to, say, bluez-cups
<benh> yup
<benh> ok, have to go, thanks for the workaround !
<Mithrandir> see you
<benh> bye
<bdgraue> 2.6.20-15.27 work well, no more problems here, i think
<bdgraue> if i can do somethink, you have to tell me :-)
<cjwatson> bdgraue: great, much appreciatted
<cjwatson> -t
<bdgraue> :-)
<`sam`> what's the deal with 2.6.20.15.14, i think it's the same as 2.6.20-15.27? i'm trying to explain it to somebody in #ubuntu+1 but don't completely understand it myself
<gene6482> this is a kernel question but it needs support, so if i'm in the wrong place i'm sorry, basically i have a toshiba laptop with sound issues and after some research have learned that my dsdt is buggy, can anyone help me fix it?
<defendguin> i don't suppose michael bienia is in here?
<Nafallo> defendguin: try -motu
<defendguin> -motu?
<Nafallo> #ubuntu-motu
<defendguin> ahh
<gortiz> ehm.. sorry, but someone will ever upload also the restricted driver for -15.25??
<gortiz> ?
<gortiz> is there someone?
<Nafallo> gortiz: some developers haven't had much sleep the last three or four days. please calm down :-)
<gortiz> sorry Nafallo 
<gortiz> i didn't want to be arrogant
<Nafallo> it's okey. I'm not one of them ;-)
<gortiz> ok i ask to forgive me..
<gortiz> Nafallo, do you know if they are uploading also the restricted drivers?
<gortiz> I can't test it withot them..
<Nafallo> gortiz: at some point I'm sure they will :-)
<gortiz> lol Nafallo 
<gortiz> thanks bye
<Nafallo> they even seems to BE uploaded already :-)
<Nafallo> gortiz: ^
<gortiz> ok so it's my mirror to be outdated..
<gortiz> i'll wait the italian mirror to be updated.. :)
<gortiz> thanks
<gortiz> ehm.. ok i've controlled.. it's the -15.27 not -15.25 the one i need..
<gortiz> i'm on -15.25 and i haven't any problem
<mjg59> -15.25 and -15.27 use the same l-r-m
<Nafallo> -15.20
<MrNOKIA> guys, may i ask what's the diference between  linux-headers-2.6.20-13-lowlatency and linux-headers-2.6.20-13-generic 
<gortiz> MrNOKIA, ehm the lowlatency?
<MrNOKIA> in other words, what is more desirable to have on a dual-core centrino ?
<gortiz> generic
<MrNOKIA> the genreric or the low-latency kernel ?
<MrNOKIA> lowlatency kernels are for slow cpu's ?
<MrNOKIA> pardon if i'm mistaking
<gortiz> no, lowlatency are for special uses on computers that need a very lowlatency..
<MrNOKIA> like editing audio/video ?
<gortiz> no
<gortiz> MrNOKIA, don't worry i dont think that you need them you can use the generic
<gortiz> :)
<gortiz> bye
<MrNOKIA> thanks
<gortiz> :)
<MrNOKIA> i just wanna clarify some issues regarding linux in general
<MrNOKIA> that's why i asked
<mjg59> MrNOKIA: #ubuntu is a better place for support questions
<MrNOKIA> thanks mjg59
<defendguin> mjg59: you can close that bug 44615 the fix works
<defendguin> nevermind i got it
<gene6482> this is a kernel question but it needs support, so if i'm in the wrong place i'm sorry, basically i have a toshiba laptop with sound issues and after some research have learned that my dsdt is buggy, can anyone help me fix it?
<pokoko> g'day everyone. In Ubuntu (Linux kernel 2.6.17-11), i think there's a bug where a mounted usb device doesn't get recognised after a suspend/resume. Has this been worked out yet or some solution which I am unaware of ?
<blueyed> Bug 106028 is still not fixed, although it's a key feature AFAIK. Not even Importance of the bug has been set..
<blueyed> Malone bug 106028 in linux-source-2.6.20 "Kvm not installable in feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/106028
<cjwatson> blueyed: people set way too much stock in the Importance field, but yes, that should get fixed; I'll try to see to it tomorrow if nobody beats me to it
<cjwatson> the number of people complaining about the Importance field there in fact encourages me to leave it unset simply as a demonstration ;-)
<blueyed> cjwatson: lol, yeah. But OTOH it would be really bad if this showstopper would make it into the RC or final, wouldn't it?
<cjwatson> "but yes, that should get fixed; I'll try to see to it tomorrow if nobody beats me to it"
<blueyed> sure. I understand this. But the last time this was brought to IRC the answer was "it will be fixed soonish" (Bug #105263).
<cjwatson> I don't know what you think you're going to achieve by further haranguing me given that I've already promised to look at it
<cjwatson> looks like the kvm-api-9 provides change was one of the things that was committed to kernel mainline but not to the -15 branches, so best thing is probably to revert kvm's dependency
<cjwatson> but, tomorrow
<BenC> It's in git
<BenC> it's going to be fixed on the first post-release update
<cjwatson> BenC: kvm needs to be fixed for release, IMO
<MrNOKIA> git ?
<cjwatson> i.e. installable
<BenC> cjwatson: kvm doesn't even work unless you use universe, so I'd argue it's not that bad?
<cjwatson> honestly I think it should do Depends: kvm-api-9 | kvm-modules-2
<cjwatson> it's a feature we've highlighted in our release notes
<cjwatson> it's kind of an oversight that it's in universe given that IMO, but I do think it needs to work
<BenC> cjwatson: do you want me to do another kernel upload to fix it? :)
<cjwatson> no, I want kvm's dependencies to DTRT with what we've got
<BenC> or wait for post-RC
<cjwatson> unless you're saying there is no way a kvm upload can fix it?
<BenC> cjwatson: it can't, they are broken because the kernel doesn't provide the right modules to work with kvm-18
<cjwatson> can we revert kvm then?
<cjwatson> blow it back with an epoch
<BenC> we really want kvm-18, but sure, we can downgrade kvm package to kvm-16
<cjwatson> I'll look at that tomorrow then
<BenC> https://launchpad.net/ubuntu/+source/kvm
<BenC> the previous version, 16-1ubuntu1 works with current kernel
<cjwatson> I don't think another kernel upload for this is likely to be an option unless there are further critical problems
<BenC> cjwatson: I can do it pretty quickly now, and test it
<cjwatson> ok, thanks
<Nafallo> epoch :-/
<cjwatson> Nafallo: people get hung up about epochs, but shouldn't
<cjwatson> BenC: ok, that works too, but it's Sunday so ...
<Nafallo> well, they are evil :-P
<BenC> epochs are a dpkg gift above
<cjwatson> Nafallo: no they aren't
* cjwatson -> bed
<Nafallo> so we might not want to sync with Debian at some point then I take it :-)
<BenC> cjwatson: good night
<Nafallo> night.
#ubuntu-kernel 2008-04-07
<TomJaeger> Can bug #124406 please be assigned to someone?
<ubotu> Launchpad bug 124406 in ubuntu "Keyboard keys get stuck and repeat (Feisty, Gutsy)" [Undecided,Confirmed] https://launchpad.net/bugs/124406
<TomJaeger> Also, importance should be "High"
<tjaalton> TomJaeger: so it's a kernel bug? I'll mark it as such
<TomJaeger> Yes it is
<TomJaeger> it's a scheduling issue
<TomJaeger> thanks
<tjaalton> yep, done
<kraut> moin
<dhaval> tjaalton, are you sure that patch fixes it?
<tjaalton> dhaval: no
<dhaval> tjaalton, i don't think that is the right fix. that patch if for the group scheduler which has not been in 2.6.22 days which is the timeframe where it has been see.
<tjaalton> dhaval: I'm not the one who did the triaging, contact Tom Jaeger
<dhaval> i have responded to the bz thread
<tjaalton> ok
<evand> Would someone from the kernel team with a free moment please provide any insight they can on bug 204133.  Thanks in advance.
<ubotu> Launchpad bug 204133 in wubi "wubi install unusable - Buffer I/O error on device loop0" [High,Confirmed] https://launchpad.net/bugs/204133
<rtg> evand: that looks like a good one for cking to noodle over.
<cking> rtg:  OK I'll pop that on my todo list... 
<evand> cking: thanks!
<cking> I start looking into in a mo.
<Ng> rtg: could your comment (#8) from bug 191338 apply to bug 211556?
<ubotu> Launchpad bug 191338 in cmap-adobe-japan2 "Please sync cmap-adobe-japan2 0+20020208-4 (multiverse) from Debian unstable (non-free)." [Wishlist,Fix released] https://launchpad.net/bugs/191338
<ubotu> Launchpad bug 211556 in linux-backports-modules-2.6.24 "dmesg spam from updated iwl driver" [Undecided,New] https://launchpad.net/bugs/211556
<Ng> err
<Ng> I mean bug 191388
<ubotu> Launchpad bug 191388 in linux-ubuntu-modules-2.6.24 "syslog is spammed with " wme:wme_qdiscop_enqueue ht_queue=4,queue=2 pool=0xF qdisc=ffff81007c4548c0" on hardy" [Medium,Confirmed] https://launchpad.net/bugs/191388
<rtg> Ng: its next on my todo list for this morning.
<Ng> sweet, thanks :)
<cking> rtg: ...just need to get a Windows system first to do this one :-(
<rtg> cking: I have a bunch of XP disks, but I'm in the same boat, e.g., no windows boxen.
<cking> ..I don't even have any XP disks - my laptop came with Linux pre-installed :-)
<rtg> soren: can you respond to https://bugs.edge.launchpad.net/ubuntu/+bug/207098
<ubotu> Launchpad bug 207098 in linux "i915 drm driver fails to hibernate with certain i855's" [High,Triaged] 
<Ng> does l-u-m use a release or snapshot of alsa?
<rtg> Ng: 0.1.16
<Ng> rtg: ta
 * Ng looking forward to building his own lum with a snapshot alsa. not ;)
<soren> rtg: Done.
<rtg> soren: thanks.
<_MMA_> I get "-1 Invalid module format" when trying to load the VirtualBox modules for -rt. Should that be a bug filed against -rt or the VB modules?
<BenC> _MMA_: what does dmesg say?
<_MMA_> Sorry. Error is "-1 Files exits"
<BenC> anything interesting from the kernel?
<_MMA_> BenC: Id most likely have to read up more to know how to find out. I just try to load the module manually from a terminal and that what it tells me. "insmod: error inserting /lib/modules/2.6.24-14-rt/misc/vboxdrv.ko ': -1 Files exits"
<_MMA_> Maybe I should just email Alessio. :-/
<BenC> sounds like it is already loaded
<BenC> dmesg might show some info
<BenC> grep vbox /proc/modules
<BenC> See if it is already there
<rtg> Ng: just uploaded http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lbm.git;a=blobdiff;f=debian/changelog;h=317fc6067758b38a7d565b687d2eb895424dd059;hp=aea6b3f549e3e97e965c81b230184f405e6f6692;hb=5d519cd93608678a686f67e3ac083d5dfc88679e;hpb=f41126e18c2f9b4988430e9de767650f09482e74
<Ng> rtg: outstanding, thanks :)
<asabil> hi all
<asabil> I am having troubles with a thumbdrive
<asabil> here is the dmesg output : http://pastebin.com/m49b74fc3
<BenC> asabil: you'll need to better describe what the "trouble" is
<asabil> I plug the thumbdrive
<asabil> and it doesn't get detected at the udev level
<asabil> actually a cdrom get detected instead
<asabil> so there is a /dev/scd1
<asabil> but not /dev/sdb
<asabil> I heard about those thumbdrives using something called U3
<asabil> this is probably one of them
<asabil> BenC: do you need any more questions ?
<asabil> s/need/have/
<stgraber> asabil: that's weird, last time I tried one of these U3 devices with my lappy it appeared as both a cdrom and a standard HDD partition
<stgraber> asabil: yours seems to only show the cdrom part
<asabil> yep
<asabil> and I think there is something missing in udev
<asabil> a missing rule maybe ?
<asabil> because the dmesg output says that both are detectec
<BenC> asabil: I'm thinking more like usb-storage isn't detecting the hdd part at all
<BenC> asabil: Otherwise, you would see it in the dmesg
<BenC> asabil: It's likely that the driver (which is what the cdrom device contains) is needed, even on windows...and that the linux usb-storage driver doesn't support it
<asabil> BenC: I do see it in the dmesg
<asabil> USB Mass Storage support registered.
<lool> w00t
<lool> I just noticed that packages like linux-headers-lbm-2.6.24-15-server seem to use linux-ubuntu-modules in the control templates
<lool> Should probably be linux-backports-modules instead
<lool> Also, would someone be so kind to process linux-restricted-modules-2.6.24-15-lpia for lpia in NEW?
<ogasawara_> BenC:  looks like the fixes for bug 202065 and bug 201431 (basically enabled cx88-alsa and saa7134-alsa in lum) are flushing out some kernel oops now.  see bugs 212100 and 212271.
<ubotu> Launchpad bug 202065 in linux-ubuntu-modules-2.6.24 "[hardy] cx88-alsa.ko missing" [Medium,Fix released] https://launchpad.net/bugs/202065
<ubotu> Launchpad bug 201431 in linux-ubuntu-modules-2.6.24 "saa7134-alsa module missing in linux-image-2.6.24-12-generic" [Medium,Fix released] https://launchpad.net/bugs/201431
<ubotu> Launchpad bug 212100 in linux "Kernel Oops: NULL pointer dereference caused by hald" [High,Triaged] https://launchpad.net/bugs/212100
<ubotu> Launchpad bug 212271 in linux-ubuntu-modules-2.6.24 "2.6.24-15-generic: saa7134-alsa makes HAL to fail" [High,Triaged] https://launchpad.net/bugs/212271
<mkrufky> actually, thats wxactly why i joined the room just now
<mkrufky> ...but im away from that machine right now and cant test 'till later.
<Amaranth> Is there any reason the libGL and etc files in nvidia-glx-new have a different md5sum from the files directly from the .run file?
<crimsun> ogasawara_: #212960 has the appropriate fix
<crimsun> ogasawara_: I've added that he needs the matching fix in _free(), but aside from that, it's fine.
<ogasawara_> crimsun: cool, thanks.
<crimsun> np
<tjaalton> Amaranth: seems that something touches the files after they've been installed in the package directories.. I've also confirmed that using the nvidia installer fixed the pink shadows bug with my 8600GT
<tjaalton> hm, dh_strip maybe
<tjaalton> eheh, "dh_strip -s -X1.0.$(nv_release) -X1.0.$(nv_legacy_release) -Xtls_test"
<tjaalton> something missing?-)
<tjaalton> (nv_new
<tjaalton> )
<tjaalton> oh, those excludes were broken anyway..
<tjaalton> since the versioning has changed.. uh
<mkrufky> guys, for the cx88-alsa you just need to pull in the alsa changes for that module from the alsa guys
<mkrufky> bug 212100 , bug 202065
<ubotu> Launchpad bug 212100 in linux "Kernel Oops: NULL pointer dereference caused by hald" [High,Triaged] https://launchpad.net/bugs/212100
<ubotu> Launchpad bug 202065 in linux-ubuntu-modules-2.6.24 "[hardy] cx88-alsa.ko missing" [Medium,Fix released] https://launchpad.net/bugs/202065
<mkrufky> building the new module from linuxtv.org fixes the problem because it's being built on the local system using the local kernel & alsa headers, thats why using linuxtv.org modules fixes it
<Amaranth> tjaalton: Someone brought this up to me and claimed it was the cause of some compiz problems
<Amaranth> I'd like to either fix it or prove them wrong :)
<tjaalton> Amaranth: well, I think that the libraries should not be stripped.. that could cause problems
<tjaalton> and that's exactly what has happened since the versioning has changed (and nv_new has been stripped right from the start)
<Ng> tjaalton: seen any suspend/resume regression with 2.6.24-15?
<Ng> reactivating the disk fails the first two times, and it waits 5 seconds each time
<Ng> it's super quick on -14 and earlier
#ubuntu-kernel 2008-04-08
<Ng> going by hardy git changes, there's not many things that could cause that
<lamont> BenC: you around?
 * lamont kinda guesses 'no' and will poke him in the morning
 * lamont wonders if he should care that his ide drive went from hda to sda with the upgrade to hardy
 * lamont wanders
<soren> Does kernel-wedge take care of dependencies?
<soren> ...or will it happily put modules into udebs that depend on symbols in modules that are not installed?
<soren> My money's on the latter.
<tjaalton> Ng: no, suspend/resume works fine here..
<Ng> tjaalton: weirdly it's  started working fine again. i hate bugs like this :/
<kraut> moin
<raju> how to detect the smart card in ubuntu
<raju> how to use the smartcard in my l;aptop
<raju> how to use the smartcard in my laptop
<amitk> raju: for support go to #ubuntu or #ubuntu+1
<elmo> is there a bug about -15 failing to suspend/resume?
<elmo> -14 worked flawlessly
<abogani> elmo: IMHO Yes (https://lists.ubuntu.com/archives/kernel-team/2008-April/002260.html)
<Whoopie> hi, any chance to get a small patch for ipw2200 into the linux-image to fix the rtap interface regression? http://aur.archlinux.org/packages/ipw2200-inject/ipw2200-inject/ipw2200_rtap_fix.patch
<Ng> Whoopie: is there a launchpad bug about it?
<Whoopie> Ng: it's also on the wireless ML: http://article.gmane.org/gmane.linux.kernel.wireless.general/13181
<Whoopie> checking now for a bug report.
<Whoopie> Ng: no, there's no launchpad bug report.
<Ng> Whoopie: I reckon it'd be worth filing one with the patch attached and a rationale of why you want it included
<Whoopie> Ng: question is if it'S worth opening a report for it.
<BenC> Whoopie: most likely it wont make the freeze, so no
<Whoopie> BenC: ok
<cjwatson> I bounced bug 210200 over to you guys, since it seems kernel-side
<ubotu> Launchpad bug 210200 in linux "cdrom-detect fails for HP DL145 in hardy beta" [Undecided,New] https://launchpad.net/bugs/210200
<cjwatson> Ng is in the datacentre at the moment and could do some remote-hands testing if anyone would like to take that on
<cjwatson> I think I've done as much as I can from the installer diagnosis point of view
<cjwatson> I was wondering if http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=6ddd6861 might have something to do with it (this system uses pata_serverworks, and I *think* the CD is attached to that), but it's a long shot
<mjg59> cjwatson: dmesg would be helpful
<cjwatson> err, I think I mean http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commit;h=9256d0b8cb13a854c0a29861ce37a252f7712568
<cjwatson> Ng: can you get dmesg out somehow?
<cjwatson> there was nothing in /sys/block other than ram*
<mjg59> cjwatson: No hard drives, either?
<cjwatson> mjg59: hard drives were detected when he booted the desktop CD (though it still couldn't find the CD)
<mjg59> cjwatson: That bug doesn't /look/ like it'd cause this failure
<cjwatson> mjg59: the alternate CD's initrd doesn't have hard disk drivers; it relies on loading those from the CD
<mjg59> cjwatson: Ah, ok
<cjwatson> Ng: FYI the initrd has usb-storage, so you might be able to save dmesg off to a USB stick
<cjwatson> if you load modules by hand and stuff
 * Ng returns from lunch
<Ng> cjwatson: excellent, I have some usb storage with me, I'll give that a go
<Ng> cjwatson: mjg59: I'll pull out dmesg and lspci - anything else worth nabbing?
<cjwatson> tarball of /sys?
<cjwatson> oh, wait, busybox-udeb's tar doesn't have the create option compiled in
<Ng> hrm, does the initrd not have vfat?
<Ng> I can reformat my stick I guess. it's just my phone ;)
<zul> BenC: is it too late for an update for iscsitarget in lum?
<BenC> zul: quite possibly
<zul> dang ok...ill just fix the one in universe then
<mjg59> Ng: dmesg and lspci should be fine
<Ng> k
<mjg59> Ng: Oh, lspci and lspci -n
<Ng> sure. I was going to do lspci and -vvnn :)
<cjwatson> Ng: I think the reason we had to take fat out no longer applies, so I'm going to put it back for hardy
<Ng> awesome :)
<cjwatson> (it was because it had been borged into fs-secondary-modules, which was too big for those initrds)
<makx> cjwatson: thanks for the initramfs-tools push upcoming 0.92 should be an easier baseline for ubuntu sync
<maks_> :)
<cjwatson> good stuff
<abogani> elmo: I hope that Tim will revert fix, which cause regression, as soon as possible. (https://lists.ubuntu.com/archives/kernel-team/2008-April/002266.html)
<Ng> ok, I've had to go with syslog rather than dmesg because the dmesg buffer seems to be pretty small
<mjg59> Ng: Ok
<mjg59> Back in 15 minutes
<Ng> it has what looks to me like the start of the kernel messages though, so it should be fine
<Ng> and, err, ignore all the usb madness towards the end, that's me fighting to get anything mounted ;)
<Ng> cjwatson: mjg59: syslog and various forms of lspci added to the bug
<BenC> We're supposed to have an IRC meeting now, but I think we'll pass in favor of just working on the current milestone list for Hardy RC
<smb_> BenC: ok, ack.
<mjg59> Ng: Ok. Apr  8 14:53:44 kernel: [   84.248978] ata1: SRST failed (errno=-16) looks like the most meaningful aspect of that.
<mjg59> Ng: Has any version of Ubuntu installed on this hardware?
<Ng> mjg59: I don't think we've tested anything older than 8.04beta, but I have a 6.06.2 CD here I could try
<mjg59> Ng: If you could, that would be helpful
<Ng> sure
<Ng> mjg59: huh, 6.06.2 can detect the CD drive
<Ng> the installer seems to be pretty seriously confused though
<mjg59> Ng: Ok. Can you grab syslog from 6.06.2?
<Ng> sure. I want to do another boot of it to figure out why it ran a CD test and then rebooted
<Ng> I'm tempted to blame vncviewer stealing input when I wasn't looking
<Ng> gar, it's taking ages to do anything and doesn't seem to want to actually get far enough in the boot to give me a console, but it did the first time
<Ng> I can see hda: ATAPI 24X DVD-ROM drive though, so the kernel is definitely seeing it
<Ng> cjwatson: can i do a break=mount style thing with the installer?
<Ng> (6.06.2 installer, that is)
<cjwatson> BOOT_DEBUG=3
<Ng> anywhere on the cmdline?
<cjwatson> yeah
<cjwatson> gives you a shell at a couple of different stages
<Ng> cool, ta
<Ng> mjg59: sorry for the delay, it turns out it wasn't broken, it just needs about 15 minutes to boot or something crazy like that
<Ng> dmesg from 6.06.2 server installer added to the bug
<Ng> cjwatson: mjg59: is there any value in proceeding any further with this dapper install?
<Ng> I'd quite like to get going, but if there's anything else you need I'm happy to get it
<Ng> it took a while to detect disks, and is now just past that with a blank blue screen
<Ng> I reckon dapper is using an older idea driver for this, because the CD shows up as hda
<Ng> idea?! IDE
<bfallik> anyone around to help with bug 214002?
<ubotu> Launchpad bug 214002 in linux-source-2.6.22 "uhci_hcd host controller halted, very bad" [Undecided,New] https://launchpad.net/bugs/214002
<mario_limonciell> rtg, while you are touching iwl3945, would you consider taking a look at this too: http://git.kernel.org/?p=linux/kernel/git/rchatre/iwlwifi-2.6.git;a=commit;h=ec2ce7fc7890b37d564a274513d8d99ed4edb9ac ?
<_MMA_> Hi all. I can confirm bug 208247. What info should I add to help diagnose?
<ubotu> Launchpad bug 208247 in linux-restricted-modules-2.6.24 "nvidia-glx-new crashes when using rt kernel" [Undecided,Incomplete] https://launchpad.net/bugs/208247
<mjg59> Ng: Ok. The srst thing is libata specific - the old IDE code doesn't do srst at all.
<mjg59> Ng: The cases I can find suggest that this is actually an issue with teh drive rather than the controller, though
<mjg59> Ng: I'm not sure that there's going to be a trivial fix, I'm afraid
<Ng> mjg59: is there a kernel cmdline option that can make it not use libata?
<mjg59> Ng: I don't /think/ we build the old driver at all
<Ng> ah
<mjg59> Ng: Yeah, just the libata one
<Ng> mjg59: so in terms of not a trivial fix, if it misses release then it misses release. is it something we could likely fix in a point release?
<mjg59> Ng: We could do with working out whether it's the controller or the drive. Are you able to swap out the drive with another one?
<Ng> mjg59: I'll need to check, but I'd say it's quite likely I can
<mjg59> Ng: Ok, that would be helpful
<Ng> the hp servers all seem to use similar laptop drives
<mjg59> If it's the drive, in the worst case we can have some blacklist bollocks
<Ng> mjg59: what would we blacklist? we don't appear to be able to detect the drive ;)
<mjg59> Ng: Hah. Yeah, good point - it's failing before we send the identify
<mjg59> Well, it'd let me narrow down the issue :)
#ubuntu-kernel 2008-04-09
<AliRezaTaleghani> hello
<AliRezaTaleghani> i use hardy, 
<AliRezaTaleghani> is their any i686-smp kernel for me?
<AliRezaTaleghani> no idea?
<kraut> moin
<Ng> mjg59: so. the optical drive in the DL145 is 9.5mm where all the other HPs we have seem to be about 12mm
<Ng> ie I have nothing to swap it out for :/
<FXMaveric> hello
<Ng> cking: the DL145 bios does have an option to present the SATA controller as PATA, trying that now
<Ng> cking: doh, it's still full of fail
<cking> Ng: bummer
<Ng> I'll poke around the bios a little more to check there isn't anything else along those lines
<Ng> normally that option does seem to specifically refer to AHCI, this just offers SATA/PATA
<cking> The main problem is that the controller subsystem has changed a lot - so it's one of those corner issues where a quirk may need to be added :-(
<elmargol> Hi if I inset my proxim wireless pccard into my laptop syslog is spammed wifi0: hardware error; resetting 
<elmargol> and i get 100% system cpu usage
<elmargol> The same card works on my other laptop
<Ng> cking: hmm, no other options in the main system bios
 * Ng checks for a sata controller bios
<cking> Ng, Annoyingly, there are some possible kernel module tweaks one could try, but I don't know how to pass them down to the module on a LiveCD.
<Ng> sata controller bios has no options
<Ng> cking: I could at least try the options from the busybox shell
<cking> Ng: Give me a little while and I will find some appropriate runes.
<Ng> sure
<Ng> I'm just going to have a quick check to see if there's an updated bios or something
<cking> Ng: I suggest trying: options libata noacpi=1
<Ng> cking: I'm going to try booting a gutsy alternate installer to check this definitely isn't a regression. beyond that I should hand this off to the server team - they can netboot it and yous can all get it seeing the CD drive. I don't think physical presence or actual CDs are necessary here since the issue is the thing not even being detected
<Ng> (I will check that it netboots correctly though ;)
<cking> Ng: OK makes sense.
<xivulon> hi cking
<cking> xivulon: hi there. How can I help?
<xivulon> I believe that evand mentioned some issues with wubi and buffer i/o error
<xivulon> I did some testing yesterday and found out the issue, but would appreciate some further help
<cking> xivulon: good - I've been stuck trying to obtain a working XP system to experiment further.
<xivulon> no need anymore :)
<xivulon> this is the new problem
<xivulon> basically wubi uses a nested filesystem, one problem is that data loss in the host filesystem (generally ntfs) may result in journal disruption in the hosted filesystem
<xivulon> to minimize the problems, Szaka suggest to use sysctl settings that would minimize the use of cached disk data
<cking> That makes sense
<xivulon> what happened is that new version of the kernel (12) does not like the settings we always had
<xivulon> and that resulted in the buffer I/O errors
<cking> OK - any details on the settings being used?
<xivulon> sure one sec
<xivulon> https://bugs.launchpad.net/wubi/+bug/204133/comments/12
<ubotu> Launchpad bug 204133 in wubi "wubi install unusable - Buffer I/O error on device loop0" [High,In progress] 
<xivulon> so first point is: I am quite sure those settings used to work in the past, and I do not know if that is any reason of concern kernel-wise
<xivulon> second point is: what would be a reasonable/safe set of settings to use in order to minimize hardreboot problems?
<cking> xivulon: OK I will put some effort in this afternoon to see if they work.
<xivulon> cking thanks, please post anything you find in the bug
<cking> xivulon: 2nd point: good question. This needs some figuring out :-)
<xivulon> great, looking forward to that!
<cking> xivulon: Thanks for getting it so far. I got stuck on the XP enviroment to test this out, so you've helped me a huge amount.
<cking> ..I also got side tracked on other stuff too :-(
<xivulon> ah that wasn't strictly necessary, provided you have an ntfs partition (virtual or not) you can test on that...
<xivulon> I could have provided a skeleton for the rest
<cking> xivulon: I'll keep you posted... your help has been invaluable - collect 1 free virtual beer :-)
<xivulon> ah thank you for looking into this!
<cking> np - it's what we are here for.
 * cking_lunch time for food
<Ng> cking: 7.10 fails in exactly the same way as 8.04 with the same SRST error. 
<rtg> zul: Please send a note to the kernel mailing list when you get xen patched. I won't be on IRC much today.
<zul> rtg: sure...im doing a test build right now
<rtg> zul: thanks
<amitk> rtg: you in austin?
<rtg> amitk: yep, getting ready to head out.
<mjg59> Ng: Arse.
<smb> zul: Are you currently working on bug 208281?
<ubotu> Launchpad bug 208281 in iscsitarget "iscsitarget will not compile" [Undecided,New] https://launchpad.net/bugs/208281
<zul> smb: Im trying to get a ffe for it for the universe one but yes I was
<zul> smb: do you want me to fix the lum one?
<smb> zul: I was about to ask whether I should do something or what. :) 
<zul> smb: I was going to send a patch today once I fix this ebox problem :)
<smb> zul: I guess soon enough. So I rather take care of your xen updates. 
<zul> smb: ok
<zul> xen updates builds fine and boots fine here
<smb> zul: Ok, thanks
<zul> smb: got an update but just have to see if it builds
<smb> zul: ok
<munckfish> Hi, re ps3-kboot update. Good new is I can now get the hardy daily live to boot on PS3, however, although the install kernel boots, the graphics are all messed up.
<munckfish> and when it reaches X it's going to a sort of messed up failsafe 
<munckfish> pseudo terms are also messed up
<munckfish> I need to quickly work out if this is something left wrong from kboot or whether it's a new issue
<munckfish> does anyone have any tips or links on how to debug the framebuffer graphics we use while booting up?
<munckfish> I'm completely green to this whole part of Linux at the moment
<infinity> Hrm, is anyone doing anything about the FTBFS of linux on all x86 arches (broken virtio configs)?
<infinity> soren: I suppose the changelog might have you to blame...
<amitk> infinity: it'll happen later today
<infinity> amitk: Kay.  I was just about to kick off a rebuild test, and having the kernel FTBFS annoys me. :)
<amitk> heh
<IntuitiveNipple> Building the hardy git 'generic' flavour tonight I'm getting "previous or current ABI file missing" - it's building 2.6.24-16.29, is that correct (CONCURRENCY_LEVEL=4; fakeroot debian/rules  binary-generic binary-header) ?
<amitk> IntuitiveNipple: it needs an ABI bump, will happen later today
<IntuitiveNipple> Thanks Amit - I thought that was the case haivng looked at debian/abi/* but wanted to be sure
<IntuitiveNipple> Didn't realise until the end of a long build... was trying to avoid starting from scratch with AUTOBUILD :)
<amitk> IntuitiveNipple: you can add a skipabi=1 to the end to force a .deb if you want
<IntuitiveNipple> Hmmm, I did try that but got ignored... thanks for that, I'll try it again later to see if I got it wrong somehow
<IntuitiveNipple> ahh! I only put "skipabi", forgot the "=1" bit :p
<sourcemaker> when I use vpn on linux... I receive the following message:  martian source, ll.. what's wrong?
<sourcemaker> and my application does not work then
<IntuitiveNipple> sourcemaker: A martian source is an invalid, non-routeable address... You'd be better off asking in ##linux or #ubuntu
<sourcemaker> IntuitiveNipple: ok... thanks
<amitk> IntuitiveNipple: thanks for the wiki update
<IntuitiveNipple> you're welcome - I've lived on that page before so every little helps :)
<IntuitiveNipple> The only thing I've left to work out is how to do a make-kpkg out-of-tree build 
<IntuitiveNipple> Hopefully this build will give me a pure Ubuntu kernel with the i450NX patch in so I can sign off the failed PowerEdge server
<elmo> IntuitiveNipple: the patch in that b ug report won't work on the server I originally reported it against, though, will it?
<IntuitiveNipple> elmo: No, but if you want to provide the dmidecode output of the server, it can be added. I didn't want to add anything I'm not 100% sure about
<IntuitiveNipple> It'd be best to test each one - unfortunately there's not an easy way aside from building a kernel that ignore the i450nx fix entirely.
<elmo> IntuitiveNipple: I don't have an i450 in the machine though?
<elmo> is what I meant
<IntuitiveNipple> Did you manage to capture a boot log ?
<elmo> I think there's a screenshot in the bug
<elmo> oh, yes
<elmo> because, haha!, if you wait 30+ minutes, it eventually finds the drives
<elmo> and you can continue the boot
<IntuitiveNipple> I was wondering more about a full serial console log, but, looking at your screenshots the aacraid module is loading so it's possible the causes of the "Disk offlined" messages are different. I switched to bugzilla in solving the bus issue - I maybe should create another Ubuntu bug report especially for this
<elmo> yeah, we haven't upgraded firmware yet either, to rule that out
<elmo> IntuitiveNipple: how did you update the firmware btw? 
<IntuitiveNipple> I had some fun today - discovered the PERC2 is also a HP NetRAID 4M (Adaptec AAC364) and got one from ebay for Â£18!
<IntuitiveNipple> Downloaded the Dell firmware DOS-floppy installer .exe, ran it from wine and wrote the files to the two floppies, then used them to update it
<IntuitiveNipple> there's "afu.exe" (adaptec firmware updater) on the boot floppy
<IntuitiveNipple> The battery on the PERC2 cache was failing and Dell don't do a replacement - got the NetRAID 4M, found a HP replacement part # on the battery, they cost US$128 minimum, so done well on that server today!
<tormod> hi, bug #192772 could need some sponsor love before the freeze. It's assigned to Tim Gardner but he seems to hide.
<ubotu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.8+svn1851+dfsg-1 from Debian main unstable" [Low,In progress] https://launchpad.net/bugs/192772
<soren> rtg: Did you get the kernel build sorted out?
<smb> rtg might still be in transit
<soren> smb: In transit? Fro/to?
<soren> from, even.
<smb> soren: From Linux Founation
<soren> smb: To? :)
<soren> smb:  I thought he'd be here until tomorrow sometime.
<smb> soren: but the build should be ok now. 
<soren> Ok. For a second I thought I was missing a patch, but looking at the changelog, it must be there already, so I'm slightly more calm now.
<smb> soren: Hm, got the impression he was travelling today, but I might be totally wrong
<smb> soren: We had two updates from alessio and chuck to get xen and rt building again
<soren> smb: Alright.
<IntuitiveNipple> elmo: I've redone the i450NX bus issue as bug #214814
<ubotu> Launchpad bug 214814 in linux "BUG: soft lockup - CPU#0 stuck for 61s!" [High,In progress] https://launchpad.net/bugs/214814
<Amaranth> tjaalton: so should i file a bug for the dh_strip stuff? I've got a report that installing from the .run file fixes the yellow/pink/etc shadows in compiz so it seems stripping the files is causing this problem
<Amaranth> oh, you probably aren't here :P
<elmo> IntuitiveNipple: ah, ok, thanks.  shame.  I don't suppose you want to debug by PE for me? ;-)
<IntuitiveNipple> Well whilst I'm on a roll... want to PM me about it?
<elmo> IntuitiveNipple: heh, I was mostly kidding - thanks though
<IntuitiveNipple> :) It looks simply enough
#ubuntu-kernel 2008-04-10
<blueyed> In case there's another upload for -meta, please include the fixes for bug 197632
<ubotu> Launchpad bug 197632 in linux-meta "Error in linux-image-xen package description" [Medium,Triaged] https://launchpad.net/bugs/197632
<tjaalton> Amaranth: actually, I've tried copying all the libs from an extracted installer, but it didn't help. So maybe the problem is somewhere else, but it's definately in our lrm
<tjaalton> Amaranth: the pink-shadows bug already has a comment from me that using the installer fixes the shadows
<Amaranth> ah
<tjaalton> it could fix something else too..
<Amaranth> well someone else filed the bug and pointed me to it, i just set the priority and such :)
<tjaalton> but dropping dh_strip might be wise anyway.. there's not much saved by it
<hti_pro> need help building kerne
<hti_pro> kernel
<hti_pro> when i build the package it grows to about 2GB
<hti_pro> anyone awake
<hti_pro> i am using the following guide:    http://howtoforge.com/kernel_compilation_ubuntu_p2     If anyone wakes up and has an idea pm me
<kraut> moin
<mvo> hm, 2.6.24-15-386 does not boot on my test system (cant find the root fs), -generic does - any hints? should I file a bug?
<amitk> soren: could you have a look at what config you want for openvz
<Ng> are there any more kernel rebuilds now before release?
<amitk> Ng: there should be, but I am a awaiting some input from rtg or soren for the openvz failures.
<Ng> amitk: thanks. I just checked shortlog and the patch I was wondering about has been reverted, so it's all good :)
<soren> amitk: Is thiss still relevant?
<prana> hello; triaging bug 213308...i believe it demonstrates a regression for perhaps a very small case of hardware...should I mark it confirmed and assign it to the kernel team?
<ubotu> Launchpad bug 213308 in linux "Update from 2.6.24-12 to -14 or -15 results in ata SRST failed (errno=-16)" [Undecided,Incomplete] https://launchpad.net/bugs/213308
<prana> when you read the bug report, you can ignore everything except the comments from the original reporter and Emil Sit (me).
<Ng> prana: I see you're trying to get her to mount a USB device to get some debugging info out of the busybox shell she gets left in?
<Ng> prana: it should be fixed for hardy, but at least as of daily hardy images a couple of days ago, the vfat module isn't in the initrd
<prana> Ng:i did try to do that though i don't think itwas successful. i found a workaround to the specific problem that was causing the boot failure on the web that seems to work.
<Ng> yeah, it wasn't successful because there's no vfat module :)
<amitk> soren: fixed
<Ng> I hit exactly the same situation on a server, but with a CDROM throwing the SRST error
<prana> Ng: so i guess we don't have a dmesg trace from what the sys looked like in the bad state.  if a newer initrd includes vfat support, it might be possible to get the trace.  or we could perhaps store the output on one of her ntfs partitions.
<Ng> prana: there's dmesg and lspci info on the one I found
<hti_pro> any idea if this bug will be fixed in hardy release  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/110636
<ubotu> Launchpad bug 110636 in linux-source-2.6.22 "hdparm - cannot set dma on IDE hard drive that works via pata" [Medium,Incomplete] 
<prana> Ng: ah, but i think those are from the -12 kernel, not the -14 or -15 kernels.
<soren> amitk: Cool, thanks.
<Ng> prana: I hit the problem with the beta release and with daily images from earlier this week, which should have been -15
<prana> Ng: anyway, it seems like the problem does exist so is marking it confirm and assigning to kernel team at this point reasonable? or would kernel team want more info first?
<Ng> prna: it's Bug #210200 
<Ng> pass
<Ng> I'm not on the kernel team :)
<prana> hm. ok, gotta rnu for a bit. will check back later.
<hti_pro> or is there a kernel I can switch too that didn't have the prob
<amitk> BenC: I've got classmate suspending with 2.6.24.2 + a patch but not with ubuntu tree + patch. This is going to require some time to bisect/debug. How long do I have?
<hti_pro> nothin on #110636???
<BenC> amitk: we're under freeze now, so you are very limited
<BenC> amitk: likely wont make RC
<amitk> BenC: i meant after rc
<Ng> rtg: any idea what could be causing https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/215102?
<ubotu> Launchpad bug 215102 in linux-ubuntu-modules-2.6.24 "switching from wireless to wired causes wireless confusion" [Undecided,Confirmed] 
<Ng> I'm moderately sure I've not seen that before, but I don't switch between the two very much without suspending because I'm going home, and suspend means unloading the modules
<rtg> Ng: when you do that, is the wireless interface (probably wlan0) UP or DOWN ?
 * Ng plugs back into wired to test
<Ng> rtg: UP
<rtg> Ng: I assume this is a WPA enabled AP in the office?
<Ng> wlan0 and wmaster0 are up, although there's no IPs and iwconfig suggests it's not on an ESSID, but is on an AP
<Ng> yeah
<rtg> Ng: OK, that is likely the cause. Please add that to the LP report and I'll forward it to Rolla.
<Ng> k
<BenC> rtg: I saw you on a linux.com report from the conference
<rtg> Ng: I think NetworkManager should down the interface.
<BenC> rtg: you were standing in the background talking to someone during the entire video
<Ng> rtg: I kinda agree, or at least do iwconfig ap off
<rtg> BenC: just by showing up :)
<rtg> Ng: you could test the theory by DOWN'in the interface.
<Ng> rtg: ok, will cycle again to test that shortly, I just tested iwconfig ap off and that's stopped the syslog messages
<Ng> rtg: looks like ifconfig wlan0 down doesn't completely stop it
<Ng> all added as comments
<rtg> Ng: thanks. Maybe you should bug asac as well?
<Ng> yeah, that was my next move :)
<BenC> So was the openvz ftbfs fixed in 16.30 as well?
<amitk> BenC: yes
<BenC> commit cd5576d74945916aa88a0476fe07a059b2f24ceb
<BenC> Author: Tim Gardner <tim.gardner@canonical.com>
<BenC> Date:   Thu Apr 10 06:24:48 2008 -0600
<BenC>     UBUNTU: Accidentally copied amd64 config over i386
<BenC>     Ignore: yes
<BenC>     
<BenC>     Really fix openvz configs for virtio.
<BenC>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
<BenC> just wondering why the commit was ignored...would be useful info for the changelog
<xivulon> cking hi
<cking> xivulon: hi there
<xivulon> thanks a lot for your help really appreciated
<xivulon> added a comment to #204133
<xivulon> what is your opinion on that?
<cking> just a second..
<lamont> xivulon: wondering if you can help with testing the fix for bug 206113
<ubotu> Launchpad bug 206113 in util-linux "Wubi install cannot create swap space (8.04 Beta) [Regression from alpha 6]" [Undecided,New] https://launchpad.net/bugs/206113
<xivulon> lamont can only do that tonight (am at work now), but I cannot reproduce that bug
<xivulon> can only test if it works
<cking> xivulon: not sure about it. Let me ponder on it for a few minutes over a strong cup of coffee. I was up until past midnight working on this one so head is a bit fuzzy. 
<xivulon> cking, sure
<lamont> xivulon: sure
<lamont> I verified that mkswap works when there aren't any errors already... :-(
<lamont> but more eyes would be wonderful
<xivulon> lamont one potential issue wubi installations may have is that the swap file might be fragmented
<xivulon> not sure about the implications of that
<cking> xivulon: I need to play with the remount options and see if this works. I will keep the bug report updated with my findings
<lamont> xivulon: that could possibly make for short reads, I suppose
<lamont> which we should handle now
<xivulon> cking as mentioned 186117 and 186114 are the related bugs in this case
<cking> xivulon: perhaps a sync is required before / is remounted r/o. 
<xivulon> cking adding syncs shouldn't be problematic, see last comment in 186117 though
<cking> will do
<cking> ..ah ntfs remount r/o was broken and so the regression is not really a regression - just stops one from cutting off a branch while standing on it type of safeguard
<cking> ..no way of using a memory based file system for some of this so that we can umount the ext3 fs cleanly and not have it as / ? 
<xivulon> do you mean we should have the remaning sysvinit in a memory fs, and unmount ext3 and host completely?
<xivulon> cking I wouldn't know how to implement that in a non invasive way, I'd think that the easiest root might be to apply the patch in #186114
<xivulon> but I am not sure about the implications mentioned by Szaka in 186117
<cking> xivulon: the worst case scenario is screwing up somebody's NTFS filesystem - which is something that must be avoided. It's kind of chicken and egg here.
<cking> mmmm.  / is dependant on /home, and /home must not be umounted. Is the remount of / ro causing the problem or is /home being umounted?
<xivulon> do you mean /host?
<cking> ...oops yes /home ---> /host my mistake - need more coffee
<xivulon>  / is in a file inside /host. During initramfs first we mount /host, then /root then mount move /host to /root/host
<xivulon> so after run-init /root -> / and /root/host -> /host
<xivulon> in umountroot we make everything r/o again (/ and /host)
<cking> ok.. and in umountroot what happens - does /host get umounted before / ? 
<xivulon> except that now /host is excluded because I was scared by szaka 
<xivulon> nothing is unmounted only remounted r/o
<cking> OK: .. remount / ro is OK, but then /host needs umounting before shutdown.
<xivulon> hmm no I do not unmount /host because that is equivalent to unmount /
<cking> ..well I think remouting / is OK :-)
<cking> maybe I'm missing something fundamental here, but something needs to sync and umount the NTFS filesystem (surely?)
<xivulon> well in a normal installation / is never really unmounted right?
<xivulon> so why is it required to unmount /host as opposed to remounting it ro?
<cking> ..yes but / is not normally loop'd back.
<xivulon> cking I do not think it is possible to unmount /host, at most you can remount /host and / r/o and then reboot
<xivulon> unless you use a memory fs
<cking> I could be wrong here, but I believe one needs to flush the ext3 file back to the ntfs filesystem otherwise one will see / getting corrupted. The blocks are still in memory and need to be written back before the ntfs filesystem is unounted
<cking> unounted --> umounted
<cking> ..the alternative is, as you say, use a memory fs.
<xivulon> making / (ext3) ro + sync would not ensure that?
<xivulon> and then making /host ro + sync
<cking> xivulon: I think making / (ext3) ro + sync may be enough.. but I am now 5% worried it may not be enough for a looped back file on ntfs - I've never toyed around with this before.
<cking> xivulon: It's worth tinkering with anyway. I think making sure the ext3 file on the ntfs partition is written back is more important than any of the vm dirty page hacks
<xivulon> absolutely
<xivulon> you can emulate without XP, by creating an ntfs partition and putting a file conating ext3 /
<xivulon> then add grub and boot using the ROOT=/dev/sdX LOOP=/path/to/loopfile arg
<cking> xivulon: perhaps you can write these notes in the bug report as a reference for anyone else facing this problem in the future.
<xivulon> that is in lower-case
<xivulon> will do
<cking> ..indeed. I've faked up some of that today and realised that one can umount the ntfs /host with the / still busy - hence screwing up / good and proper. 
<xivulon> you mean by manually unmounting /host or when rebooting? in the latter case I'd expect / to be ro reducing risks
<cking> ...manually forced umount of /host  which made me wonder what was happening in the real reboot scenario.
<cking> ..that is, it made me wonder if the loop mounted / was being screwed up because the blocks in the buffer cache were not being written back to /host when the system shut down.
<cking> xivulon: I need to go in 5 mins or so.. I have an somebody picking me up to fly some model planes..
<houdini> I've got what I think is a bug in the x64 builds of Ubuntu 7.10 and 8.4, but I'd like some help making sure it's not just me.  anyone willing to help for a few minutes?
<xivulon> cking sure
<xivulon> umounting host manually though will create problems
<xivulon> at the moment we have an obfuscation method
<houdini> the bug reporting guidelines suggest filing it as a kernel bug, so that's why I'm here
<xivulon> not in /media not in fstab only visible in /proc/mounts
<cking> xivulon:  is that enough to work on though? Do you think it helps enough to maybe get a little further?
<xivulon> yes ntfs + nested root file + grub is enough
<xivulon> for testing
<cking> OK. keep us posted! :-)
<cking> xivulon: I'm especially keen to know if one can actually get rid of the vm dirty hacks if the umount can be sorted out 
<cking> ..anyway. I need to go.
<blueyed> linux-server triggers the nvidia black window bug for me. Is this a bug with package "linux" or "linux-restricted-modules-2.6.24"? The different kernel config settings should be this: http://pastebin.com/m89666bc (no problems with linux-generic)
<blueyed> (using nvidia-glx-new)
<blueyed> Might be bug 214836
<ubotu> Launchpad bug 214836 in linux-restricted-modules-2.6.24 "lrm incorrectly installs nvidia-glx-new" [High,Triaged] https://launchpad.net/bugs/214836
<rtg> tjaalton: I finally have a kernel for -16. Can you upload LRM?
<tjaalton> rtg: sure, I'll do a couple of fixes too. stripping fglrx/nvidia seems to be pointless, since there's not much space saved and it could cause issues
<rtg> tjaalton: be very conservative, 'cause this is about the last upload for Hardy.
<Nafallo> :-)
<tjaalton> haven't yet found out why the lrm version of nv_new is broken compared to installing it by hand..
<tjaalton> rtg: of course :)
<rtg> tjaalton: thanks. 
<tjaalton> hmm, shouldn't envy be in universe?
<tjaalton> I mean, it's not in the archive
<tseliot> tjaalton: not yet but it should be there soon
<tseliot> in the meantime you can use my repository to install it:
<tseliot> http://albertomilone.com/wordpress/?p=185
<tjaalton> tseliot: ah right. does it use the upstream installer scripts?
<tjaalton> ok, I'll just try it out later today
<tjaalton> ..to find out if the pink-shadows issue is fixed with it
<tseliot> ï»¿tjaalton: it uses a customised version of the l-r-m with DKMS, CUDA, etc.
<tseliot> tjaalton: improvements which we can talk about in Prague
<tjaalton> yeah
<Nafallo> aaaaaaaaaaaaaaaa/win 30
<Nafallo> oops
<xivulon> Hi all, have a question
<xivulon> in a nested filesystem (loopfile) when I mount it with the sync option how does it work exactly?  
<xivulon> I mean if set sync for the nested filesystem does that also apply to the host filesystem?
<xivulon> so that the data actually hits the metal?
<tjaalton> tseliot: how do I make sure that I'm using the envyng-version of the kernel module?
<tseliot> ï»¿tjaalton: if nvidia-new-kernel-source is installed then EnvyNG's module will be loaded.
<tjaalton> tseliot: where does it load the module from?
<tseliot> ï»¿tjaalton: /sbin/lrm-video makes sure that EnvyNG's module is loaded
<tjaalton> I mean where can I find the module :)
<tseliot> tjaalton: it's in /lib/modules/$kernel/updates/dkms/
<tseliot> tjaalton: it's the module which was built and installed by DKMS
<tseliot> tjaalton: problems?
<tjaalton> tseliot: no, I just wanted to see where it came from
<JanC> DKMS = the Dell tool?
<tseliot> ï»¿JanC: yep
#ubuntu-kernel 2008-04-11
<osmosis> i dont understand what this means, http://www.news.com/8301-13580_3-9867657-39.html
<osmosis> zul: ping
<tjaalton> hmh, resume from hibernate failed, ie. it booted normally and not from the file
<cking> xivulon: Hi, I've been looking at your notes for the Wubi issues
<xivulon> just added a new one!
<xivulon> was waiting for you in fact...
<xivulon> let me know if I need to clarify anything
<cking> xivulon: I managed to screw up my /home today playing around with this - I was offline for a while sorting my machine out :-(
<xivulon> sorry to hear that :(
<cking> xivulon: It's all part of the fun :-)
<xivulon> You are invited to explain the fun part to my wife...
<cking> xivulon: I looked at the notes - the problem is umounting / and then /home - can one actually do this in practice? 
<cking> xivulon: I was thinking of using pivot_root but I haven't much experience with this, so I am not sure if this a possible way of doing things
<xivulon> unmounting is not a problem except that it will be the last thing you can do (without a ramdisk)
<xivulon> see my last comment on that
<cking> ..but with a ramdisk, one could umount /?
<xivulon> I would assume so
<xivulon> but I have never tried that
<cking> ..me neither. I think we may need some expertise from someone like Colin Watson.
<xivulon> eheh...
<cking> But I think it will lead to a sane shutdown that will ensure / and /home are flushed and umounted properly 
<cking> ..otherwise one will always see this kind of corruption of / 
<cking> if one can do this then the vm dirty hacks are no longer required 
<xivulon> I'd think that if we could remount /host ro (safely) it would be good enough
<xivulon> see my umountroot attachment for that, unfortunately ntfs-3g complains about remounting...
<xivulon> cking the vm dirty hacks are still required in case someone hard-reboot
<cking> xivulon: yep - true about the hard-reboot - I overlooked that detail.
<xivulon> In fact based on user feedback all the problems of fs corruption were due to hard reboots
<xivulon> I haven't seen any complaint about fs corruption because of normal reboot
<xivulon> I'd guess that remounting root ro + the sysctl hacks is enough in most cases (and maybe some fsck help...)
<cking> xivulon: I managed it :-)  I did started removing a huge tree of source and then rebooted - and I got a bit of a mess
<xivulon> that is with the sysctl hacks?
<xivulon> cking was disconnected 
<cking> xivulon: what happened there?
<cjwatson> there was a netsplit, too
<cking> ..a netsplit?
<cjwatson> IRC networks consist of many servers, in general, which are connected in a graph; if a pair of servers lose their connection, that's a netsplit
<cking> ah.. I am enlightened
<cjwatson> which results in the users on the network being effectively partitioned in terms of their ability to talk to each other
<xivulon> cking missed replies after my last comment
<xivulon> didn't miss cjwatson explanation though :)
<cking> xivulon: yep, I kind of missed the last few lines
<cjwatson> 10:56 <cjwatson> cking: I think you misunderstand the order of events slightly, though
<cjwatson> 10:56 <cjwatson> cking: the NTFS filesystem in question is actually /host, not /home
<cjwatson> 10:56 <cjwatson> cking: and Wubi is a little odd here - the way it works is that / is actually a loop-mounted filesystem *on top of* an NTFS filesystem that is then moved to /host
<cjwatson> 10:57 <cjwatson> cking: so the filesystems are the other way round from what you'd expect
<cjwatson> in case that was missed
<cking> thanks
<cking> .. I keep on writing /home when I mean /host - it's a constant brain type of mine
<cking> ^type^typo.  I need coffee.
<xivulon> the crux though is that /host cannot be remounted r/o IMHO
<cjwatson> I suspect that you cannot actually unmount / and then expect to be able to unmount /host
<cjwatson> because you won't have a reference to /host any more
<xivulon> cking did you experience fs corruption when rebooting (rc6.d) and with the sysctl hacks in place?
<cjwatson> you'd have to move all the mount points around, and frankly, I do not think that is a viable approach at this point
<xivulon> was /host to be corrupted or / and did corruption involve the journal?
<cking> xivulon: yep
<cjwatson> we need something pretty simple and foolproof, and playing Tetris with your mount points isn't that :)
<cking> cjwatson: I'm not sure if there is a solution that is simple and foolproof.
<xivulon> not sure if we can try fixing /host (ntfs-3g) remount
<cking> xivulon: one could do that - but wasn't there a big risk that  NTFS could get corrupted?
<xivulon> that was my understanding from last szaka comment
<xivulon> did ask him some more info by mail but he didn't reply
<cjwatson> if the NTFS filesystem is never remounted read-only or unmounted (as is the case at the moment, I understand), why does that affect the kernel's ability to writeback changes to the ext3 /?
<cjwatson> or rather, what is breaking the kernel's ability to writeback changes?
<cking> cjwatson: from the way I see it, we can either force disk writebacks using the vm flush hacks - but this does not necessarily guarantee a fulling sync'd fs.. or..
<cjwatson> IIRC the kernel always syncs just before reboot
<cking> .. we can fool around with the umounting.  The former may help when systems power down in an uncontrolled way, the latter makes sure the filesystems are coherently umounted at shutdown
<cking> cjwatson: true.
<xivulon> ...and yet you ended up with a corrupted fs
<cking> ..my concern is that the /host is not being properly written back to.
<cking> I believe /host is not being umounted which worries me.
<xivulon> it certainly is not
<xivulon> or you would lose /
<xivulon> and hence /sbin/reboot
<cjwatson> remounting it read-only ought to be as good as unmounting from the perspective of avoiding corruption, but that's been problematic due to ntfs-3g bugs
<xivulon> cking, on a side note, you also suggested using sync mount option on the loopfile, I assume you meant the /host fs
<cking> xivulon: yes, if it's possible on ntfs.  The sync is not required on the loop file since it's mounted ro at the shutdown. However, the sync,dirsync and commit=1 could help on power outages I suppose.
<xivulon> but isn't host that has to sync automatically? the fact that the loopfile syncs to host does not help if host does not sync to disc, correct?
<cking> xivulon: true - yep, it's clear I haven't thought that one through.
<cking> xivulon: I suppose the outstanding questions are: can ntfs-3g be fixed in time to enable a ro remount, and if so, can one avoid NTFS corruption?
<cking> xivulon: ..also, do the vm dirty tweaks do anything useful in reality?
<xivulon> yes, that would be the best avenue, I had that bug open for quite some time... 
<xivulon> but did not bother too much because had zero bug reports about fs corruption... so far...
<cking> xivulon: ..thirdly.. does the ntfs-3g support sync and commit=1 or are these only applicable to ext3? 
<xivulon> cking I know that in wubi 7.04 we did not have them we had more reports about people having fs corruption after hard reboot
<xivulon> that is based on a completely subjective measure
<cking> xivulon: ..yes but it's comforting to hear this.
<xivulon> might be due to better user education also (added a few faqs)
<xivulon> I would not know how to test that in an objective way
<xivulon> for ntfs-3g we would need to ask szaka
<xivulon> I know nothing about its internals
<xivulon> but if you see #186117 that didn't go too far
<cking> xivulon: that's the best path to take if he is available.
<cking> xivulon: Meanwhile I will google around to see if there are any other ways to make sure the filesystem is flushed other than using the vm dirty hacks,
<cking> ..one never knows if there is something better.
<xivulon> cjwatson as plan b couldn't we still try to go for /sbin/reboot on ramdisk (but leaving current behaviour whenver that is not strcilt needed)?
<cjwatson> it's very risky, you need to copy over any libraries it needs as well; it needs /proc and /dev; and who knows what else you might have to play catch-up with
<cjwatson> I have a suspicion changing ntfs-3g would be safer
<xivulon> cking still other route might be to ensure that ntfs-3g does actually empy his cache whenever the sync command is issued. I think.
<xivulon> if / is ro and synced properly, rebooting should not be too drastic even if /host is rw
<cking> xivulon: an extra sync can only help
<cking> xivulon: I recall that twiddle with (one of) the vm dirty options may also forces a sync. 
<xivulon> cking you might want to try to reproduce fs corruption with new initramfs + sysctl + umountroot, as per thread
<xivulon> as per bug attachments...
<cking> yep. Will do.
 * cking need to reboot to try this.. rebooting ..
<xivulon> FS corruption of the host is probably far more important than the guest corruption. And for the latter I'd focus on journal loss.
<cking> xivulon: NTFS + ntfs-3g's behaviour is not really well know in this scenario. That's my concern. I'd hate too see Wubi users hacked off because their NTFS is screwed up
<cking> ..so sync sync sync and then a fixed ntfs-3g mount -o remount may be the best way forward.
<cking> ..one can never sync enough.
<cking> :-)
<xivulon> only confort I can give you is that with almost 1 million downloads all the ntfs corruption claims were due to hard reboots. And I have no evidence that ntfs-3g makes things any worse
<cking> 1 million(!!) 
<xivulon> since you would still risk fs corruption when hard rebooting
<xivulon> I discussed that with szaka more than once, and he always asserted that the chances of fs corruption are not made any worse by the use of ntfs-3g
<xivulon> yep we are close to a million
<xivulon> but of course now that wubi is official, host corruption would make very bad press...
<cking> cking: rebooting ..
<xivulon> lamont: I did do some basic tests yesterday for #206113 and commented on the bug let me know if you need anything else
<lamont> my most recent dist-upgrade (-15.27 et al) killed sound...
<amitk> lamont: does it also lead to a long boot time?
<lamont> dunno
<lamont> I wasn't watching...
<lamont> and actually, I think it's related to session management, not to the kernel upgrade...
<amitk> lamont: hmm.. how so?
<lamont> I think I saw this before, now I just need to remember how I got told to fix it...
<lamont> [   54.214217] iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0xf860)
<lamont> not seeing where I figured it out before, istr it was simply muted hard somewhere
 * lamont afk for about 15 min
<lamont> amitk: so I take back what I said... let's blame the kernel for now... debugging ideas?
<amitk> lamont: sound-applet reports no mixers?
<xivulon> lamont, in case you missed it, did the tests you asked, see comment in 206113
<lamont> xivulon: yeah - thanks
<xivulon> let me know if you need anything else
<lamont> sure
<lamont> amitk: bringing the system fully current to now and rebooting (new lrm), and then I think I'll need something more basic in the way of instructions...
 * lamont iz sound neub
<lamont> amitk: anything I should tweak before I reboot
<lamont> ?
<lamont> Open Volume Control --> No volume control GStreamer plugins and/or devices found
<amitk> lamont: just note if you reboot takes longer than usual
<pwnguin> is -16 known to not boot? i cant find a report on it
<rtg> pwnguin: on what? -16 is still not widely distributed as meta was just uploaded a few minutes ago.
<pwnguin> ah
<pwnguin> on my laptop, toshiba tecra m7. -generic
<rtg> pwnguin: is this a regression?
<pwnguin> yea
<pwnguin> on the other hand, i dont have -meta 
<rtg> from -15 to -16?
<pwnguin> yep
<pwnguin> im on -15 right now
<rtg> pwnguin: meta won't affect the boot.
<pwnguin> rtg: i'd feel better about not missing part of the package with meta though
<rtg> pwnguin: at what point in the boot process does it stop?
<pwnguin> after turning off the graphical boot, hardware detection is the last message
<pwnguin> i booted into recovery mode
<pwnguin> and
<pwnguin> the last two modules giving messages were iwl and cs
<amitk> pwnguin, wait for a few minutes
<amitk> it should continue booting
<lamont> unsurprisingly, that didn't fix either of my issues
<amitk> rtg: I see this too, I was woring on Classmate when I hit this
<pwnguin> a few minutes?
<pwnguin> thats a hell of a timeout ;)
<amitk> pwnguin: I am trying to determine if you are seeing the same problem as me ;)
<pwnguin> well
<pwnguin> lemme reboot it i guess
<rtg> amitk: everything since -15 has been custom binary, except for the mmc timeout.
<pwnguin> heh
<pwnguin> the mmc timeout 
<pwnguin> interesting; i upgraded because i wanted to test that
<amitk> rtg: yeah.. I saw the changelog, and even the mmc timeout was 10ms, not 2 minutes
<rtg> better go through the git log and make sure.
<smb_tp> It is if it was 2ms before and not 2min
<rtg> brb, rebooting after upgrade.
<smb_tp> It was just a one liner changing mmc_delay from 2 to 10
<pwnguin> its supposed to be ms
<pwnguin> it could be seconds
<pwnguin> i never found that particular function
<smb_tp> It is an inline function in one of the headers
<amitk> core.h:static inline void mmc_delay(unsigned int ms)
<amitk> pwnguin: can you confirm that the boot contineus after a few minutes? albeit w/o sound
<pwnguin> on a related note, the sdhci developer's asked me to retry with MMC_DEBUG
<pwnguin> amitk: not yet
<pwnguin> give it a minute or so
<amitk> pwnguin: just wait a few more please, that'll tell me that it is reproducible behaviour
<amitk> pwnguin: What does Alt+F1 show?
<pwnguin> doh
<pwnguin> nothing much
<amitk> F2?
<amitk> I forget which one it is
<pwnguin> kinit: no resume, doing normal boot
<lamont> 8
<pwnguin> loading manual drivers
<pwnguin> i forgot to set verbose
<amitk> pwnguin: care to disable "quiet splash" in the kernel cmdline on the next boot?
<pwnguin> indeed
<amitk> thanks
<amitk> hmm. now to see what changed in lum
<lamont> amitk: my boot seems to proceed at normal-ish pace
<pwnguin> lets see. theres hda_codec at 30 saying it cant find my audio. iwl at 31 saying there's 11 tunable channels for bg, 13 for a, and several I/O port probes for module cs
<amitk> rtg: 607ab6f78fa5d51b4dab72d218455a858c499c6f in lum
<pwnguin> if you want logs, im afraid i dont have a serial port =(
<amitk> rtg: smb_tp: that commit looks like it will affect every sound driver
<rtg> amitk: is that the culprit?
<pwnguin> huzah
<pwnguin> fail
<amitk> rtg: I am going to revert and try on the classmate
<rtg> amitk: just rename snd_core to something, then try.
<pwnguin> amitk: after 2 minutes of no activity, it wrote some new text
<pwnguin> it seems to still be stuck though
<amitk> pwnguin: I'll bet it'll boot eventually :)
<smb_tp> Hm, might be bad if register all will eventually call register...
<pwnguin> heh
<pwnguin> well, it doesn't seem to be spinning
<amitk> rtg: crap.. just realised soundcore.ko comes from kernel, not ubuntu directory in /lib/modules :)
<rtg> amitk: I was just looking to see where that file gets compiled.
<amitk> rtg: that seems to improve things a lot
<amitk> I'm going to revert the commit if you have no objections
<rtg> amitk: can tyou rebuild lum with that patch reverted?
<amitk> rtg: yeah.. doing that now
<xivulon> cking in your tests did you try mounting /host with sync & co?
<rtg> amitk: removing soundcore indicates it is the sound sub-system, but isn't proof positive.
<xivulon> would it help to have 1 sec sleep before rebooting?
<cking> xivulon: I couldn't see to create any filesystem corruptions whatsoever.
<rtg> amitk: I started a new release in LUM
<cking> xivulon: what is interesting is looking at /proc/vmstat | grep dirty  
<amitk> rtg: I've been seeing this since morning, but thought it was due to my usb patch for classmate suspend
<cking> ..even with the agressive vm dirty tweaks the data is not getting written back that quickly
<cking> ..one can see the writes by doing a bit of an ugly hack:  sudo echo 1 > /proc/sys/vm/block_dump  and looking at dmesg
<amitk> pwnguin: you are running -15?
<pwnguin> no
<pwnguin> -16
<amitk> you compiled yourself?
<pwnguin> nope =(
<cking> xivulon: ..even with the most aggressive vm dirty settings one can observe writes being flushed a few seconds after the initial write...
<pwnguin> i noticed -16 in the repos
<amitk> rtg: ^^
<cking> xivulon: ..which could explain why some users are seeing corruptions even when we are forcing writebacks to occur as soon as possible.
<rtg> amitk: I saw that.
<cking> xivulon: ..because ASAP is not really that ASAP :-(
<xivulon> hmm
<rtg> pwnguin: do you also have -16 LUM installed?
<xivulon> is that an ntfs-3g / fuse implementation issue?
<amitk> I only see -16 LRM, no LUM or kernel
<xivulon> cking what is your suggestion based on that?
<pwnguin> well my mirror wins i guess
<amitk> ohh and I see -16 linux-libc-dev
<cking> xivulon: no. I initially thought it was all the layering in the ntfs-3g, fuse, loopback etc.. but one can observe this on a normally mounted filesystem.
<smb_tp> amitk: Got that installed already
<xivulon> when you say "couldn't see to create any filesystem corruptions whatsoever" do you mean you couldn't create corruptions or that you were simply not testing that
<xivulon> so it's a kernel issue...
<cking> xivulon: so it appears what the kernel documentation says and what is actually happening differ.
<xivulon> not to pleased to hear that
<cking> xivulon: as for the corruptions: I hammered the system with loads of creat's and unlinks and forced a reboot and everything was OK...
<amitk> smb_tp: no sideeffects?
<cking> xivulon: and also I repeated this several times and pulled the plug and got the normal fsck'ing fixes but I did not get any major failures
<xivulon> cking that is in line with lack of reports on the matter. was this with the new initramfs / umountroot or in a plain vanilla case?
<cking> xivulon: it was using the new scripts from the bug report
<smb_tp> amitk: None I noted, but I guess this only affects programs comiled on that host. and I didn't compile any user-space
<xivulon> well that is good news
<xivulon> for once...
<amitk> rebooting now....
<cking> xivulon: I left some notes on the bug report so one can see what I mean about the write backs being a little bit too lazy for my liking
<xivulon> could it be that the mount options (sync & co) interfere with sysctl?
<cking> xivulon: no. when I saw the less than perfect performance I tried it on a vanilla configuration to do a sanity check - i.e. no insane sync,dirsync,commit=1 flags.
<xivulon> cking: would you suggest we keep mount options and/or sysctl settings?
<cking> ..and I saw the same "problem".  We are probably seeing the pdflush pushing out all it can before it gets rescheduled or something. I need to shove a whole load of debug in to see why it is a little less aggressive than expecyed
<xivulon> so I guess you'll need some more time for the tests then we can reassess
<xivulon> I would not think though that in the light of what you say the new initrd/umountroot should make much difference
<cking> xivulon: well, closer inspection shows that the mount options are ignored by ntfs - so we just fall back to the sysctl's.
<xivulon> since /host is still not remounted ro (at least in my tests)
<cking> xivulon: agreed
<cking> xivulon: I basically need to figure out why pdflush is not being totally true to the vm dirty knobs
<amitk> rtg: revert works and sound is back
<xivulon> sure, keep in mind that we'll need to do a feature freeze exception for each change, if something is not strictly necesseray (proven to be so) we should skip it
<amitk> rtg: I've pushed the revert to lum
<xivulon> that applies to initrd, sysctl and umountroot
<cking> xivulon: yep. Well I think the real issue is that we want to flush blocks out asap and I need to figure out why the pdflush does not quite match the behaviour as described on the lid
<cking> ^on the lid^in the docs^
<cking> ..and then I'm a little worried about tinkering with the pdflush daemon this late in a code freeze :-(
<cking> ..but it could be something obvious once I've got my head around it.
<cking> xivulon: any ideas on anything else we could do?
<xivulon> not really
<cking> xivulon: OK I investigate pdflush and the vm dirty knobs
<cking> s/I/I will/
<xivulon> cking, maybe doublecheck whether initramfs/umountroot make any difference
<cking> xivulon: I think most productive thing is to see if we can get pdflush to really do aggressive writebacks to limit loopbacke'd fs corruption 
<cking> xivulon: I hope it is something obvious
<xivulon> agree
<xivulon> by the way, wouldn't something like that be relevant also for vm?
<xivulon> that too is a nested fs and hence subject to the same vulnerabilities
<xivulon> I am surprised I am the only one running into this
<xivulon> at least for the power-loss part (normal reboot is very different of course)
<rtg> amitk: I verified the cx88 revert. it definitely makes a difference.
<amitk> rtg: half the patch was mutexes, it had to ;)
<rtg> amitk: I looked through it when I applied it. everything looked balanced, _and_ it came from upstream.
<amitk> rtg: I guess it needs another part from upstream
<rtg> amitk: could be. now I'm f\gonna have to figure out what the real cx88 crash was .
<nxvl> i have just updated to -16 kernel and it hangs
<rtg> nxvl: LUM is currently percolating with a fix. wait for linux-ubuntu-modules-2.6.24 16.22
<nxvl> ok
<nxvl> so it was a know issue?
<pwnguin> heh
<pwnguin> only recently
<rtg> nxvl: it became a known issue fairly quickly.
<nxvl> yes of course it has no more than one day uploaded
<nxvl> but if you already have what you need to fix it
<nxvl> i'm ok
<pwnguin> 16.22?
<rtg> https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-16.22
<pwnguin> i have linux-headers at 16.30
<pwnguin> is that . not kept in sync?
<rtg> pwnguin: The LUM package version is not related to the headers package version (except for the ABI number)
<pwnguin> ok
<nxvl> so, fix is released and we only need to wait until it reach the mirrors?
<rtg> yep
<pwnguin> not booting is a fairly high priority bug ;)
<pwnguin> espcially when someone like amitk and reproduce it
<nxvl> ok thanks!
<nxvl> btw
<nxvl> i forgot to report something else
<nxvl> i hav a lenovo T61
<nxvl> with hotplug DVD-rom
<nxvl> but when iunplug it the system hangs
<mario_limonciell> rtg, i was thinking this morning, could you see to it that LBM is shipped as available on the DVD image to install?
<mario_limonciell> in it's pool directory or similar
<rtg> mario_limonciell: thats a question for cjwatson
<mario_limonciell> okay i'll ask him
<crimsun> rtg: are there are traces from the bootup problems (WRT #212960 in l-u-m -16)?
<crimsun> amitk: ^
<crimsun> are there, sheesh.  can't type.
<rtg> crimsun: there don't seem to be. I'm looking at it now. Frank's original patch works, but the one Leann attached does not (it locks up)
<rtg> crimsun: I'm trying to decide if it is really the root of the problem.
<crimsun> rtg: I don't think it is, after closer inspection.
<rtg> crimsun: can there really be that much list activity going on? Or is the use of mutexes just jostling the thread timing.
<rtg> crimsun: as far as I can remember, PCI device discovery is single threaded, right?
<crimsun> rtg: there shouldn't be much activity, and it is single-threaded IIRC.
<rtg> crimsun: that's what I thought. I'm not sure Frank's analysis is correct (about the lists getting corrupted).
<pepie34> I can't catch an AP with my AR5008 madwifi card since the two last -14 and -15 kernel
<pepie34> still no problem with the -12 kernel and the same userland as the others new
<mario_limonciell> hm what is creating the symlink between cpufreq directories on two core systems initially?
<mario_limonciell> i had thought it'd be powernowd doing it, but I don't see evidence of that
<pepie34> any idea ? for the regression on madwifi
<smb_tp> rtg: Hm, I might be stupid but in the report snd_card_register_all is called and later snd_device_new. If thats both in core, how should that work?
<pepie34> I should be more precise as it is a AR5XX8 chipset i had to use the madwifi svn and not the module in the restricted package
<pepie34> it works fine on feisty/gutsy and hardy since the 2.6.24-12 kernel
<rtg> smb_tp: it clearly must work because its not a problem for everyone. I'm still looking at the cx88 driver. However, right now its lunch time.
<rtg> pepie34: you are on your own 'cause I haven't pulled the madwifi branch that supports the AR5008. I've been waiting until they make it official.
<smb_tp> rtg: Enjoy. I was just thinking of the same codepath with mutexes
<pepie34> rtg i just want to warn then that since the -14 the madwifi-svn does not work and you will get all the mac user really angry
<lamont> amitk: so will this new kernel make my soundz werk>?
 * pwnguin does a zomg sd works again dance
<pwnguin> rtg: thanks
<infinity> lamont: You don't need sound.
<lamont> infinity: do too
<infinity> lamont: The kernel team disagrees.
<rtg> lamont: we've gone out of our way to wreck only _your_ audio support.
<lamont> rtg: I feel so much more productive without the noise-canceling music
<rtg> lamont: I thought you had audio once upon a time?
<sistpoty> hi, can someone please look at the FFe in bug #185634 and give a comment? thanks!
<ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634
<tjaalton> is there something in -16 which broke nvidia from loading? bug 215778
<ubotu> Launchpad bug 215778 in linux-restricted-modules-2.6.24 "2.6.24-16.30 kernel update - nvidia: module license 'NVIDIA' taints kernel" [Undecided,Confirmed] https://launchpad.net/bugs/215778
<tjaalton> lrm debdiff looked good, so it shouldn't be due to the dh_strip fix
#ubuntu-kernel 2008-04-12
<infinity> tjaalton: It's not universally broken, for the record.
<infinity> tjaalton: So, whatever's causing that bug is more subtle.
<infinity> tjaalton: 
<infinity> Linux cthulhu 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux
<infinity> adconrad@cthulhu:~$ lsmod | grep nvidia
<infinity> (ie: it's working fine here)
<infinity> nvidia               8858052  36 
<infinity> tjaalton: Perhaps it has something to do with people upgrading l-r-m while they had the broken l-u-m, getting a broken modules.dep, and then depmod not refreshing the nvidia deps after l-u-m was upgraded, or something equally fragile?
<infinity> tjaalton: (I upgraded to -16- wholesale a few minutes ago, so never saw the broken package)
<tjaalton> infinity: ah, good to know. It was too late for me to test, since the updates would've taken ~1h to download :)
<tjaalton> but I'll check it now to make sure
<tjaalton> infinity: yeah, worked like a charm
<sourcemaker> how can I disable "martian source" checks?
#ubuntu-kernel 2008-04-13
<lamont> yay!  I can haz audio
<sioux> Hi
<sioux> who help me with module-assistant?
<siou1> ?
<DanaG> Oh hey, does the current Hardy kernel support assigning tap interfaces to groups?
<DanaG> I know you can use such interfaces for specific users, but groups don't seem to work.
<DB42> i seem to have a problem with 8.04 and 2.6.24
<DB42> i get
<DB42> [ 2833.378456] ALSA /build/buildd/linux-ubuntu-modules-2.6.24-2.6.24/debian/build/build-386/sound/alsa-driver/usb/usbaudio.c:1289: 2:1:4: cannot set freq 55010 to ep 0x4
<DB42> any ideas ? (worked ok in 7.10)
<crimsun> which SSID?
<DB42> SSID ?
<DB42> it's a Microsoft Sound System 80
<DB42> dmesg http://paste.ubuntu-nl.org/63106/ | lsusb http://paste.ubuntu-nl.org/63107/
<DanaG> Heh, when you said "Microsoft Sound System," I thought of the old days of Sound Blaster 16, and DOS games.
<DB42> nah, it's actually pretty quality speakers
<DanaG> They're just reusing an old brand name.
<DB42> not really, but nm.. any ideas on fixing it ?
<crimsun> DB42: lsusb -v
<crimsun> -> pastebin, please.
<DB42> crimsun, it's there
<DB42> dmesg http://paste.ubuntu-nl.org/63106/ | lsusb http://paste.ubuntu-nl.org/63107/
<crimsun> and we should migrate to #ubuntu+1
<DB42> k, i'm there
#ubuntu-kernel 2009-04-06
<idiotechnique> hello, I have an issue with udevd startup after upgrading to a new kernel. during boot udev population has noticeably slowed down, and my system has slowed down as well after boot. i did uncheck support the deprecated sys-fs, where as it was compiled in the previous kernel. any ideas? should udevd be recompiled?
<asac> when will last "regular" kernel push happen to jaunty? (or has that already happened)?
<tjaalton> asac: AIUI tomorrow is the last chance to get changes in
<tjaalton> I'm working on getting support for Option Globetrotter in..
<asac> tjaalton: i need to add a bunch of ids to cdc_ether
<asac> tjaalton: who has the lead ? do i need to talk to pgraner?
<asac> tjaalton: what do you need for that modem?
<asac> tjaalton: do you have a "nozomi" ?
<tjaalton> asac: bug 348861
<ubot3> Malone bug 348861 in linux "Option GE0301 3G modem doesn't work" [Medium,Incomplete] https://launchpad.net/bugs/348861
<tjaalton> asac: with the patch the device works fine, but authentication fails
<tjaalton> (n-m auth)
<asac_> tjaalton: do you have a syslog?
<tjaalton> asac_: sure, a sec
<tjaalton> asac_: http://users.tkk.fi/~tjaalton/foo/syslog
<asac_> tjaalton: are you running latest NM?
<asac_> seems so
<tjaalton> asac_: I should be
<asac_> tjaalton: please start with NM_SERIAL_DEBUG=1
<asac_> and get a new syslog
<tjaalton> the daemon?
<asac_> yes
<asac_> tjaalton: run it as NetworkManager --no-daemon 2>&1 | tee /tmp/nm.log.txt
<asac_> or whatever you prefer ;)
<tjaalton> asac_: http://users.tkk.fi/~tjaalton/foo/nm.log.txt
<asac_> tjaalton: what do you have set as username/password ?
<tjaalton> pwd is "internet"
<tjaalton> username is blank
<asac_> tjaalton: did you use the wizard to create that account?
<tjaalton> originally yes, but this is another user so it didn't ask anything
<asac_> tjaalton: set something in username
<tjaalton> then it'll ask to access the keyring, and fails the same way if I grant access
<asac_> tjaalton: yeah but please the log ;)
<tjaalton> same url
<asac_> it might fail somewhere else
<asac_> tjaalton: there is no password/usernme
<tjaalton> reload
<asac_> Sending: 'AT$QCPDPP=0,1,"",""
<asac_> that shoujld have them
<tjaalton> right, the first time it didn't
<asac_> ah
<tjaalton> which is strange since the password was ser
<tjaalton> *set
<asac_> tjaalton: hmm. auth type is pap
<asac_> tjaalton: can you minicom against that tty and run the same command but with 2 instead of 1?
<asac_> tjaalton: or maybe first try to reproduce
<asac_> tjaalton: alternatively just hack that in the code and try ;)
<tjaalton> asac_: how do I send the command with minicom? never used it..
<asac_> tjaalton: http://pastebin.com/f72c15e7a
<asac_> tjaalton: i guess its easier to try the patch
<tjaalton> ok
<tjaalton> building
<tjaalton> asac__: http://users.tkk.fi/~tjaalton/foo/nm.log2.txt
<tjaalton> didn't seem to help
<asac__> tjaalton: maybe "foo" is wrong now?
<asac__> ;)
<tjaalton> it just hung without a username
<asac> tjaalton: use the right values for your provider. some need values ;)
<tjaalton> the sim card works on my X61
<tjaalton> same settings 
<asac> tjaalton: right, but might be ppp
<asac__> anyway. you need to talk to dcbw and see if he has more ideas
<asac__> in #nm
<tjaalton> ok
<asac__> tjaalton: let him know asap as we want to tag 0.7.1 final ;)
<tjaalton> asac__: sure :)
<tjaalton> he's not there atm
<asac__> yeah US
<tjaalton> if the card turns out to be broken I'll kill someone ;)
<tjaalton> spent way too much time on this..
<asac> tjaalton: did you try on windows?
<tjaalton> asac: hmm no, the machine did have it though
<tjaalton> I'll ask the owner
<dnwe> I have a simple patch for linux-image-2.6.28-11-generic to add the Sony PlayTV usb ids
<dnwe> what's the best way to submit this for inclusion in ubuntu?
<dnwe> just raise a wishlist bug against ubuntu/+source/linux ?
<Kamping_Kaiser> ideally take it upstream, but otherwise the local bug thing
<dnwe> its already upstream in v4l-dvb
<Ng> dnwe: out of interest, is that thing supported in any way?
<dnwe> ? yeah its identical to other dib0700 devices
<Ng> oh nice :)
<dnwe> infact its better than lots of those as a) it ships in a well shielded casing, b) it has a single aerial port but dual tuners and c) its cheaper and you can buy it in most game shops :)
<dnwe> http://linuxtv.org/wiki/index.php/Sony_PlayTV_dual_tuner_DVB-T
<Ng> last time I looked at dual tuner stuff it was an all-hauppauge game, and we were losing ;)
<Ng> I've not touched any DVB stuff in 14 months, reception in my current home sucks and only my Sony TV is able to handle the signal. the hauppauge dvb PCI card I have (and xine on top of it, via VDR) just choke and crash all the time
<dnwe> what machine are you running the DVB in?
<dnwe> i've had problems with cpufreq scaling making DVB unstable
<dnwe> (even though the cpu reported as running at full speed whilst making recordings / playing live tv)
<Ng> the main machine is a self-build PC with a core2duo. It had worked fine in my previous place. I confirmed with a USB hauppauge stick on my laptop
<dnwe> Kamping_Kaiser / Ng : raised as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356250
<ubot3> Malone bug 356250 in linux "[jaunty] [wishlist] [patch] Support for Sony PlayTV USB vendor/product ids" [Undecided,New] 
<mdz> apw: latest comment on bug 319825 looks relevant
<ubot3> Malone bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,Fix released] https://launchpad.net/bugs/319825
<sbeattie> ogasawara: bug 355291 looks like an easy one for the kernel team to pick up.,
<ubot3> Malone bug 355291 in linux "linux-image-lpia needs CONFIG_NETFILTER_XT_MATCH_RECENT" [High,Triaged] https://launchpad.net/bugs/355291
<ogasawara> sbeattie: ok cool, I'll squeeze it on the list and ping the kernel team
<manjo> ogasawara, did anyone look at your  cherry ppick request ? if not I can do them 
<ogasawara> manjo: I don't anyone's actually pulled them in yet.  just got the 2 required acks from you and steve
<manjo> ogasawara, k looks like that will make rtg pull those in ? 
<ogasawara> manjo: I suspect so
<manjo> k cool
<Shock> hi, I have changed a config option, built source package with "debuild -S" and uploaded the package to launchpad. the build fails with "EE: Previous or current ABI file missing!". how can I fix this?
#ubuntu-kernel 2009-04-07
<Shock> hi, I have changed a config option, built source package with "debuild -S" and uploaded the package to launchpad. the build fails with "EE: Previous or current ABI file missing!". how can I fix this?
<rtg> pgraner: CONFIG_USB_SERIAL=y bug number?
<manjo> smb_tp, the kernel prints out so much info that its hard to run the suspend resume tests with it 
<smb_tp> manjo, Ok, feared so much. I remove most of it and get you something lighter
<manjo> smb_tp, also I could not figure out what it was printing coz it was printing so much stuff... 
<manjo> so looks like the drive reports ready but still in EBUSY state
<smb_tp> manjo, Yeah, I turned on the verbose debugging, but saw it probably is too much
<manjo> it happens when you suspend without power cord attach and attach the power cord after you suspend and then resume with the power cord still plugged in
<manjo> if you give me a clue I can put some debug printfs 
<smb_tp> Hm, thats interesting
<manjo> do you have any hints ? 
<manjo> I think I found some points where I want to print info reading the code yesterday
<smb_tp> I need to play around this anyways as we want/need some debugging there. But I would start around the soft/hard reset functions
<manjo> now I have a fair understanding of libata stuff to start putting printfs
<manjo> smb_tp, yeah that is what I had in mind
<smb_tp> Won't prevent you from doing that then. :)
<manjo> :)
<tjaalton> apw: hi, what about bug 224642, any chance to get it in before the freeze?
<rtg> tjaalton: lest you feel ignored, apw just asked me if he could push the patch for that bug.
<apw> rtg thanks ... just got bounced from the network :(
<apw> tjaalton, thanks for the prod.  i've pushed that change up and it should make the kernel
<manjo> apw, smb_tp did we cancel the meeting for today?
<apw> hrm, we cirtainly didn't actually do anything to cancel it
<smb_tp> I thought I had written an email...
<manjo> smb_tp, yeah see that 
<manjo> thansk
<tjaalton> rtg, apw: great, thanks!
<liw> sysklogd looks for a symbol matching Version_[0-9]+ in System.map, but Ubuntu (intrepid, jaunty) doesn't seem to include one; Debian (lenny) does; anyone know what's up?
<liw> this is related to #277924
<lool> liw: We had one in /boot/System.map-2.6.24-19-generic; perhaps something which was dropped upstream?
<liw> I don't have a changelog.Debian that reaches that far back in time, only to 2.6.26-2.6
<infinity> liw: What kernel version is lenny shipping that has this symbol?
<liw> infinity, 2.6.26
<infinity> liw: Ahh, hrm.  In the LP bug, all the reported METOOs are from 2.6.27+, so it may well be an upstream change.
<liw> infinity, would you be able to easily check that?
<infinity> I have no local git love here.  Haven't worked on the Ubuntu kernel in ages. :/
<infinity> So, no, not any more readily than you could.
<infinity> liw: There's a random claim from Russell King that on kernels with KALLSYMS, we should be invoking klogd with "-x" to skip the System.map lookup entirely.
<infinity> liw: But, we had KALLSYMS=y back in hardy too, where it seemed to work fine.
<smb_tp> liw, Hm, what do you mean exactly by Intrepid and Jaunty do not have a System.map?
<liw> smb_tp, they don't have a symbol that matches Version_[0-9]+ in their System.map, which is what sysklogd wants to find
<liw> in order to figure out which kernel version the map is for, I think
<smb_tp> liw, Ah, ok. Got it
<liw> infinity, indeed, in my hardy VM, with 2.6.24, System.map is correctly loaded and the symbols it there
<liw> I haven't had any real understanding about building kernels since 0.97 or so, so I'm a bit lost here
<infinity> liw: Well, I'd begin by a violent recursive grep of the hardy kernel source for the string "Version_", find out where the symbol comes from, then check intrepid/jaunty to see if that codepath went away, or if we're accidentally optimising it away with a certain config option.
<smb_tp> infinity, yeah. currently looking
<infinity> liw: Out of curiosity, does this missing symbol (and klogd not getting to load System.map) actually lead to any real bugs, or just ugly log output? :P
<liw> infinity, that's a good question :)
<infinity> liw: I mean, I'd assume it prevents klogd from doing pointer lookups to name symbols... But I have no idea why we'd care.
<infinity> liw: Assuming that programs that actually make use of System.map (modutils, ksymoops, that sort of thing) are parsing it correctly, I'm not entirely sure that the klogd thing matters at all, and maybe we should just be invoking it with "-x" to skip the System.map read entirely.
<infinity>        -x     Omits EIP translation and therefore doesnât read the System.map file.
<smb_tp> I would think that missing the right System.map has simmilar effect
<liw> if we don't care about System.map being found by sysklogd, we don't need to do anything, really
<smb_tp> But since I already saw stack traces with symbol names there must be an alternate way
<infinity> smb_tp: Oh, I'm sure the end result is the same, just that one avoids an Sky is Falling error message. :)
<infinity> smb_tp: I suspect the symbol names are coming from KALLSYMS=y
<infinity> smb_tp: (As noted, users of KALLSYMS should be loading klogd with -x anyway)
<infinity> liw: Optionally, if you can find a clever way to detect KALLSYMS is in effect, you could patch klogd to print a friendlier "KALLSYMS kernel loaded, skipping System.map load", instead of "OH GOD, NO SYSTEM.MAP, HALP!"
<liw> infinity, I think I'd rather see someone who understands what you just said do that :)
<smb_tp> infinity, that would be a plausible explanation. 
<liw> the bug was marked as medium priority by colin king, so I should perhaps ask him why
<infinity> Anyhow, from what I can tell with some basic research and a bit of futzing in the code, I think the error message (for us, anyway) is entirely harmless.  Just a bit scary.
<smb_tp> infinity, Well the message is just plain "Cannot find map file" and then "Loaded x symbols from y modules". Not someting that let me panic
<infinity> smb_tp: "Cannot find" on a file that clearly exists is cause for panic for a lot of people. :)
<infinity> smb_tp: "Not loading, because of $reason" is a bit friendlier.
<infinity> (The number of people METOOing the bug sort of backs up my assertion)
<liw> (the real fix would might be to switch to a syslogd written by people who know C I/O)
<infinity> liw: Our klogd works well enough.  *shrug*
<smb_tp> infinity, Agreed, it is slightly misleading
<infinity> smb_tp: No one likes the second line in their boot sequence to be "I can't find ur filez noob"
<liw> anyway, I'm done for today, thanks for you help with this
<smb_tp> infinity, We could suggest "Confused by the contents of the file"
<infinity> smb_tp: Well, I'm curious if the Version_* symbol goes away only on KALLSYMS builds, or if it's gone completely.
<infinity> smb_tp: If it's gone completely, then we do have a real bug here, whether in the upstream kernel or in our klogd, where things will be suboptimal for users building their own kernels.
<smb_tp> infinity, Yeah I am trying to find out for curiosity. Somehow it is not quickly grepable
<infinity> smb_tp: If it's only gone on KALLSYMS builds, I call it a non-bug.
<infinity> (Though the error message going away or being re-written would be swell)
<infinity> liw: I tossed a pithy followup on the bug with very little technical explanation, because I didn't feel like typing. :P
<infinity> liw: If you want more info there, there's plenty of backscroll here to cut and paste. :)
<smb_tp> I would very much suspect if cking put it as medium, then its just a nuisance and probably time was lacking to bother
<infinity> smb_tp: On the flipside, this could be seen as an accidental optimization.  If we have symbol lookups built into the kernel, it's a terrible waste to have them also loaded into klogd's (probably non-pageable) memory.
<smb_tp> infinity, It makes much sense. Why have that twice. Maybe just an oversight to _not_ display the message.
<smb_tp> infinity, hah, yeah...
<smb_tp> #ifndef CONFIG_KALLSYMS
<smb_tp> #define version(a) Version_ ## a
<smb_tp> in init/version.c
<infinity> smb_tp: Perfect, that's what I was hoping for.
 * infinity follows up to the bug again.
<smb_tp> commit 197dcffc8ba0ea943fee86e28e99cd9575799772
<smb_tp> init/version.c: define version_string only if CONFIG_KALLSYMS is not defined
<infinity> smb_tp: Thanks for the backtracking.  I've updated the bug to confirm that it's harmless, and to suggest making klogd's error message disappear or be made friendlier.
<smb_tp> infinity, Ok, cool.
<rtg> apw: kirkland says he is stable now without the i945 patch.
<apw> yes he said that to me too
<rtg> apw: are you doing a different patch for it?
<apw> the patch cannot be the trigger for pgraner's issue as it wasn't in .38
<apw> and the reports of the compiz issues explicitly were seen on .38
<apw> bug 356951
<ubot3> Malone bug 356951 in compiz "Compiz sometimes hangs the machine" [High,Confirmed] https://launchpad.net/bugs/356951
<apw> we have no clue as to cause of his issue at this time
<rtg> apw: hmm, so you're thinking that the i945 patch had nothing to do with kirkland's stability?
<apw> sorry ... i am confusing you with use of him
<apw> kirkland was ok on .38 and ok with 41 with the revert,. this is consistant with it being the BCHBAR patch as it was .39 material
<apw> its not consistant with pgraner's issue as that is seen in .38 which does not have it
<apw> (it == the patch)
<rickspencer3> apw: could that not mean (as bryce points out to me) that pgraner suffers from yet another issue?
<rtg> apw: so, you're OK with reverting the BCHBAR patch?
<apw> right, that is what i was trying and failing to communicate, that pgraner has a different issue
<apw> i think kirkland is sufficient reason to be suspicious of the patch and revert it regardless
<rtg> apw: got it. will do.
<apw> rtg ack
<bryce> rtg, apw: if you have any other questions on that patch, jbarnes has popped in here
<rtg> bryce, jbarnes: Its been shown to be the culprit for hard lockups on kirkland's laptop (which I think is i945).
<jbarnes> rtg: at boot or during use?
<jbarnes> s/boot/i915 load/
<rtg> apw built a test kernel with only the BCHBAR patch reverted. it locks fairly soon after GDM starts, certainly within a few minutes.
<jbarnes> MCHBAR I hope?
<apw> yep
<rtg> jbarnes: I think so, but he's busy at this conference using his laptop, so its hard to get much access to  it.
<apw> we are separately suffering a compix triggered machine hang on a number of systems
<jbarnes> hm
<apw> yep saw it with my own eyes, hard locks, compiz off
<jbarnes> the MCHBAR patch will allow for tiled rendering on more machines...
<apw> revert the patch and goodness ensues
<jbarnes> so there may be a more generic tiling related problem
<apw> and blow up machines
<apw> :)
<apw> jbarnes, does sound feasable
<jbarnes> that could be confirmed by running with the patch but adding option "tiling" "false" to xorg.conf's intel driver section
#ubuntu-kernel 2009-04-08
<rtg> jbarnes: I'll try to catch up to kirkland later today and get him to test with tiling disabled.
<jbarnes> cool that would help
<jbarnes> afaik the MCHBAR patch by itself shouldn't cause lockups
<jbarnes> except indirectly...
<rtg> jbarnes: agreed, but it does appear to be causative
<jbarnes> yep
<Giotrader> help install please I have a RAID 0 and 2 IDE drives, Ubuntu alternate CD only see 1 IDE drives and gives me an error message when trying to partition the RAID 0
<alphaaquilae> hello
<alphaaquilae> any interresting ubuntu screensaver?
<Shock> hello
<Shock> i desperately need some help in compiling the kernel with PAE enabled, anyone willing to help?
<Shock> wake up!
<Nafallo> Shock: as the topic says... "Ubuntu kernel development discussion ONLY"
<Nafallo> Shock: you want #ubuntu or another support channel.
<Shock> oh, right...
<Shock> what would "another support channel" might be since I tried getting help in #ubuntu quite a few times to no avail?
<anubhav> Shock: maybe you can  try kernelnewbies on oftc
<Shock> oftc?
<anubhav> Shock: irc.oftc.net
<anubhav> Shock: http://kernelnewbies.org/IRC
<Shock> thanks anubhav
<Shock> should I still try that if I don't consider myself a newbie? :)
<Shock> my errors come from the abi checker, btw
<anubhav> Shock: try it out ..most probably  some one will know
<anubhav> Shock: https://help.ubuntu.com/community/Kernel/Compile
<Shock> anubhav: thanks, i've used that document in my research
<Shock> also https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<Shock> the info I'm looking for doesn't seem to be on the wikis/forums
<IntuitiveNipple> Shock: what info?
<anubhav> Shock: You question is not pointed enough as it is
<Shock> ok, I'm getting this error "EE: Missing modules (start begging for mercy)"
<Shock> I've done debian/scripts/misc/getabis
<Shock> I've bumped the ABI
<Shock> I don't know what else to try
<Shock> this is the buildlog: https://launchpad.net/~mmiron/+archive/ppa/+build/941290/+files/buildlog_ubuntu-intrepid-i386.linux_2.6.27-12.32ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
<Shock> IntuitiveNipple: I don't know how to fix this error: "EE: Missing modules (start begging for mercy)"
<IntuitiveNipple> Shock: What changes have you made?
<Shock> I've enabled CONFIG_HIGHMEM64G and disabled CONFIG_HIGHMEM4G
<Shock> I've run debian/rules updateconfigs which asked me about another option (about adaptec 64bit DMA) for which I've answered no
<anubhav> I the dump is see MISS: dca
<anubhav>       MISS: ioatdma
<Shock> I don't think it should have asked me about a new kernel option, though
<Shock> it should have already been set
<Shock> I've run dch -i and bumped the ABI version
<Shock> after that I ran debian/rules debian/control.stub
<Shock> and then debuild -S -j 3 (not that it matters much)
<Shock> anubhav: yes, I don't know why those are missing
<anubhav> Maybe because of that module-check-generic script is unhappy
<Shock> prolly :) but I still can't figure out how to fix it :(
<anubhav> or whatever script checks for missing modules
<Shock> I don't know what kernel option controls the build of those modules, I've searched google but wasn't able to find it
<anubhav> IntuitiveNipple: do know what can be done in that case?
<Shock> as a side note, why would updateconfigs ask me about that adaptec 64bit DMA option?
<Shock> shouldn't it have already been answered?
<Shock> presumably by the Kernel Team
<IntuitiveNipple> ioatdms is missing since it selects DMA_ENGINE which has the depends !HIGHMEM64G && HAS_DMA
<IntuitiveNipple> s/ioatdms/ioatdma/
<Shock> ok, so it will never get built if HIGHMEM64G is set
<Shock> how can I fix it?
<Shock> meaning get the packages to build
<Shock> they need the previous kernel version ABI files and fail otherwise
<Shock> if I give it the ABI files, it also fails because some modules are missing
<Shock> I'm unsure what my options are
<Shock> anyone?
<lool> Hi folks, we need quick advice on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/357700
<ubot3> Malone bug 357700 in linux "mmcblk0p* don't appear in /sys/block" [Undecided,New] 
<lool> amitk, cooloney: ^
<lool> It's the same behavior on my SD card reader on my desktop
<lool> fdisk -l /dev/sdd => I see the parts, /dev/sdd* exists, but they don't show up in /sys/block
<lool> Perhaps it's bug that they don't appear in /sys/block or perhaps casper assumes too much and shouldn't use /sys/block?
<cooloney> lool, ok, i will take a look right now
<Kano> hi rtg ,did you see .30-rc1
<lool> cooloney: We're also discussing it in #ubuntu-installer
<lool> I think it's because it's /sys/block/mmcblk0/mmcblk0p1
<rtg> Kano: yes, but I'm unlikely to do anything with it until next week since I'm traveling right now.
<Kano> then there will be rc2 ;)
<lool> cooloney: Ok, it turns out it's a casper bug for sure: it's only looking at usb|pci-[^-]*-(ide|scsi|usb) devices
<lool> cooloney: And ours is a platform-mmc device
<cooloney> ok, no problem
<cooloney> lool, i am not familiar with casper
<lool> cooloney: Thanks for being around; it's kernel freeze tomorrow so I'm really worried we miss something!
<cooloney> what is casper
<lool> cooloney: casper is an initramfs script which we use in live CDs etc. and which will setup an unionfs and do various stuff to setup the live CD
<cooloney> and LIVEMEDIA is a kernel command line parameter
<Kano> usually live-initramfs has a live-media-path option
<Kano> did casper adopt it
<cooloney> ok 
<Kano> live-media=*|bootfrom=*) ok, both are there...
<Kano> live-media is the device
<Kano> same as bootfrom
<Kano> live-initramfs has a few more...
<lool> cooloney: Fix pushed
<lool> cooloney: LIVEMEDIA is what we use when we want to skip autodetection and force the device to use
<cooloney> lool, fix pushed? it was fixed?
<lool> cooloney: I uploaded casper
<amitk> lool: casper needs to know about mmcblk*, that's what all mmc devices on arm are
<lool> amitk: Actually it's because of the ID_PATH
<lool> bug #357700
<ubot3> Malone bug 357700 in casper "mmcblk0p* don't appear in /sys/block" [Undecided,Fix released] https://launchpad.net/bugs/357700
<lool> (Not of the dev name)
<manjo> smb_tp, around ? 
<smb_tp> manjo, no 
<smb_tp> it just looks like I am
<manjo> heh .. one eye open ? 
<manjo> I debugged the damn ata stuff all day yesterday... and I am so confused
<smb_tp> might even be two. whats up ?
<smb_tp> anything specific?
<manjo> can i skype you ? 
<smb_tp> give me a sec
<smb_tp> *sigh* all at the same time
<smb_tp> manjo, seems I should first join somewhere else
<philn> hi
<philn> where can i find support for kernel if this channel is for devs only?
<manjo> philn what support are you looking for ? 
<philn> well i recently moved my hard drive to another computer and since then i can't boot any kernel installed after that date
<manjo> what happens on boot ? 
<philn> i see ATA errors
<philn> don't remember exactly the messages but makes me think the kernel is trying to access an invalid hard-drive or something like that
<manjo> philn, you should ask #ubuntu... but just curious .. did u reinstall the hdd in the new computer ? 
<philn> i asked, none replied
<philn> well the hdd is hosting my /
<manjo> philn, are you able to boot the hdd by 1st booting from a USB key ? 
<manjo> or CD ?
<philn> could that be related to initramfs-tools ?
<philn> manjo: well i'm using an old 2.6.27 kernel right now
<philn> haven't tried boot from a USB key or CD
<manjo> philn, I think you have the hdd hooked up in some wrong order 
<philn> hmm /dev/sda2 is my / 
<philn> ha you mean i inverted the 2 cables on the mother board?
<manjo> philn, iirc you should not have issues with moving hdds ... unless you moved from ide to sata etc... but the kernel drivers should take care of it ... try to boot hdd from a live cd or usb to be sure your disk is not bad
<philn> the hdd is fine, i'm booting from it but... with an old kernel 
<manjo> also you could remove "quiet splash" from the kernel commadn line and see what exactly is gonin on
<philn> hey Tony
<smb_tp> One thing might be to look what and how the grub root device is defined
<philn> smb_tp: how can i do that?
<manjo> right that is why I suggested boot from livecd and then boot hdd
<smb_tp> it is define in /boot/grub/menu.lst
<smb_tp> groot=<something>
<philn> root            (hd0,1)
<manjo> hey smb_tp you have few mts ? or still busy ? 
<philn> groot is commented out
<smb_tp> So that would be the second partition of the first hdd
<philn> yep, /dev/sda2 is my /
<smb_tp> It is used by update-grub to create the root entries for the kernels below
<smb_tp> philn, can you paste the sections for one of the non-booting kernels (root, kernel, initrd)
<smb_tp> manjo, I try to spare you a slice from my multitasking
<philn> http://pastebin.com/mc292300
<manjo> smb_tp, awesome will take only 5mts
<smb_tp> manjo, thats waht they all say
<philn> ;)
<manjo> smb_tp, going to get some coffee while I wait
<smb_tp> philn, For the booting kernels, is there all the same. Especially the /boot/... 
<smb_tp> manjo, I was about to call...
<philn> smb_tp: yes, that's what make me think it might be an issue with initrd file generation
<manjo> smb_tp, oops missed it 
<smb_tp> philn, I think I saw something like that before
<smb_tp> philn, you could try to remove the prefixing /boot just to test
<philn> ok i'll try that, i'll BE BACK! ;)
<manjo> ata_sff_check_status
<philn> re
<philn> smb_tp: you meant, commenting out the initrd line? i guess i misunderstood because then i get a kernel panic
<smb_tp> philn, yeah, I meant: eg replace "/boot/vmlinuz-2.6.28-11-generic" by "vmlinuz-2.6.28-11-generic"
<philn> ah
<smb_tp> for initrd and the kernel line
<philn> ok, so remove /boot/
<smb_tp> yep
<philn> .. ok
 * philn crosses fingers and reboot
<philn> re
<philn> well i get "Error 1" from Grub
<philn> pathname must be absolute or block (something like that)
<smb_tp> philn, Ok, so that was not the problem
<philn> :(
<smb_tp> grub reads directly so it needs the complete path
<smb_tp> hm, could you probably give the error messages that happen?
<philn> when i normally boot?
<philn> hm i need to go home now, but tomorrow i'll take some photos of my screen and put them online
<smb_tp> restore the /boot things before and then boot into the non-working kernel. probably remove quiet and splash on the grub prompt
<philn> ok i'll do that, thx for the help, seeya tomorrow
<ogasawara> rtg: bug 348836 - is it too late to get in another cherrypick?
<ubot3> Malone bug 348836 in linux "ext4: panic working with large files" [High,Triaged] https://launchpad.net/bugs/348836
<ogasawara> rtg: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33a1976fbee1ee321d6f014333d8f03a39d526c
#ubuntu-kernel 2009-04-09
<lool> Will there be another kernel upload today or is the current one aimed at release?
<Kano> hi,did anybody manage to compile 2.6.30rc1 from u git
<lazka> nvidia dkms failes with latest 2.6.30 from http://kernel.ubuntu.com/~kernel-ppa/mainline/
<NCommander> apw, can you please comment on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/280669; I tested your DMA patch for the jax10 with bonnie++, but I don't seem to get any better performance
<ubot3> Malone bug 280669 in linux "DMA mode and driver jax10" [Low,Triaged] 
<apw> NCommander, so if its not of benefit we don't need it then?
<NCommander> apw, that was my conclusion since bonnie++ only shoed a minor change (likely noise)
<smb_tp_> apw, As we were asked today about the hibernate prevention. I could propose a change that inhibits hibernation if that file is present. There would be two questions, though
<smb_tp_> a) It doesn't seem that file is automatically removed on reboot
<apw> smb_tp_, yeah looking at it right now as it happens
<smb_tp_> b) Is there a way to be more obvious than just not doing anything 
<apw> there is lots of places which know how to do it.  in theory desktop stuff should can implement it
<apw> i have been playing with using notify to show the inhibit as well
<apw> let me play for a bit
<smb_tp_> My approach was a hook in /usr/lib/pm-utils/sleep.d which call inhibit on fail
<apw> yeah.  thats what i have been doing as the 'last fallback' was looking to see what we could do higher up too
<apw> /var/run gets wiped on reboot does it not?
<smb_tp_> Thinks...
<smb_tp_> Oh could be. Gosh, I always hibernated when things did not work correctly, so the file is there naturally.
<smb_tp_> forget a) then
<apw> right ... stilll looking at gnome-power-manager to see if tis easy to tell it too
<apw> it hink there is an official interface for desktop in general
<apw> but ... step one is to do it in pm utils so it works for everything
<smb_tp_> That would be a good thing
<apw> so ... i am working on it
<smb_tp_> Ok, then I leave it to you. I thought I might help as you actually should sleep, get breakfast and other stuff...
<apw> smb_tp_, who needs sleep
<smb_tp_> I usually do
<apw> :)
<manjo> smb_tp_, one of the changes I made fixed the resume issue... but now I dont know which one :)
<smb_tp_> manjo, Well, proper solution there would be to take out one change after the other and retest. ;-)
<manjo> :) heh that is what I am doing ... stupid me.. was working from the same tree all along 
<smb_tp_> On the good side the number of changes you did is likely not too vast
<manjo> no like 3 changes
<jbarnes> manjo: fyi there's a patch available for the java crash
<manjo> jbarnes, cool! 
<manjo> do u have a ppa that I can test ? 
<jbarnes> it really works around the core issue (server bug) but it works for me
<jbarnes> manjo: bryce provided one... lemme get the url
<manjo> ok
<jbarnes> oh he didn't give a url, just said it was in his personal ppa
<manjo> let me ping him 
<manjo> jbarnes, no responds from bryce ... 
<jbarnes> doesn't launchpad give you access to his ppa?
<manjo> looking .. 
<manjo> all I see is a change in status from Triaged to In Progress... 
<manjo> waiting  for bryce to respond .. will let you know what I find .. 
<jbarnes> ok
<bradf> manjo: ping
<manjo> pong
<bradf> manjo, i'm adding a driver config (mvsas)
<bradf> manjo, in the modules files in d-i what is the significance of the ? in the files?
<manjo> which file is that ? 
<bradf> manjo, d-i/modules/scsi-modules
<bradf> manjo, if you look at d-i/modules/fb-modules the lines don't have a ? after the driver
<manjo> bradf, dont know what that means... some have ? others dont ... 
<bradf> manjo: yup, that's why I was asking
<manjo> bradf, something to do with python parser ? 
<bradf> majo, how do those files get used?
<manjo> I think the debian-installer does some magic 
<manjo> I think it generates a dsc file from that list 
<IntuitiveNipple> they're used in debian/rules (around line 98) to exclude modules on a per-arch basis - the names can have shell glob expansions
<manjo> IntuitiveNipple, so ? is unwanted ? 
<manjo> coz I dont see any regex for looking for  ? 
<IntuitiveNipple> manjo: not sure on that; but that is how it is used (the final expansion is done with the "xargs rm -f")
<manjo> hmm pure magic 
<manjo> bradf, ? disables the module
<manjo> bradf, debian kernel wedge does some magic to take that out 
<manjo> mvsas in debian is under scsi-extra-modules
<manjo> bradf, so adding mvsas without ? enables it for d-i
<manjo> bradf, gen-control does some magic 
<bradf> manjo, thanks
<bradf> manjo, might have pulled the trigger a little soon on my patch, sigh
<manjo> heh u did not tst it !
<manjo> http://kmuto.jp/svn/d-i/etch/d-i/packages/kernel/kernel-wedge/commands/
<bradf> manjo, built it, don't have the hardware that matches the module
<manjo> ah someone will report that it does not or does work ... u can fix then I guess
<manjo> bradf, I posted the link with the commands that looks at those files ... you can look at the perl scripts and guess if that is exatcly what It dos 
<bradf> manjo, thanks, am looking at it now
<manjo> debian builds are just magic... I am glad I dont have to mess with it 
 * manjo goes back to regular scheduled program of debugging 
<bradf> manjo, according to rtg: A '?' implies the module is optional, e.g., if it doesn't exist for a
<bradf> particular config then its not an error.
<manjo> ic 
<RainCT> Hi
<RainCT> Since a few weeks my filesystem is corrupting all the time. I'm on Jaunty (this first happened with ext3 so I thought it was a problem with it but from then on I've reinstalled Jaunty several times choosing ext2 and it still happens). Any idea?
<RainCT> (all the time = usually once a day or more often. I'll power off and when I start the PC again it'll run a fsck because of not being umounted properly and find lots of errors which it asks me to repair manually, or sometimes even grub will directly refuse to boot and I'll have to fsck from a live CD. Sometimes it even corrupts while I'm using it and / switches to read-only, and after a while fails completely and gives "read errors", also getting fixe
<RainCT> May this be because of the kernel or is it a hardware fault (which I doubt as the hard disk isn't even 5 months old)?
<dtchen> are updates involved at any step?
<RainCT> dtchen: Afaics no, but the lowest I've tried is plain Jaunty Alpha 5.
<dtchen> also, is this "plain ext3", or is it "ext3 on LVM", "ext3 on encrypted LVM", etc.?
<RainCT> plain ext3
<RainCT> (err above in my first sentence ext3=ext4, ext2=ext3)
<dtchen> interesting. i cannot reproduce the symptom across fresh boots, but i can across week-long suspend-to-ram/resume cycles.
<dtchen> it's reproducible for me on plain ext3, ext3 on LVM, and ext3 on encrypted LVM
<dtchen> (however, i'm also using wl and nvidia, so who the heck knows?)
<RainCT> I'm downloading Lenny now, will see if it fails there too. (I've decided this is a signal for my to finally try out Debian :P).
<dtchen> i don't think it's Ubuntu's kernel, per se. i remember the first time i had a trashed jaunty install was while running the kernel-ppa mainline build of 2.6.29-rc5.
<pwnguin> RainCT: when you say the FS is corrupting
<pwnguin> arg
<pwnguin> data loss, or fsck triggers?
<RainCT> (sorry, damn Ethernet cable :P)
<pwnguin> RainCT: when you say FS is corrupting, do you mean data loss, or fsck triggers?
<RainCT> pwnguin: both, although usually the data loss is not serious
<pwnguin> and you power off normally?
<RainCT> Yes
<RainCT> For some time there was some message before it powered off (if I booted without "quiet splash")
<RainCT> "could not iterate IDE devices" or something like that (I'm telling from memory from several days ago)
<pwnguin> is there any raid involved?
<RainCT> nope
<pwnguin> how old is the drive and whatever it plugs into?
<RainCT> It's a laptop, less than 5 months old, partitions: sda1 (ext3, /) and in an extended partition sda6 (ext3, /home) and sda5 (swap); both sda1 and sda6 have the problem
<RainCT> (I've reinstalled and recreated the partitions several times, btw)
<RainCT> (that's the exact error it gave: Â«unable to iterate IDE devices: no such files or directoryÂ»)
<pwnguin> by chance, do you have diagnostic cds or partitions?
<IntuitiveNipple> RainCT: Has the laptop taken any unexpected knocks around the time this started?
<RainCT> (ah, gparted says the hard disk is an ATA TOSHIBA MK2552GS)
<IntuitiveNipple> If it were a desktop I'd immediately say "check the cables" - as a laptop I'd say, have you opened the HD access panel and checked the SATA connection and drive are secure
<RainCT> and no, I haven't moved it much this last months
<RainCT> and no, I haven't opened it, and I can't (or warranty voids)
<IntuitiveNipple> it sounds hardware related, so I'd be suspecting something loose or out of place or shorting or overheating
<pwnguin> have you searched LP for your laptop model?
<pwnguin> it sounds like a hardware thing, and if your model is susceptible, that might be an avenue to pursue
<RainCT> a google search with the model + launchpad only shows webcam support related stuff
<pwnguin> you might also check smart for anything
<RainCT> smart says "passed", if there's anything else I can ask smart to do I'd need to know the command for that
<RainCT> (smartctl, that is)
<dtchen> hmm, yeah, too late for HDA enablements fixes for HP Minis
<dtchen> i'll queue these for -proposed
#ubuntu-kernel 2009-04-10
<dandel> apw, your resume/suspend testing app is busted.
<dandel> doesn't run right on 8.04.2 (to check kernel revisions and whatnot )
<pixelmonkey> quick question: is the source code in the linux-source-2.6.27 package exactly the source code used to build my kernel in Intrepid, namely 2.6.27-11-generic?
<dtchen> pixelmonkey: with patches applied, yes.
<dtchen> wow, there are a shedload of Dells using the STAC9227 that are just broken.
<dtchen> workaround: don't use the provided quirk of dell-3stack - it's just crack
<dtchen> instead, use 3stack
<dtchen> reference: bug 279478
<ubot3> Malone bug 279478 in linux "alsa sound fades out when headphones are plugged in until you inaudible" [Undecided,Incomplete] https://launchpad.net/bugs/279478
<dtchen> confirmed for 1028:01f4
<dtchen> (and 1028:01dd and 1028:01ed)
<dandel> sheesh, trying hte apw test tool on 8.10 upgrade from 8.04 on 2.6.29 kernel caused the ubuntu partition to self destruct.
<dandel> suspend/hybernate tests mainly.
<JanC> dtchen: most dell hardware is just rebadged 3rd party hardware, so I'm not really surprised  ;)
<dtchen> well, i am.
<dtchen> there are specific quirks that purportedly work around the insanity. obviously that's bunk.
<JanC> you mean you need quirks on quirks?
<dtchen> heh. no, we just revert to the "don't rely on bios to have proper info" approach
<dtchen> which really seems to be the sensible approach when speaking HDA implementations anyhow
<JanC> that's not the default yet?  ;)
<JanC> lol
<JanC> sometimes I think that implementing interfaces in firmware could actually solve this sort of issue...
<JanC> can't be all that difficult for vendors to provide correct info
<JanC> maybe there is a way to extract this info automaticly from Windows drivers?
<JanC> (I suppose most Windows drivers are based on a reference driver)
<cooloney> ikepanhc, do you know what is the latest kernel version on intrepid?
<cooloney> ikepanhc, is that 2.6.27-14? I'm in jaunty now
<cooloney> ikepanhc, 2.6.27-14.32, right
<cooloney> ikepanhc, thanks
<ikepanhc> cooloney: its Ubuntu-2.6.27-14.32
<ogasawara> apw: smb_tp is away today right?  just fyi bug 357970
<ubot3> Malone bug 357970 in linux "No sound in Intrepid after kernel update to 2.6.27-11.31" [High,Triaged] https://launchpad.net/bugs/357970
<sconklin> rtg: I need advice on a couple of things. First, Tony is having trouble building hardy lpia in his ppa. It's trying to build other arches. I don't know how to make it do the right thing.
<apw> PPA's always build on all arches, thats normal i believe
<rtg> apw: the problem is that if i386/amd64 fail, then the package build fails
<sconklin> apw, thought you were traveling, or I would have asked you
<apw> rtg hmmm.  i thought we just didn't worry about that in PPA's only but
<apw> as i thought the result packages were separate in some sense
<apw> if we can stop it, all the better
<sconklin> apw: so I should tell Tony to ignore the package build failure and take the lpia part?
<apw> i'll have to defer to rtg's knowledge, if we can stop it \o/
<rtg> sconklin: I'd have to experiment a bit, but I don't think build _just_ LPIA is practical.
<sconklin> rtg: ok. I suppose that this has only come up because the lpia build process has been moved to the buildds
<rtg> sconklin: he can always build locally in an LPIA chroot
<sconklin> that's what he's doing, 
<apw> rtg if we removed amd64 and i386 from control.stub.in might that stop it doing the arch specific portions on those other arches
<apw> obviously the all part will still build on i386
<rtg> apw: hence, the experimentation. the PPAs behave differently in subtle ways
<erikc> Looking for some boot time help --- any idea why pty_init is taking 45 seconds to return during boot time?
<awe> sconklin: ping
<sconklin> awe: pong
<dtchen> oh fun, more pcm_lib fixes. the week of release freeze.
<pgraner> dtchen: we are going to have to spin another kernel most likely, we have some ugly intel graphics freezes we are hoping to get fixes for prior to release
<dtchen> pgraner: ok. i'm backporting those and other HDA enablement fixes
<dtchen> will ask for testers in a few hours
<dtchen> the HDA enablement ones are wishlist - SRU material, seeing how they're known quirk workarounds
<pgraner> dtchen: ack, keep rtg in the loop so we can get those in he will talk to the release team if and when the time comes
<dtchen> pgraner: will do, thanks
<pgraner> dtchen: no prob
 * manjo searches the house for some beer ... 
#ubuntu-kernel 2009-04-11
<dtchen> d'oh, it's an abi bump :(
<RAOF> How should I go about asking for the MMIO tracer to be enabled in an Ubuntu kernel somewhere, probably the kernel-ppa mainline builds or something?
<RAOF> It's not really a bug against any Ubuntu package... I suppose the kernel mailing list might be the goer.  If no one here would like to say "oh, yeah.  I'll do that" :).
<RainCT> (As a follow-up from two days ago, I installed Lenny -with default 2.6.26 amd64 kernel- and so far I haven't experienced any file system corruptions anymore.. I'll wait a bit more and then upgrade to a newer kernel)
<Kamping_Kaiser> hi all. um... should the page http://packages.ubuntu.com/hardy/linux-ubuntu-modules-2.6.24-23-generic exist? http://packages.ubuntu.com/hardy/linux-image-2.6.24-23-generic does but not the modules
<Kamping_Kaiser> might it not have been built for hardy{,-security}?
<maxb> rmadison knows about it
<maxb> linux-ubuntu-modules-2.6.24-23-generic | 2.6.24-23.37 |                        hardy-updates | amd64, i386
<Kamping_Kaiser> hm. not used rmadison before
<Kamping_Kaiser> why does it only exist in -updates not -security ?
<maxb> perhaps it wasn;t a security update?
<maxb> linux-ubuntu-modules-2.6.24 (2.6.24-23.37) hardy-proposed; urgency=low
<maxb> Right, just a normal SRU
<Kamping_Kaiser> i cant seem to find it in 'hardy' though, so what was it an update for? :| (apply cluebat if i'm missing something obvious btw)
<maxb> What do you mean "what was it an update for?"
<maxb> And why would you necessarily expect it to be in "hardy" ?
<Kamping_Kaiser> because i'd expect it to still be ther from before it was updated in -updates
<Kamping_Kaiser> i thought thats how the archive worke
<Kamping_Kaiser> d
<maxb> Aha
<maxb> The little fact you're missing is that the kernel ABI version is included in the binary package name.
<maxb> Thus, linux-ubuntu-modules-2.6.24-23-generic should be considered as an update to linux-ubuntu-modules-2.6.24-(some smaller number)-generic
<Kamping_Kaiser> i think i follow, but i'm going to sleep on it and reread in the morning to be sure. 
<maxb> Or to put it another way: -updates are updates for the distribution as a whole - which in a few very specific circumstances can involve new binary package names.
<Kamping_Kaiser> to try and clarify this for me, does that mean linux-image-2.6.24-23-386 is only useful if you have -updates, because thats the only way to get corresponding linux-ubuntu-modules-2.6.24-23-386
<Kamping_Kaiser> maxb, sorry, i'm really off. thanks for the help, hopefully its clearer in the morning
<maxb> erm
<maxb> If the -23 ubuntu-modules is in -updates, but the -23 image is in -security, that's an error
 * maxb afk too now
<mxboy15u1> hello
<mxboy15u1> anyone care to help with a atheros wireless issue?
<kees> maxb: it's in both places.
<kees>      linux | 2.6.24-23.52 | file: hardy-security/main Sources
<kees>      linux | 2.6.24-23.52 | file: hardy-updates/main Sources
<kees> oop, wrong package.  hrm
<kees> maxb: looks like it's an old error, I'll get an archive admin to fix it.
<maxb> Right... "linux" being updated in -security but "linux-ubuntu-modules-2.6.24" not being on ABI 22 in -security is uh, bad, right?
<maxb> erm
<maxb> I mean "not being on ABI 23"
<kees> yeah, though it's been like that since the first time linux was bumped to -23.  I'm checking the others....
<maxb> Kamping_Kaiser: ^ There you have it: There is indeed a problem, thanks for noticing
<kees> I'm embarassed it took so long to figure that out.  :(  Looking at the USNs, it seems that I missed the ABI bump on Hardy in January.
<dtchen> is there anything in buildscripts.git to help automate that?
<dtchen> (since i began building test kernels, i've been updating the documentation to match actual practice, too)
<kees> dtchen: the buildscripts don't really have much knowledge of the archive; I'm adding a script to the archive tools to scream when it happens.
<kees> maxb, Kamping_Kaiser: hardy should be sane again on the next publisher cycle.  sorry that took so long.
#ubuntu-kernel 2009-04-12
<mehall> hey guys, trying to pin down a kernel bug
<mehall> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292155
<ubot3> Malone bug 292155 in linux "Ubuntu freezes on startup with 2.6.27-7 generic until power button is pressed" [Undecided,Confirmed] 
<mehall> Just pinned down more details, see last comment on the bug page
<Kamping_Kaiser> kees, thanks, I'll leave it a day or two then try again.
<Kamping_Kaiser> kees, (as i dont know how long it'll take to propagate to a local mirror)
<mehall> yeah, it's upstream. Can;t find a report thoguh, I'll report it to bugzilla.kernel.org just now
<RainCT> Hi
<RainCT> I guess nobody's around now, but anyway: some days ago I explained that with Jaunty my filesystem (ext3, same with ext4) got corrupted all the time (randomly several times a day). I guess this must be a kernel issue, if not please tell me what else it can be. I've been tring with Debian Lenny now and both 2.6.26-13lenny2 and 2.6.29-3~snapshot.13390 kernels work fine.
<RainCT> If I take Jaunty's kernel will it build & work on Debian (to try to reproduce the issue here)? Or what else can I do?
#ubuntu-kernel 2010-04-12
<manjo> cking and manjo in the lobby
<manjo> anyone in the hotel?
<manjo> pgraner, you in?
<pgraner> manjo: yep just got here
<manjo> pgraner, cking says hi
<manjo> we are in the lobby
<pgraner> manjo: k be there in 5
<manjo> pgraner, cking making a phone call and will be back in 10
<pgraner> manjo: ack see you in 10 then
<manjo> ack
<dholbach> hola
<dholbach> how many people reported already that 2.6.32-20 does not boot any more?
<dholbach> I saw it on ubuntu-devel-discuss already but wondered if you'd still need a backtrace or something
<RAOF> I haven't seen anyone report that, except the one post on u-d-d.
<dholbach> I have the same on my laptop here
<dholbach> I guess it dies too quickly to even write an apport log or something
<RAOF> What does it actually do?
<dholbach> write an oops message and hang there, no magic sysrq
<RAOF> Urgh.
<dholbach> very very early on
<dholbach> damn it
<Sarvatt> can you get a picture of it?
<dholbach> I don't have my camera here
<RAOF> Oh, with no /dev/sda thingy?  THat the one?
<dholbach> RAOF: I'd need to check again
<RAOF> It oopses with no root filesystem found, though?
 * RAOF russtles up the u-d-d post.
<dholbach> RAOF: I'll check - hang on
<dholbach> brb
<Sarvatt> darn, -20 boots fine on all of my machines
<RAOF> That's an ominous lack of dholbach.
<dholbach> http://people.canonical.com/~dholbach/Bild002.jpg
<dholbach> RAOF: ^
<RAOF> Hm.  I'm not going to be of much help here.  It'd be nice if the kernel didn't scroll the top of that trace off the screen, though!
<Sarvatt> dholbach: looks like https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/561151
<ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [Undecided,New] 
<dholbach> Sarvatt: thanks muchly
<dholbach> RAOF: I agree :)
<Sarvatt> dholbach: fallout from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=3f80f9e8e30f4759ad0e29d23856126edbfc7b41 :(
<dholbach> aha
<dholbach> apw: ^ :)
<Sarvatt> apw: reverting 6a63b06f3c494cc87eade97f081300bda60acec7 instead might be an option to fix that bug going by the upstream bug report. after reverting 3f80f9e8e30f4759ad0e29d23856126edbfc7b41 it reverts cleanly
<dholbach> hey smb
<smb> dholbach, Morning
<dholbach> did you also have something to do with http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=3f80f9e8e30f4759ad0e29d23856126edbfc7b41 (causes bug 561151)
<ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [Undecided,New] https://launchpad.net/bugs/561151
<Sarvatt> dholbach: does a 2.6.34 kernel boot for you?
<dholbach> Sarvatt: I didn't try
<Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-04-09-lucid/ -- that fix is upstream so if it doesn't fail the same way it's probably something due to it being backported from .34 to .32..
<dholbach> ok
 * apw looks at dholbach ... how dare you have issues with my shiney kernel :(
<dholbach> I'll try 2.6.34 in a sec
<dholbach> brb
 * smb waves to apw
<apw> o/ smb
<RAOF> Aloha apw
<apw> yo
<jk-> hey .eu-ers
<RAOF> Can I haz also a noaccel quirk for geforce 6100 cards? :)
 * smb wonders whether we will have 3D in Lucid
<RAOF> apw: You whipped up a test kernel for bug #558657 before the weekend, I believe.  Where is it, so I can point the reporter at it?
<ubot3> Malone bug 558657 in linux "mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive" [High,Incomplete] https://launchpad.net/bugs/558657
<apw> Sarvatt, got a pointer to the upstream bug for daniels issue?
<RAOF> smb: Not in nouveau; we've never planned on having it.
<smb> RAOF, Yeah right, that was the one with experimental 3D on xorg-edgers
<dholbach> Sarvatt: 2.6.34 boots
<apw> RAOF, possibly, i did about 200
<smb> RAOF, But probably not for my card anyways. I need to check whether there has been any progress on the phantom connector front. :-P
<Sarvatt> apw: no I haven't seen any upstream bugs about it at all which is why I was asking him to try 2.6.34, https://bugzilla.kernel.org/show_bug.cgi?id=14667 is the bug I was looking at though
<RAOF> smb: Right.  Sadly, nouveau's version of âexperimentalâ seems to be pretty much superior in every way to intel's version of âfully supported i845 chipsetâ :(
<ubot3> bugzilla.kernel.org bug 14667 in EC "bisected 2.6.32 EC regression - Temperatures not correctly detected after suspend" [Normal,Resolved: patch_already_available] 
<apw> <Sarvatt> apw: reverting 6a63b06f3c494cc87eade97f081300bda60acec7 instead might be an option to fix that bug going by the upstream bug report. after reverting 3f80f9e8e30f4759ad0e29d23856126edbfc7b41 it reverts cleanly
<apw> so what does upstream bug report refer in that context
<Sarvatt> the bug I linked just now bisected it down to the regression starting from 6a63b06f3c494cc87eade97f081300bda60acec7
<Sarvatt> (which is the latest commit to drivers/acpi/ec.c in lucid outside of the fix)
<apw> RAOF, seems i built and pushed them and forgot the bug update ... now in the bug
<RAOF> apw: Thanks.
<apw> Sarvatt, its a shame that one is a pre-req of the EC multi-byte fix which fixed a whole bunch of peoples overheating
<apw> dholbach, so a recent mainline worked ok for you ... on your x61
<dholbach> apw: yes, x61s, like in the bug report
<Sarvatt> the EC multi byte fix was needed *because* of ACPI: EC: use BURST mode only for MSI notebooks though
<Sarvatt> at least thats what it sounds like from the report, it unconditionally disabled ec burst mode unless there was a MSI dmi match.. anyway I'm not sure thats even the issue, just what I noticed at a glance
<apw> Sarvatt, ahh i seem what you mean
<apw> dholbach, you on 32 or 64 bit?
<dholbach> apw: 32
<Laibsch> what is the proper way to fix bug 535132?  One way to deal with this would be for the newer package to conflict on the older, but I'm not sure that is the best way to do this.  I'm thinking about moving /lib/udev/compat_firmware.sh into a separate package.  Opinions?
<ubot3> Malone bug 535132 in linux-backports-modules-2.6.32 "package linux-backports-modules-wireless-2.6.32-16-generic-pae 2.6.32-16.6 failed to install/upgrade: trying to overwrite '/lib/udev/compat_firmware.sh', which is also in package linux-backports-modules-wireless-2.6.32-16-generic 0:2.6.32-16.7" [Medium,Triaged] https://launchpad.net/bugs/535132
<mdz> I'm having a terrible time using b43 to associate a Broadcom 4306 (core rev 5) with my home AP. it fails to scan most of the time, and when it does see the AP, it usually fails to associate (WPA or insecure). rebooting the AP, oddly, seems to have helped, and now I can associate insecurely, but it's unusably slow
<mdz> any tips?
<smb> mdz, Usually my best tip is not use b43 but the binary driver (wl)
<apw> mdz in my experience b43 has not been a good driver for those, i have used wl for all my broadcom based systems
<mdz> this is a powerpc system, so I think that's not an option for me
<apw> ahhh
<smb> Thats bad
<smb> Not sure lbm is better atm
<mdz> so my other options are buying a USB dongle, or using Mac OS X
<mdz> I am going to try with macos to see if I can rule out a hardware problem or incompatibility with the AP
<apw> i would suggest we try lbm as well, that has a newer stack i believe
<apw> lbm-wireless
<smb> I think around 2.6.33
<mdz> apw, I don't think there is one for ppc
<apw> oh hrm
<mdz> I could build compat-wireless from source easily enough, presumably
<apw> mdz yeah was just wondering why its only x86 these days
<smb> Yeah, either just never tried or it had issues in the past
<smb> But have not tried it lately
<apw> likely cause of the ports/not-ports split
<mdz> any recommendations for a USB dongle if I go that way?
<jk-> mdz: which machine is this?
<mdz> jk-, it's an iBook G4 with an Airport Extreme
 * jk- thinks back to powerbook days
<mdz> I'm told the slot is electrically miniPCI, but the form factor is incompatible for the usual Apple reasons
<mdz> so the card is in theory replaceable, but I don't think anything else fits
<jk-> hooray apple :(
<jk-> is this a recent change after upgrading, or the first you've tried on this machine?
<mdz> jk-, first try
<mdz> though I was encouraged to hear that others had success with this hardware, e.g. http://shellack.de/info/content/ibook-g4-running-ubuntu-karmic-koala
<jk-> mdz: ISTR that b43 tended to have problems when the firmware version was out of sync with what the kernel expected
<jk-> but that was a while ago..
<jk-> i've gotta scoot, but benh and johill on #mklinux may be able to help
<mdz> jk-, the firmware is all versioned, and the driver is getting what it asked for
<mdz> jk-, thanks
<amitk> apw: I've got another enforce to add to omap and just got me thinking how to make sure these are available to all branches
<apw> amitk, well if its applicable to all branches it should be on master
<apw> of course you arn't based on any of our masters so its not so easy
<amitk> apw: I wonder if it makes sense to separate out debian/ into its own branch, then every 'branch' would only contain the local debian.foo dir
<apw> well then you would have to have git to make a buildable directory
<amitk> -ENOPARSE
<amitk> me would merge the 'debian' branch at build-time
<amitk> *we
<amitk> apw: ^
<apw> amitk, or check it out perhaps yes ... the problem is you might want different ones for differnet releases, or not
<apw> i think it is a sensible goal to be honest, and one i would think deserves thinking on for sure
<apw> i was going to do some sync up between releeases after L is off my plate, so that would be a good time
<apw> we should put it on the agenda for our release sprint too, ie. in beer time
<amitk> apw: release sprint agenda?
<amitk> heh, ok
<apw> yeah ... i've added it to my paper list
<ogra> shudder ... paper
<apw> dholbach, about?  want to try a test kernel for your boot issue?  as mainline works I am trying to eliminate some ubuntu changes in the area
<apw> dholbach, kernels will be here shortly: http://people.canonical.com/~apw/lp561151-lucid/
 * apw waits for his t30 to update
<smb> apw, I just sent out another work-around patch you might want to consider (or not). I really only covers a WARN_ON by removing it. And its there only to prevent incompatible (e.g. with ARM) development. But for that reason never goes upstream that way. And the proper fix needs a bit more time that we have
<apw> smb, thanks ... i'll look it over
<apw> once i've shovelled all these thinkpads into a skip
<smb> apw, How many do you have?
<apw> all of them i think
<smb> apw, Hm, probably I am not parsing "shoveling ... thinkpads into a skip" correctly
<apw> that EC change seems to have made them _all_ break
<smb> apw, Sounds like joy. And you mentioned that upstream kernels are ok, right?
<apw> yep ... and they have the same patches ... so ... can't happen... *bang*
<mdz> apw, Jane has just told me about the issue you're working
<apw> mdz, hi
<mdz> apw, can we get on the phone for 3 minutes to assess the situation?
<apw> mdz sure
<dholbach> apw: will test in a sec
<apw> dholbach, i suspect it will crash too
<dholbach> apw: I'll let you know
<mdz> apw, I've got a sysadmin on standby to do the magic, as soon as I have the version number(s)
<mdz> is it this change here?
<mdz> * (pre-stable) ACPI: EC: Allow multibyte access to EC
<mdz>     - LP: #526354
<apw> mdz:
<apw> linux-image-2.6.32-20-generic_2.6.32-20.29_amd64.deb (29.5 MiB)
<apw> linux-image-2.6.32-20-preempt_2.6.32-20.29_amd64.deb (29.9 MiB)
<apw> linux-image-2.6.32-20-server_2.6.32-20.29_amd64.deb (29.5 MiB)
<apw> linux-image-2.6.32-20-386_2.6.32-20.29_i386.deb (29.5 MiB)
<apw> linux-image-2.6.32-20-generic_2.6.32-20.29_i386.deb (29.5 MiB)
<apw> linux-image-2.6.32-20-generic-pae_2.6.32-20.29_i386.deb (29.6 MiB)
<apw> mdz that is the one we believe it is yes, will confirm shortly
<mdz> apw, and it's lucid only, correct?
<apw> mdz that is correct lucid only
<apw> mdz thanks 
<apw> bug #561462
<ubot3> Malone bug 561462 in linux "MacBook 4,1 starts up with 2.6.32.19 but not 2.6.32.20" [Undecided,New] https://launchpad.net/bugs/561462
<dholbach> apw: fails too, let me upload the picture
<apw> dholbach, yeah ironically that is good ... as its therefore not the changes we made internally to the code there
<apw> i assume its the same type of hand
<apw> hang
<dholbach> apw: new crash: http://people.canonical.com/~dholbach/IMG_6807.JPG
<dholbach> apw: this is the old one: http://launchpadlibrarian.net/43892737/Bild002.jpg
<apw> dholbach, ok thats good, same type of crash ... not ubuntu code changes ... revert is building and i'll have that tested shortly (/me has found a laptop behind the TV which exhibits the issue
<dholbach> awesome
<dholbach> although it will mean that we have to reopen the other bug again?
<apw> amazing where laptops hide out these days
<apw> yep, but at least they booted, even if they overheat
 * apw also has one of those ... how lucky am i
<dholbach> :)
 * dholbach hugs apw
<apw> dholbach, thanks ... /me kicks his build box ... faster damn you
<dholbach> let me know if there's anything I can do
<apw> will do ... ta
<smb> apw, So mysteriously upstream kernels work and ours doesn't even as our specific change does not make a difference?
<apw> smb, that is the non-sensible current facts yes
<apw> i am waiting on both the revert to test, and a mainline build of .32.11 to complete for comparitive testing
<apw> i am assuming if the revert is 'good' on thinkpads we'll upload that and expedite it out
<apw> and then try and work out how on earth that change can work upstream later
<smb> apw, sounds quite reasonable for this time
<smb> apw, I am upgrading the external installation of my thinkpad too
<apw> smb, thanks if you could confirm it kills your TP as well that would be helpful
<apw> smb, unless its a T30 when i know it does :/
<smb> apw, That was my line of thinking. No, its a T42p
<apw> smb, cool
<JFo> Bug 561140
<ubot3> Malone bug 561140 in linux "Boot hangs after update to kernel 2.6.32-20" [Undecided,Confirmed] https://launchpad.net/bugs/561140
<mdz> apw, should ^^ be the master bug for this issue, or is there a better one?
<apw> bug #561151 is the one i was first made aware of
<ubot3> Malone bug 561151 in linux "reproducible oops at startup on thinkpad x61s in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151
<apw> that at least has the accurate panic information recorded in the title et al
<JFo> good call
<apw> mdz ^^
<mdz> apw, OK to set 561140 and all dupes as duplicates of 561151?
<JFo> I can do that if you like.
 * JFo begins gathering the duplicates to look over
<apw> mdz JFo i think the first one mentioned is a duplicate in the main
<apw> though there are as always some bad sharers i think, but yes i think consolidating on that one is good
<mdz> OK
<JFo> got it
<apw> i'll put something in it so they have some information
<JFo> apw, cool
<mdz> JFo, I had the command line all cued up, running it now
<mdz> done
<JFo> mdz, excellent :)
<mdz> 561151 is the master now
<apw> dholbach, its looking like this EC change is the culprit, could you test this kernel and confirm its good for you: lp561151-lucid/linux-image-2.6.32-20-generic_2.6.32-20.30~lp561151v201004121418_i386.deb (should be there in 2 minutes)
<dholbach> rock on
<apw> dholbach, ok its complete ... should be there to download
<dholbach> apw: rebooting
<mdz> apw, robbiew is relieving me wrt this issue
<apw> mdz, ack
<dholbach> apw: 
<dholbach> daniel@miyazaki:~$ uname -a
<dholbach> Linux miyazaki 2.6.32-20-generic #30~lp561151v201004121418 SMP Mon Apr 12 13:19:07 UTC 2010 i686 GNU/Linux
<dholbach> daniel@miyazaki:~$ 
<apw> dholbach, thanks ... i think we can call that 'good'
<dholbach> yeah :)
<dholbach> mdz: ^ (test kernel with fix seems good :))
<mdz> robbiew, ^^
<mdz> apw, does that give you enough data for an ETR?
<robbiew> mdz: ack
<apw> mdz ETR ?
<mdz> apw, sorry, estimated time for repair
<mdz> how long before the fix
<apw> robbiew, mdz, i have three reliable confirmations that a single patch revert will resolve the thinkpad issues
<apw> i would propose uploading just that single change now, wh
<robbiew> apw: but will the Dell issues occur?
<apw> which should see updated binaries in the archive in about 4 hours
<apw> robbiew, yes we will regain the dell issues, but they do at least boot
<robbiew> ok
<apw> i will continue to examine the combination to understand why upstream works on TP with that fix
<apw> as that indicates we should be able to make a working combination for both
<robbiew> apw: ack
<robbiew> thanks apw
<JFo> bug 561532
<ubot3> Malone bug 561532 in linux "MacBook Pro 5,1 fails to boot with 2.6.32.20" [Undecided,New] https://launchpad.net/bugs/561532
<apw> JFo, i am unsure if that one is a correct duplicate at this instant
<JFo> same here
<apw> will confirm with bac whether the kernel fixes him.  suspect not
<JFo> ok
<robbiew> apw: what is the bug number for the Dell issue
<apw> http://bugs.launchpad.net/bugs/526354
<ubot3> Malone bug 526354 in linux "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,Fix released] 
<robbiew> thnx
<apw> this actually seems to affect m1330 and a number of other dell systems to varying degrees of severity
<JFo> bug 561431
<ubot3> Malone bug 561431 in linux "OOPS during boot with linux-image-2.6.32-20-generic-pae" [Undecided,New] https://launchpad.net/bugs/561431
<JFo> think that ^ is a dup
 * JFo reads some more
<JFo> yep, it is thinkpad as well
<JFo> marked appropriately
<apw> jfo yeah looks like it
<JFo> cool
 * apw tries a 2.6.32.11 kernel to see if that boots ok
<smb> apw, confirmed that the t42p also crashes on boot, though it would need to find out how to make the font smaller to see what the messages are
<apw> smb, near the bottom you should have EIP still
<apw> whats that
<smb> apw, No it moves on for quite a while after it and does not allow to move up again
<apw> smb, ok ... does this kernel fix you
<apw> http://people.canonical.com/~apw/lp561151-lucid/linux-image-2.6.32-20-generic_2.6.32-20.30~lp561151v201004121418_i386.deb
<smb> apw, while I am installing. Have you checked whether thinkpad-acpi received anything we do not have, yet after the multibyte-ec patch?
<apw> smb, also could you look over the tip of master for any 'rushing too fast' thinkos
<apw> smb, not as yet
<apw> smb, skype?
<JFo> bug 561151
<ubot3> Malone bug 561151 in linux "2.6.32.30 reproducible oops at startup in acpi_ex_read_data_from_field" [High,In progress] https://launchpad.net/bugs/561151
<JFo> I'm asking for more details
<JFo>  /logging
<apw> yep thats the one we are working on?
<apw> i don't think we need anything more
<JFo> grrr, wrong bug #
<JFo> bug 561497
<ubot3> Malone bug 561497 in linux "With new Linux Kernel linux-image-2.6.32-20-generic system does not boot  " [Undecided,New] https://launchpad.net/bugs/561497
<JFo> there we go
<smb> apw, sure, just need to use the hands-in-the-air machine
<apw> smb, hehe
<smb> apw, ok, the test kernel boots
<JFo> apw, what do we mean when we say "The EC change" what does EC mean in that context?
 * JFo just trying to understand the bug
 * JFo guessed Error Correction 
<smb> JFo, embedded controller
<JFo> ah hah!
<JFo> thanks smb 
<apw> JFo, most x86 systems have a little embedded controller scanning the power buttons and the like, and its 'on the other side' of acpi normally
<JFo> I see
<JFo> ah, excellent
<JFo> Launchpad is read only
<apw> jfo u jest
<JFo> nope
<apw> how can they keep doing that right before milestones
<JFo> no idea
<JFo> but it is back out of read only
<JFo> naturally they only put it read only when I am doing something
<JFo> :-/
<BenC> Note to self, latitude d420's don't use normal sized hd's so get a spare :-/
<robbiew> cjwatson: I wonder if we should enable the grub menu be default during development (alpha and beta), and then disable in the RC.  Probably would have helped people boot into older kernels a lot easier.  
<robbiew> apw: any thoughts? ^^
<apw> robbiew, an interesting idea... 
<apw> though we have more people after release who are likely to be unable to cope than before
<robbiew> true
<robbiew> I know there was some sort of "magic" cjwatson put in that caused grub to boot to the menu if the first boot failed...however I guess in this instance, the boot "succeeded", but the kernel failed :/
<robbiew> I dunno...we are in beta, so...there has to be some tolerance for issues like this
<robbiew> imo
<apw> yeah its not obvious it was trivial to avoid
<apw> perhaps we need to better document 'useful things to do if your beta breaks'
<apw> which could include 'hold shift'
<robbiew> heh...good point
<persia> GIven the number of folk who didn't get hit by this (and similarly wouldn't get hit by any given kernel issue), it may make sense to push that documentation for RC even.
<Laibsch> I've successfully recompiled a -generic kernel from Ubuntu git.  Now I want to add a patch for one of the modules and recompile without restarting from scratch.  Is that possible?
<Laibsch> make clean in the respective directory does not work
<JFo> apw, bac says that your kernel fixed him
<apw> jfo, yeah i think it can be explained though unexpected ... the async thread would die ...and not do the other tasks assigned
<JFo> well I am glad that helped get further to the cause
<JFo> I still have no idea what is happening :-)
<JFo> well, I can't say that. I have an idea, but some things are still new enough that I don't fully understand
<apw> ogasawara, about?  whats what with that raid thing bug #557429
<ubot3> Malone bug 557429 in mdadm "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,Triaged] https://launchpad.net/bugs/557429
<ogasawara> apw: it's still seeing discussion upstream and it seems by looking at the bug report, not all are in favor of the potential fix
<ogasawara> apw: I'm skeptical that i'll get resolved by final release
<apw> ogasawara, did it end up being userspace in fact?
<ogasawara> apw: yes, appears so
<apw> well thats something
<apw> akgraner, you about?
<akgraner> apw, I am - what's up?
<apw> just a heads up that the dell fix for our fans had to be backed out
<apw> i think i have it fixed so it doesn't eat all thinkpads now, and will have a
<apw> test kernel later i hope for testing ... as you were affected i'd like you to test it 
<akgraner> yeppers
<akgraner> just let me know when and I will help ya out he best I can :-)
<akgraner> s/he/the
<apw> akgraner, thanks ... will be around an hour i'd guess
<akgraner> apw after 4:30 EDT I have to run the kids to practice and all that - so If I don't get to test with you today can we try it 1st thing in the morning your time?
<apw> akgraner, what time is it now?
<akgraner> 3:06PM EDT :-)
<apw> ahh there it is on my menu ... hiding in plain sight
<akgraner> hehe
<apw> yep ... no problem if you arn't there you arn't there, and i can't whip the horses any harder than i am
<apw> akgraner, if and when you get to look at the test kernel its here: people.canonical.com/~apw/lp526354-lucid/ ... let me know
<akgraner> apw, thanks!  I'll let ya know :-) shortly :-)  do you want an email or do you want me to reply here?
<Nader> will there be any chance of including ATA TRIM in .32? whats the situation
#ubuntu-kernel 2010-04-13
<apw> RAOF_, was that another i915.powersave i saw you handing out?
<apw> (on #ubuntu-devel ?)
<RAOF> apw: Frustratingly slowly, yes.
<apw> heh ... i did see some teeth being pulled
<apw> RAOF, what was it on ...
<RAOF> A 4 series card.  Let me grab the bug.  I'm pretty sure it'll be covered by our existing stuff.
 * apw bounces
<RAOF> I can still get a nouveau noaccel quirk into the kernel, can't I?
<RAOF> The final kernel upload is tomorrow morning?
<RAOF> apw: Yeah, there it is.  GM45.  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/555503
<ubot3> Malone bug 555503 in xserver-xorg-video-intel "screen flickers at least once every few minutes" [Medium,Confirmed] 
<apw> RAOF, and that is already covered ... ?  why didn't the user have it
<RAOF> They were on the -19 kernel.  Have we pushed the powersave quirk to the -20 kernel?
 * apw actually has lost track after the kitten killer yesterday
 * apw checks
<RAOF> I can't see anything in the changelog.
<apw> RAOF, no the change was to disable FBC for those sets not powersave
<RAOF> Ah, right.
<RAOF> bug #538648 is what I'm thinking of.
<ubot3> Malone bug 538648 in xserver-xorg-video-intel "[gm45] Irregular sync flashes with compiz on (Lenovo T500)" [Medium,Triaged] https://launchpad.net/bugs/538648
<apw> the bug there does not have the upstream infor on powersave in it does it?
<apw> hrm thats oddd, its longer now, much longer ... launchpad what are you up to?
<apw> RAOF, so in short if they need powersave = 0 we arn't expecting to need to fix them
<RAOF> Because the symptoms are insufficiently bad?
<apw> RAOF, no simply because we are unaware the issues still exist and have no bugs open on linux (that i am aware of) to change it, and no patch out there for testing
<RAOF> Ok.
<apw> final freeze kernels close today ... so i don't know if we can get it in before release
<apw> as its not stopping them booting it can easily be an SRU after release of course
<RAOF> Yeah.
<apw> and indeed has a simple work around, which we could releasenote
<RAOF> apw: Will the nouveau acceleration disabling patch make it into lucid?  Are you waiting for anything from me for that?  Splitting it into the components looks like an excelent idea.
<RAOF> https://lists.ubuntu.com/archives/kernel-team/2010-April/009884.html and its follow ups.
<apw> RAOF, i already split it up and pushed it back for review.  i hope it has all the required ack and 
<apw> am intending on merging it today ... for the final kernel
<apw> its all a bit behind due to yesterdays thinkpad debackle
<RAOF> Yeah, that was mad.
<apw> we tend to get at least one a cycle ... its hard to avoid
<apw> i am very glad it was this week and not next
<RAOF> OOoooh, yes.
<apw> and in part was why i pushed half the update last friday instead ..
<RAOF> Can I add an extra quirk - bug #542950 would like GeForce 6100 cards (pciid 0242) quirked.
<ubot3> Malone bug 542950 in linux "[Needs noaccel quirk] Screen corruption on startup" [High,Confirmed] https://launchpad.net/bugs/542950
<apw> RAOF, do we have a patch for that?
<RAOF> We don't; I can generate one easily though.
<apw> can you test the final patch ?
<RAOF> I cannot.  However, setting nouveau.noaccel=0 has been reported to work by multiple people.
<apw> thats tricky ... after yesterday i am nuvous of breaking people ... get the patch out ... and we can look it over.  i am sure it'll be 'ovvious'
<apw> if you get it out i presume on top of the other one (that was nouveau right)
<apw> then i can make a kernel and ask for testing ... and we can make a decision later today
<RAOF> It'll be an extra patch on top of your existing 3 in the series.  Is there an easy way to apply them on ubuntu-lucid?
<apw> save them into a mailbox and git am the mailbox
 * apw wonders if akgraner tested that kernel
<apw> i'd like to get that patch into the kernel and some testing feedback would help
<zimbatm> hi there
<apw> hi
<jjohansen> apw: is it to late for include a driver in the initrd
<jjohansen> Bug #530361
<ubot3> Malone bug 530361 in linux "Support for DELL H200/H700/H800 SAS cards is missing in the CD/DVD installer for Lucid (mpt2sas)" [Undecided,New] https://launchpad.net/bugs/530361
<apw> jjohansen, you know just how late it is in the cycle!
<apw> as its a CD driver for a dell server we might be able to do something
<apw> as they are likely just hosed without it
<apw> however, that is predicated on it being a simple fix
<apw> if its 'whole replacement driver' its not going to make the release images imo
<jjohansen> apw: yes, and I expect no but I just got the Q in my inbox and figured I'd ask
<apw> looking at the bug i don't see anything other than 'its broken' so its hard to evaluate whether there is a possibility or not
<apw> finally it may just be that the driver is not in the udebs
<apw> jjohansen, do we have someone who has one who can answer some of these questions?
<jjohansen> from the bug that we actually ship the driver its just not in the initrd
<jjohansen> not that I know of but I'll poke and see
<apw> it does appear that we have the driver building
<apw> debian.master/config/config.common.ubuntu:CONFIG_SCSI_MPT2SAS=m
<apw> obj-$(CONFIG_SCSI_MPT2SAS) += mpt2sas.o
<apw> it appears to be called mpt2sas
<apw> and we don't appear to put it in the installer stuff
<jjohansen> yep, there are reports of using it to "fix" the problem, its just not in the initrd
<jjohansen> right, or the installer
<apw> so if that the only issue then it is fixable i'd say ... but why the hell can't people ask last week not this
<apw> jjohansen, so who asked
<jjohansen> ttx
<apw> ttx should know better
<apw> i even sent out an email last week saying the deadline was here
<jjohansen> right, but everyone else is focused on a thursday deadline, so that gets forgotten
<apw> the thurday deadline doesn't mean thursday for _anyone_ really
 * apw needs more brown brain fuel
<mirsal> Hello there
<apw> hello
<mirsal> It's probably not the right place to ask for help but I'm trying to build NetworkManager from the upstream source tree and I'm having trouble with the wireless-tools
<mirsal> http://pastebin.com/rmUedvqs
<apw> mirsal, that normall implies there is a -dev package
<apw> you probabally want to ask about that on #nm on this server
<mirsal> apw, yeah, usually there is, but I can't find it
<mirsal> apw, I just asked there. No reply so far :)
 * apw swears ... that updated EC fix works for dells and doesn't break thinkpads ... but still breaks damn macs
<mirsal> (your last two words summarize an awful lot of issues)
<JFo> apw, very odd
<mirsal> apw, ah ! found it, thanks
<mirsal> libiw-dev - Wireless tools - development files
<mirsal> go figure ;x
<apw> mirsal, 'so' obvious
<mirsal> hmm, why I did not think about apt-get build-dep is another story...
<abogani> smb: Hi Stefan! I'm wondering if you could sponsor me (for PPU right on linux-rt package https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication) adding your comments about Feisty-Gutsy-Hardy period...
<smb> abogani, I guess I can, but you better mail me a reminder to look at it. I am currently at the airport and I'd rather do it with a bit more time later
<abogani> smb: Of course, thanks!
<achiang> hm, is there a way to get dev_dbg() statements in usb to display on console?
<achiang> maybe just pass 'debug' on the kernel command line?
<apw> achiang, do they not appear in dmesg output?
<apw> if they are in there you probabally can get them on the console direct via loglevel, if i've understood
<achiang> apw: haven't confirmed, i'm just doing some drive-by triaging on https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/433438
<ubot3> Malone bug 433438 in linux "device descriptor read/64, error -110" [Medium,Confirmed] 
<achiang> apw: in my 5 minutes of reading, that message is due to an urb timeout of some sort
<achiang> so i was just going to suggest something that the bug reporters could do to get some more info before someone who's really on the kernel team can take a look
<apw> soz can't be more authorative on that 
<achiang> "soz" ?
<apw> short for sorry
<achiang> heh, thanks
<kaouthia> Hello all. Amitk suggested it would be a good idea to say hello to you all and introduce myself. My name is Lee Jones. I have recently accepted a role within Canonical as an Arm Kernel Engineer, with a view to start at the beginning of May.
<ogra> kaouthia, awesome ! i see you are also in #ubuntu-arm already :)
<kaouthia> Yes, and ubuntu-meeting (a bit too keen me thinks) ;)
<kaouthia> I would like to pick your brains if I may. I have to purchase a laptop and Iâm finding it difficult to choose.  I would like something which compiles Kernels quickly and is going to last. Do any of you have any suggestions youâd like to make? I hear a lot of you like ThinkPads - anything in particular?
 * ogra doesnt lkie thinkpads ... i tend to buy whitebox systems to be able to replace parts if they get outdated ... but then i'm not a kernel guy i just happen to hang around here to annoy apw for ARM stuff :)
<ogra> *like
<achiang> kaouthia: building kernels quickly requires lots of cores and fast I/O, so something with Core i7 and an SSD would be good
<apw> generally i don't build on my laptop, the disk is just too slow
<achiang> your best bet is probably getting a fast desktop and a cheap laptop for travel, actually
<apw> yeah i have a "desktop replacement" latop i use as my 'home machine' a 10" laptop for travel, and use remote machines for build generally
<abogani> apw: distcc?
<achiang> fast local CPUs + fast I/O + ccache generally outperforms distcc, at least in my experience
<apw> abogani, nothing so sophisticated, just porters really
<abogani> apw: right
<abogani> achiang: Obviously ccache and distcc have different goals so I don't think that you can compare these.
<apw> i am more of a ccache user myself
<apw> not that i see a whole heap of difference to be fran
<apw> frank
<kaouthia> I already have a Sony laptop, which I really like, but I can't put Linux on it. It is the only Windows based machine in the house now. If I put Linux on it, the girlfriend will BSOD.
<apw> kaouthia, heh this is the time of equal rights, she can buy her own windows laptop
<kaouthia> That could be a cheap alt - I'll buy her a cheap laptop to surf the web and I'll have the Sony back - great suggestion!
<apw> kaouthia, now you are thinking
<apw> if you have a desktop and the sony u are likely sorted
<apw> though i suspect none of your buttons will work ... you can fix that :)
<kaouthia> Buttons?
<apw> brightness up/down volume up/down eject, that sort of button
<apw> hotkeys is prolly a better description
<kaouthia> Couldn't possibly, it doesn't have an Arm Core ;)
<ogra> nothing a hammer and soldering iron couldnt fix :)
<kaouthia> What would you want to solder a hammer to? ;)
<ogra> the old CPU to get it ripped out more easily :)
<mjg59> Hotkeys ought to work by default on all Sonys now
<apw> mjg59, heh that'd be nice
<kaouthia> Nothing a few extra volts and a cup of liquid nitrogen wouldn't fix
<mjg59> Support for the new-style systems went in a year ago
<apw> mjg59, yeah i admit i've not heard any whining about them for a while :)
<mjg59> apw: The fun bit was writing it without any of the actual hardware
<apw> qudos for that for sure
<lamont> I used to be able to see my SD card (karmic, inspiron 1520).  Now it's not there...  wtf?
<jjohansen> lamont: what kernel
<lamont> 2.6.32-17-generic
<lamont> though I guess I could reboot into -19
<jjohansen> lamont: -20 is the current kernel
<lamont> meh
<smoser> jjohansen, or anyone, can i disable the function-f2 (disable wireless) button easily ?
<jjohansen> smoser: depends
<jjohansen> smoser: on some machines its a key press the kernel sees and triggers events, on others the kernel doesn't even see it
<smoser> well this one sees it
<smoser> it probably gets routed to gnome-power-manager, right ?
<jjohansen> smoser: well does it see the keypress or just propagate an event after the fact
<smoser> the event goes through and my wirelss drops
<jjohansen> smoser: right, but there are a couple ways it can go through, and that will determine whether the kernel see it early enough to stop it
<jjohansen> smoser: basic key debugging is start with xev, see it shows up there, then move to show keys and then acpi_listen
<jjohansen> but it also could be handled by the ec
<smoser> ok. i'll poke at it sometime
<smoser> but thanks. i was hoping something easy. i keep accidently hitting it
<anoteng> Anybody wanna take a look at Bug #183461, it's not fully triaged yet, but I think it should have importance high as it makes a default installation unusable for some users. This is a very old bug, and I think it could use a pair of kernel-eyes by now.
<ubot3> Malone bug 183461 in opensuse "ksoftirqd/1 using 50% CPU or above" [Unknown,In progress] https://launchpad.net/bugs/183461
<mjg59> anoteng: I think that's several dozen different bugs
<anoteng> I was thinking the same to, should I make the reporters file separate bugs?
<JFo> anoteng, there are several thousand old bugs that need a look. it is just not currently possible to look at them all
<JFo> but yes, the reporter needs to file separate bugs 
<JFo> as much as it pains me to say it :)
<JFo> I will put this one on my list for review
<anoteng> thanks. I asked everybody to file their own bugs with apport-bug -p linux.
#ubuntu-kernel 2010-04-14
<akgraner> apw, getting ready to look at the kernel now - I had a talk tonight 6 hour drive round trip and the meeting lasted 2.5 hours :-(
<jjohansen> ouch
<EruditeHermit> hello, is there a way to build kernels and only have make build modules that have changed/been patched?
<EruditeHermit> I am currently using these instructions
<EruditeHermit> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<EruditeHermit> is there a better way?
<akgraner> apw, ping
<apw> akgraner, hi
<akgraner> so I installed the Kernel and haven't had any heat issues
<akgraner> is there anything you need me to run to stress the CPU more - I have noticed though I don't hear the fans as much but that could just be me
<apw> if your tem stays arround 45 then all is good
<apw> though that patch still breaks mac books, so we still don't have it in the lucid kernel ... grrr
<akgraner> apw, alrighty - I'll keep my eyes open and watch that  - but I haven't gotten above 48 in the last few hours
<apw> akgraner, perfect thanks ... i'll let you know when i have something more to test, likely after freeze now
<apw> and we'll have to ram the fix through the freeze if we are allowed
<akgraner> apw cool  - just let me know what if anything you will need from me :-)  I help where I can!  Thanks again!!
<mdz> JFo: I have confirmed bug 535315, which seems to have a stack of duplicates
<ubot3> Malone bug 535315 in linux "WARNING: at /build/buildd/linux-2.6.32/net/sched/sch_generic.c:261 dev_watchdog+0x262/0x270()" [High,Confirmed] https://launchpad.net/bugs/535315
<JFo> mdz, thanks :)
<JFo> I have seen several similar ones with a lot of duplicates too
<JFo> one in particular from the last 48 hours is an ath9k issue
<JFo> it is now on my list for review
<mdz> JFo: thanks
<JFo> my pleasure mdz
<refic> so.. um.. where are the headers-*_all -packages from latest mainline builds?
<JFo> refic, I don't know what you mean. I have just looked and they are all there
<JFo> in fact, I am looking now
<refic> I must be blind then
<JFo> ah wait
<JFo> I am misreading your statement
<JFo> you are looking for the _all.deb I was thinking header...deb
<JFo> sorry
<refic> yeah :)
<JFo> :)
<refic> np, good to know I'm not blind after all
<JFo> no, they are gone
<JFo> apw, any reason we no longer have _all.deb in the Kernel PPA?
<JFo> I vaguely recall a conversation about it, but I can't recall now the reason
<JFo> bug 562742 your bug refic?
<ubot3> Malone bug 562742 in linux "r8169 ethernet MAC address changes in 2.6.32 kernel" [Undecided,New] https://launchpad.net/bugs/562742
<JFo> grrr, wrong bug number
<JFo> that is what I get for trying to type it in
<JFo> oh, err looking at the wrong bug too.
<JFo> bug 562899
<ubot3> Malone bug 562899 in linux "linux-headers-*_all.deb is missing on latest mainline builds" [Undecided,New] https://launchpad.net/bugs/562899
<JFo> that one ^
<refic> nope, just found it
<JFo> iirc there was some issue building them or some such. I just can't remember
<JFo> we will find out refic 
<refic> great, thanks
<JFo> np
<gnomefreak> why is it saying that "linux is not a genuine package" when i try to report a bug?
<gnomefreak> Lucid
<mdz> gnomefreak: I believe there are cases where that actually means "you aren't running the latest kernel"
<gnomefreak> ah yes because i cant
<mdz> I don't think apport can tell the difference between an obsolete package and a non-Ubuntu package
<gnomefreak> 2.6.32-20-generic is broken
<mdz> gnomefreak: I believe you can override it by editing the problem report in /var/crash
<mdz> try deleting the UnreportableReason line
<gnomefreak> mdz: thanks
<mdz> JFo: it might be worth looking into the issue gnomefreak mentioned, since it's quite common with the kernel (due to its changing package name)
<JFo> gnomefreak, when did you update?
<JFo> mdz, I agree
<JFo> I think he may be suffering from the issue we worked yesterday
<gnomefreak> J a little while ago but that is first time in a week 
<JFo> gnomefreak, hmmm
<JFo> are you able to boot at all gnomefreak?
<gnomefreak> JFo: i get plymouth but gdm never loads
<JFo> gnomefreak, ok, thanks
<gnomefreak> dumped into TTY
<JFo> hmm
<mdz> JFo: the problem is: user tries to boot x.y.z-2, it fails, so they boot back to x.y.z-1, and then can't report the bug
<mdz> (and they get a confusing error)
<gnomefreak> mdz: i dont have a crawsh report for this issue
<mdz> gnomefreak: ah, of course
<mdz> gnomefreak: in that case, maybe you could report the bug using a browser, and then run apport-collect to add the details
<gnomefreak> mdz: i will do it in a minute, thanks
<JFo> mdz, I have added the kernel reporting issue to my notes for our next meeting
<ogra> hmm, whats the kernel-img.conf option i need to make the kernel postinst create links in / ?
<JFo> I'll bring it up before then, but we will discuss specifically at the meeting
<mdz> JFo: thanks. if you can work out what the correct behavior should be, it should be possible to fix it in apport
<JFo> gnomefreak, just let me know the bug number once you have it
<JFo> mdz, I agree. I'll rely on ogasawara's experience with apport. i'm still new to the tool
<gnomefreak> JFo: will do. you want a bug for apport reporting and the gdm not loading?
<JFo> gnomefreak, actually yes, if you don't mind
<gnomefreak> JFo: not at all
<JFo> thanks
<apw> Bug #546743
<ubot3> Malone bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
<ogra> sigh, is there any way to tell the kernel package to not create a backup link for the old kernel ? 
<mdz> ogra: man kernel-img.conf
<ogra> mdz, which package is that in ? i dont seem to have it 
<ogra> (was indeed the first i tried before asking :) )
<mjg59> ES1000 with KMS is generally miserable
<mdz> ogra: kernel-package
<ogra> ah
<mjg59> It's a horrible part with all kinds of random quirks in the DDX
 * ogra somehow needs to convince the kernel to be installable in vfat /boot 
<JFo> brb, rebooting
<ogra> hrm, no option that helps me to avoid the linking of backup kernels :/
<apw> ogra, what stops it being so installable
<ogra> dpkg: error processing /linux-image-2.6.33-500-omap_2.6.33-500.5_armel.deb (--install):
<ogra>  unable to make backup link of `./boot/vmlinuz-2.6.33-500-omap' before installing new version: Operation not permitted
<ogra> apw, if it would mv instead of linking that would solve it
<mdz> apw: vfat doesn't support symlinks
<mdz> or hardlinks for that matter
<mdz> ogra: I thought you were talking about something else
<apw> seems unusual to want to do that
<ogra> mdz, no, i'm trying to get omap working 
<mdz> ogra: that's not the maintainer script; that's dpkg itself
<ogra> oh
<apw> most systems which need to use FAT too contain their bootable kernels
<apw> install them into a normal /boot and then cp them into the fat at 'flash' time
<mdz> yes, I think a vfat /boot is perhaps not the best solution
<apw> ogra, yeah thats dpkg ... i doubt that is ever going to work
<ogra> hmm
<apw> on efi systems i used to work on they mounted the efi /boot thingy onto /boot/efi and did magic to get them into there at 'grub-install' type time
<mdz> dpkg needs to do that in order to safely replace the file
<ogra> well, sadly kernel-img.conf preinst_hook seems deprecated 
<ogra> else that could call something that mv's 
<mdz> I don't think it will help you anyway
<ogra> effectively the vmlinuz file is never used anyway
<ogra> mdz, if i manually mv it i can dpkg -i linux-image-...
<mdz> ogra: then why do you need a vfat partition?
<ogra> the only prob is that its a link 
<mdz> ogra: yes, but if you mv it, you are reintroducing the race condition that dpkg is trying to avoid
<ogra> mdz, because u-boot on beagle doesnt support any other FS
<ogra> it needs to read uImage from a vfat partition ... 
<mdz> ogra: surely it's using the vmlinuz file though?
<ogra> and that also needs to essentially be the first one on the SD
<ogra> currently its using nothing ... i havent written the flash-kernel code for that yet 
<mdz> ogra: it sounds to me like you just want to mount your vfat partition somewhere other than /boot
<ogra> but by default it treis to run boot.scr which in turn loads uImage
<apw> ogra, so why can't we mount that on /boot/efi; cp uImage* /boot/efi; umount /boot/efi as part of the flash part
<ogra> mdz, and copy uImage there ? 
<mdz> as apw says
<ogra> well, we surely can 
<apw> s/efi/something sane/
<ogra> uboot 
<mdz> or even leave it mounted, and just copy as needed
<ogra> now i'm scared ... that requires a partman module ...
<ogra> not what i was hoping for last minute before freeze :)
<ogra> but yes, that sounds very sane 
<gnomefreak> JFo: bug 563094 and bug 563102
<ubot3> Malone bug 563094 in linux "unable to report a "linux" bug using ubuntu-bug" [Undecided,New] https://launchpad.net/bugs/563094
<ubot3> Malone bug 563102 in linux "Unable to get any GUI other than Plymouth" [Undecided,New] https://launchpad.net/bugs/563102
<JFo> thanks gnomefreak 
<gnomefreak> JFo: np
<apw> bug #542208
<ubot3> Malone bug 542208 in linux "Please blacklist i830 from Kernel mode-setting" [Critical,In progress] https://launchpad.net/bugs/542208
<amitk> apw: around?
<apw> amitk, 
<amitk> apw: fsl-imx51 has control-scripts directory inside debian.fsl-imx51 with all the prerm/postrm, etc. Should it? mvl and ti don't.
<apw> amitk, yes, cause its 'old-school' 2.6.31 way of doing things
<apw> mvl and ti are both new-school and share one
<apw> amitk, thats on my radar for 'soon' as i want to pull back the new debian abstraction to karmic and thus to the .31 branches
<amitk> aah, keep forgetting
<apw> yeah its a nightmare and one reason i want to roll it back ... so it _is_ the same and not confusing
<hggdh> jjohansen: still getting the oops on -21.31
<jjohansen> hggdh: :(
<hggdh> jjohansen: want me to run a mailine?
<jjohansen> hggdh: sure
<hggdh> jjohansen: which one? Any prefs?
<jjohansen> hggdh: not at the moment
<hggdh> jjohansen: will go to the latest 2.26.33, then. 2.26.34 would not even boot on my machine
<jjohansen> hggdh: actually it would be good to try 32 and 33
<hggdh> jjohansen: OK. latest .32 and latest .33
<jjohansen> yes please
<hggdh> will do
<JFo> bug 563156
<ubot3> Malone bug 563156 in linux "laptop runs hot, shorter battery life, fan always on - lucid beta2" [Undecided,New] https://launchpad.net/bugs/563156
<johanbr> the mainline headers build still looks broken
<johanbr> linux-headers-2.6.34-020634rc4-generic depends on linux-headers-2.6.34-020634rc4
<johanbr> and the latter doesn't exist
<hggdh> jjohansen: 2.6.32-11-lucid does not install the headers, missing a package
<jjohansen> hggdh: hrrmm, okay I'm not sure what is up there will have to poke what of 2.6.33
<apw> yeah some headers are missing from the mainline builds at the mo, not had a chance to look why
<apw> its on  my list, but its freeze today ... so ... not today
<tumbleweed> firmware request: this should be easy enough to fix, the firmware is in gregkh's git repo: https://bugs.launchpad.net/bugs/508746
<ubot3> Malone bug 508746 in linux "rtl819xE:request firmware fail!" [Low,Confirmed] 
<apw> tumbleweed, its 3 hours to freeze its unlikely anything will change before then
<tumbleweed> apw: yeah, somebody just gave me a laptop to look at that, which was suffering from that bug 5 hours ago :0
<ubot3> tumbleweed: Error: Could not parse data returned by Malone: list index out of range
<tumbleweed> :)
<apw> heh
<kern00b> hi guys. I'm not really a very big kernel expert, so I would rather ask the pro's. I have a box that's presently in production, and I/we had to manually roll in the NIC driver/module. If/when I dist-upgrade the kernel, would I have to manually re-roll the driver into the new kernel, or will it get ported in the upgrade?
<jjohansen> kern00b: if the new kernel doesn't include the driver you will need to re-roll it
<jjohansen> the new kernel may have the driver you need though
<jjohansen> basically each kernel gets its own set of modules
<kern00b> jjohansen: thanks
#ubuntu-kernel 2010-04-15
<EruditeHermit> hello, if I have a kernel compiled according to https://wiki.ubuntu.com/KernelTeam/GitKernelBuild is there a way to patch it and only rebuild that module and get another package?
<EruditeHermit> how do I avoid rebuilding the entire kernel
<EruditeHermit> anyone?
<RAOF> You might be able to get away with just calling fakeroot debian/rules binary
<RAOF> You might be able to get away with just calling fakeroot debian/rules binary-generic
<jjohansen> yep, 
<jjohansen> what you need to do is patch
<amitk> EruditeHermit: try make O=debian/build/build-<flavour>
<jjohansen> rm debian/stamps/stamps-build-generic
<jjohansen> then you can do fakeroot debian/rules binary-generic
<jjohansen> it will only rebuild the module and then do packaging
<jjohansen> amitk: way of make will work but won't give you the package
<jjohansen> s/amitk/amitk's/
<EruditeHermit> ok
<EruditeHermit> let me try that
<EruditeHermit> this has bugged me for months
<EruditeHermit> no rule to make target 'binary-generic'
<EruditeHermit> I reran the build command
<EruditeHermit> maybe that screwed things up?
<jjohansen> what exactly did you run?
<EruditeHermit> CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers
<amitk> EruditeHermit: eeeeks
<amitk> make-kpkg is not supported
 * amitk checks the wiki
<EruditeHermit> so what do you guys recommend?
<EruditeHermit> what tutorial should one use?
<EruditeHermit> I was using this
<EruditeHermit> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<amitk> wtf, wiki talks about make-kpkg
<jjohansen> heh???!!! since when I don't remember it talking about make-kpkg
<EruditeHermit> basically I need to git clone a kernel source, patch it, then build it into an installable package
<jjohansen> EruditeHermit: I would just run  fakeroor debian/rules binary-generic
<EruditeHermit> but the cloned version doesn't have a debian dir
<RAOF> jjohansen: That won't work for upstream kernels, though.
<jjohansen> ah, I was thinking patching our kernel and rebuilding
<EruditeHermit> nah
<EruditeHermit> so I am working with a kernel dev on a bug
<EruditeHermit> so I need to use his specific kernel
<amitk> this one is a user-contributed wiki page, I think. Needs to be scrubbed
<EruditeHermit> and then he sents me patches
<amitk> Try this instead: https://help.ubuntu.com/community/Kernel/Compile
<amitk> hmm.. but Leanne has contributed to the page
<EruditeHermit> amitk, which part of that page?
<EruditeHermit> amitk, I am not using Ubuntu kernels
<EruditeHermit> so I don't have debian dirs
<EruditeHermit> most of those instructions assume a debian/ dir
<amitk> errm, this is a channel for ubuntu kernels, really.
<amitk> you didn't mention that at the beginning
<EruditeHermit> right, but I am building kernels the Ubuntu way
<EruditeHermit> err I want to build kernels that are created as deb packages
<jjohansen> EruditeHermit: I have never done mainline into a package before but one idea would be to grab our kernel and copy over debian and debian.master
<EruditeHermit> do you guys have a 2.6.34-rc2 or newer kernel?
<amitk> apw: ^^^ mainline building as a .deb question
<amitk> EruditeHermit: yes, we build all mainline rc releases these days
<EruditeHermit> so I can just copy the debian dir from that?
<amitk> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<EruditeHermit> as jjohansen said?
<amitk> that might be easiest
<jjohansen> EruditeHermit: I've never tried it, it might need a tweak but it should work
<EruditeHermit> err rok
<EruditeHermit> i'll try that if no one has any better suggestions
<crazybyte> hello! Perhaps somebody could help me to either solve or find the cause of the following problem. I switched from Hardy to Karmic (and Lucid Beta 2 for a short time). Since my switch the kernel is constantly sending out oopses at random times (after boot up). It says that it cannot satisfy a paging request around a certain address that repeats itself. Also always in the traceback I'm getting functions related to file system oper
<crazybyte> ations (like getting an inode). I figured iot could be a memory problem so I ran memtest for a long test and also a hard drive test (including badblocks, fsck and smart self test) but without any luck, there is no hardware error (at least that is the impression).  Could somebody enlighten me what could be the possible cause of these errors or how could I debug it and find what is causing them? At this stage my machine (which is 
<crazybyte> a laptop) is unusable entirely. Thank you!
<amitk> crazybyte: filesystem errors? We'd need a log to say more...
<crazybyte> amitk, i would happily send it or put it up somewhere
<crazybyte> but only tonight because i'm at work now.
<crazybyte> amitk, could a hw be the cause of these kernel oopses?
<crazybyte> amitk, also I tried using ext4 and ext3 with the same result
<jjohansen> crazybyte: its possible, but it is likely you are hitting something else
<jjohansen> we really need to see a traceback to get a better idea
<crazybyte> jjohansen, i will get all of them and come back later
<crazybyte> ok?
<jjohansen> crazybyte: also I would try installing the latest 2.6.32-21 kernel it has several fixes in it
<amitk> crazybyte: file a bug using 'ubuntu-bug -p linux' and it will get everything we need
<crazybyte> amitk, ok
<crazybyte> i will
<crazybyte> thanks
<crazybyte> :)
<EruditeHermit> jjohansen, so how do I obtain the debian dir from an ubuntu kernel source package?
<EruditeHermit> I downloaded the source package from the mainline kernel ppa
<EruditeHermit> but it doesn't have the debian dir inside
<EruditeHermit> they don't make this easy
<EruditeHermit> lol
<RAOF> EruditeHermit: You could (a) clone the ubuntu kernel git tree, then (b) add Linus' tree as a remote, and git checkout the kernel commit of your choice, then (c) run âgit checkout master -- debian debian.masterâ to do a partial checkout of ubuntu's tree - picking up just the debain directories.
<EruditeHermit> err sounds a little intense
<EruditeHermit> if ubuntu has a git repo
<EruditeHermit> perhaps I can just clone that repo somewhere
<EruditeHermit> and copy over the debian dir
<EruditeHermit> where does ubuntu keep its repos?
<amitk> kernel.ubuntu.com/git
<EruditeHermit> so which one is the mainline one?
<EruditeHermit> lets say I wanted to clone 2.6.34-rc2 of Ubuntus mainline tree
<jjohansen> EruditeHermit: I don't believe the mainline ones are there
<jjohansen> sorry I didn't realize the debian dir wasn't in the mainline source package
<jjohansen> I would say clone the lucid tree
<jjohansen> and just copy over debian and debian/master
<jjohansen> I am sure apw will have a better way when he shows up
<EruditeHermit> the lucid tree is 2.6.32
<amitk> EruditeHermit: today is a very bad time for most of us - we're busy with Lucid freeze
<amitk> you'll have to figure out yourself or wait for next week
<EruditeHermit> no probs
<EruditeHermit> i'll try checking in daily
<EruditeHermit> or every few days
<apw> EruditeHermit, yep thats how the builds are made, copy the one out of the tip of the lucid tree into the tree you want to build
<EruditeHermit> apw, will the 2.6.32 debian dir work with 2.6.34?
<EruditeHermit> apw, and do you have a git repo URL for me for the master?
<apw> that is literally how we make the mainline builds
<apw> so it works as well for .34 as the mainline builds
<EruditeHermit> lol
<EruditeHermit> ok let me try
<apw> the main tree from lucid is the place to get it
<EruditeHermit> what is the git URL?
<apw> git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<EruditeHermit> ah thanks
<EruditeHermit> i'll let you know how it goes
<EruditeHermit> and its literally the master branch of this tree right?
<apw> yep
<EruditeHermit> so copy over debian dir, then fakeroot debian/rules binary-generic will build packages
<EruditeHermit> then I can patch 1 driver
<EruditeHermit> and do fakeroot debian/rules binary-generic again
<EruditeHermit> and it will just compile that one changed driver
<EruditeHermit> and create a new package
<EruditeHermit> correct?
<apw> plan is correct, the build will rebuild everything, thats the nature of debian packaging
<EruditeHermit> wait thats the whole point
<EruditeHermit> to avoid rebuilding every module
<EruditeHermit> also it keeps running me through the config script every time I try it
<EruditeHermit> and doesn't build anything
<EruditeHermit> apw, how do I avoid having to rebuild everything all the time
<apw> in the debian/stamps there is a build stamp i think you can remove that and it'll do what you want, but i normally build in full so i can't be more definative
<jjohansen> yes, it does
<EruditeHermit> will it rebuild just the module I want?
<jjohansen> you may need to retouch the prepare stamp
<apw> i only recall removing one
<jjohansen> EruditeHermit: as long as the patch doesn't touch other parts of the kernel
<EruditeHermit> just touches a GPU driver
<EruditeHermit> also unrelated
<EruditeHermit> what does this mean?
<EruditeHermit> check-config: FAIL: value CONFIG_DEFAULT_SECURITY_APPARMOR y
<apw> it means that your config does not have app-armour
<apw> which is a manditory configuration for ubuntu therefore enforced
<apw> you can build skip-modules=1 or modules-skip=1 something like that
<EruditeHermit> do I need to install app-armour?
<apw> crap, config-skip or skip-config
<jjohansen> EruditeHermit: no
<apw> grep for it in the debian directory
<jjohansen> skip-config=true
<apw> you will also want skip-modules=1 and skip-abi=1
<jjohansen> yep
<apw> else we'll be having conversations on those as well
<EruditeHermit> so what would the command I run be
<EruditeHermit> skip-modules =1 skip-abi=1 fakeroot debian/rules binary-generic
<apw> and skip-config=1
<apw> otherwise i think thats right
<EruditeHermit> skip-modules=1 command not found
<EruditeHermit> how do you guys manage such a build system
<EruditeHermit> isn't it hard to work with?
<jjohansen> EruditeHermit: not really, the kernel is kept in sync with it
<jjohansen> having the extra checks can be a life safer
<EruditeHermit> so that skip-modules=1 stuff isn't working
<jjohansen> now deviating and doing your own custom builds with it does become harder
<amitk> EruditeHermit: your requirements are a bit unusual, mainline kernel, ubuntu configs, no ubuntu patches, own patches, no complete rebuild, *sigh*
<EruditeHermit> lol
<EruditeHermit> all I want to do is have my mainline kernel or custom kernel sources built the ubuntu way with something like ccache
<jjohansen> skipmodules=true skipabi=true fakeroot debian/rules binary-generic
<amitk> and now add ccache
<EruditeHermit> ccache essentially does what I wanted which is to not rebuild the entire kernel if I patch 1 driver
<EruditeHermit> I am trying to debug a problem in one driver
<EruditeHermit> I don't really care about most of the kernel, just the graphics stack that I am working with
<amitk> so why not just compile it normally using make and use the resulting zImage and modules?
<EruditeHermit> its easier to keep track of packages
<EruditeHermit> package managers are nice because you don't leave stray files around
<EruditeHermit> and it seems that Ubuntu/debian packaging isn't designed to do this easily
<EruditeHermit> which I understand is not the goal of it
<EruditeHermit> but it still makes things hard for me =p
<EruditeHermit> btw thank you all for your help
<EruditeHermit> I'm sorry if I am asking too many questions
<EruditeHermit> but there really isn't documentation about how to do this
<apw>  bug 563679
<ubot3> Malone bug 563679 in linux-mvl-dove "CONFIG_BLK_DEV_RAM_SIZE should be 65536 as in other kernels" [Undecided,New] https://launchpad.net/bugs/563679
<apw> bug 563893
<ubot3> Malone bug 563893 in thunderbird "Thunderbird will not launch do to a recursive symlink" [High,Triaged] https://launchpad.net/bugs/563893
#ubuntu-kernel 2010-04-16
<EruditeHermit> hey, what does this mean when doing fakeroot debian/rules binary
<EruditeHermit>       read 2675 modules : new(166)  missing(77)
<EruditeHermit> EE: Missing modules (start begging for mercy)
<EruditeHermit> make: *** [module-check-generic] Error 1
<EruditeHermit> and what do I do to overcome it
<raof> Disable the ABI checker, I think.
<akheron> there are a bunch of make variables that disable these tests, you need to use those
<akheron> just don't remember their names :)
<EruditeHermit> hrm
<EruditeHermit> I thought I did
<EruditeHermit> I did skipabi=1
<EruditeHermit> my command was
<EruditeHermit> skipmodules=1 skipabi=1 skipconfig=1 fakeroot debian/rules binary-generic
<EruditeHermit> do I have to remove the stamp or something?
<EruditeHermit> beb
<EruditeHermit> brb
<RAOF> http://paste.ubuntu.com/415384/ has been happening a bit on my laptop (on the order of maybe once a week or so) - is this a kernel bug, or is my hardware bad?
<amitk> raof: it could be HW or kernel. I suspect you've already tested your memory and disk for errors?
<raof> amitk: I've run SMART tests and done a memcheck some time ago; are there better tests?
<amitk> raof: it is probably worth filing a bug, csurbhi, our extX expert is at a conference, should be able to look at it next week
<raof> amitk: Could you bounce the pastebin url back at me?  It's obviously difficult to store any form of log once the bug flips my storage read-only :)
<amitk> http://paste.ubuntu.com/415384/
<raof> Thanks.
<raof> amitk: Looks like it's probably not my hardware; bug #539467 seems to be what I'm seeing.
<ubot3> Malone bug 539467 in linux "Frequent ATA errors and disk corruption" [Undecided,Triaged] https://launchpad.net/bugs/539467
<gribelu> Hi. I noticed that http://kernel.ubuntu.com/~kernel-ppa/mainline/ doesn't have the linux-headers-2.6.34-020634rc4_2.6.34-020634rc4_all.deb package
<gribelu> any reason why? 
<jjohansen> gribelu: something is broken, with mainline kernel generation and no one has had time to look at it and fix it yet
<gribelu> ah so it's a known issue. I'll wait
<gribelu> thanks
<jjohansen> yeah, thanks for reporting though
<refic> are there any scripts available that one could use to build those packages? instead of getting them from mainline/
<amitk> refic: http://kernel.ubuntu.com/ubuntu/kteam-tools.git
<jjohansen> refic: we grab the mainline kernels, and copy the debian and debian/master directory into it and then do the regular fakeroot debian/rules build
<artnay> is there any way to obtain alpha 1 or alpha 2 and/or daily builds between those alphas? I'm asking this because of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/560306 - 5xxx series is the most sold separate GPU at the moment so I think the importance of this bug would be high
<ubot3> Malone bug 560306 in linux "[lucid] ATI hd5xxx cards wrongly doing kms?" [Undecided,Confirmed] 
<persia> Hi.  I just noticed a new linux upload, and it didn't include the one-character fix for my pet bug.  Would anyone have time to look at bug #560717 to suggest what I could do to help make it land?
<ubot3> Malone bug 560717 in linux "ports kernel lacks device-mapper as built-in (causes LVM not to activate)" [Medium,Triaged] https://launchpad.net/bugs/560717
 * persia attacks the IRC client with new and different techniques
<persia> ]Worked.  Sorry for the noise.
<refic> anyone looked into the headers-*_all issue yet?
<apw> refic, us t
<apw> is thi
<apw> is this for mainline builds?
<apw> if so no, that person will be me, and i am dealing with main kernel release crises right now
<apw> it will have to wait until next week
<persia> apw: Hey.  So, I've a pet bug that makes my lucid server unbootable with a 1-character change to fix it.  What's the best way to get this included in the next upload?
<apw> persia, when did we hear about this?  its missed release, have to be SRU
<apw> milestone it lucid-updates and subscribe me i guess for now
<persia> bug #560717 : I noticed it last weekend
<ubot3> Malone bug 560717 in linux "ports kernel lacks device-mapper as built-in (causes LVM not to activate)" [Medium,Triaged] https://launchpad.net/bugs/560717
<persia> apw: kees milestoned it for release: does that need to change?
<persia> Ah, it got retargeted.  Nevermind.
<apw> he can milestone it there, but without settting a fire under the release team its not going to happen
<persia> OK.  Thanks.
<apw> if you'd brought it direct to me on the monday you might have gotten it in, might, we were already slamming the door as the last expected upload to main distro kernle was last thing tuesda
<persia> Sorry.  I thought filing a bug would do it, but apparently needed to have done more.
<apw> persia, we have 10k open bugs, there is little way one can sensibly sift the most important things out in a timly fashion
<persia> heh.  makes sense.  I'll come make a fuss here if I find something like that again.
<apw> yeah better to make a fuss an be told we've seen it
<apw> jfo does a sterling job but there are loads of new bugs everyday
<ogasawara> bug 563436
<ubot3> Malone bug 563436 in linux "comedi drivers are missing completley in the /lib/modules dir" [Medium,In progress] https://launchpad.net/bugs/563436
<ogasawara> bug 483343
<ubot3> Malone bug 483343 in linux "USBDUX driver timeout" [Medium,In progress] https://launchpad.net/bugs/483343
<ogasawara> anyone have the power to approve the Lucid nominations in those bugs for me?
<tgardner> ogasawara, done
<ogasawara> tgardner: thanks!
<ogasawara> tgardner: good to have you back :)
<tgardner> ogasawara, I thought you could do it? Did you get removed from some critical team?
<ogasawara> tgardner: yah, I got dropped from canonical-qa so my magic is gone
<tgardner> ogasawara, bummer
<persia> This is already scheduled to be fixed, but we're having a bit of implementation fuss.  Worst case, it ought be sorted by the 27th (which is too late for lucid, sorry)
<apw> ogasawara, which package are they on ?
<apw> is that the actual kernel ?
<ogasawara> apw: yah, am about to send emails
<Keybuk> apw: you around?  got a question for you
<apw> do i ever leave?
<Keybuk> no ;)
<Keybuk> so Val just gave a great talk on vfs union mounts
<Keybuk> apparently there's a new set of patches on lkml
<Keybuk> it would be GREAT if we could get a kernel built with those applied
<Keybuk> either the lucid or maverick kernel base (depending which was available)
<Keybuk> so we can test pre-UDS
<apw> Keybuk, ok could you send me a link to the emails or something to remind me
<apw> i should be able to retask a ppa to them
<Keybuk> apw: I'll mail you when I have e-mail :)
<apw> heh sounds like fun
#ubuntu-kernel 2010-04-17
<crazybyte> amitk, jjohansen  hello! If you remember I tried to ask you in helping me find the cause of some kernel oops in Karmic. Here is the bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565172 I also tried to use noapic kernel command line option that seems solves the issue (apparently). Any suggestion about this would be greatly appreciated. Thank you!
<ubot3> Malone bug 565172 in linux "BUG: unable to handle kernel paging request at f76ff01c" [Undecided,New] 
<jjohansen> crazybyte: okay thanks I'll have a look
<joaopinto> hello
<joaopinto> was the ext4 barrier set to a default with the last upgrade ?
 * hyperair thought it had always been a default.
<joaopinto> hum, that is odd I just noticed a major performance decrease recently
<joaopinto> a debootstrap that usually takes 1-5 minutes was taking like 10-20
<joaopinto> I had to manually force barriers to 0 on fstab
<joaopinto> I don't have this problem with a VM which is using the server kernel
<hyperair> joaopinto: you could cat /proc/mounts on older releases to check
<StallMan> hi all
<StallMan> can i use kernel.ubuntu.com as PPA/repo ? 
<melkor> The kernel development seems to have changed recently.  Why aren't there any more 2.6.33 versions?
<melkor> Also these distro dependant packages.  I can't seem to install because they are missing a file (2/3)  so do I have to use the file from a previous release?
<melkor> ie the latest 2.6.34 rc4 installed okay today with only two files, but I already had a 2.6.34 rc 4 installed.
#ubuntu-kernel 2010-04-18
 * StallMan Ð½Ð¾ÑÐ¸ Ð²ÑÐµÐ¼ / good night all
<VinceN> Evening folks, I was wondering if this was the correct place to ask a question about a specific Kernel bug?
<crimsun> it could be, just ask.
<VinceN> I'm concerned about a long standing bug the came up with the 9.10 release documented on launchpad under Bug #451337.  It's a cooling fan issue with an Acer Aspire series laptop.  I've been stuck using a patched -14 kernel and I keep hearing a fix is coming but nothing ever seems to materialize in the newer releases.  I'm very concerned about what those who are affected are going to do when Lucid comes out.
<ubot3> Malone bug 451337 in linux "CPU cooling fan does not start at all" [High,Triaged] https://launchpad.net/bugs/451337
<persia> VinceN: Do you know if anyone affected has tested a prerelease kernel?
<VinceN> I have contacted the Bug Maintainer, Andy Whitcroft and was advised someone had closed the bug out, it got reopened and he was going to try to find someone to work on it.  Never heard anything back.  I offered to help since I have one of the affected machines.  I'd work on it myself but i'm afraid this kind of thing is way way way way above my knowlage level.
<VinceN> persia, Not to my knowladge, and i've been afraid to upgrade myself because my 9.10 release was unusable until the -14 patch came out.  It isn't availible in Mr Whitcrofts PPA anymore so I couln't go back if it breaks.
<persia> VinceN: If you're affected, you might want to try downloading an lucid-beta2 ISO, and creating a bootable USB, and booting off that to see if you can replicate: this would let you leave your base system unaffected.
<VinceN> I'd be happy to do that to see if the newer version is affected.  If it is what can I do to get this in the hands of someone who can fix it and how can I help them?
<persia> That's harder to answer.  I know the lucid kernel is now hard-frozen, but you might have something eligible for SRU.
<persia> But the best way is usually to communicate your testing experience with each available kernel to the bug.
<VinceN> Ok, I will work on downloading that and testing and get back to you on that.
<crimsun> at this point you're probably better off using the latest daily-live iso.
<crimsun> just boot from it to test, etc.
<persia> Oh, that's right.  There was a new kernel post-beta2.  Yeah, sorry.
<VinceN> crimsun : Where would be the best place to get that?
<crimsun> cdimage.ubuntu.com/daily-live/current/
<crimsun> (I think)
<VinceN> Got it thanks
<VinceN> I'll download that and try it out.  I would be so happy if we could get this fixed if it isn't already.  It's been a major pain in the neck since 9.10 came out.  Previous versions of Ubuntu worked great under this platform aside from some PulseAudio issues.  I'd be estatic if Lucid could be the perfect fit.
<VinceN> Thank's agian guy's, I'll let you know
<junmin> hello, please anybody could paste me the default ubuntu kernel config file? thanks
<persia> junmin: If you're running Ubuntu, it's in /boot/config-`uname -r`
<junmin> persia: i am not running ubuntu :s
<persia> http://paste.ubuntu.com/417568/ is my config : might be slightly different for different flavours/architectures
<junmin> persia: thanks let me see
#ubuntu-kernel 2011-04-11
<JoshuaL> Since the kernel freeze is in 3 days I have a request, can someone please take a look at this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/754825
<JoshuaL_> Oops, kernel panic
<apw> JoshuaL_, that is the 'staging' driver for broadcom chips right?  does your system work ok with the proprietry wl driver ?
<JoshuaL_> apw: its the driver enabled by default, the same happens with the proprietary driver 
<apw> JoshuaL_, if the panic is the same with the prop driver then i suspect that the brcm80211 driver has not been disabled correctly
<JoshuaL_> apw: ok, how can i check if it is disabled properly and if not how do i disable it then?
<apw> JoshuaL_, it would make sense to see if brcm80211 is blacklisted in /etc/modprobe.d/* .... if it is not make a new file blacklist-brcm80211.conf containing 'blacklist brcm80211'
<apw> (all when the prop driver is enabled) and see if that works as a combination
<apw> the brcm80211 driver is very flaky as far as i know at the current release
<JoshuaL_> blacklist-bcm43.conf is present, ill add the blacklist-brcm80211.conf and see if it helps
<apw> JoshuaL_, thanks
<JoshuaL_> apw: isnt it an idea to have it disabled by default in the final release?
<apw> JoshuaL_, yes may well be ... will decided based on your testing
<apw> its enabled on all my systems with those chips but seems to silently do nothing with wl in place so you are slightly unique
<apw> but it also seems odd that installing bcmwl does not add the disable
<JoshuaL> Oops, after my last message i had the kernel panic, could you please repeat what I had to blacklist?
<apw> <JoshuaL_> blacklist-bcm43.conf is present, ill add the blacklist-brcm80211.conf and see if it helps
<apw> <apw> JoshuaL_, it would make sense to see if brcm80211 is blacklisted in /etc/modprobe.d/* .... if it is not make a new file blacklist-brcm80211.conf containing 'blacklist brcm80211'
<JoshuaL> apw: thanks. isnt it an idea to disable the driver by default in 11.04?
<apw> <apw> its enabled on all my systems with those chips but seems to silently do nothing with wl in place so you are slightly unique
<apw> <apw> but it also seems odd that installing bcmwl does not add the disable
<diwic> poor dude
<apw> yep he has a bad case of the bouncy bouncy
<JoshuaL> it makes me happy to hear that I am unique :D
<JoshuaL> :p
<diwic> hmm, that was the old one disconnecting though, thought he had another panic
<JoshuaL> i am going to reboot so the bad driver gets disabled, brb
<apw> diwic, heh me too
<JoshuaL_> back, is there anything i could do to collect more information to solve the problem?
<apw> JoshuaL_, the quality of that driver is so bad right now just avoiding it seems to be the recommendation ... i don't think its going to mature for a few upstream kernel releases
<apw> it is one of the drivers which truly deserves to be in staging
<JoshuaL_> ok :)
<apw> still at least it exists and is improving, better than nothing
<JoshuaL_> true
<ppisati> kexec -l /boot/vmlinuz-2.6.38-1207-omap4 -append="console=ttyO2 ..."
<ppisati> Memory for crashkernel is not reserved
<ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
<ppisati> but if i add "crashkernel=16M" and flash-kernel
<ppisati> the board dioesn't boot anymore
<ppisati> so, what's the magic to get kexec work on ARM?
<ppisati> i'm just following: LP517841
<ogra_> i think ericm and cooloney worked on kexec support on arm in the past 
<ogra_> (but gave up when it broke over and over again)
<ppisati> let's see if they are still around
<apw> ppisati, does that work without a 'where' part?
<ppisati> apw: it should figure out where to reserve memory by itself
<ppisati> apw: that's what the kdump doc says
<ppisati> http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
<ppisati> crashkernel=size[KMG][@offset[KMG]]
<ppisati> the funny thing is that, all the docs i found about kexec didn't mention this crashkernel= option
<apw> ppisati, ahh ok, supprised for most use cases you need to also know where it is ... but that shouldn't stop it working i ugess
<ppisati> so i wonder if it has been added later
<apw> you shouldn't need a crash kernel if you are just using it for kexec though should you ?
<ppisati> nope
<apw> ie if you are kexec 'load' then reboot or whatever you do these days
<ppisati> apw: the i guess you need to specify where the "new" kernel is loaded
<apw> i thought when you -l'd it it just found enough space in memory for it anywhere
<ppisati> actually is the kexec tools that complains about that option
<apw> then copied it to the normal place on actuall hand over
<ppisati> that was the plan, but it complains
<ppisati> kexec -l ...
<ppisati> Memory for crashkernel is not reserved
<ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
<ppisati> Then try loading kdump kernel
 * apw wonders if there are two load options
<apw> or possibly that simply it cannot find enough memory to load it
<ppisati> perhaps the second one
<ppisati> the kexec man page states:
<ppisati> kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd
<ppisati> and then
<ppisati> kexec -e
 * apw whines about installing kexec-tools to just look at the man page regenerating his initramfs
<apw> ppisati, oddly there are two load options '-l' and '-p' and the message you get is what i'd expect from -p
<ppisati> kexec-tools broken?
<apw> possible
<apw> i would try -p for giggles and see what it does
<ppisati> on mvl-dove it doesn't complain about the missing crash-kernel=
<apw> ppisati, wihch kernel did you say it was complaining?
<apw> i wonder if there is a kexec config difference on omap4
<ppisati> yep, omap4
<ppisati> Linux panda 2.6.38-1207-omap4
<fairuz>  Hi, If I patched my kernel with a xxx.h, and I build an external modules that uses xxx.h. I've tested it on the patched kernel and it works. Is it possible to use the module (by recompiling of course) with an unpatched kernel? or will it complaining about the missing xxx.h?
<apw> fairuz, all depends where the xxx.h is, if its with the module source it should be foudn
<fairuz> apw: ok ty
<ogasawara> apw: \o/ welcome back!
<apw> ogasawara, YAY!
<jjohansen> apw: Bug #757549
<apw> bug #757549
 * apw hits ubotu
 * smb thinks ubotu has quit
 * ogasawara back in 20
 * apw goes to touch test natty on his main dev box
<donri> I'm having sound issues with ALC892 in Maverick and I'd like to try a more recent kernel. Do I have to build myself?
<lag> apw: Why doesn't checkpatch like emacs?
<lag> apw: Specifically, it's tabs
<apw> lag, define not liking them, how does it complain
<lag> It's not checkpatch's fault, it's Emacs
<lag> 0001-Framework-for-exporting-System-on-Chip-information-v.patch:69: WARNING: line over 80 characters
<lag> #69: FILE: drivers/base/soc.c:22:
<lag> +                                                                                 struct device_attribute soc_attrs[])
<apw> suspected as much
<lag> Auto indentation 
<apw> emacs is stupid at times
<apw> s'why real men don't use it :)
 * lag tuts
<lag> I like it :)
<lag> It's never done this before though?
<lag> All looks good in the file, but when you run checkpatch I receive a million errors
<lag> I thought you may have heard of it before and have a solution?
<apw> its nearly 15 years since i gave up on emacs for wrecking my wrists, sorry :)
<lag> :(
<apw> it must think you want spaces though
<lag> Okay, thanks anyway
<apw> you could try unexpand to clean up on it
<lag> It only happens for function parameters 
<apw> oh that may be deliberate
<apw> thats a gnu ism
<apw> to use '    ' to fix auto indent on those
<lag> Why put 1500 spaces?
<lag> Use what?
<apw> so that if you display tabs as 2 characters they line up or something
<lag> What's '   '?
<apw> those are spaces :)
<lag> Checkpatch winges about spaces
<apw> there are setting on c-mode to control that sort of thing iirc
<apw> yes as it should, gnu c formatting is not right for the kernel
<apw> they have different and equally bizarre rules as the kernel
<apw> there is a guide on how to configure emacs for the kernel somewhere
<lag> Even git doesn't play nicely with emacs
<lag> +static ssize_t ux500_get_family(struct device *dev,
<lag> +                                                               struct device_attribute *attr,
<lag> +                                                               char *buf)
<apw> lag see the very very large bit of lisp in Documentation/CodingStyle
<apw> lag, that is just poor presentation of epicly long lines
<lag> You'll have to expand XChat if you want to see what I'm talking about
<apw> see chapter 9 'You've made a mess of it'
<lag> That could work
<lag> apw: Didn't work
<lag> apw: How annoying!
<lag> apw: This isn't something I've noticed before?
<apw> lag, hrm you are hosed :)
<apw> must be a change in emacs
<donri> Is recompilation the only option to get a more recent kernel?
<donri> Maverick
<apw> donri, more recent than what?
<donri> apw: than the 'linux' package in main
<apw> for maverick no there is nothing offered officially
<donri> ppa?
<apw> donri, not that i can recall no
<donri> okay thanks
<kirkland> JFo: hey
<kirkland> JFo: I just wanted to make sure that https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 is on your radar
 * JFo looks
<JFo> kirkland, I don't usually look at qemu-kvm bugs. Does it need a kernel patch?
 * JFo reads some more
<JFo> ah yeah
<JFo> I see serge's comments
<donri> how about something like http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc2-maverick/ ?
 * JFo adds a kernel task
<kirkland> hallyn: am i correct in reading that https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 is kernel-only, ie, no bug in qemu-kvm userspace, right?
<kirkland> JFo: i just marked it high/triaged/B2 against linux
<kirkland> JFo: feel free to adjust according to your standards ;-)
<JFo> kirkland, you beat me to it :-)
<JFo> will do
<kirkland> JFo: ;-)
<kirkland> hallyn: i think the qemu-kvm task to that bug should be marked invalid
<JFo> I've tagged it so it will show up in our hot list
<kirkland> JFo: you da man
<JFo> ogasawara, https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 which you are probably already looking at. :-)
<JFo> kirkland, no, that is you. I am the man standing next to da man :)
<hallyn> kirkland: yes, i believe so
<kirkland> hallyn: cool, i updated accordingly already
<hallyn> kirkland: thx
<kirkland> jjohansen: any progress on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/610597 ?
<jjohansen> kirkland: no, I was poking at it and reproduced, and then it kind of fell by the wayside to a couple critical bugs
<jjohansen> kirkland: aufs suffers from the same basic thing though
<kirkland> jjohansen: okay, i just noticed it was milestoned against b2
<kirkland> jjohansen: right
<kirkland> jjohansen: it's not critical to me, i was just wondering if it was really a b2 bug
<jjohansen> well, hrmm I guess not
<jjohansen> that is its not going to get done for beta2
<jjohansen> kirkland: also the best solution I have come up with is entirely userspace
<kirkland> jjohansen: oh?
<kirkland> jjohansen: something i can put in ecryptffs-utils?
<kirkland> jjohansen: what is it?
<jjohansen> kirkland: its walking the mounts late in resume
<kirkland> ah
<kirkland> jjohansen: so mountall?
<jjohansen> yeah possibly, I hadn't decided on where exactly, but that is a candidate
<kirkland> jjohansen: okay, well, i've moved the milestone on the linux part of that bug to ubuntu-later, rather than natty-b2
<kirkland> jjohansen: feel free to update if you change your mind ;-)
<kirkland> jjohansen: or perhaps adding a task for mountall
<jjohansen> kirkland: oh, thanks.  I just might I want to poke at it a little more before adding the mountall task
<jjohansen> kirkland: of course I can see some kernel dev that could be done for it, might be fun to start sending out udev events, that propogate up a mount chain :)
<kirkland> jjohansen: k
<JFo> <-lunch
 * apw calls it a day ... this is toooo much like work
<kirkland> JFo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751689
<kirkland> JFo: me, jdstrand, and slangasek  have all hit this bug in the last few days
<jdstrand> last few days? I've hit it all cycle
<jdstrand> it affects the maverick kernel too (it's in the bug)
<kirkland> jdstrand: yeah, i've been hitting it in Maverick randomly for a while now
<kirkland> jdstrand: but i've hit it 2 days in a row (for the first time) on Natty
<jdstrand> kirkland: you just need to hit all 8 cpu/threads for a while
<jjohansen> hey vendors need to stop shoving 45W parts in little machines
<jjohansen> s/hey/heh/
<JFo> kirkland, ok thanks
<kristian-aalborg> jjohansen: ping - private?
<jjohansen> kristian-aalborg: can you wait 30 min?
<kristian-aalborg> sure
<kristian-aalborg> I didn't mean to stress you :)
<slangasek> kirkland: hum, I never hit this bug before upgrading to natty, and I was running my system at full-throttle at various points during UDS
<slangasek> now I've hit it 4-5 times in the past two weeks
<stgraber> kirkland: +1 on x201s ;) Had the issue twice today working with kvm ...
<hallyn> slangasek: which bug?
<hallyn> oh, you all are having the kvm memory bogosity?
<hallyn> all on x201s?
<slangasek> hallyn: no, kernel failing to throttle the CPU when it hits the thermal threshold
<slangasek> and the machine shutting down when it hits the critical point
<slangasek> either it's a kernel bug or I've worn out my fan in the past 6 months :)
<stgraber> laptop going from 60C to 100C in 5 minutes, then triggering emergency shutdown ...
<hallyn> doh
<stgraber> I have a "watch -n1 cat /proc/acpi/ibm/thermal" running on my external monitor, as soon as I see it reach 98C I usually start killing kvms :)
<slangasek> hah
<stgraber> gets down to 60-70C really fast after that :)
<jjohansen> sadly the better we make use of the cpu, the more likely this is to happen
<jjohansen> not saying there isn't a bug here,
 * jjohansen -> lunch
<kirkland> stgraber: interesting, i hadn't tied the heat to my use of lots of kvm's yet;  thanks for the pointer
<stgraber> kirkland: today with AC/heating fighting at the office (new building ...) just starting an ubuntu desktop install would get my laptop to 100C
<kirkland> stgraber: wowsers
<lrf0808_> Hello!
#ubuntu-kernel 2011-04-12
<hallyn> feh.  btrfs just went readonly for no good reason
<RAOF> It's trying to save you :)
<hallyn> no doubt
<hallyn> i guess that rsync from a debootstrapped image into a subvolume was just a bit too fast
<RAOF> Hm.  Now that we run fsck.btrfs, booting takes a *loooong* time.  In an hour or so that system might be ready!
<Jerub> g'day. this bug is marked as closed/fix-released: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748
<Jerub> but i can replicate it on the same hardware as the original bug reporter's hardware with the very latest natty debs
<Jerub> it looks like from the notes made by 'Tim Gardner' that he was told by an intel engineer that it should be fixed, but no report of anyone saying that any changes effected a change.
<jjohansen> Jerub: hrmm update the but with your information
<Jerub> i did. i'm the last two comments on the ticket. but it's still marked as 'fix-released', instead of 'confirmed'
<Jerub> i guess what i've said isn't very clear, i could spam the ticket more if you want.
<jjohansen> Jerub: it would be good, to be explicit has to which kernel (version # not latest), and what exactly you are seeing.
<jjohansen> Maybe even doing an apport-collect 630748
<jjohansen> to add your information
<Jerub> okay, doing that now
<Jerub> i can't do apport-collect because the bug is closed.
<Jerub> i've added specific version numbers and my uname -a to the ticket, and noted that i cannot run apport-collect due to the bug being marked as closed.
<magcius> I have two support questions: one about FS not working, one about network not working. If there's a better place, please tell me :D
<magcius> 1. Sometimes the FS causes a complete failure where "sync" refuses to work.
<magcius> If I run "sync", and then do a cat /proc/$(pidof sync)/stack
<magcius> I get "call_rwsem_down_read_failed" at the top of the stack. There is a fixed kernel bug about this, but it's still happening.
<magcius> I have a somewhat borked external, and it's happened across two different hardware computers, so I'm not sure what's happening.
<magcius> 2. e1000e fails to work if I don't do proper shutdown when I reboot
<apw> magcius, what filesystem format is the drive wh
<apw> with the issue
<apw> and with which kernel for that matter
<smb> The main problem with those kind of question is the lack of information. What fs, what drive, what release...
<magcius> NTFS
<magcius> I believe
<magcius> I have no idea, the stack trace doesn't give me much info.
<magcius> I have about 4 or 5 filesystems on this thing
<magcius> I'm running Ubuntu 11.04 right now, but I've had this problem for a while.
<apw> can you get a picture of the problem?
<magcius> "picture"?
<magcius> And I'm trying to dig up the exact error message from e1000e, but not having much success since my dmesg log has been scraped
<smb> I guess it is an external usb drive, but thats only guessing
<magcius> It was something like "probe failed with error code 5"
<magcius> smb, indeed.
<magcius> The NTFS drive, at least.
<magcius> I have no idea *if* it's that filesystem that's failing.
<smb> The stack only says that sync wanted a semaphore which is already taken
<magcius> Right.
<smb> This can be a communication problem with the external usb case
<magcius> OK.
<smb> So something tries to write and does not complete
<magcius> Right.
<smb> then the next access just locks up waiting
<ohsix> i've had fuse do some funny things like that :D
<magcius> could be fuse or ecryptfs
<smb> givien that it is ntfs there is likely fuse involved here too
<smb> Probably one thing to look for is usb reset messages in dmesg
<magcius> When it happens the next time, is there anything I can or should do to check for the filesystem?
<magcius> what should I grep for?
<smb> Not sure about the exact message but something about reset of usb device bla
<smb> then there could be the automatic softlockup message. maybe it triggers for the other process too. Though with writes going into the background those usually doent show
<magcius> just check /var/log/dmesg the next time it happens?
<smb> magcius, Its dmesg (as a command) 
<magcius> Is there a difference? :P
<smb> That does not depend on the filesystem working. /var/log is the written output. dmesg directly reads the buffer
<magcius> aha
<apw> smb, any feel for where in his cycle gregkh is?  for stable-38?
<smb> apw, The was a larger dump between yesterday and today. He might be preparing to fire the next review/release
<apw> good
<fairuz> Hi, if I want to build packages, can I cross compile?
<apw> most packages in debian/ubuntu are not really cross compile capable
<apw> the kernel is partially cross-compilable
<fairuz> apw: So the manual way is to cross compile the kernel, cross compile modules, and do modules_install on target machine? 
<apw> no, i was trying to say that some of the build doesn't work, iirc the tools package doesn't build well in a cross compile environment
<apw> we use cross-compilation for build verification and architecture boot strappng so we haven't cared to fix these remaining issues
<magcius> debian multiarch?
<apw> ?
<magcius> isn't that the cross-compilation work?
<apw> nope, multiarch is cross arch installation
<magcius> huh, I thought they were at least planning to do cross-compilation
<apw> multiarch is all about installation, as far as i know, it would be a handy tool as a basis for cross compilation but i don't beleive that is its function
<bullgard4> Is the Natty kernel thread aio generated thorough the source code file /usr/src/linux-source-2.6.38/fs/aio.c?
<bullgard4> -o
<ohsix> bullgard4: look for something that creates the kthread, like create_singlethread_workqueue
<bullgard4> '~$ locate create_singlethread_workqueue' does not produce any output.
<tayyabali1> how to learn kernel compilation any resources ?
<apw> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<JFo> tayyabali1, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> jinx
<JFo> :P
<apw> JFo, not on mumble ?
<JFo> not yet, charging my headset
<JFo> realized a bit ago that it was dead
<JFo> should be ready soon, it has been on a while
<hallyn> apw: fwiw on the kvm soft interrupt bug just got a more affirmative reply from avi, so he might be sending a patch soon.  
<hallyn> (bug 747090 that is)
<apw> hallyn, ok keep me in the loop, on the patch, sounds like its a nasty one ... any idea what the trigger for 'sometimes' is
<JFo> where in the heck is ubotu?
<hallyn> apw: i think the trigger is just when you notice :)
<apw> needs inviting in again i suspect
<hallyn> apw: it must always happen on softint
<apw> ahh that kind of sometimes
<hallyn> right.  for the most part 'who cares' if you do the interrupt twice :)
<apw> i thought you could just invite ubottu, but it seems not
<JFo> hmmm
<smb> I sort of had hoped that this one was "employed" by #is and would not leave with somebody leaving
<JFo> it looks to still be in other channels
 * JFo goes to investigate
<smb> hallyn, Hm, is that the two backport patches or something different? I was wondering about the other things just today
<hallyn> smb: ?
<hallyn> smb: you mean the kvm bug?
<apw> hallyn, is that conversation on the original thread or elsewhere>
<hallyn> apw: in the kvm mailing list
<smb> hallyn, I think I was messing things up in my memory. Yes, some kvm bug with clock going backwards, I just sent a nag mail round
<hallyn> smb: <shrug>  i don't know enough about softints to know if it could cause that.  but it sure should cause some funky stuff
<apw> hallyn, whats the subject on the contination ... the archives of the kvm list only show your original and one replay
<apw> reply
<hallyn> smb: so every 'INT 0xYY' will be called twice
<apw> hallyn, now how is it that its twice and not thrice?
<apw> or 10000 times
<hallyn> apw: Subject: Re: buggy emulate_int_real
<smb> hallyn, Oh its surely not the only kvm bug. Just got reminded of the other one
<hallyn> apw: because I assume after the first time, regular instruction stepping happens.
<hallyn> apw: i did wonder that myself, and am not sure
<hallyn> all right, since there's no patch from him yet, i'll start one now
<apw> ahh its there on gmane not other archives, odd
<apw> yeah it seems its something like if it page faults taking the int, it then runs the int again
 * ogasawara back in 20
<apw> JFo, looking at the key bugs list we have a large number in New and Undecided status, arn't those supposed to get fixed by the scripts
 * apw grins at ogasawara 
<JFo> apw, what do you mean?
<JFo> oh the arsenal scripts
<apw> yeah
<apw> at least the New bit?
<JFo> I stopped running the 'new' one because it is improperly tagging some bugs as found by myself and bjf
<apw> and i thought we were concentrating on ensureing there was no Unspecified priorities on that list
<JFo> he has a new one that he is testing
<JFo> that does the basics and gets them to confirmed
<apw> ok cool.  the priorities we should be fixing
<JFo> yes, indeed
<apw> else how can we tell which to care about
<JFo> I just haven't gotten to those yet.
<JFo> they are next on my list
<apw> JFo, chat time ?
<JFo> sure, whenever you like
<moustafa> Hi, sorry to pop in, but I was wondering if it would be possible to backport the intel i915 video modules to Lucid?  I'm sure a number of users would enjoy the improvements to the driver code on their LTS machines
<apw> moustafa, we do offer lts backports kernels on lucid, offering the maverick, and soon the natty kernel for lucid
<apw> though they are only officailly supported for servers, they are complete
<moustafa> apw: So, enabling the backports should technically allow a user to update to a more recent version of the kernel as well as the available open source drivers?
<apw> moustafa, they are separate from the -backports, they are elective installs via a separate meta package
<apw> linux-image-generic-lts-backport-maverick ... -natty (once natty releases)
<moustafa> apw: Since I haven't tried this myself, is there any place I can read more about doing that?
<apw> now that is a good question, i am unaware of any speciic documentation other than the announcement
<apw> JFo, can you remember if there is any specific docs on the LTS backports kernels?
<JFo> not that I am aware of apw
<JFo> and I can't find anything in the brief search I did
<moustafa> apw , JFo so how would it work exactly?  just type in linux-image-generic-lts-backport-(name of release)?  Or am I missing something?
<moustafa> I remember reading an annoucement, but didn't get the details of how far along it was
<JFo> I recall the announcement, but I thought we documented the method
<JFo> I'm just not finding it
<apw> moustafa, apt-get install linux-image-<flavour>-lts-backports-<release>
<JFo> found the blueprint, but still no docs
<apw> where flavour is the one your machine normally uses, and release is the release for the kernel
<moustafa> apw JFo : Perfect, thanks 
<JFo> apw, was this always the description for this blueprint? https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
<JFo> oh wait
<JFo> no, that is a feedback request or something
<apw> the description is right yes, just hidden
<JFo> yeah, I just realized :)
<JFo> sorry about that
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<apw> bjf, yo ... i hear you have a new New bug frootle script for the arsenal ?
<bjf> apw, for generating regression reports
<apw> bjf not for handling the triage phase ?
<bjf> apw, oh, right now it is just looking at bugs that have the required logs and bumping them from "New" to "Confirmed"
<bjf> apw, it's not running via cron yet, but will be soon
<apw> bjf, ahh ok, so that is the one i mean
<apw> if they don't have the required logs will it ask?
<bjf> apw, right now no, i'm taking it one step at a time, but that would be the next step
<apw> bjf, ok cool, as long as its coming, as our bugs are getting in a mess :)
<bjf> apw, tell me about it
<apw> bjf, i would say, if it has the required logs, then it hsould be going Triaged shouldn't it ?
<apw> confirmed means more than one person has seen it, triaged means it has the needed data
<bjf> apw, according to "our rules" we need to ask for "upstream testing" first, 
<apw> oh i see ... hmm
<bjf> apw, you need to look at our bug triage status wiki page
<apw> (i try not too :))
<bjf> apw, not sure i agree with what is says, just following it for now
<bjf> apw, this is the page i'm referring to : https://wiki.ubuntu.com/Kernel/BugTriage/BugStates
<apw> bjf, something odd is happening with apport ... which you might need to be watching out for ... like bug #758400
<apw> has needs-upstream-testing as a tag on it, but ... its never been requested in the bug
<apw> and i think apport may have done it
<apw> (and it may be an error in fact for it to have done so)
<bjf> apw, http://people.canonical.com/~kernel/reports/24.html
<smb> apw, FYI Review for 2.6.38.3 was more or less just sent out, ending on Thursday
<apw> smb, cool. that'd be good timing
<bjf> apw, yes, those are apport, been doing it all along, you just haven't noticed
<bjf> apw, we talked sunday about gutting our part of apport
<apw> bjf, i think the now broken scripts also used that tag too, but either way i think that we should be reinforcing it via a direct comment in the bug
<apw> as it would only have been in a dialog box and without any hint as to how to actually do it
<bjf> apw, i'm pretty sure the scripts, when they add it, add a comment, apport does not
<apw> right ... and i think it is really a mistake to have it in both places ... my opinion of course
<bjf> apw, right, it needs to come out of apport and we need to be smarter about it in the scripts
<apw> bjf, so where are you accumulating the new smaller leaner scripts ?
<bjf> apw, me thinks we need someone on the team to "own" our part of apport
 * apw looks at you significantly
<bjf> apw, wanted to talk to you about that, we said something about a structure under kteam-tools but I couldn't remember what we agreed on
<apw> bjf, i think we were at that vague level yes
<bjf> apw, i have it in a local kteam-tools under "bugs" directory
<apw> bjf, i have one here which shortly will handle the 'New' and 'Incomplete (with response)' onces and puts them back into the right state
<apw> bjf, that or arsenal seem logical to me
<bjf> apw, have you looked at http://people.canonical.com/~kernel/reports/ ?
<apw> nope, they are all new since i was off i think
<bjf> yes
<bjf> they are running automatically via "cron" from the "kernel" user on people
<apw> do i have access there?  and are we going to run the arsenal there too ?
<bjf> apw, you do have access (everyone on the team should)
<apw> cool
<bjf> apw, we can run there or on cranberry, the reports run there because they are public and people can talk to LP via the api
<bjf> apw, my pref would be to do it all in one place
<apw> seems an appropriate place to run everything then (to me)
<apw> snap
 * apw notes that this green against grey/black is not good to look at, its hard for me to see the text and the background on the same plane, the letters float oddly
<apw> why are all our pages not the normal -verse
<bjf> apw, you are the first to complain, others have like it and it works for the author
 * apw will have to persuade you to generate both -verses so i can view the other one :)
 * JFo reads back
 * smb wonders whether we got our meeting warning already
<smb> Otherwise it might be over before we realize it started
<JFo> looks like bjf got dropped
<smb> Usual conference quality
<JFo> :)
<jjohansen> heh well the sever team looks to be using our meeting time any ways :)
<smb> jjohansen, ? Isn't ours not due in an hour?
<jjohansen> smb: oh cripes so it is, /me is so confused by daylight savings time still
<smb> jjohansen, Wow I thought we now all changed for two weeks now. :-P I was somewhat surprised there had been a relative smooth transition
<jjohansen> smb: well that doesn't mean /me is used to it.  /me still expects meets at 9am local and now they are at 10am.  By the time I get used to it, it will switch back
<apw> jjohansen, it does change only twice a year
<jjohansen> apw: yeah I know, only 6 months to adjust :)
<apw> bjf, how does one tell that a bug has had upstream testing ?
<apw> (programatically)
<bjf> apw, that's a really good question
<apw> i suspect we cannot tell at the moment, as we ask them to remove needs-upstream-testing
<bjf> apw, i don't have a good answer and am wondering if we can really blanket spam bugs
<apw> hmmm, as i am already looking at the activity log to work out the 'previous state' i might be able to work out if it was on there and removed
<apw> and use that as indicator
<bjf> apw, but if they don't remove the tag but have done the testing what do you do ?
<apw> bjf, how are you detecting 'has apport data'
<apw> bjf well in that case the automation should assume they have done it, and it'll end up in a state saying we should look
<bjf> apw, i'm looking to see if the original bug submitter has attached, specific logs
<apw> and if we find it missing we ask again and re-add the tag
<bjf> apw, bot comes along, changes status to "Incomplete", adds "needs-upstream-testing" tag and adds comment asking for upstream testing
<bjf> apw, user does upstream attachment, adds comment, may not change from "Incomplete" to "Triaged/Confirmed" and may not remove "needs-upstream-testing" tag
<bjf> apw, s/upstream attachment/upstream testing/
<bjf> apw, is the bot going to look at all "Incomplete" status bugs to see if testing was done? how does it know ?
<bjf> apw, if the status has been changed but the tag still exists, how do you know if the testing was done ?
<apw> well look at this way round ...
<apw> i am looking at things which were imcomplete and want to change, ie incomplete (with response)
<apw> i would think it should occur as part of that processing
<apw> as from there it should go to 'new' (with no data), 'confimed (with apport data), or triaged with apport and with testing done
<apw> so the trigger to care is incomplete (with response) or 'new'
<apw> as those are the only places it can go to if they say something
<apw> bjf mumble ?
<bjf> at ELC
<apw> oh yeah, no chance
<apw> as you say we cannot rely on moving or not moving to New
<apw> but we can handle that i think
<bjf> i think your approach is the right one, i'm just wondering how a bot is going to look at the last comment and decide that the testing was done
<apw> and i thiknk if they test but don't remove the tag (which we explicitly ask them to do) then we lose them, and they get expired
<apw> i think we only look at the absence of the tag
<apw> ie, was it added and then removed
<apw> ie. was it on there, and is not now
<apw> that says they removed it
<apw> if the history says it was tagged, and bug.tag('needs....') == false
<bjf> i was thinking the same, but concerned that relying on users to remove tags is problematic
<apw> it is not clear how we can do it using text
<apw> as there is no common way to say it
<apw> the text the script inserts says how to remove the tag etc, JFo can confirm i think
<bjf> bottom line, do it the way you are thinking (which i agree with) but we need to keep an eye on it to see if it's "working"
<apw> click the pencil, remove the text 'needs....'
<apw> yep, so i think if they have either apport data, or have removed the tag (ie done upstream testing) but not both we go to Confirmed, if both then to Triaged
<apw> and keep an eye on things lingering in Confiirme
<bjf> agreed
<apw> do you have a function to determine if we have apport data I can steal ?
 * apw notes we need a library of useful snippets to share shortly
<bjf> yes
<bjf> will push soon
<bjf> working on pushing, right now
<apw> bjf, i suspect that this processing i am doing right now is so allied with the 'ask for data' and 'ask for upstream testing' we are going to end up merging them
<apw> but ... anyhow :)
<apw> we can likely work out how long we have been waiting for needs-xxx to be removed, and add comments to hastle people
 * JFo curses xchat
<bullgard4> What does "MRU" stand for in  /usr/scr/linux-source-2.6.38/fs/xfs/xfs_mru_cache.c?
<bjf> apw, pushed, look at bugs/proc-new-regressions   and ktl/bugs.py
<apw> bullgard4, (guesses at) most-recently-used ?
<bullgard4> apw: hm
<JFo> I think for the test to see if they actually did test upstream, it may come to a point where we have a script compile for me a list of bugs to look at. I am not above that.
<JFo> in fact, it will make what I need to be doing a ton easier
<apw>  * inserted at the head of the current most-recently-used list.
<JFo> still thinking about the 'keeping an eye on confirmed
<apw> bullgard4, looks like that is what it is
<JFo> '
<JFo> I have an opinion, but it isn't making a lot of sense right now. :)
<sforshee> has anyone noticed this thread about bluetooth borkage: https://lkml.org/lkml/2011/3/19/80
<sforshee> someone sent a backport to the stable list today, maybe we want to get it into natty
<sforshee> unfortunately I have nothing to test with
<apw> sforshee, is that the version of bluetooth we use?  there are two and i can never remember which is which
<apw> manjo normally knows
<bullgard4> apw: It seems your guess is correct: http://en.wikipedia.org/wiki/Cache_algorithms
<sforshee> apw, had no idea there were two versions, and also no idea which one we use
<apw> sforshee, seems we do use bluez
<sforshee> apw, that's the conclusion I was coming to as well
<sforshee> I see one bug that might be related
<sforshee> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/700292
<apw> sforshee, thanks, adding a linux task in case
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
 * JFo stretches
<ppisati> o/
 * apw thinks ppisati missed
<smb> apw, me too
<ppisati> uat?
<ppisati> ops, wrong channel :)
<JFo> <- lunch
 * apw goes find some dinner ...
<GrueMaster> JFo: What more data would you like on bug 758961?  The oops text is there and the kernel devs that actually have these platforms can easily reproduce this.
<JFo> well, the norm is to gather all of the apport-collect data, that way there is (usually) no need to ask for anything further.
 * jjohansen -> lunch
<skaet> JFo, ogasawara - could you have a look at https://launchpad.net/bugs/759115?
<skaet> its hitting in Ubuntu Alternate and Edubuntu images.
<ogasawara> skaet: hrm, and I assume this wasn't the case for Beta 1
<JFo> ugh, LP taking forever for me :)
<skaet> ogasawara, discussion going on in u-release, looks like security update early this month.
<lifeless> JFo: doing what ?
<JFo> lifeless, it is a connection issue for me, not LP's fault
<JFo> :)
<lifeless> JFo: well, that could because of our ISP or whatever choosing poor routes
<JFo> I'm pulling an ISO at the same time, so my connection is slow
<ogasawara> skaet: Author: Kees Cook <kees@ubuntu.com>
<ogasawara> Date:   Wed Mar 23 13:17:13 2011 -0700
<ogasawara>     UBUNTU: [Config] packaging: adjust perms on vmlinuz as well
<ogasawara>     
<ogasawara>     Since kernel symbols are resolvable internally to the kernel, the kernel
<ogasawara>     itself has a map of the symbols. Continuing the tradition of frustrating
<ogasawara>     off-the-shelf kernel exploits, make vmlinuz unreadable for non-root, just
<ogasawara>     like has been done for System.map, etc.
<ogasawara>     
<ogasawara>     Signed-off-by: Kees Cook <kees.cook@canonical.com>
<ogasawara>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
<kees> I thought alternate was already fixed?
<kees> stgraber is working on edubuntu, iiuc
<skaet> ogasawara, yup.  LTSP impacted in alternate and edubuntu.
<kees> skaet: stgraber is working on it (was just talking to him about it in #ubuntu-hardened)
<skaet> kees,  yup,  he started the discussion off in ubuntu-release, and the question of "why" came up.
<kees> skaet: for "frustrating off-the-shelf kernel exploits"
<stgraber> kees, skaet: The easiest, most maintenable and fastest way for me to fix it is to release a new LTSP upstream. I can have one released with a fix in 5 minutes or so. Other upstream diff is bugfix only and minimal.
<skaet> kees:  lol,  indeed.
<kees> skaet: less tersely, it is to stop non-root users from being able to trivially resolve kernel symbols when performing local kernel exploit attacks.
<kees> skaet: it doesn't stop a dedicated attacker, but it does stop script-kiddies, which has real-world benefits.
<skaet> stgraber,  ok,  let pitti know its coming and why. 
 * skaet crosses fingers bug fixes only means bug fixes and no regressions.
<skaet> thanks kees
<kees> skaet: np, sorry for the trouble!
<ogra_> lets just tell the script kiddies to grow up :)
<JFo> I wish
<gondoi> I seem to be missing my quota modules in -virtual
<gondoi> is this expected?
<gondoi> btw, I'm running maverick
#ubuntu-kernel 2011-04-13
<GrueMaster> JFo: Re apport-collect and bug 758961.  A) Bug was autofiled by apport (triggered by two oops occurances) B) I can find no correlating oops messages in /var/log/*.  Image is fresh from today with only 4 reboots total.
<GrueMaster> I am trying to reproduce it, but have not seen an oops since 10:41 (it is now 16:41).
<jjohansen> rebooting
 * apw waves to smb
 * smb looks sw
<smb> apw, Morning
 * apw puts up a flare
<apw> smb, morning ...
<smb> apw, too late, latitude already did. :)
<apw> heheh
<apw> gondoi, quota modules may not be included in -virtual, i suspect it would be an oversight if so... what specific module names are you missing
<Mamarok> hi
<Mamarok> I have problems installing he 38-8 kernel on my system, see also bug 759531
<Mamarok> the output of the update is in the report as well
<Mamarok> after that I started with the previous -7 kernel: the update doesn't hang anymore but I get the following error: http://paste.ubuntu.com/593527
<ppisati> what does it happen if i manually modify one of the debian/configs/...? i don't like editconfigs
<smb> ppisati, There is a special place in heck for people like you
<smb> ppisati, Make sure to run updateconfigs after any manual change and see how the effects are.
<Mamarok> smb: may I ask you to have a look at my question above?
<smb> Mamarok, Hm might be the dkms compilation of the nvidia driver failed for some reason  but its hard to say for sure
<Mamarok> the funny thing is that I don't even have a Nvidia card
<smb> I would probably try to run apt-get install -f
<Mamarok> that doesn't help
<smb> What is done at line 1010 of /var/lib/dpkg/info/linux-image-2.6.38-8-generic.postinst (which seems to be the failing point)
<Mamarok> the output stays the same
<Mamarok> there are not even that many lines, I guess it means line 110
<Mamarok> as it prints later
<smb> One seems to be for the headers and the other for the kernel package
<Mamarok> yes, the line is the same, run-parts
<Mamarok> sorry,   system ("run-parts --verbose --exit-on-error --arg=$version " 
<smb> right so that seems to call /etc/kernel/postinst.d/nvidia-common
<Mamarok> as I said, I don't have a Nvidia card, but it insists on installing it by default
<smb> Yes I believe the wrapper is always there
<smb> Though it should just do nothing when the binary driver is not there...
<smb> Does the file itself look executable/reasonable (not corrupted)?
<Mamarok> yes, I can edit and search in it without problems
<smb> I am looking at an older version right now but that would try to read in /usr/share/debconf/confmodule
<Mamarok> I will try removing nvidia related packages I can, just a moment
<Mamarok> hey, that solved it! I removed nvidia-common and now it works
<Mamarok> I will add a comment in the bug
<Mamarok> thanks for the hint
<smb> Mamarok, As I said, it should aslo work with it
<smb> I got it installed here too and no nvidia card either
<Mamarok> indeed, but since I don't have a card it doesn't hurt me
<Mamarok> the problem will be for those using a Nvidia card if they run into that problem
<smb> Do you have that /usr/share/debconf/confmodule?
<Mamarok> yes
<smb> Hm, ok. I would suspect a bit that something goes wrong with fiddling around with the debconf and that may strike again even without the nvidia stuff
<Mamarok> I ha to kill the process a few times then I needed to unlock /var/cache/debconf/config.dat, but I didn't really modify something else
<Mamarok> had* to
<smb> That would somewhat sound even more like your problem does not only exist for the kernel package but might run into other trouble sooner or later
<Mamarok> I checked again: apparently there were some old nvidia-xx-modaliases packages that I removed, that might be the origin of the problem
<Mamarok> since those are not in the Natty repos anymore
<smb> Hmm odd.
<Mamarok> anyway, I updated the bug report with this information and changed its status to "opinion"
<Mamarok> thanks a lot for the hints :)
<smb> Those alias packages should only contains some hints for jockey. There is multiple of those on my system too
<smb> Mamarok, Welcome. Just don't expect too much feedback for "opinion" bugs. ;) 
<Mamarok> I know, but at least something is lying around if other people run into the same problem
<Mamarok> for now the report is out of the way, it can still be reactivated if needed
<smb> Right, if I had more time I would probably try to run through the upgrade path from Maverick to see that works...
<Mamarok> me too, but the same applies here, I don't really have time for that
<apw> mjg59, you heard any complaints of thinkpads overheating on 2.6.38 kernels?
<apw> mjg59, thinkpad x201* seems to be implicated
<mjg59> Heard, yes.
<mjg59> Haven't been able to track down yet.
<mjg59> There's basically nothing that's changed in the thinkpad driver
<mjg59> So I'm a bit stumped
<mjg59> I think someone's really going to have to do a bisection
<mjg59> The main reason I'm confused is that they don't have ACPI fans, so it's entirely under firmware control...
<apw> mjg59, i'll ask for some mainline kernel testing then between 2.6.35 and 2.6.38 and see what that gets us
<apw> mjg59, the last time we had anything like this it was a change of width of a read in acpi was confusing the ec, so it could be anything
<mjg59> Yeah, it's more likely to be an ec change than anything else
<apw> mjg59, ok in the reporters court now, thanks for the info
<root___> Hi, sorry if this is the wrong place but I know that my USB Audio DAC works with ubuntu I was wondering if you could help me set it up in my distro? The receiver is a texas instruments PCM2706 here is the output of lsusb - http://paste.pocoo.org/show/370983/ thanks if you can help at all I don't know where to start
<hallyn> apw: hi, on bug 747090, you say you incorporated a comment from jan - but I don't see such a comment!
<apw> he simply suggested merging the xxx += inc_eip into the line above
<apw> that was jan wasn't it, or have i miss attributed
<hallyn> that's what i assumed based on your patch - i just don't see that msg in my inbox
<hallyn> was that in the kvm mailing list?
<hallyn> oh, you know - maybe he didnt' cc: me.  I'm not actually on the list
<hallyn> lemme go fix that
<apw> hallyn, ahh ok ... cool
<apw> hallyn, it was nothing more than a nit, the binary produced should be identicle
<hallyn> apw: yeah the patch in your dir looked fine.  I haven't been able to test the kernel itself yet
<hallyn> apw: say, would you mind sending your version of the patch to the kvm m-l then?  :)
<apw> hallyn, no worries, how severe is the symptoms of the issue, ie. are we hoping to get it into the release kernel or can it wait for the first sru kerenel
<hallyn> apw: oh, no.  there it is.  I simply missed his comment in the noise.  I don't do well with un-snipped emails some days
<hallyn> i was hoping for release kernel.  let's ask cjwatson what exactly made him track this down
<apw> hallyn i think you're better doing it, so you get the credit
<hallyn> apw: it seems like ppl  are running kvm just fine, on the one hand...
<apw> ok, i hope we can slip one more kernel in, but we are going to have to hoop jump to get it in
<apw> and if we do i'll make sure this one is in if we do
<hallyn> sounds good, thanks
<apw> hallyn, let me know when you have tested, and i'll get that patch out for acks
<apw> JFo, about ?
<ppisati> apw: in 5bfc8061, any reason why you choose CONFIG_USB_MUSB_TUSB6010 over any other option?
<apw> ppisati, erm
<ppisati> apw: easy :)
<ppisati> apw: even a "the name was cool" is ok
<apw> ppisati, is that a select ?
<ppisati> yep
<ppisati> apw: and we lost musb on omap
<ppisati> that's why i was asking
<ppisati> anywa, i'll modify it locallu
<ppisati> locally
<ppisati> omap.config
<apw> ppisati, looks to be the default for that new choise on omap, ie the first vslid one
<ppisati> ok
<apw> so essentislly arbitrary
<ppisati> ok ok, no prob
<apw> hallyn, ok i've taken you testing as good, and pushed the kvm patch to kernel-team@ for review
<hallyn> apw: great, thanks
<gondoi> apw: according to /boot/config-2.6.35-28-virtual: CONFIG_QFMT_V1=m
<gondoi> CONFIG_QFMT_V2=m
<apw> gondoi, yes but only select modules are actually packaged for the virtual flavour to keep it nice and small
<gondoi> apw: but the files are not there: ls -l /lib64/modules/2.6.35-28-virtual/kernel/fs/quota/
<gondoi> total 0
 * apw waves to cking 
<apw> gondoi, right that is entirly possible given how -virtual is packaged
<gondoi> hmm
<gondoi> so how can I do quotas on my vm?
<apw> gondoi, what are the module names which are missing, so i can check if they are meant to be included
<gondoi> or... where can I get the modules
 * cking waves to apw
<gondoi> apw: just a sec
<apw> cking, hiya, back yet?
<cking> apw, still in SFO, will be back on Saturday
<gondoi> quota_v2.ko and quota_v1.ko
<apw> gondoi, maverick ?
<gondoi> yes
<apw> gondoi, doesn't look like they are included, and likely they should be
<apw> gondoi, is there a bug filed?  if not please file one and let me know the number
<gondoi> i'll have a look and see what I can find
<gondoi> thanks apw
<apw> gondoi, if you haven't filed one already you may as well just file one
<gondoi> will do
<ppisati> cooloney: your patch on natty's make the board hags at boot
<ppisati> s/hags/hangs/
<vanhoof> sforshee: heya if you're interested: http://people.canonical.com/~vanhoof/lazy_itable_init_testing_plus_dirty/debug/
<vanhoof> sforshee: first directory is at start, last is either right before, or during the hang
<vanhoof> its hard to tell since forcing a sync w/ sysrq didnt appear to trigger any activity
 * vanhoof posts to bug
<sforshee> vanhoof, cool, I'll take a peek and see if I notice anything interesting
<vanhoof> sforshee: awesome lmk if you see anything interesting :)
<bjf> apw, tgardner, and i have noticed a dramatic drop off in LP bug email, have you seen the same ? i know there have been 37 new bugs in the last 24 hours but i've only received 5 emails
<bjf> JFo, ^ ?
<vanhoof> bjf: getting updates from my projects pretty quickly
<apw> bjf hmmm, not really noticed, but then i don't really read ones which arn't assigned to me
<jjohansen> bjf: well I can say I haven't gotten an email for every bug I have filed lately, so something seems off
<bjf> jjohansen, tim thinks there was a change that you don't get email about LP actions you've performed, but I'm not getting email about any new bugs against the linux source package
<jjohansen> bjf: odd because I am getting emails from some of the bugs I am filing just not all of them
<bjf> jjohansen, ok, then, -ENOCLUE
 * apw wanders to find some food ... laters
 * jjohansen -> lunch
<michaelh1> Hi there.  The latest Natty kernel keeps faulting on my Core 2 ThinkPad.  What should I do next?
<hallyn> what sort of faulting?  is it overheating?  (that's a popular one this week)
<michaelh1> hallyn: I've had a few times where it logs me out and powers off.  The others are where it switches to a black screen and dumps the backtrace on the different cores.
<michaelh1> hallyn: I'm suspicious that it's due to the rtl8192 driver.  I've switched from wired to wireless to see if the problem reduces.
<michaelh1> hallyn: (the last backtrace had rtl8192_rx_normal and skb_put in it)
<michaelh1> Is there a way of recovering the backtrace after a halt?
#ubuntu-kernel 2011-04-14
<jjohansen> michaelh1: can you hook up a serial console?  sometimes a net console will work (though unlikely in your case), there is also always falling back to a camera if you have something on screen.
<michaelh1> jjohansen: ah, a camera!  Good idea.  I've switched from wired ethernet to wireless and been working fine for two hours (fingers crossed)
<jjohansen> michaelh1: also setting /proc/sys/kernel/printk_delay can some times make it so have a chance to read /catch output before it scrolls off the screen
<michaelh1> jjohansen: ta.  I have a nice high-resolution screen so it holds quite a few lines.
<jjohansen> michaelh1: ah, its nice when you can fit the oops on the screen, I was looking at a bug recently where it just didn't fit so I used printk display and took multiple pictures
<bryceh_> JFo, bug #735126 has a kernel patch that looks ready to go (and already in linus' tree)
 * apw yawns
<jk-> hey apw 
<apw> jk-, heya hows you
<apw> morning all
<smb> bonjour
<apw> indeed, though getting up that early is never bon
<smb> Hm are you not now in my tz?
 * apw has been up for two and a half hours already
<smb> Heh, ok. Probably a disadvantage being countryside. Rising with the chickens... :)
<apw> the village bells don't help, clanging away at 7am
<smb> Yeah, though one gets used to stuff like that
<TeTeT> smb: I've talked to the customer on the xen guest problem with the high number of interrupts - they cannot really bring the system down and test as it is in production use
<smb> TeTeT, Well and that may be the problem actually...
<TeTeT> smb: the production use ? ;)
<smb> TeTeT, Of course. Won't you think that a high number of eth0 interrupts may be somehow related to the network traffic taking place on the machine? ;)
<TeTeT> smb: yeah, might be related - so you think it's just the usage and not a bug at all?
<smb> TeTeT, It could very well be. The disk io did not seem to be exceptionally slow (for a fully virtualized guest on a busy host) and my experiments locally did not show something obvious
<smb> Hence the question of trying to enable acpi to get slightly different interrupt routing and see whether that changes things
<smb> Or compare to a different guest. The problem I can see is the syn package flood
<smb> but that could be real traffic as well
<smb> TeTeT, Maybe one thing to try would be to gather some wireshark or tcpdum log from within the guest to see what happens there
<TeTeT> smb: hmm, what would it reveal beyond that network traffic is coming from and to the proxies?
<smb> Beyond what kind, how much and whether that traffic is expected? :)
<smb> The fact that the syn flood protection starts handing out cookies does not sound right. Though I am not sure I really have something to compare as it felt there was a lot of outbound traffic on that host
<TeTeT> smb: it's their mirror of the archive and all updates are coming from that host, minus the proxies
<smb> TeTeT, Basically all I can say from having tried CentOS5.5+Xen 3.0.3 (which should be quite close to what they got) is that I just did a quick install of 10.04 and did not see many net interrupts. However I did only have a simple one level failover bonding in place.
<smb> Maybe it makes sense to check the switch configuration as well. I think one can twiddle something for bonding on that side as well.
<TeTeT> smb: ok
<JFo> bryceh_, got it
<ogasawara> tgardner: bug 731878, looks like upstream is reverting the patch as well
<tgardner> bug #731878
<tgardner> no bot this morning?
<JFo> been gone for a while
<JFo> not really sure why
<JFo> apw, or ogasawara whomever :) mind taking a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/737080?
<JFo> it is the same hardware as akgraner and it is having similar overheating
<JFo> this one owned by Stuart Langridge
<apw> be good to ask him to see if the .38 mainline kernel has the issue, and if so, test .37, etc till it goes away
<JFo> ok, will do
<JFo> actually, should have done.
<JFo> apw, there is a linus commit outlined by bryceh_ in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/735126
<JFo> do you think it is possible to get it in?
<tgardner> JFo, we love radeon patches.
<JFo> :)
<apw> JFo, will add it to my list for tommorrow ... looks pretty small
<JFo> thank you sir
<tgardner> JFo, this'll likely show up in stable pretty soon.
<JFo> I suspect so, I just wanted to ask in case it didn't in time
 * JFo is paranoid
 * JFo goes back to the hotlist
 * smb thinks sometimes he should wait longer before pushing the send button
<JFo> heh
<JFo> same here, but for me that should be every time
<JFo> not sure what to do with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759503?comments=all
<JFo> I think it needs csurbhi to look it over, but I can't find her
<tgardner> JFo, that kinda looks like a kernel bug. 
<smb> JFo, it seems to be a kernel bug triggered. Damn tgardner was faster
<JFo> heh
<hggdh> folks, pedro and I are going back to lucid SRU; I was doing the EC2, but I do not see an updated EC2 kernel
<JFo> <- lunch
<smb> hggdh, The last version I got in git is -315.28...
<smb> That seems still to miss that one fix afaics
<hggdh> smb: so you will be genning an update?
<smb> I probably should do. Its only doing some sb600 fixup but one never knows...
<hggdh> k. I will let pedro know
<smb> hggdh, It will take a bit because I want to get my tree into a sane state first (working on something else)
<hggdh> smb: no prob :-)
<smb> But I hope I got it uploaded by tomorrow
<ppisati> when does lucid expire?
<ogasawara> ppisati: April 2013 for the desktop, April 2015 for the server
<ogasawara> ppisati: https://wiki.ubuntu.com/Releases
<ppisati> ogasawara: k
<cooloney> ppisati: just got your email
<cooloney> ppisati: let me try to recall this bug
<ppisati> cooloney: it's the OTG thing/patch
<ppisati> cooloney: basically, i can't get the a_idle state, so i'm doing something wrong
<cooloney> ppisati: oh, i think you need a mini-A plug which is special for OTG
<cooloney> ppisati: do you have such things?
<ppisati> cooloney: what you mean special? i've a plug that i use to power that board
<ppisati> cooloney: and what do i have to connect on the other end?
<ppisati> cooloney: s/plug/cable with a mini-usb plug/
<cooloney> ppisati: oh, OTG can work as USB host which named A mode
<cooloney> so you need plug-in a mini-a connector to OTG port
<cooloney> then the OTG will change to A mode
<cooloney> at the other end of that cable, you can connect a USB flash disk 
<cooloney> so the beagle board works as USB host to operate USB flash disk
<ppisati> ok
<ppisati> cooloney: but then i need a mini-usb plug <-> female usb cable
<cooloney> ppisati: right, let me find one for you
<ppisati> cooloney: no prob, i can chase one
<cooloney> ppisati: great, man. i forget the name of my cable manufacture.
<cooloney> ppisati: i'm in the conference, after I got home, i will check that for you
<ppisati> cooloney: it's ok, i can handle it
<ppisati> cooloney: is the panda board affected too? i mean, ti-omap4
<cooloney> ppisati: i was told otg still has some issue on panda. but don't have much time to test that
<cooloney> ppisati: i will try that later
<ppisati> k
<jjohansen> rebooting
 * tgardner --> lunch
 * jjohansen -> lunch
<vanhoof> sforshee: you are a brave man :) (re: 561802)
<sforshee> vanhoof, brave or stupid ? ;)
<michaelh1> Hi there.  My machine is unreliable with the current Natty kernel - it dies with a kernel oops and backtrace sometimes, and sometimes halts with the numeric keylock led flashing
<michaelh1> It seems to be more reliable on WiFi instead of ethernet, but dies ~4 times a day
<sforshee> michaelh1, the blinking led means the kernel paniced
<sforshee> if you can somehow capture the oops and open a bug it's probably your best bet
<sforshee> even a photograph of the screen is better than nothing
<michaelh1> Yeah, the camera trick is cool :)  Once I have a backtrace, how can I roll back my kernel?
<sforshee> michaelh1, you mean roll back to a previous version ?
<sforshee> if you have a known good kernel version that's important information for the bug report
<michaelh1> sforshee: yeah, last weeks was more reliable on my machine.
<jjohansen> michaelh1: you may have an older kernel already installed, what does ls /boot show
<jjohansen> michaelh1: if there is multiple kernels in there you just need to hold down the left shift key on boot to get the grub menu, then you can select the one you want
<jjohansen> to make it permanent you need to edit the grub.cfg
<jjohansen> grub1 is /boot/grub/menu.lst
<jjohansen> grub2 temporary is /boot/grub/grub.cfg
<jjohansen> for permanent you need to update /etc/grub/<something>
<michaelh1> grub always shows on my machine due to Maverick.  I have 2.6.38 -7 and -8 in /boot, so I can try -7 and see if it faults.
<jjohansen> sorry can't remember what the actual file is atm
<jjohansen> michaelh1: yeah that sounds good
<jjohansen> you can also manually download kernels from packages.ubuntu.com
<jjohansen> the maverick kernel works okay on natty
<michaelh1> Not for me unfortunately.  The KMS in Maverick leads to red banding on my screen...  Non-KMS leads to draw errors :)
<jjohansen> michaelh1: :(, the graphics stack is one of those areas that is problematic
#ubuntu-kernel 2011-04-15
<yofel> is there a way to extend https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey for alternate images or is this way only possible with the desktop images?
<quentusrex> Anyone here know how to get more detailed application profiling info? I have an application that runs 4x faster on CentOS Intel boxes as it does on an Ubuntu 10.10 AMD box(with more cores, and faster speed). 
<nelhage> I'm trying to build a 2.6.39-rc2 kernel using make-kpkg and the config extracted from a mainline PPA kernel. The mainline PPA kernel boots, but mine doesn't. Is there anything obvious I might be doing wrong?
<nelhage> My command line is: make-kpkg --rootcmd fakeroot --append-to-version nelhage2 --us --uc --initrd --bzimage kernel_image
<aakshay> jjohansen, hi.. i am done with scull driver thoroughly now how can i start contributing the community? do i need to first study more? please suggest.. thanks
<jjohansen> aakshay: which community?  aakshay are you more interested in anything kernel or ubuntu kernel
<jjohansen> anything kernel -> http://kernelnewbies.org/
<aakshay> jjohansen, yes.. i am intrested in ubuntu kernel development. :p
<jjohansen> aakshay: ubuntu kernel, the place to jump in is kernel bugs
<aakshay> jjohansen, ok... what bugs can i start with?  
<jjohansen> aakshay: there is bug triaging and then there is taking any of the bugs associated with the linux package and working on it
<aakshay> i have seen the list of bugs but was not able to select one. can u please help me choosing one for a begineer? :)
<jjohansen> https://wiki.ubuntu.com/Kernel/BugTriage/BugDay 
<jjohansen> https://wiki.ubuntu.com/Kernel/BugTriage/Process 
<jjohansen> http://voices.canonical.com/kernelteam/?p=6208 
<jjohansen> those are triage links but bugs can be found in them readily enough
<jjohansen> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html 
<jjohansen> that is the hot bug list
<aakshay> jjohansen, thankyou  so much but i am done with triaging.. i want to enter into the bug correction.. 
<aakshay> so which bug can i start with?.. :p
<jjohansen> aakshay: triage links don't need to be used for just triaging there are a lot of bugs in there
<jjohansen> aakshay: anything that grabs your interest and isn't assigned
<aakshay> jjohansen, ok... :).. 
<jjohansen> well you could work on some of the assigned ones too ;)
<aakshay> ;)
<aakshay> then i visiting the links and will try to find one bug for me... :p
<aakshay> jjohansen, thanks a lot.. :)
<jjohansen> aakshay: np
<aakshay> jjohansen, and what to do if i would like to enter into the driver development or kernel development?.. 
<jjohansen> aakshay: that is more upstream kernel work, identify an area your interested in
<jjohansen> say its filesystems and maybe btrfs in particular
<jjohansen> join the fs-devel mailing list and the btrfs mailing list, go to their wiki (if the project has one (btrfs does))
<jjohansen> start by following along, and maybe picking out a bug or something to work on
<jjohansen> submit patches, get feedback, rinse and repeat
<aakshay> jjohansen, ok.. sorry but how to join the mailing lists? 
<jjohansen> you do it enough you become part of the project community and as you get more involved you know more what needs done
<jjohansen> aakshay: it will depend on the project
<jjohansen> a good place to start is http://www.kernel.org/pub/linux/docs/lkml/
<jjohansen> http://vger.kernel.org/vger-lists.html
<aakshay> jjohansen, woow!!! it sounds more fun now....  
<jjohansen> that isn't every project but its a good start
<aakshay> i am starting  with the links... 
<aakshay> jjohansen, thanks for guidance.. :)
 * apw yawns
 * RAOF fills apw's gaping mouth with bees.
<apw> woh, harsh
<RAOF> No, they're stingless bees.
<RAOF> Native Australian bees.
<RAOF> They make for a very nice gargle.
<apw> harsh for the bees
<apw> gargling with bees, thats an unusual game and no mistake
<RAOF> They're deliciously tickly.
<apw> smb`, hey ... whats the status of the fix for bug #539467
<ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
<smb> apw, morning
<apw> morning :)
<smb> apw, I think there was some blacklist fix going somewhere for one specific nvidia chipset
<smb> but I have not checked about that upstream
<smb> or I cannot remember to have
<smb> And any other affected controllers would need to extend that blacklist if it is there...
<smb> apw, ... in theory "libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65"
<apw> it doesn't seem to be in mainline then so far sm
<apw> smb
<smb> Guess then I need to ask, it went to Jeff Garzik+linux-ide
<smb> apw, I put you on cc
<jk-> smb & apw: I've implemented 'patch update notifications' on patchwork.ozlabs.org
<jk-> so the sender gets notified when the patch state changes
<jk-> want me to enable this on ubuntu-kernel?
<jk-> s/ubuntu-kernel/kernel-team/
<apw> i don't know how closly the stable team is tracking patchworks at the moment
<smb> Honestly I am not sure how much in use patchworks is anymore
<smb> apw, Stop saying my thoughs before me. :-P
<jk-> heh
<jk-> yeah, there's a bit of a backlog there
<apw> i think the lack of per release info has been a major blocker on it
 * jk- ponders
<apw> smb how is bug #634487
<ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
<smb> apw, Well I was not able to reproduce it with CentOS 5.5 + Xen (3.0.3 and 3.4.3) locally. So it really looks to me like something that is hidden in their host environment. Did not get much feedback to my findings though, so I have not followed up
<apw> ok thanks
<bj0_> aufs not work in .37?
<eagles0513875_> hey gusy not sure if you can help me but every time i try to connect to my wpa2 wifi connection natty kernel panics. my wifi card is an atheros card
<eagles0513875_> gnomefreak: do you kn ow how i can file a feature freeze exception to get the kernel patched asap on natty
<gnomefreak> dorry i ner not
<eagles0513875_> ok :( this is an urgent fix that need to be included
<gnomefreak> damn my typing suck today. im not good with gum_carlies
<gnomefreak> just for the record all day yesterday i was unable too boot using 2.6.38-8-generic-pae it kept restarting and/or freezing up. ill be back another smoke would be great.
<eagles0513875_> and im having kernel panic issues which i have a fix for
<eagles0513875_> but nto sure who to talk to
<smb> eagles0513875_, If you got a fix and a bug report going with it I would write an email to kernel-team@lists.ubuntu.com pointing to those. There should be no need for ffe unless your fix is a whole new feature
<eagles0513875_> no its a patch to the current kernel in natty
<eagles0513875_> thanks smb  :) thats exactly the info i needed
<eagles0513875_> will do that when i get home
<smb> that should be ok then. more a question is seeing trees in the forest :)
<apw> yep, we will need a bug filed if there isn't one, and get the patch out.  make sure it says where the patch came from, or is properly signed off if it is new
<eagles0513875_> i have the link of the patch as well :) 
<eagles0513875_> courtesy of some kind people from upstream and the kernel channel :) 
<apw> all the provenance information including the link is great
<eagles0513875_> apw: ya its imho for those with atheros cards a big show stopper for natty
<bj0_> is there a way to enable aufs support in .36 or .37 kernels w/out recompiling the kernel?
<apw> bj0_, in the mainline kernels ?  aufs is not in those kernels
<bj0_> apw: are the mainline kernels different than what ships with the releases?
<apw> yes, they are mainline kernel sources without any ubuntu patches
<apw> aufs is an out of tree driver, and included as part of the ubuntu delta, and therefore not in mainline kerenels
<bj0_> ah
<bj0_> do you know if it will be in the 11.04 release?
<apw> bj0_, aufs2?  yes it is included in the natty kernels, needed for the CDs
<bj0_> cool
<ogasawara> apw: I got ya covered for the meeting
<fairuz> Hi, I got "Suspending console(s) (no_console_suspend to debug" . How to disable the console suspend? I tried to add no_console_suspend to the bootatgs but no luck.
<herton> fairuz: how do you added no_console_suspend, eg. did you edited /etc/default/grub, added no_console_suspend to GRUB_CMDLINE_LINUX_DEFAULT, and run update-grub2?
<JFo> apw / ogasawara let me know when you'd like to go over those bugs that Pete mentioned
<ogasawara> JFo: gimme 10min, I'm documenting it in the wiki for the release manager tasks
<JFo> ok, I thought you might be :-)
<ogasawara> JFo: apw might be out and about for a while.  you and I can at least get a jump on the list and anything we have questions on we can craft an email.
<JFo> sounds good
<ogasawara> JFo: https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bugs
<MrBeanAC> hi guys
<gondoi> apw: I finally got a bug report created: #761809
<MrBeanAC> I habe a question: I installed the maverick backported kernel within Lucid Server. But I cannot find the corresponding linux-source-2.6.35 package... any idea?
<MrBeanAC> I also checked the mainline folders... a lot of versions do not include the source package... why?
<MrBeanAC> module-assistant i.e. needs that package
<JFo> brb
<JFo> back now
<ogasawara> JFo: almost done with my part in the release meeting, will ping you when I'm ready to resume going over the list
<JFo> cool :)
<ogasawara> JFo: ready?
<JFo> I am indeed
<JFo> :)
<sconklin> tgardner: you made a commit to the maverick meta "Add compat-wireless-2.6.38 meta package", should that also be made to the ports metapackage?
<tgardner> sconklin, I think LBM is only built for i386/amd64
<tgardner> for Maverick. lemme check for sure
<tgardner> sconklin, yep, thats the case.
<sconklin> tgardner: ok, thanks. Turning the crank.
<sconklin> severe weather here - if I drop that's why
<JFo> <-grabbing lunch, back soon
<bjf> JFo: you might be interested in: http://people.canonical.com/~kernel/reports/1-day-new.html  http://people.canonical.com/~kernel/reports/7-day-new.html   http://people.canonical.com/~kernel/reports/30-day-new.html
<JFo> bjf, I am indeed
<JFo> oh, and bjf, on the not seeing mail from bugs, I hadn't noticed, but I will have a look to see if I am seeing the same
<JFo> that 1-day-new report will come in really handy
 * tgardner --> lunch
<smoser> will a rebase to 2.6.38.3 (upstream stable) be done before release ?
<tgardner> smoser, no more rebasing, but 2.6.38.3 is already applied to master-next
<smoser> master-next ?
<smoser> for -updates ?
<smoser> sorry for not understanding what that means
<tgardner> smoser, its the working branch, but typically includes the next stuff to be uplaoded.
<smoser> so "no more rebasing". did that mean "this will not make natty release"?
<ogasawara> I believe apw is planning to do one last upload on monday which will include the 2.6.38.3 patch set
<tgardner> smoser, I doubt if this will get uploaded before final release.
<tgardner> um, I sit corrected.
<smoser> :)
<smoser> so the end result is that i would expect bug 662288  to be fixed
<ubot2> Launchpad bug 662288 in linux "rt3090: freeze on module rt2800pci unload" [Undecided,Confirmed] https://launchpad.net/bugs/662288
<smoser> as the opener says its fix is in 2.6.38.3
<ogasawara> we can probably add the bug number to the changelog so it'll get closed automatically
<smoser> would it be appropriate to mark it "fix-commited" then ?
<smoser> i'll eleave that to you.
<ogasawara> smoser: lemme just double check the commit is actually applied to master-next.  I'll fix up the bug status accordingly.
<smoser> thank you.
<ogasawara> tgardner: I'm gonna update master-next to shove the buglink in the commit message for 662288 so it get's closed by the janitor when we upload
<tgardner> ogasawara, ack
 * jjohansen -> lunch
<quentusrex> Is there any way to specify the kernel CONFIG_HZ option from the boot line?
<sforshee> quentusrex, no, afraid not
<quentusrex> Is there a tutorial for how to rebuild the stock server kernel and change only this option?
<quentusrex> sforshee, I see tutorials on how to build the latest git repo, but I'm looking to just build the exact kernel package, but with one config change.
<sforshee> quentusrex, not that I know of. The closest things I know of are the KernelMaintenance and Maintenance/Advanced pages at https://wiki.ubuntu.com/Kernel/Dev
<sforshee> you'd have to edit the server flavor config file and edit it there I believe
<quentusrex> Thanks. I'm trying to track down a massive performance difference between Intel and AMD hardware, as well as a performance drop from CentOS 5.2 to Ubuntu 10.10
<quentusrex> to the order of 4x as fast on Intel hardware, compared to AMD. And centos is about 2x as fast. 
<quentusrex> sforshee, But I'm aware that the issue is probably in the software itself, but I'm trying to track down what in the software is causing the issues.
<GrueMaster> What is the best way to get notified of sru kernel updates for armel?  I have yet to be notified of an available kernel until just before it gets deleted.
<hallyn> hey, what is the easiest way to install a maverick kernel on natty?
<hallyn> dpkg -i doesn't work on the stock package.  don't particularly want to compile my own, though that's starting to look easiest
<herton> hallyn: any error on dpkg -i? I think it should work, but I didn't tried, I remember a lucid kernel I installed for some tests on natty worked
<hallyn> herton: well, it just said
<hallyn> dpkg: dependency problems prevent configuration of linux-image:
<hallyn>  linux-image depends on linux-image-generic (= 2.6.35.28.36); however:
<hallyn> but apt-get install -f didn't help
<hallyn> i suppose i should just extract the contents
<hallyn> d'oh
<herton> hallyn: what's the deb file, is it the meta package or the linux-image...?
<hallyn> heh, the .deb i grabbed doesn't have te actual kernel anyway :)
<hallyn> yeah it's the meta package
<hallyn> sorry about that
<herton> ah ok, np :)
#ubuntu-kernel 2011-04-17
<savvas0> hello! do you know if rtl8192cu / r8192cu driver ( http://wireless.kernel.org/en/users/Drivers/rtl819x ) is included in ubuntu kernel packages? It is supported by linux wireless, but I don't see it in eg. natty linux image nor ppa mainline kernels, not even the linux backports packages.
<savvas0> I've sent my request as bug 763366
<ubot2> Launchpad bug 763366 in linux "rtl8192cu / r8192cu driver not included" [Undecided,New] https://launchpad.net/bugs/763366
#ubuntu-kernel 2012-04-09
<JamesJRH> Hello. I'm an Ubuntu user. Where can I file feature requests upstream for the Linux kernel? Specifically the USB drivers? Or should I first file it on Launchpad?
<JamesJRH> ?
<JamesJRH> kengyu___?
<JamesJRH> I learn that it is possible in the USB spec to disable ports, but apparently this feature isn't exposed in the USB drivers in the kernel. I'd like to file this as a feature request.
<anubhav> apw: Does Ubuntu support Lustre Filesystem?
<apw> a/close
<ogasawara> tgardner: want to double check before I start that you're not in the process of rebasing q to 3.4-rc2?
<tgardner> ogasawara, go ahead. I'm still messing with oneiric and precise
<ogasawara> tgardner: ack.  also, I coordinated with the release team to upload tomorrow.
<tgardner> ogasawara, ack
<tgardner> ogasawara, you're still picking up changes for q made to precise, right ?
<ogasawara> tgardner: yep
<tgardner> ogasawara, cool, then I don't have to remember
<jsalisbury> tgardner, herton, should I submit another patch request for 381b872cf7942ab8c95de156ce403bd906f3915d ?  
<tgardner> jsalisbury, nah, I just bundled it all together
<jsalisbury> tgardner, just saw it :-)  Thanks!
<jsalisbury> tgardner, I build an Oneiric test kernel with those patches, and have the original bug reporter test it, if needed?
<tgardner> jsalisbury, I think the get_reason_str() patch is straightforward enough that you needn't bother
<jsalisbury> tgardner, ok, thanks.
 * ogasawara back in 20
<penguin42> Hi
<penguin42> bug 922906 seems to have  a few dupes with the same backtrace; bugs 957846, 977143, 977156   and probably some more
<ubot2> Launchpad bug 922906 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [Medium,In progress] https://launchpad.net/bugs/922906
<ubot2> Launchpad bug 957846 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c" [Undecided,Incomplete] https://launchpad.net/bugs/957846
<ubot2> Launchpad bug 977143 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c (dup-of: 922906)" [Medium,Confirmed] https://launchpad.net/bugs/977143
<ubot2> Launchpad bug 977156 in linux "BUG: unable to handle kernel NULL pointer dereference at 0000009c (dup-of: 922906)" [Medium,Confirmed] https://launchpad.net/bugs/977156
<penguin42> oh, someone has duped two of them since I looked at two of them
<penguin42> I'd still add 957846 - and possibly some of the much older ones
<penguin42> and bugs 760959, 760300 and 748773 all look the same as well to me
<ubot2> Launchpad bug 760959 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x20" [Undecided,Incomplete] https://launchpad.net/bugs/760959
<ubot2> Launchpad bug 760300 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x20" [Undecided,Incomplete] https://launchpad.net/bugs/760300
<ubot2> Launchpad bug 748773 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x20" [Undecided,Incomplete] https://launchpad.net/bugs/748773
<jsalisbury> penguin42, Thanks, all the older bugs are now marked as dups
<penguin42> jsalisbury: I guess that's something trying to access a thumb drive when it's already out and in the users pocket
<jsalisbury> penguin42, It's also a know bug upstream, and is being discussed on LKML
<penguin42> nod
<ogasawara> jsalisbury: just fyi, posted comment to bug 974982
<ubot2> Launchpad bug 974982 in linux "pvops NULL pointer dereference oops in latest precise kernel" [Medium,Confirmed] https://launchpad.net/bugs/974982
<ogasawara> jsalisbury: can you ping me once you get their testing feedback, I'd like to get that into tomorrow's upload but would prefer positive testing feedback first.
 * bjf -> lunch
<tgardner> jsalisbury, can you add your standard 'please test upstream" blurb to bug #972823 ?
<ubot2> Launchpad bug 972823 in linux "Precise Beta 2 Live CD hangs at boot on HP Pavilion zv6000" [Undecided,New] https://launchpad.net/bugs/972823
<jsalisbury> tgardner, will do
<tgardner> I'm kind of out of ideas on that one
<nxvl> hey, in which package can i find compat-wireless?
<jsalisbury> ogasawara, oops, missed your message.  I'll let you know when there is feedback.
<nxvl> i need to patch it to fix the negative channel issue and i can't find it
<ogasawara> nxvl: which release?
<nxvl> ogasawara: precise
<ogasawara> nxvl: linux-backports-modules-3.2.0 contains a backported v3.3 compat-wireless stack, is that what you're looking for?  or do you just want the kernel package?
<nxvl> ogasawara: hmm, that's not installed on my system
<ogasawara> nxvl: lbm is an elective install, so not available by default
<nxvl> ogasawara: i need to apply http://patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patch and http://patches.aircrack-ng.org/channel-negative-one-maxim.patch to whatever compat-wireless i have on my system
<nxvl> ogasawara: and i prefer to re-pack and install rather than make && make install
<nxvl> ogasawara: so i was looking for pointer on which package to find the source of the driver that are managing my wireless card ATM
<ogasawara> nxvl: you probably are wanting the precise kernel git repo, ie. git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<nxvl> ogasawara: will take a look, thanks!
<ogasawara> nxvl: I can build you a test kernel if that's easier for you
<ogasawara> nxvl: assuming those patches apply cleanly
<nxvl> ogasawara: that would be awesome
<nxvl> ogasawara: just keep in mind that those patches are for compat-wireless
<ogasawara> nxvl: amd64 or i386?
<nxvl> ogasawara: amd
<ogasawara> nxvl: http://people.canonical.com/~ogasawara/nxvl/precise/amd64/
<nxvl> ogasawara: \o/
<nxvl> thanks
 * nxvl HUGS ogasawara 
<Amoz> ogasawara, wow, you just built him a complete kernel from sources?
<ogasawara> Amoz: we've got pretty robust kernel build resources :)
<Amoz> ogasawara, hah, I figured
<Amoz> I'm getting this error in dmesg, is it a bug, or is my HDD about to crash?
<Amoz> task jbd2/sde1-8:870 blocked for more than 120 seconds
<Amoz> here's the call trace in whole
<Amoz> http://paste.ubuntu.com/922441/
<jjohansen> ogasawara: do we have a wiki page detailing how backport kernels are handled?
#ubuntu-kernel 2012-04-10
<bjf> jjohansen: do i have to start looking for a new roomie ?
<jjohansen> bjf: ? oh shoot, I booked but I don't know that I filled everything in
 * jjohansen goes to fill in all the different things that were missed
<ogasawara> jjohansen: hrm, I'm unaware if we have a specific wiki detailing the backport kernels and process
<ogasawara> jjohansen: the best I can think of would be the spec -> https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS
<ogasawara> jjohansen: and I know the idea of backport packages (eg the kernel, X, etc) was discussed at UDS last time around, but I'm unaware of any formal docs that may have come out of it
<jjohansen> ogasawara: thanks
<bjf> jjohansen: heh
<jjohansen> bjf: not sure exactly what happened booked weeks ago, missed adding myself some how but it should be fixed now
<bjf> jjohansen: np
<jjohansen> bjf: thanks for the heads up :)
<bjf> jjohansen: just being selfish, didn't want roomate roulette
 * apw yawns
 * apw notes smb is suffering some technical difficulties
 * cking pulls in some updates and needs to reboot
 * smb seems to have completed recovery
<apw> smb, hehe nice
 * apw reboots, i may need recovery shortly
<smb> Now I just have to find out how complete this is...
<smb> apw, good luck
<apw> smb, well i made it back, i guess that is something
 * ppisati hates splitconfig.pl...
<apw> ppisati, ?
<ppisati> apw: messing around with config
<apw> ppisati, you know you can just add whatever you want to change to the leaf config you want to change it in, then run updateconfigs x2 and everything will be tidied up ... right ?
<ppisati> apw: you mean i can change a symbol in debian.X/config/armhf/config.flavour.foo, run updateconfigs x2 and the modification will flow to all the other configs?
<apw> ppisati, yes you can add a new line at the end of any leaf, with any value, and the updateconfigs will sort out moving it up and merging it with the values of other configs
<apw> moving which ones are merged and the like
<ppisati> uhm, nice i didn't know
<apw> ppisati, oh yuo must have been suffering much pain
<apw> ppisati, it often needs two runs to settle such that it doesn't move things again
 * ppisati -> rush out
 * smb begins upgrading...
 * smb reboots
<tgardner> smb, apw: http://kernel.ubuntu.com/~rtg/tangerine.png
<apw> tgardner, older userspace perhaps ?
<tgardner> apw, fully up to date precise as of yesterday
<tgardner> apw, wouldn't let me login, so I had to go to the console
<apw> tgardner, unexpected then ... 
<tgardner> apw, its that /run/udev part that bothers me
<apw> tgardner, recently updated?  as in could this be an updatre foobar?
<smb> some linkage fail for /run
<smb> ?
<apw> /run/udev should be a real place in the memory fs /run
<tgardner> apw, thats what I think too
<smb> apw, /run is tmpfs... 
<apw> tmpfs                                                                        801640      1332    800308   1% /run
<apw> yeah and there it is on my machine
<tgardner> its fsck'ing right now, should be up in a min or 2
<tgardner> apw, smb: tangerine is back. I'll have to keep an eye on the console for awhile. i wonder if it's problem is related to schroot mount/umount cycles ?
<apw> run should be an old member and its hard to see how that could affect it
<tgardner> apw, udev definitely went crazy when it lost its mount point
<diwic> apw, isn't /run fairly new?
<smb> not sure whether one could still see whether /run itself became ro or something like that...
<diwic> apw, it was on /var/run previously..or is my memory failing me?
<apw> tgardner, oh yeah i don't doubt that analysis.  i mean even if we ran out of something something i'd expect the old ones to keep working
<apw> diwic, indeed /run is newish
<smb> diwic, It was, I think it started to migrate there about O
<smb> tgardner, We'll need to have an eye on it. in my experience schroot umount often hangs after doing an upgrade in there
<smb> (somehow restarting (or tying to) of services seems to cause it)
<tgardner> smb, the schroots should be stable for now, so I won't update them until I see a build dependency go by in the upload queue.
<ogasawara> Could I get a few quick Ack's on the patch I just sent to the list to revert upstream stable commit 73d63d03?  I'd like to squeeze it into the upload today.
<smb> ogasawara, There has been a work-around too... But I guess we need something quick...
<ogasawara> smb: indeed, was just writing a response...
<smb> ogasawara, I sent out an ack as well
<ogasawara> smb: thanks :)
<smb> We could re-apply with the work-around in updates
<ogasawara> smb: yep, those were my thoughts too
<smb> I let upstream Xen know about the issue
<ogasawara> smb: and I assume if it really was meant for stable, it'll come in the next release
<ogasawara> smb: either the revert or the additional patch
<smb> ogasawara, Right, actually Konrad was doing the discussion. So one or the other likely happens
<ogasawara> tgardner, apw: I'm gonna start prepping the upload, anything else you want in?
<tgardner> ogasawara, nothing pending, though as soon as you start I'll think of something :)
<ogasawara> heh
<ogasawara> tgardner: did you want to make adjustments to "UBUNTU: [Config] Fix invalid linux-headers link"?
<tgardner> ogasawara, oh that, yeah. gimme a minute or 2
<bjf> apw, about ?
<apw> bjf, yep
<ogasawara> tgardner: sure
<bjf> apw, mumble
<cnd> sforshee, fyi, someone posted an ALPSv4 semi-mt patch on linux-input
<cnd> you might want to give it a review
<sforshee> cnd, I was just looking at it
<cnd> cool
<tgardner> ogasawara, "UBUNTU: Remove headers asm symlink entirely" emailed to the list
<tgardner> and build tested
<ogasawara> tgardner: ack
 * ogasawara back in 20
<tgardner> ogasawara, bug #978038 just appeared on the radar
<ubot2> Launchpad bug 978038 in apparmor "change to unconfined by name fails" [Undecided,New] https://launchpad.net/bugs/978038
<ppisati> brb
<ogasawara> hrm, no jj here
<tgardner> ogasawara, 978038 doesn't seem to be an OMFG kitten killer for the default install.
<ogasawara> tgardner: ok, I'm gonna apply your patch and then start prepping.
<tgardner> ogasawara, wfm
<tgardner> long live maverick meercat. EOL April 10, 2012
<cking> quite like maverick :-/
<dileks> goose died 1986
<henrix> apw: http://thread.gmane.org/gmane.linux.file-systems/55063
<henrix> apw: not sure if you found it already
<apw> henrix, just ... 0/9 ... gah
<henrix> yep, quite intrusive... and messing w/ locking... and not tested
<henrix> cool :)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> henrix, in better news he has at least shoved it into his for-next branch, so i have somehting to look at
<henrix> apw: ah, cool. last time i checked (last week, i believe) he didn't
<apw> henrix, yep, its very recent
<jjohansen> ogasawara: what does the kernel is frozen and then you have scheduled one additional upload mean?
<ogasawara> jjohansen: means we froze last thurs, but have arranged with the release team for one more upload today.
<ogasawara> jjohansen: only bug fixes needed to land for release
<jjohansen> ogasawara: right, but are you still taking patches
<ogasawara> jjohansen: yes, if they are not release critical, they'll go out in the first SRU
<tgardner> jjohansen, is your AA bug gonna qualify for an OMG kitten killer ?
<ogasawara> jjohansen: if it is critical for release, we just need to ask the release team permission to upload and justify it
<jjohansen> tgardner: no. I was just checking what was meant, I have assumed sru only since last week
<tgardner> jjohansen, ack
<jjohansen> ogasawara: no, just checking
<jjohansen> if there was a chance to slip some more patches in with out the extra overhead of sru, I would have taken it is all
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 17th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> jsalisbury, ok unexpectedly that 9 patch stack applied pretty well to P, so i have pushed some test kernels for those who can repro the issue
<apw> jsalisbury, if you could remind me if you see anything positive or negative on it
<ogasawara> tgardner: is gomeisa down?
<apw> ogasawara, not working for me, and i used it not 20m ago, tangerine is ok
<tgardner> ogasawara, I just rebooted it. should be back pretty soon
<tgardner> no body was on it except cking
<ogasawara> tgardner: yep, thanks.  just wanted to make sure it wasn't just me.
<apw> tgardner, yep and he can't have been using it
<tgardner> apw, I ran update-initramfs by hand after the kernel update, so if it doesn't come back....
<apw> it up a bit cause it is rejecting me really fast
<tgardner> apw, its not pinging from tangerine
 * tgardner goes to the console
 * tgardner stares at a blank console
<apw> tgardner, oh dear
 * tgardner goes to bang on the PDUs
 * tgardner -> lunch while gomeisa thinks (and maybe boots)
<wamty> in fdisk , printing the partition table, is it normal for the Start cylinder of the 2nd partition to be the SAME value as the End of the earlier partition?
<wamty> i remember it used to be a difference of 1, but right now on checking both my machines ive found the above.
<wamty> both are primary paritions
<wamty> the first partition was created through ubuntu's install.
<wamty> the 2nd thro fdisk, allowing the default cylknder values
<wamty> also is it safer to add one manually?
<jsalisbury> apw, keeping a close eye on that bug.  I'll let you know as soon as there is any feedback for your test kernel.
<josepht> p
<josepht> p
 * tgardner -> EOD
#ubuntu-kernel 2012-04-11
<infinity> ogasawara / apw: Kernel's through NEW, BTW.
<ogasawara> infinity: cool, I'll upload lbm then
<infinity> ogasawara: When staging to -proposed, you may as well just blat linux/lbm/meta all at once.
<infinity> ogasawara: (Assuming build-deps on lbm are correct for it to dep-wait)
<ogasawara> infinity: I think they are, or at least I recall they were
<ogasawara> infinity: I'll do meta too then
<infinity> Then yeah.  The whole point of staging it is that we don't care if it's temporarily broken, so easier for you to just fire and forget until morning. ;)
<infinity> (This should, hopefully, simplify your workflow a tiny bit in Q)
<ogasawara> infinity: indeed
<ppisati> moin
 * apw survives an update
 * ppisati -> reboot
<viktor_d> Hello! i've been advised to ask my question here.
<viktor_d> It is almost year since i can't use wi-fi on my netbook. I didn't really needed it but finally decided to investigate this issue.
<viktor_d> I tested upstream linux kernels 3.3.1 and 3.4.0rc and have been told to perform a kernel bisection.
<viktor_d> Since my problem appeared for the first time after i upgraded from maverick to natty, i need to compare latest maverick and earliest natty kernel.
<apw> smb, you have a bug linked to hardware-p-config-review, bug #913860
<ubot2> Launchpad bug 913860 in linux "Suepend/resume causes problems with mounted and active mmcblk device" [Medium,In progress] https://launchpad.net/bugs/913860
<viktor_d> So here is the question: how to work with git with two kernels lying in different repositories?
<apw> viktor_d, so i assume its not fixed in the latest kernels and the issue appeared back between those two
<smb> apw, Oh dear... 
<apw> between natty and maverick
<c10ud> i have a big question for you, i'll let you finish with this issue and then post my walltext ;)
<apw> c10ud, we're not signly threaded here
<smb> apw, I will have to look back at that. But I have not found a really good way around it
<c10ud> ok then:
<c10ud> hello there, i do not intend to generate flames or whatever, i tried searching but no luck so far on this. here's my story: i've read there's a proposal on lkml to change the default io scheduler to deadline for ssd etc. then i discovered the possibility to change it on the fly and for my system it really feels snappier (e.g. firefox+heavy wine game+dvb-tv app) but i have SATA and AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (they say for SA
<c10ud> TA cfq is better..but..) running on lucid with 3.0.0-18-generic #31~lucid1-Ubuntu
<viktor_d> yes, wi-fi worked in maverick and doesn't work in latest versions
<c10ud> question is: any reason on why deadline isn't the default for desktop?
<apw> c10ud, partly collective wisdom and partly experimentation, deadline is normally for situations where raw throughput is needed i believe and fairness is not an issue.  so you'd also need to consider how things are when you have many things running
<apw> c10ud, it is likely one of those things that needs someone to make a good test to allow comparitive testing
<cking> ..me senses a study of different usecases on a bunch of SSDs is required...
<c10ud> btw, lkml thread is here: https://lkml.org/lkml/2012/4/10/198
<apw> viktor_d, ok then personally i would do a manual bisection using the mainline kernels for the same versions, so the latest 2.6.35.x mainline kerenl and the latest 2.6.38.x mainline kernel; if those work boot ok and exhibit the same wifi working/not working, you can use the in between kernels to narrow the search to the mainline kernel tree
<apw> c10ud, snappiness is such a subjective thing ... but without testing properly we arn't going to change the default in a hurry
<apw> cking, something to add to your suggestions box for Q perhaps
<cking> apw, reckon so
<apw> cking, given we always say use deadline for servers and not for desktop, and perhaps the decision is as the thread suggests more about ssd/rust
<cking> apw, yep, however, I know that whatever we do it will be wrong from some subset of users :-/
<c10ud> apw, sure, that's the main issue there "measure snappiness" but as a matter of fact till 5mins ago i feared opening a tab in firefox under such heavy load lol
<c10ud> defaults are always tricky, yeah
<apw> cking, well yah i assume we need some kind of latency measure for requests there must be a tool for that
<c10ud> afaik the scheduler's war is not new though
<cking> apw , there are tools like bonnie++ can do that 
<cking> c10ud, I also suspect we need to figure out what's best for a set of typical applications and a typical mix of I/O on a bunch of typical modern drives
<c10ud> yep, it's just i wtf'ed when i read "cfq is best on sata" then tried deadline and was better for me
<viktor_d> apw, ok, i'll think about this, thank you
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<c10ud> could even be a firefox-specific thing, no idea
<apw> viktor_d, that is where they are hiding if you need them
<cking> c10ud, indeed, this is the problem with tunables, everyone has different settings to suit their config
<cking> we will put it down as something to study as a blueprint item for the next release
<apw> cking, cool
<c10ud> yea, i think it could be worth checking this out (also given i don't exactly have "new" hardware so i might not be the target for the new releases)
<ohsix> if there was a metric for it that was valid in most cases it could be switched by the kernel :> you can monitor the bio queue depths and things as the system operates to find out when deadline isn't fair enough and it starts starving things
<ohsix> maybe you could get a uevent for device congested out to userspace
<apw> ohsix, userspace activity triggered by disk conjection is never going to fly
<ohsix> there's a point where it's ok, then not ok; going to have to pick that somewhere, otherwise you sacrifice one side of the fence
<apw> ohsix, indeed but in the middle of a disk storm is not the time asking userspace to do anything is going to help
<apw> its just going to make more stuff need the disk and that is fail
<ohsix> eh, switching the policy to cfq while it's congested is going to make stuff need the disk more? the disk is already congested, you're just picking fairness when things are already bad, so it's not compounded and you don't pay all of the penalty for using deadline when it is
<apw> ohsix, no you are handing off a uevent which ... needs a program to handle it, which is ... on the disk
<apw> so inevitably by the time you react it will be far too late
<ohsix> i see
<ohsix> well the definition of congested can be chosen arbitrarily conservatively
<ohsix> maybe for the 10th percentile of the best benefit you can get from deadline
<apw> and right now we have no idea if there is any benefit other than a subjective it seems better from one person
<ohsix> as far as i know there'd be no huge penalty for doing it, also, doesn't cfq already have a knob that basically does that?
<apw> without any numbers who knows if deadline is better for _anyone_ else
<apw> (it probabally is, but we have nothing to base that on)
<ohsix> well there's probably a paper or two to be had about what it does for specific io patterns, if you have those io patterns it will be better; with ssd it's a little more certain due to the io rates and penalties for seeking being almost nil
<ohsix> (i know there's a paper, just not where it is or by whom to cite it)
<apw> ohsix, indeed and i have personally read exactly 0 of them, and have even less idea which access patterns we have
<ohsix> deadline is "fair" when io takes a trivially small amount of time
<apw> so saying 'at 10% we'll be able to switch easily' is a bit meaningless when we have nothing to take 10% of
<ohsix> and gets progressively more unfair
<apw> for which definition of fair though
<apw> snappiness is not fair, snappiness is 'my shit gets done first'
<ohsix> the same one used for cfq probably, if you consider all io to be the same class
<apw> or if that is your definition then cfq is unfair
<apw> we really don't give the kernel much info about which IO is important to us and which not
<apw> for it to make fairness decisions with
<ohsix> nod
<brendand> bjf - hi
<ohsix> anyways, deadline scheduling is well documented in other contexts, and how it behaves when the "run" or io queues get larger, and how to schedule among cooperating cpus or writers doing io, if one wanted to characterize it
<apw> brendand, very early for bjf, he's probabally not going to be about for 4hrs
<ohsix> none of the papers on the optimality can be applied to disk io tho
<brendand> apw - any idea of the Lucid -proposed kernel is going to finish verification soon?
<apw> brendand, it appears to be waiting on one verification, the recommendation from the engineer it to release with it either way, so i suspect it could happen today; cirtainly the deadline is up
<apw> brendand, i suspect they are having fun with oneiric issues which is the biggest delay
<ppisati> my electronic smuggler is closed... :(
<apw> ogasawara, i have a patch which i'd like in the precise kernel should you be forced to do another upload for any reason.  i believe it is not an abi bumper
<martinphone> if I install xubuntu 12.04 beta it will come with 3.2, right?
 * ppisati -> lunch
<brendand> herton - hi
<herton> brendand, hi
<brendand> herton, will verification complete on the Lucid -proposed kernel today?
<apw> herton, there seems to be one bug unverified, but it seems the fix there was also an upstream stable patch we missed (if i am reading the last comment right) so the engineer is recommending we keep it anyhow
<herton> brendand, probably not, there is still one bug not verified. we are waiting for one bug to be verified as apw said
<tgardner> herton, which ones are they ?
<herton> tgardner, bug 624510
<ubot2> Launchpad bug 624510 in linux "Copying To USB Is Very Slow" [Undecided,Fix committed] https://launchpad.net/bugs/624510
<herton> I talked with bjf yesterday, we could wait one more week for verification, since QA is busy now probably testing will be delayed
<herton> apw, yeah ming we could keep it as the patch was marked for stable
<herton> *ming said
<apw> ok cool, thats all i had to say :)
<tgardner> herton, you said there were 2 bugs ? whats the 2nd one ?
<herton> tgardner, hmm, I said still one bug not verified :)
<brendand> herton, what about oneiric?
<tgardner> herton, prolly wanna get that one verified. there is a lot of stuff going on in that patch.
<herton> brendand, oneiric was redone because of regressions, we decided to restart the SRU process for it, including all of master-next, since we had important fixes on there. So oneiric is on verification this week, will be released by next week, or earlier depending on how long bugs are verified
<herton> tgardner, indeed, not a simple change
<ogasawara> apw: ack, send it out and I'll get it applied.  I'll be surprised if we don't have another upload.
<bjf> brendand: did you get answers for your questions ?
<brendand> bjf, yeah. herton and apw update me. thanks
<harry32134324> hey guys I've got a quick question
 * ogasawara back in 20
<apw> harry32134324, unless you ask it you won't get an answer
<harry32134324> ahh ok :-)
<harry32134324> so here's the deal.
<harry32134324> i'm on 12.04 latest kernel with an intel sandy bridge
<harry32134324> i5
<harry32134324> when resuming my pc after a suspend it freezes
<harry32134324> however, when rc6 is disabled everything works fine
<harry32134324> i was previously told that my motherboard is to blame since it doesn't set voltages correctly
<harry32134324> i have an ASRock H67M-ITX
<harry32134324> any ideas if it can be resolved?
<harry32134324> kernel is 3.2.0-23-generic
<apw> if the reason is because the BIOS is setting the voltages wrong, very likely not other than applying an rc6 disable for it
<apw> who worked out your voltages are wrong
<harry32134324> so no way to keep rc6 enabled?
<apw> it sounds liek the h/w is broken in that mode, so i'd guess no
<harry32134324> hold on i can tell you who...
<harry32134324> one of the guys that i submitted an ubuntu bug to...
<apw> we cirtainly don't have many sandybrige people complaining any more about it, so i assume it works well in the majority of cases
<harry32134324> hmm got it...
<harry32134324> sucks
<harry32134324> here's the bug i submitted:
<harry32134324> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/964246
<ubot2> Launchpad bug 964246 in linux "Kernel Freezes upon resume when rc6 is enabled." [Medium,Incomplete]
<apw> harry32134324, yeah that information came from the upstream developers, seems that the bios was blamed
<harry32134324> i upgraded my bios but still have the problem. i suppose ultimately my hardware is to blame...
<cking> harry32134324, it does appear so
<diwic> apw, nitpick: the description for ubuntu/ubuntu-lucid.git says "Ubuntu 11.04", should be "Ubuntu 10.04" 
<diwic> apw, on kernel.ubuntu.com gitweb
<apw> diwic, thanks
<harry32134324> k guys thanks.
<apw> harry32134324, and with the latest bios do you have an item for "iGPU voltage", the upstream bug claims success when changing it from auto to 'fixed 1.25v'
<harry32134324> haven't tried that. i'll give a shot now.
<apw> harry32134324, not 100% sure its the same issue he is reporting against though or not, bugs can be so unclear
<harry32134324> well doesn't harm to give it a shot.
<harry32134324> see you in a bit i hope :-)
<ogasawara> cking: speaking of RC6, I was going to officially close the call for testing.  that ok with you?
<cking> ogasawara, yep, good idea 
<apw> ogasawara, i closed out my last wi, i think you've done yours, so i think that means only smb's is open
<ogasawara> apw: sweet!  I didn't realize smb had one open
 * ogasawara looks at the charts
<apw> its a linked bug
<smb> apw, ogasawara Is there a chance to postpone that somehow...?
<ogasawara> smb: lets just unlink it
<apw> yep if its just a bug and not going to be fixed, unlink it
<apw> or maybe milestoning it to precise-updates may work
<smb> I'd need to recreate the setup and then the aspire one I used to test seems slowly falling to pieces...
<cking> smb, was the Aspire One tested to destruction then?
<ogasawara> I'll be surprised if the burn down charts are smart enough to infer that precise-updates indicates POSTPONED
<smb> cking, at least the cheap ass ssd in it seemed to be more and more unwilling (some errors reported there) and once it hided completly
<cking> on a clear SSD you can seek forever
<ogasawara> smb: ok, unlinked from the config-review blueprint
<smb> ogasawara, Thanks, I try to get it tested again but it should not keep us from reaching 0 items
<smb> Stupid mmcblk anyway...
<harry32134324> no good unfortunately.
<harry32134324> it was a decent try at least.
<ogasawara> jsalisbury: bug 948235, lets close that out based on jamie's last comment (he's the original bug reporter).  if anyone else is still experiencing issues, have them open a separate bug report so we can gather their specific hw information and symptoms.
<ubot2> Launchpad bug 948235 in linux "Intel wireless still randomly drops connection" [High,Confirmed] https://launchpad.net/bugs/948235
<jsalisbury> ogasawara, will do.
<cyphermox> tgardner-lunch: for when you're back; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/973241 has a link to a kernel patch for the ipw2x00 wpa caps now
<ubot2> Launchpad bug 973241 in network-manager "ipw2200 driver doesn't report any capabilities or wireless properties using the nl80211 interface to network-manager" [High,In progress]
<ppisati> today i got the new panda and i was finally able to track down the "rebase bug" we had in the omap4, do you think there's still space for an upload?
<ppisati> tgardner: ogasawara ^^^
<ogasawara> ppisati: you'll just have to clear it with the release team
<ppisati> ogasawara: k
<ogasawara> ppisati: and they'll likely ask you to upload to the precise-proposed pocket
<ppisati> ogasawara: and from there to the final image, right?
<ogasawara> ppisati: then they'll pocket copy to the release pocket after it's built in proposed
<ppisati> ok
 * ppisati -> dinner, and after that, i'll do the pull req+prod release dance
<ogasawara> ppisati: I'm assuming final freeze doesn't take affect until 2100UTC today, so you have a few hours I think
<ppisati> cool
<ppisati> ah wait
<ppisati> UTC?
<ppisati> it's a couple of hours away
<ppisati> anyway
<ogasawara> ppisati: eat fast :)
<tgardner> eat while working...
<ogasawara> ppisati: what's the bug# again, I can give the release team a heads up
<ppisati> ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/963512
<ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed]
<ogasawara> ppisati: ack, thanks
<ogasawara> ppisati: just to confirm, the current ti-omap4 kernel is working (as in you backed out the changes which broke video)?
<ogasawara> ppisati: actually, can you jump into #ubuntu-release...
<tgardner> ogasawara, pushed Precise LBM w/ixgbe OEM driver update. will send meta patch on list.
<ogasawara> tgardner: ack
<tgardner> ppisati, let ogasawara know when you've sent your pull request. I've gotta bolt.... see y'all tomorrow.
 * tgardner -> EOD
<ppisati> zinc is crawling...
<ppisati> ogasawara: ok, mail with pull req sent
<ogasawara> ppisati: ack
<ogasawara> ppisati: did you want bug 963512 referenced in the changelog so that it's autclosed when we upload?
<ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
<ppisati> ogasawara: yes
<ppisati> ogasawara: it's referenced in...
<ppisati> ogasawara: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=commit;h=4dc553f924976f0a595079d9fe460a2220390548
<ppisati> "UBUNTU: blend upstream hdmi detection code and TI bits"
<ppisati> ah crap
<ppisati> i psated in the wrong lp
<ogasawara> ppisati: I can fix it up
<ppisati> ogasawara: thanks
<ogasawara> ppisati: uploaded, just pending archive admin to approve it in the queue
<ppisati> ogasawara: cool, thanks
<ppisati> infinity: ^^
<infinity> ppisati: Already done.
#ubuntu-kernel 2012-04-12
<vanhoof> ppetraki: would that have caused red artifacts to spam the screen on a panda-es w/ hdmi?
<vanhoof> no ppisati 
<ppisati> moin
 * ppisati -> look for some breakfast...
 * smb already had some
<smb> cking, i can hear you :)
<cking> smb,  but I didn't hear you :-/
<smb> cking, Now we need ppisati to sort out who is at fail :)
<cking> could be all 3
<ppisati> wait
<smb> cking, He can hear me
<ppisati> cking: say comething cking :)
<ppisati> cking: yesterday's update messed up my pulse audio config, check input mic maybe
 * cking is pulling in today's updates, then will kick pulse audio
<diwic> for 12.10, will we likely be running 3.5 or 3.6 kernel?
<ppisati> diwic: hopefully
<smb> cking, You are quite bouncy on mumble
<cking> it's gone weird on me
<cking> and now I can't connect
<diwic> ppisati, which one of them?
<ppisati> diwic: we don't know yet, UDS will tell
<ppisati> diwic: personally, the latter, the better
<diwic> ppisati, ok, yeah, I totally share that point of view
<ppisati> diwic: another thing to take into account for me is jelly bean kernel: the closest we do to their kernel, the better
<ppisati> diwic: actually it we could pick the same exact kernel, it would help
<diwic> ppisati, what is "jelly bean" ?
<diwic> ppisati, for me it's the latter the better because more machines end up getting fixed without me trying to backport things into our kernel
 * diwic looks up "jelly bean kernel" on google and finds a cupcake recipe...and android 5.0
<apw> diwic, its likely to be the latest we can shoehorn in.  we know 3.4 will be out shortly, and 3.5 is cirtainly going to be out about half way through.  depending on the exact dates will define whether 3.6 will drop before Q or not
 * apw runs some errands
<diwic> apw, ok, thanks
 * smb -> lunch
 * ppisati -> out for lunch (and to buy a new multimeter)
<Daviey> Hey.. Who would be able to help me with an overlayfs /dev issue?
<apw> Daviey, whats the issue
<Daviey> apw: Can overlayfs be used for /dev.. or do i need to use tmpfs?
<apw> Daviey, well /dev is normally a devtmpfs in ubuntu anyhow, so not real
<Daviey> apw: iscsi read only root, with overlayfs /.. and it's not doing the right thing :(
<apw> Daviey, define not doing the right thing
<Daviey> apw: simplest test case, $ sudo grub-probe /dev/sda1
<Daviey> grub-probe: error: cannot find a device for /dev/sda1 (is /dev mounted?).
<apw> and is there anything in /dev in your overlayfs
<Daviey> well it's populated
<Daviey> and "head /dev/sda1" looks genuine
<apw> are you checking from the host of the image or the machine using it
<Daviey> apw: another test case, http://pb.daviey.com/2dZU/
<Daviey> apw: the machine using it
<Daviey> fresh boot, http://pb.daviey.com/tmer/
<apw> that strace just shows strace not running anything no ?
<Daviey> apw: no, it shows mkdev failed.
<apw> Daviey, what are the two mounts its overlaying, can /proc/mounts
<apw> cat
<apw> strace: exec: No such file or directory
<apw> and there is no mkanything in it
<Daviey> http://pb.daviey.com/Ai1w/
<apw> Daviey, where is your root-rw i can't see it
<apw> -ro even
<Daviey> http://pb.daviey.com/rMHf/
<apw> Daviey, yes byut where is it in the mount ?
<Daviey> apw: I have no idea..
<Daviey> wait, it is in mount output.. /dev/disk/by-label/cloudimg-rootfs /mnt/root-ro ext4 ro,relatime,user_xattr,barrier=1,data=ordered 0 0
<Daviey> apw: Okay.. i lost my environment.. so i can't easily provide any more info right now.. But is there something i can dig into when i get it back?
<apw> i'd like to poke it when its there if thats ok, i am unmsure
<apw> unsure as to what the heck you are even doing and how it ends up on /
<Daviey> apw: okay.. i'll ping later when i have it.
<apw> i'd like to see dmesg as well
<Daviey> damn, i had dmesg.. but now gone.
<Daviey> apw: So the process is this.. pxe boot -> mount / from iscsi target, overlayfs / .. then do-stuff()
<Daviey> /dev/ seems wonky.. as in inconsistently working with some values, but not others.
<Daviey> /dev/sda1 is a block device.. which seems valid.
<Daviey> but grub-probe disagrees that /dev is mounted 
<apw> Daviey, do you overlay directly onto /, or overlay onto like /root then chroot into there
<Daviey> apw: i be live  it's direct, based on fstab
<apw> Daviey, ok can i see the script that builds this?  is it in our initramfs system so you cat break=bottom on it?
<apw> Daviey, and fstab is not reliable, none of the paths are in the face of a chroot in
<apw> udev /dev devtmpfs rw,relatime,size=4074700k,nr_inodes=1018675,mode=755 0 0
<apw> note that in your mounts list there the /dev is a kernel devtmpfs officially and not an overlayfs
<apw> Daviey, ^^
<Daviey> apw: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/scripts/maas-cloudimg2ephemeral
<apw> i think i meant the result this makes which when booted makes the overlay sandwich
<apw> Daviey, ^^
<Daviey> apw: Ah, i can't get to that now.. but when i do.. i can punt it over
<tgardner> apw, did you notice you are muted ?
<tgardner> apw, your lips are moving
<herton> ppisati, do you know who is doing arm qa SRU testing now? It seems ubuntu-armel-qa team was removed from launchpad, all tracking bugs now have no assignee for it
<ogra_> herton, QA is supposed to do all testing now, talk to pgraner 
<herton> ogra_, ack
<ppisati> herton: right, QA should handle that
<pgraner> herton, carlos is
<pgraner> herton, or I should say hggdh
<herton> pgraner, ok, will assign all bugs to qa team
<hggdh> herton: there will be a bit of delay, I am being shipped an ARM
<herton> hggdh, I'll make the bot and all tracking bugs have the regression-testing task assigned to canonical-platform-qa from now on
<ogra_> hggdh, make them ship a hand too, very helpful ;)
<hggdh> herton: perfect
<hggdh> ogra_: hum. So two hands are not quite enough... well. I have three big dogs that will be more than happy to help
<ogra_> so you got helping paws then instead of helping hands :)
<ogra_> as long as no thumb is needed :)
<hggdh> heh
<apw> tgardner, as we use rsync in this package, i think this should be pretty easy at least, --include-from=debian/fat-list for one and --exclude-from=debian/fat-list for the other
 * ericm|ubuntu git send-email is sometimes annoying to get people automatically Cc'ed
<ericm|ubuntu> apw, tgardner, bug 969334
<ubot2> Launchpad bug 969334 in linux "Support of Sentelic touchpad in Asus K53U notebook" [Medium,Triaged] https://launchpad.net/bugs/969334
<apw>         --suppress-cc all \
<tgardner> ericm|ubuntu, use --suppress-cc=all
<ericm|ubuntu> apw, tgardner, just sent out a series - would really like to hear from you guys
<apw> ericm|ubuntu, add that ...
<ericm|ubuntu> tgardner, apw, nice trick
<ericm|ubuntu> tgardner, apw, guess I can put it in git config
<ericm|ubuntu> git config sendemail.suppresscc all
<ppisati> back in 20
<pgraner> ppisati, did you get your panda yet?
<tgardner> pgraner, he did, and used it to fix a video regression yesterday
 * ogasawara back in 20
<pgraner> tgardner, ack
<ppisati> pgraner: yep, got everything and fixed the regression, thanks :)
<apw> terminal_output vga_text
<apw> tgardner, ^^
<apw> configfile (hd0,XX)/boot/grub/grub.cfg
<apw>         linux   /boot/vmlinuz-3.2.0-22-generic root=UUID=cf503727-25f2-4ecd-b0f3-2b894523bcba ro   quiet splash $vt_handoff
<apw>         initrd  /boot/initrd.img-3.2.0-22-generic
<apw>         set root='(hd0,msdos5)'
<cking> rtg, sudo hdparm --fibmap filename
<cking> oops, tgardner ^
<tgardner> rtg@gomeisa:~$ sudo hdparm --fibmap /boot/grub/grub.cfg
<tgardner> /boot/grub/grub.cfg:
<tgardner>  filesystem blocksize 4096, begins at LBA 4096; assuming 512 byte sectors.
<tgardner>  byte_offset  begin_LBA    end_LBA    sectors
<tgardner>            0 1007845376 1007845391         16
<tgardner>         8192 4431163456 4431163463          8
<tgardner> (parted) print                                                            
<tgardner> Model: Intel Logical Volume (scsi)
<tgardner> Disk /dev/sda: 2392GB
<tgardner> Sector size (logical/physical): 512B/512B
<tgardner> Partition Table: gpt
<tgardner> Number  Start   End     Size    File system     Name  Flags
<tgardner>  1      1049kB  2097kB  1049kB                        bios_grub
<tgardner>  2      2097kB  2318GB  2318GB  ext4                  boot
<tgardner>  3      2318GB  2392GB  74.0GB  linux-swap(v1)
<tgardner> root@gomeisa:/boot# hdparm --fibmap /boot/grub/grub.cfg
<tgardner> /boot/grub/grub.cfg:
<tgardner>  filesystem blocksize 4096, begins at LBA 4096; assuming 512 byte sectors.
<tgardner>  byte_offset  begin_LBA    end_LBA    sectors
<tgardner>            0 1007845744 1007845751
<tgardner> ogasawara, gomeisa is back online. we think we understand what the issue with rebooting is.
<ogasawara> tgardner: ack, I've been listening
 * tgardner goes back to shrinking linux-firmware
<tgardner> sconklin, uploading kills mumble
<sconklin> yeah, I have to turn on traffic shaping
<tgardner> this'll be done pretty soon
<cking> great shows topper to my file system testing - random errors on my 500GB HDD 
<ppisati> ouch
<cking> been like this all day, everything that could go wrong has.
<tgardner> cking, just in time for beer time
<cking> yep, think I will kick off a long palimpsest test on this drive and go for a break
<cking> HDD is fine, looks like the drive was lose in the bay and the SATA connector was poorly connected. doh
<tgardner> what luck
<tgardner> jsalisbury, rebooting tangerine
<jsalisbury> tgardner, ack
<jsalisbury> looks like it's already back :-)
<tgardner> jsalisbury, yep
<apw> after a disasterous day i am giving up for the night
 * ogasawara lunch
 * tgardner -> EOD
#ubuntu-kernel 2012-04-13
 * smb mornings
<smb> diwic, Hm, could it be that something visually stole a lot of hda microphones?
<diwic> smb, eh?
<smb> diwic, Somehow I only realized this this morning, but somehow at least on two machines, the microphone isn't called microphone but capture. Which I don't mind, but the sound settings dialog seems not to accept those as input devices. Leaving inputs empty (or only containing other inputs)
<diwic> smb, oh :-/
<diwic> smb, isn't it called "Analog input" or something?
<smb> Hm, Not in alsamixer
<apw> morning
<smb> apw, morning
<diwic> smb, so there was a change yesterday which I hoped would help against a few usb inputs
<diwic> not showing up in the UI
<smb> diwic, It helped... sorto of :)
<diwic> smb, so could you pastebin the output of "pacmd ls" on an affected machine, please?
<smb> diwic, sure, just a sec
<smb> diwic, http://paste.ubuntu.com/927534/
<diwic> smb, so according to this output, you should only have one input in sound settings, and that's your webcam/internal mic, because nothing else is connected.
<smb> diwic, Hm, probably not the best example. It used to show the microphone jack as well, but there is really nothing connected... Wait I get the same output from the other machine
<smb> That one would have an internal microphone not showing
<smb> http://paste.ubuntu.com/927537/
<diwic> smb, ok, and the internal mic disappeared something like yesterday or today?
<smb> diwic, The timeframe is bigger. I just installed that machine yesterday for some other testing.
<smb> It has been idling around for a bit... Though I thought I had it on Precise before and not noticed the mic being gone
<smb> But you know, you won't always look at the right place
<diwic> smb, ok. so can you run "ubuntu-bug pulseaudio" from the latter machine and point me to the resulting bug?
<smb> diwic, yes, sure
<smb> diwic, bug 980565
<ubot2> Launchpad bug 980565 in pulseaudio "Microphone gone from sound-settings while still usable for apps" [Undecided,New] https://launchpad.net/bugs/980565
<diwic> smb, aha, it's colin guthrie's bug but for input...interesting
<smb> diwic, Errrrr, well... ok, what? :)
<diwic> the good news for me is that I don't have to revert my fix from yesterday, because this is something different *phew*
<diwic> smb, so the kernel gives us no sign (no mixer control, or anything else)  that there is an internal mic present
<apw> diwic, does that mean it should also be missing in alsamixer thing ?  to confirm that
<smb> Well there is a control in alsamixer, its just called capture now... I think
<smb> Likewise on the other machine which has capture and capture 1
<diwic> apw, had there been something like "Internal Mic" or "Internal Mic Boost" in alsamixer, pulseaudio would have picked that up and known that you had an internal mic.
<smb> apw, Maybe you should check whether the mic fairy stole yours too... :)
<diwic> smb, just trying to determine the size of the problem here: can you still modify the gain of the mic in the sound indicator?
<smb> diwic, While an application using it is running there is a slider present. 
<diwic> smb, anyway the quick fix for you, is to modify /usr/share/pulseaudio/paths/analog-input-internal-mic.conf and comment out any line that starts with "required-any", then restart pulseaudio.
<diwic> smb, is the slider working?
<smb> diwic, and moving it does correspond to moving the capture slider in alsamixer
<diwic> smb, ok. good.
<smb> diwic, I don't think I need a quick fix. It is in the end more of a visual/usage limitation
<diwic> smb, this is not one of those machines that has an inverted phase internal mic? 
<smb> diwic, It is
<smb> diwic, I muted the right capture channel through alsamixer
<smb> It is a bit what started me looking because after a fresh install this is required to get the mic working
<smb> Then I wondered, ok, but _where_ is the mic slider now...
<smb> Then checked the desktop machine and I am pretty sure there was the web cam mic and the internal card mic there recently
<smb> But you say that is intentional if there is nothing connected to it 
<diwic> smb, a desktop machine with an internal mic?
<smb> diwic, No, sound card has a mic jack (not connected to anything)
<diwic> smb, ah, ok.
<diwic> smb, yeah, it's anticipated that it does not show up when it's not connected.
<diwic> smb, so given that this machine has the inverted internal mic problem as well, fixing that problem (in the kernel) will auto-fix the pulseaudio problem as well
<smb> diwic, Would be a plus... I try to find anything I can try to connect to the desktop machine. Just curious to see what happens then...
<apw> plug a speaker in :)
<apw> or your headphones, they ahve the saem plug
<smb> apw, yeah, yeah. theoretically every speaker is a bit of a microphone. but surely they have different impedance... :-P
<apw> smb, i wasn
<apw> smb, i wasnt expecting it work, just to trip the jack
<apw> smb, i shove mine in the wrong way round often enough
<smb> diwic, So I found some real mic to connect to the jack now. And looking in mumble (would never have dreamed to use that as a test ever) picks up something from the card... Still no show-up in the input sound-settings...
<smb> apw, Ah right, yeah that would halfway work. Just wanted some pickup of sound as well, so I can verify it does read something
<apw> smb, then i fail :)
 * apw looks at compiz and unity updates in his 'inbox' and cries
<diwic> smb, and this was the desktop machine with the webcam, right? Can you pastebin the output of "amixer contents"
<smb> apw, :) No worries, I found a cheap mans headset in my box of rectractable gadgets...
<smb> diwic, yes and yes
<smb> diwic, http://paste.ubuntu.com/927575/
<diwic> smb, ok, so the "mic jack" is "off" in that paste, which means that the problem is at the driver level
<smb> diwic, Hm, I wonder how much you can expect jack detection on desktop machines...
<smb> Just muted the web cam mic and still see audio activity picked up by mumble...
<diwic> smb, well, your line-out is plugged in, so that part of the jack detection seems to be working
<smb> diwic, Ok...
<smb> diwic, Erm, which numid you see the mic jack not connected?
<diwic> smb, the three topmost ones
<diwic> smb, the third is "Mic Jack"
<smb> and they all are =1
<smb> oh 
<smb> values
<diwic> with values=off means not connected
<diwic> values=1 I think means "the total count of values is 1"
<smb> ah
<smb> that was confusing me
<smb> Somehow this feels a bit like that  change may make this day well worth its number... ;)
<diwic> smb, if you're interested in continuing, the next step would be to run "sudo hda-jack-sense-test -a" with the mic plugged in, then with it unplugged to see if there's a difference
<diwic> smb, where hda-jack-sense-test is available in the snd-hda-tools packages in ppa:diwic/hda
<smb> diwic, sure, that would be on the desktop machine, right?
<diwic> smb, yes.
<smb> So amixer contents remains off all the times but hda-jack-sense-test toggles between yes and no for the mic
<smb> diwic, ^ (forgot=
<diwic> smb, ok, so looks like a driver bug to me. Next step, check if it's resolved upstream by https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
<apw> diwic, how does hda-jack-sense-test get the info
<diwic> apw, it sends a direct command to the codec asking for the current jack sense state
<apw> diwic, oh it can get that low a level access ouch :)
<diwic> apw, if that would have failed, it would probably have been a hardware error. 
<apw> diwic, and how have you gotten a 'no signer' on your PPA uploads ?
<diwic> apw, eh, where do you see that 'no signer' thing?
<apw> https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-daily/+packages
<diwic> apw, aha, those are recipe builds.
<apw> hmm thats a little confusing, it should really say 'launchpad' or something else they sound unsigned
<diwic> apw, hmm, https://code.launchpad.net/~diwic/+archive/hda/+packages does not show that column at all.
<apw> smb, STOP IT HURTS
<apw> smb, when you are loud it still breaks up
<apw> cking, i am silent i assume ?
<cking> apw, for once, yes ;-)
<apw> smb, i hear you yes
<mpt> Why do <https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Bug_Triage> and <https://wiki.ubuntu.com/Kernel/BugTriage/BugStates> both exist?
<apw> diwic, ok i am in a situation where gnome input selector thingy is not switching my mic any more
<diwic> apw, but the kernel still switches correctly?
<diwic> apw, I mean, from where is it actually recording?
<apw> diwic, erp ... all _i_ know is the indicator switches over and mumble continues to use the wrong one
<apw> diwic, the input level on the external mic seem to work in the selector correctly
<diwic> apw, first. what are you switching between? Internal and external mic on the same card, or an USB mic of some sort, or what?
<apw> so the internal HDA card the external connector with a mic plugged into it, and that blue snowball usb device
<apw> OH HANG ON
<apw> diwic, ignore me till i reboot i bet its an update skew issue
<diwic> apw, I don't think we've ever supported that type of switching.
<apw> diwic, it worked yesterday ... and if we don't support switching in that dialog what is it for
<diwic> apw, aha, you mean you manually switch in the GUI?
<apw> diwic, right in the GUI i am clicking and its doing nothing
<apw> but ... i have updated, so perhaps there is skew
<mpt> ... they seem to be identical
<diwic> apw, ok, rebooting might be worth a try
 * smb reboots to get alsa-next
<smb> diwic, Hm, not very positive it is fixed really. It is there now, but won't change to off when I am unplugging. So it seems to be static to whatever was the state on startup
<diwic> smb, hmm, sounds like the unsol event handling is not coming in correctly then
<diwic> smb, that's unusual, but I've seen it before. I guess the same would apply to the other jacks (line out and line in)?
<smb> diwic, Yeah sounds like some event problem. Hm, not sure I want to do that to the line out right now... But let me try line in
 * ppisati -> conf call
 * cking -> lunch
 * smb -> tired already
<henrix> smb: tired? get a good laugh here: https://lkml.org/lkml/2012/4/13/66
<henrix> :)
<smb> lol
<tgardner> ha ha
<smb> We obviously need to record a show like "The big bug theory (solving kernel problems without looking)"... :-P
<jsalisbury> "This bug is too big and boring, can you make a youtube video describing it" 
<dileks> the answer by rostedt was more amusing
<dileks> as I always say when doing 3rd level support
<dileks> I can read the faq/wiki/doc for you... if it helps
 * ppisati -> brb
 * ogasawara back in 20
<cking> bah, too many machines and too many updates, what a time sucker
<tgardner> apw, re: bug #922906. are you gonna propose that patch suite for precise ? seems like you're getting positive test results.
<ubot2> Launchpad bug 922906 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [Medium,In progress] https://launchpad.net/bugs/922906
<tgardner> plus, its got a zillion dupes
<apw> tgardner, ahh ok cool ... will let you see it and see if you whine :)
<tgardner> apw, its gonna be bjf et all that whine :)
<apw> tgardner, with only one responder, i am unsure how good two days is
<tgardner> apw, get jsalisbury to hassle some of the owners of dupe bugs
<apw> tgardner, don't they get a message too when the master is updated?
<apw> jsalisbury, ^^ ?
<tgardner> apw, dunno,. but you'd think so
<henrix> apw: i may try to reproduce the issue myself as well. i remember i had a set of scripts that could trigger it on a VM
<apw> henrix, sounds good
<henrix> apw: i'll let you know if that works ok
<apw> henrix, exceelent
<apw> tgardner, ok so i finally got some feedback on the ata patch and they want a complete rewrite
<apw> tgardner, and amazingly it works first time :)
<tgardner> apw, this is for hvc ?
<apw> tgardner, yeah this is moi trying to upstream the patch we have to ignore ATA drives
<apw> tgardner, they want a more generic soln. which is fine.  so am testing the patches nwo
<tgardner> apw, cool
 * tgardner -> EOD
<apw> cking, hey
<henrix> apw: with your test kernel, i'm not able to reproduce the bug
<pgraner> cking, you about?
<cking> pgraner, just about
<henrix> apw: i've been running the VM for a while now...
<pgraner> cking, what does this mean
<pgraner> Apr 13 13:40:33 x220 kernel: [  146.125226] Valid eCryptfs headers not found in file header region or xattr region, inode 5124144
<pgraner> Apr 13 13:40:33 x220 kernel: [  146.125231] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
<pgraner> Apr 13 13:40:33 x220 kernel: [  146.125250] Valid eCryptfs headers not found in file header region or xattr region, inode 5124144
<pgraner> Apr 13 13:40:33 x220 kernel: [  146.125256] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
<pgraner> I have thousands of them 
<cking> pgraner, let's see if tyler can explain
<tyhicks> pgraner: It means that there is a non-eCryptfs file in the lower filesystem and eCryptfs doesn't know what to do about it so it errors out of open(), stat(), etc., calls
<pgraner> tyhicks, how do I fix it up then?
<henrix> apw: anyway, i'll keep it running for some more time and post a comment on the bug report later on
<tyhicks> `find ~/ -inum 5124144` will tell you what file it is
 * henrix will be out for a while...
<tyhicks> pgraner: ^
<tyhicks> pgraner: It is probably an empty file. Verify that it has a size of 0 and then delete it.
<pgraner> tyhicks, ok it found it, look like a chromium file of some sort
<tyhicks> We really need to find a better way to handle this condition
 * cking wonders how it got there in the first place
<tyhicks> cking: Probably a kernel crash or hard power off. There is a small window between creating a file in the lower filesystem and writing out the appropriate eCryptfs headers to the lower file.
<apw> henrix, thanks
<pgraner> tyhicks, I ran out of space on my file system yesterday and I got all sorts of strange errors and file entries
<henrix> apw: np. it still see the issue with older kernels, but not with your test kernel
<pgraner> tyhicks, most cleared up after a reboot, except this one
<tyhicks> pgraner: Well, that may be it, too. Maybe you had enough space to create an inode but then didn't have enough space to write out the eCryptfs metadata (8k of data total)
<pgraner> tyhicks, prob happened while emacs was doing an autosave
<cking> tyhicks, thats a "special" condition for sure.
<pgraner> I had a script that was creating VMs and I didn't realize how many I had and ran it out of space
<tyhicks> cking: We can't handle that situation any better from an eCryptfs standpoint, but we could possibly handle the situation of opening an empty file better.
 * cking nods, yep, the error condition can appear rather worrying if one does not know how to interpret the error message
<tyhicks> cking: I've kicked around the idea of having the ecryptfs_open() path turn an empty lower file into an appropriate eCryptfs file, but some folks have spoke out against that idea
<tyhicks> (the code changes would be easy since ecryptfs_create() already does just that)
<cking> tyhicks, so why are folk opposing that idea?
<tyhicks> cking: See bug 911507
<ubot2> Launchpad bug 911507 in ecryptfs "eCryptfs should initialize existing empty files at open()" [Medium,Triaged] https://launchpad.net/bugs/911507
<tyhicks> cking: It looks like more users are speaking up for doing the conversion in open() than the one guy opposing it. I may try to fix this next week.
<cking> tyhicks, it should be fixed for  the silent majority rather than one user who opposes it IMHO 
<cking> could it be a default mount option so that the one whiner can switch it off it they want to
<tyhicks> cking: That's certainly an option, but I'd prefer not to add more mount options as it widens the amount of testing needed.
<tyhicks> cking: and I agree with your comment about fixing it for the silent majority
<cking> I suppose if they don't want it they can revert the patch and build their own kernel ;-)
<cking> tyhicks, yep, the less test paths the better
 * cking --> EOD
 * ogasawara lunch
<jsalisbury> apw, the dup bugs for bug 922906 do get updates when a bug comment is added.  Do you want me to spam some of the dups to ask for testing?
<ubot2> Launchpad bug 922906 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [Medium,In progress] https://launchpad.net/bugs/922906
<apw> jsalisbury, if you can be bothered :)
<jsalisbury> apw, no problem at all.  I'll request testing of your kernel in each of the dups
<pgraner> ogasawara, just send an email to c-k-t about a pxe boot kernel hang  can you guys dig into it asap
<ogasawara> pgraner: ack
<jsalisbury> ogasawara, whoops, mid-air collision on the email thread :-)
<ogasawara> :)
#ubuntu-kernel 2012-04-14
<BenHowes> Hey, I'm just trying to do my first kernel build (ARM omap 4) to enable an i2c feature that's not built by default. I am seeing "warning: (USB_WUSB) selects UWB which has unmet direct dependencies (EXPERIMENTAL && PCI)" when I quit my config. I'm following the instructions here: http://www.omappedia.com/wiki/Ubuntu_kernel_for_OMAP4 and trying to compile linux-ti-omap4 (3.1.0-1282.11) (from the ti git repo) for ubunt
<BenHowes> u 11.10. PCI isn't selected, and there is no option for it, which make sense...
#ubuntu-kernel 2013-04-08
<psivaa> infinity: we have still to do linux-ec2/lucid and will try to do asap. sorry about the delay
<ppisati> lp 1164074
<ubot2`> Launchpad bug 1164074 in linux (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Confirmed] https://launchpad.net/bugs/1164074
<ppisati> brb
<apw> diwic, i have no sound on todays updates, on an all intel dell, 3 years old.  any suggestions as to diagnostics?  everything alsamixer shows for output is unmuted
<diwic> apw, 13.04 ? did you have kernel and/or pulseaudio updates ?
<apw> i had kernel at least, i had 450M so probabally most things
<apw> for raring indeed
<diwic> apw, let's assume kernel - last PA update was 3 weeks ago
<apw> yay
<apw> quality in action
<diwic> apw, for initial investigation "ubuntu-bug audio" 
<apw> diwic, https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1166097
<ubot2`> Launchpad bug 1166097 in alsa-driver "[HDA-Intel - HDA Intel, playback] No sound at all" [Undecided,New]
<diwic> apw, did you test speaker only or headphones too?
<apw> diwic, i have personally tested all outputs, nothing
<apw> infinity, yep
<diwic> apw, but USB headset (if you're having any) is still working as usual I assume?
<apw> diwic, don't think we have a usb headset here...
<diwic> apw, ok.
<apw> diwic, i do have some usb speakers, but they are not physically proximate
<diwic> apw, let me look through recent patches to the driver and see if I find something
<diwic> apw, argh, nothing there either
<diwic> apw, I guess you're down to bisection then
<diwic> apw, i e boot an older kernel to verify the kernel is the fault
<apw> diwic, yeep
<apw> diwic, daily quality guarenteed ... sigh
<diwic> apw, how many days of update was it?
<apw> diwic, a lot ... i have had no network for weeks, i was last 'here' with b/w about 2 weeks ago
<apw> diwic, rebooting into a 3.5 kernel and i have sound
<diwic> apw, you must have had sound with an earlier 3.8 kernel too?
<apw> diwic, so ... 3.8-8 is ok, 3.8-9 is bad, i must have only used my usb output since then i assume to have not noticed for so long
<diwic> apw, what dates are that approximately?
<apw> commit 31b67ffaf4f9e72dce22d028180fc10a66dfec77
<apw> Author: Tim Gardner <tim.gardner@canonical.com>
<apw> Date:   Tue Feb 26 12:15:23 2013 -0700
<apw>     UBUNTU: Ubuntu-3.8.0-8.17
<apw> commit f7c0639bf5538a557a1f05ea6a81fb237776e2fa
<apw> Author: Tim Gardner <tim.gardner@canonical.com>
<apw> Date:   Thu Feb 28 08:47:51 2013 -0700
<apw>     UBUNTU: Ubuntu-3.8.0-9.18
<diwic> apw, what's the command for finding out the commits in between, for the sound/pci/hda directory?
<apw> diwic, tricky cause it is a stable update ... ick
<apw> git log 6071a7768562b970491c66127779de1f5b1250a3..Ubuntu-3.8.0-9.18 --oneline
<apw> is the only changes we made ... so it must be a mainline change, working out what that is now
<apw> diwic, it also includes 3.8 -> 3.8.1 stable
<diwic> apw, hrm, I'm looking at gomeisa's ubuntu-raring tree and the only v3.8 tag it has is v3.8-rc5
<apw> could be i have them locally separatly
<diwic> apw, yeah, just haven't synced raring because I haven't got around to buy a bigger ssd :-)
<apw> diwic, looking what was in the .1 updae
<apw> diwic, 
<apw> ca36807 ALSA: hda - hdmi: ELD shouldn't be valid after unplug
<apw> 97ec241 ALSA: hda - Fix broken workaround for HDMI/SPDIF conflicts
<apw> 13ba2f7 ALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB with ALC889
<apw> 6a9c847 ALSA: hda - Fix default multichannel HDMI mapping regression
<apw> 41e19bd ALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open()
<apw> 45d13ae ALSA: hda - Disable runtime PM for Intel 5 Series/3400
<apw> looks to be the delta for hda
<diwic> apw, I looked through all those already
<diwic> apw, none of those looks applicable to your problme
<diwic> i e your hardware
<amitk> what does linux-image-extra contain (in the mainline builds) ?
 * apw goes test that it _is_ 3.8->3.8.1
<apw> amitk, 'the other half of your modules', linux-image is 'virtual' linux-image+l-i-extras is 'generic'
<amitk> apw: so probably useful on a desktop
<apw> amitk, indeed yes
<amitk> apw: thx
<apw> amitk, np
<apw> diwic, identifying whether it is stable or our changes next
<apw> will let you know
<diwic> apw, thanks. Yeah, I think we're down to a real bisect at this point no matter what
 * apw secretly blames diwic :)
<apw> diwic, ok 3.8 mainline is good,  3.8.1 is bad
<apw> diwic, what was my bug number?  i've lost it already
<diwic> apw, bug 1166097
<ubot2`> Launchpad bug 1166097 in alsa-driver (Ubuntu) "[HDA-Intel - HDA Intel, playback] No sound at all" [Undecided,New] https://launchpad.net/bugs/1166097
<apw> diwic, ta
<apw> diwic, so it is deffo one of those 6, just reverted just those off -9 and its working
<diwic> apw, the annoying thing is that most of those are HDMI related 
<apw> diwic, yes
<diwic> apw, hmm, you do have an HDMI codec on the same sound card though
<apw> diwic, it does have hdmi as well
<diwic> apw, btw, I assume you have not tested HDMI audio?
<apw> diwic,  i have not
<apw> it is not something i use regularly
<diwic> apw, ok. well, continue searching. My guess is "Fix broken workaround for.."
 * diwic wonders if we'll need a "Fix for fix for workaround for" patch...
 * diwic goes for lunch, bbl
<diwic> back
<apw> diwic, ok ... bisect says:
<apw> commit ca368073ffcbdd25486d65c150039423f677f821
<apw> Author: David Henningsson <david.henningsson@canonical.com>
<apw> Date:   Tue Feb 19 16:11:22 2013 +0100
<apw>     ALSA: hda - hdmi: ELD shouldn't be valid after unplug
<apw> is at fault.
<diwic> apw, eh
<diwic> apw, ouch ?
<diwic> apw, probably it triggers some other bug in a strange relationship
<apw> diwic, what now :)
<diwic> apw, I'm still in denial ;-)
<diwic> apw, it's not a dangerous patch to revert
<apw> diwic, i'll reset to latest kernel and confirm it reverting it there solves it too and its not just luck
<diwic> apw, could you also attach the contents of /var/lib/alsa/asound.state to the bug?
<apw> diwic, attached
<diwic> apw, can't see it, are you sure the attachment uploaded correctly?
<apw> diwic, try that (i hate LP)
<diwic> now it's there
<apw> diwic, ok confirmed that reverting that patch against the 3.8.0-16 base also fixes my issues.  am trying to debug now, as your patch seems reasonable assuming no other bugs
<diwic> apw, it should only affect the output of a file under proc. 
<apw> diwic, ok i have just added some prints (no functional change) on top of your not-working patch and it starts working ... this is well peculiar
<diwic> apw, oh, a heisenbug
<diwic> apw, out of curiousity what prints did you add?
<henrix> brb
<apw> http://paste.ubuntu.com/5689367/
<apw> diwic, ^^
<diwic> apw, also, I saw something in your dmesg; "alsa restore exited with status 99" or something similar. 
<diwic> apw, do you know if this is related, i e, if this message only comes when it's working, non-working, or unrelated?
<apw> diwic, interesting ..
<apw> will check
<apw> [   12.683939] init: alsa-restore main process (1436) terminated with status 99
<apw> diwic, present when working as well
<diwic> apw, okay
<diwic> apw, then it's not that
<smoser> can i poke someone about https://bugs.launchpad.net/bugs/1164739 ? i'm not sure if its regression or not, but at very least i'd expect a kernel package to not have missing dependencies inside it.
<ubot2`> Launchpad bug 1164739 in linux "Can not mount cephfs in VM from cloud image" [Medium,Confirmed]
<smb> smoser, Could require the extras package. Or someone asking to move certain modules to the main package...
<smoser> smb, right. read my comment at the bottom.
<smoser> i dont have strong feeling either way on that.
<smoser> but ceph.ko should not be in a package if libceph.ko is not (as it former depends on latter)
<smoser> i'd assert thats a packaging bug if significant priority. i'm surprised if humans are maintaining the kernel module list without automatic dependency resolution
<smb> smoser, Right probably one or the other. I think there was at some point a request to have ceph in virt so if it is only 200k more I guess you or Ben would not mind the difference
<smoser> smb, well, i'd like to see the justification.
<smoser> 200k is not insignificant at all. installed size is ~ 12M, so 200k is 2% growth.
<smoser> basically, i dont want to willy nilly be adding things there.
<smb> smoser, That would be coming from the bug report, right? But yeah, it has not been a problem yet to maintain the list by hand. 
<smoser> so it is maintained by hand, ok.
<smoser> smb, ok. i'll open another bug that you can triage as you like for "module dependencies should not be managed by hand"
<smoser> and then i'll ask the user here for some use case as to why they want ceph.ko in -virtual
<smb> smoser, Yes, it is. Basically whenever someone tells us something needs to be supported in the cloud image we add it. 
<smoser> we should have some sort of policy to guide us in such decisions 
<smb> smoser, Hm, I am not sure this really qualifies (should not be done by hand). Whoever wants something now should test what is required. I wonder whether there was an actual request for ceph...
<smoser> smb, well this user wanted ceph, but really only because they wanted to use ceph and didn't know about the -extra (and i told him).
<smoser> clearly if you're given the choice between "do you want to have 1 extra step to use something" or "do you want to just use it", you'd pick the second.
<smoser> but we have the size concern to consider.
<smb> smoser, Its just that I *think* there has been someone asking for it before. I just cannot remember
<smoser> smb, right.
<smoser> smoser, can you git blame that list ?
<smoser> and see?
<smoser> at least who did it
<apw> diwic, ok confirmed removing those printks also makes it break again
<smb> smoser, thats what I currently try
<smoser> smb, reguarding the dependency resolution, i'd suggest just failing a build if you're missing dependencies. 
<smoser> there are no cases where that is not a bug.
<diwic> apw, I assume the "restring cap" printk was never printed?
<apw> diwic, correct
<smb> smoser, Not sure this is that simple. At least now, the build is done completely and just the packaging step splits the modules up.
<smoser> hm.. i dont know. but personally i'd rather have a developers build fail then have 'modprobe' fail on a user system in this way.
<smb> smoser, http://bugs.launchpad.net/bugs/1063784
<ubot2`> Launchpad bug 1063784 in linux "Ceph module not installed" [Medium,Fix released]
<smb> So added around quantal
<smb> But might be the other module did not exist then
<smoser> smb, and then broken in raring to a kernel change probably.
<smb> smoser, right
<smoser> (which gives more credence to my argument :)
<smoser> (the argument that there should be some test to stop this from being released)
<smb> smoser, Hm, there is a libceph already (in q)
<smoser> smb, the reporter claims this is broken in 12.10
<smoser> that is a 3.5 kernel in the report.
<smb> smoser, That would be Q, so someone did not test things after asking for it... :-P
<diwic> apw, the thing is, eld->eld_valid should have been false always anyway, since you don't have an hdmi monitor plugged in.
<smb> smoser, But ok, if it is possible to run a dep check on a package subdir that would catch those things
<smoser> smb, its definitely doable. it might take some re-work of the kernel build though. i dont know.
<smoser> but anyway.
<smoser> i guess the right thing to do at the moment is to include libceph.ko
<smoser> and probably sru that.
<smb> smoser, Yeah, in theory it looks like one can point depmod at a different base dir and a system map file... so it should be possible. So let me know the bug for that. And for libceph, yes, sounds reasonable as having ceph.ko was already done, too.
<smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1166197
<ubot2`> Launchpad bug 1166197 in linux "included kernel modules may miss dependencies (-virtual)" [Undecided,Confirmed]
<smoser> smb, you definitely can do that. i use depmod that way in cirros
<smb> smoser, Ok, I will try to add it to the build process then.
<plars> infinity, bjf: we are almost through with the pile of SRUs from last week, there's a precise one that psivaa is working on now, and I'm about to start the ec2 one
<bjf> plars, ack, looks good
 * ogasawara back in 20
<ppisati> infinity: i know you took care of the transition from Q/omap to Q/generic
<ppisati> infinity: we need to the same for Q/highbank to Q/generic
<ppisati> infinity: and i didn't find any patches in our kernel tree about it
<ogra_> ppisati, meta should handle that
<ppisati> ogra_: i know, but since he already handled that
<ppisati> ogra_: he knows what to do better than me
<ogra_> yep, i just mean it should be visible in your package somewhere :)
<ppisati> actually was rtg who handled that
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring-meta.git;a=commit;h=289b3dbee84086f2e323a1da7ccf3ea410b3ae59
<ppisati> and i *think* we need a transitional pkg like we did for omap
<ogra_> yup
<ogra_> the right conflicts/replaces/breaks and a transitional package shoudl do
<ppisati> ogra_: ok, i'll hassle rtg tomorrow about it
<ogra_> :)
<fxbrain> 
<infinity> ogra_: No need for conflicts, breaks, or replaces, it's just a straight up depends.
<ogra_> ah, k
<ogra_> you dont want the old package to be removed ?
<ogra_> even though its likely impossible to roll back
<infinity> When the "old package" happens to be your running kernel, forcing it off the system would be a silly idea.
<ogra_> ah, indeed
 * ppisati -> gym
<ppisati> later
<infinity> psivaa: precise/omap4 seems to also be stuck in regression-testing.
<psivaa> infinity: it's progressing now, started a little late on that and i should be able to finish it this eve. roughly in about 4 hrs
<infinity> psivaa: Cool, thanks.
<psivaa> infinity: just completed the regression testing task for linux-ti-omap4: 3.2.0-1429.38 (1160194)
<infinity> psivaa: Danke.
#ubuntu-kernel 2013-04-09
<ppisati> moin
<dholbach> hiya
<dholbach> do you know of any reports of e1000e not working in raring?
<smb> dholbach, not me, maybe some of the others
<dholbach> smb, a friend in the office just told me about it and I just yesterday noticed the same at home
<smb> dholbach, I should have some boxes myself. not sure I noticed, but maybe I have not upgraded latest enough
<dholbach> for me it's on a x220, the friend of mine downgraded to 12.04 already :-/
 * cking has a x220, will sanity check this
<smb> dholbach, did you have that with all versions of raring and quantal?
<smb> 12.04 would be precise...
<dholbach> cking, not sure if you saw the original question - it's about ethernet not working
<dholbach> smb, no - I haven't used ethernet in a long while - just noticed it yesterday
<apw> cking, yours is a ... oh you said that :)
<apw> diwic, about?  this = false thing ...
<diwic> apw, any news?
<smb> dholbach, one box is using e1000e in raring and still working but the kernel is back at 3.8.0-13. upgrading now
<apw> diwic, so i think this is a race, a race caused by the now double clear of that variable
<apw> diwic, i note that later you have produced a patch set adding locking in this area
<apw> so clearly there is some race potential here
<apw> but the main point is actuall that variable is = false and made so by the memset just above
 * cking just upgrading his x220i - confirming it has e1000e and currently working
<apw> and i think the double adds a window where it gets cleared twice
<diwic> apw, what I don't get is how any kind of race related to eld_valid could affect analog (non-HDMI) playback
<apw> all true, ... its hard to fathom, but the patch as is seems redundant
<apw> diwic, the only other reasonable inference (for me) is that the code layout changes it causes affects one of the other routines in the same file, and that is scarey
<diwic> apw, that memset looks weird. 
<apw> cking and i looked it over yesterday, it seemed to do something sane ish
<apw> ie. it clears out the first 3/4 of the structure, but not the buffers at the end
<diwic> apw, ah, now I understand it
<apw> a little odd i concur
<cking> the memset() does the job
<Kano> hi, does anybody update the unstable-3.9 branch soon?
<apw> Kano, it is likely to be a little delayed, we are in freezes right now and have other priorities
<Kano> basically it would be interesting to combine it with the uvd patches
<diwic> apw, or the additional = false causes a gcc bug because it tries to optimise it away having seen the memset, but fails in some weird way?
<apw> diwic, we read the asm for both forms and they seemed right to us
<diwic> apw, oh, you went that deep
 * diwic bows down in admiration
<apw> diwic, yeah we found pretty  much any addition to the routine also  avoided whatever the issue
<apw> diwic, there is clearly something nasty in there, whether it is related to races your new locking (in later kernels) avoid or not ... how to tell
<cking> it certainly seemed racy
<diwic> apw, is it easy for you to file up a broken and a working kernel and attach alsa-info for both to compare for differences?
<diwic> apw, for best reference alsa-info should be taken while playback is in progress
<apw> yet, the code in question on the machine in question should be static as there is nothing in the port, ...
<diwic> apw, did I miss anything?
<diwic> apw, latest is <apw> yet, the code in question on the machine in question should be static as there is nothing in the port, ...
<apw> diwic, noope you miseed nothing
<apw> diwic, i'll try and get what you wanted.  it's my main machine
<ppisati> brb
<smb> cking, dholbach, server now on 3.8.0-17 and e1000e still working (82574L NIC)
<dholbach> what kind of info would you need in a bug report?
<dholbach> I'll double check in a bit
<cking> hrm, my X220i with e1000e and latest kernel works OK
<smb> dholbach, whatever ubuntu-bug linux collects. Though you probably need to work via apport-cli as you have no network at that time
<dholbach> all right, will do - thanks
<infinity> apw: I assume you noticed that lowlatency exploded in make oldconfig?
<apw> flaps
<apw> how is that even possible
<infinity> https://launchpadlibrarian.net/136658295/buildlog_ubuntu-raring-amd64.linux-lowlatency_3.8.0-17.10_FAILEDTOBUILD.txt.gz
<infinity> Cause there was something new? :P
<apw> i don't doubt that it did so, but ... the configs are made from the main ones on rebase, and those would have to explode too... in theory
<infinity> And you didn't sync configs when you rebased?  I'm guessing?
<apw> that happens on rebase as part of the rebase
<apw> but i will go and poke it, as this 'cannot' happen
<Laney> hello kernel friends. Is there some badness with the -17 kernel in raring? I'm seeing nvidia-310 now not compiling: http://paste.ubuntu.com/5691789/ and http://paste.ubuntu.com/5691769/
<apw> Laney, i don't think we expect it to be significantly different from the previous version, which worked i assume
<Laney> indeed
<Laney> hmm, it's checking for SUBLEVEL -le 5 and that's now 6
<apw> Laney, so an issue with nvidia then?
<Laney> well, assuming that SUBLEVEL increase is right then I guess so
<Laney> tseliot: ^ looks like bug #1166639; do you know if n-g-d-310 needs an update?
<ubot2> Launchpad bug 1166639 in nvidia-graphics-drivers-310 (Ubuntu) "nvidia-310 310.32-0ubuntu2: nvidia-310 kernel module failed to build" [Undecided,New] https://launchpad.net/bugs/1166639
<tseliot> Laney: I guess the correct headers were simply not installed: *** Unable to determine the target kernel version. ***
<tseliot> Laney: or the DKMS log is bogus
<Laney> tseliot: They are - I got a set -x log of conftest.sh and it's failing when (presumably) checking the kernel version at line 1706
<tseliot> Laney: I'll have a look at it here. Thanks
<Laney> Seems like that check should be reworked a bit
<Laney> thanks tseliot 
<ppisati> mumble down?
<cking> ppisati, seems to be borked
<ppisati> cking: i'm back in
<ppisati> cking: yep
 * ppisati -> out for lunch
<tseliot> Laney, apw, ogasawara: do you know why SUBLEVEL was changed to 6 in the Makefile in 3.8.0-17.27? It was previously set to 5. This makes nvidia's build fail
<tseliot> http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-raring.git&a=search&h=HEAD&st=grep&s=SUBLEVEL
<tseliot> and by previously I mean in ABI 16
<apw> tseliot, it is the third number of the upstream version, it changes when that changes
<apw> VERSION = 3
<apw> PATCHLEVEL = 8
<apw> SUBLEVEL = 6
<ogasawara> tseliot: what apw said, we rebased to upstream stable v3.8.6
<apw> so that says this is based on 3.8.6 stable update from upstream
<apw> it would be a completely normal action when we are in rebase territory, ie before release
<apw> and actaully any time we apply stable we'd do it, so expect it :)
<tseliot> apw: does this check make any sense to you? http://pastebin.ubuntu.com/5692393/
<tseliot> I don't see why sublevel should be less than or equal to 5
<apw> so i think that is probabally designed for the 2.x days, it feels like it is trying to check for versions greater than 2.6.5 when perhaps the makefile name changed? something like that, it also just lookes borkes
<apw> borked
<tseliot> hmm... removing the "-a $SUBLEVEL -le 5" part gets it to work... I'll send NVIDIA a patch
<Laney> it is borked
<Laney> probably ought to check the major version too?
<apw> tseliot, yeah i think ... it assumes the first digit is always 2, then it says for 2.6.x where .x < 5 then we need to change makefile to the old one
<apw> but ... as it doesn't check the 2, that means it now hits for 3.6 and above
<apw> (i think)
<tseliot> the comments in the code look a bit dated: http://pastebin.ubuntu.com/5692404/
<apw> tseliot, so that matches what I guessed i think, i suspect just zapping the whole lot is reasonable now, we don't have anything that old any more
<tseliot> apw: are you suggesting that I skip the entire check or just the -le 5 thing (which seems less risky)?
<apw> if the comments concur that they intended to select one bit of code for 2.6.5 and older and one for 2.6.6 and later, then we can rip out the decision en toto and use the code for 2.6.6 and above
<tseliot> apw: here's the complete picture (with some code ripped out), just to give you an idea: http://pastebin.ubuntu.com/5692420/ (and we're hitting the "else"
<ppisati> lp 1164074
<ubot2> Launchpad bug 1164074 in linux (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Confirmed] https://launchpad.net/bugs/1164074
<ppisati> rtg_: ^
<ppisati> rtg_: there's a patch attached, can you give it a look? it's for raring-meta
<rtg_> ppisati, will do
<apw> rtg_, are you applying patches ?
<rtg_> apw, haven't started yet, but did push some updates this AM (to existing patches)
<apw> rtg_, i was going to apply jj's patch but don't want to step on our bags of man sausage
<rtg_> apw, go ahead, I'll look at ppisati's upgrade bug
<apw> rtg_, ack
<apw> rtg_, forget that ... ogasawara is on the case anyhow
<ogasawara> apw: ah yep, applied both jj's and piti's patches to Raring
 * ppisati goes for an apple...
<ogasawara> apw: I didn't touch Lucid, Precise, or Quantal, was gonna leave that to bjf and his minions
<bjf> ack
<Gen0me> Hi
<apw> ogasawara, ta
<Gen0me> guys;)
<bjf> Gen0me, we are not a very touchy-feely channel, if you have a question, ask it
<apw> Gen0me, yep we are pretty passive
<rtg_> some are more aggressively passive then others
<Nafallo> hey... what happened to chumby kernels? ;-)
<ogra_> Nafallo, we dropped support for armel quite a while ago ...
<Nafallo> seems these things are dead-weight unless someone revive them :-)
<ogra_> mine still runs fine 
<ogra_> showing the LCARS clock in my living room 
<Nafallo> oh? I thought the server it syncs with died?
<Nafallo> company went bust or whatever
<ogra_> there is a hacked image you can install that doesnt require the network
<Nafallo> aha
<Nafallo> that's the answer I was looking for I guess ;-)
 * ogra_ forgot how it was named, i did that right when they shot down ... was a while ago
<Nafallo> zurk perhaps?
<Nafallo> oh
<Nafallo> actually.
<ogra_> Nafallo, http://sourceforge.net/projects/chumby/ and http://sourceforge.net/projects/zurk/
<Nafallo> I've already binned that device :-P
<Nafallo> how pointless
<Nafallo> sorry
<ogra_> still does its job for me (being a nice start trek clock) 
<Nafallo> thought it was still hiding in a corner somewhere, but I didn't realise it would be at a tip ;-)
<ogra_> you could have proted ubuntu touch to it :P
 * ogasawara back in 20
<Nafallo> lol
<Nafallo> yeah... :-P
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg_> ppisati, https://bugs.launchpad.net/ubuntu/raring/+source/linux-meta/+bug/1164074/comments/6 , uploaded linux-meta
<ubot2> Launchpad bug 1164074 in linux-meta (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Fix committed]
<ppisati> rtg_: nice, thanks
<Gen0me> help : Run `bundle install` to install missing gems.
<Gen0me> Could not find pg-0.15.0 in any of the sources
<Gen0me> bundel install -> Bundler::GemfileNotFound
<Gen0me> help
<rtg_> Gen0me, try #ubuntu-devel
<bjf> jsalisbury, i think bug 1140716 can be removed from the hotlist. henrix will be submitting patches to the mailing list shortly
<ubot2> Launchpad bug 1140716 in linux (Ubuntu Quantal) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<jsalisbury> bjf, will do, thanks
<Gen0me> rtg_, ubuntu-devel -> not found
<bjf> Gen0me, ubuntu-devel is an irc channel on this same server, try  '/join ubuntu-devel'
<Gen0me> bjf, ;) thanks
<ppisati> apw: assuming 'ubuntu-raring' is an up to date ubuntu-raring got tree
<apw> ppisati, ?
<ppisati> apw: is './kteam-tools/devel/devel-config-summary --html ubuntu-raring foobar' the correct rune to invoke your review script?
<ppisati> apw: sorry i'm juggling between different things :P
<apw> ppisati, yep that would do it
<apw> ppisati, assuming the branch you want to check is checked out
<ppisati> apw: http://paste.ubuntu.com/5692711/
<apw> ppisati, ahh i fixed that somewhere one sec
<apw> ppisati, ok pushed, try that
<apw> (kteam-tools)
<rtg_> henrix, how about a pull request for the i915 regression patch sets ?
<henrix> rtg_: ack, will do that
<bjf> rtg_, you can still ack/nak and let sconklin deal with them since he's trying to turn the crank
<rtg_> bjf, I'm busy reading them
<bjf> rtg_, i wasn't trying to rush you
<rtg_> bjf, I just prefer pull requests when there are more then a couple of patches 'cause using thunderbird is a PITA
<bjf> rtg_, ack
<rtg_> sconklin, i915 patch sets applied. crank away.
<sconklin> rtg_: thanks
<rtg_> now, back to figuring out why mumble is borked
 * henrix is also a little bit nervous about the i915 patchset...
<rtg_> henrix, has it been tested to show that the regression is at least mitigated ?
<henrix> rtg_: no, not really. Chris commented on the bug 2 or 3 times identifying these patches as the solution
<rtg_> yeah, that bug report is getting to be kind of a mess
<henrix> rtg_: yep, there are definitely different bugs being reported there and its hard to follow all the discussions/reports
<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 April 16th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * henrix -> out for a bit
<rtg_> ogasawara, re: Minutes from the Ubuntu Kernel Team meeting, 2013-04-09. Where is that work item 'rtg       || hardware-r-delta-review' actually defined ?
 * rtg_ -> lunch
 * smb mischief accomplished -> EOD
 * cking EOT (rewind)
 * rtg_ -> EOD
<charlie> I just had another kernel panic from here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1165985 but using the upstream kernel instead. I've still got it displayed on the screen, and was wondering what would be the most useful information to transcribe from it before I reboot the machine.
<ubot2> Launchpad bug 1165985 in linux (Ubuntu) "13.04 - kernel panic - unable to handle kernel paging request ffffffec -- Dell Inspiron 9300" [High,Confirmed]
#ubuntu-kernel 2013-04-10
<ppisati> ah
<ppisati> it just crashed
<smb> yeah more fun
 * apw idly wonders what has happened to his history load for this channel, either that or you guys have said the same things 3 days in a row
<smb> Hm, I am not sure I normally look back 3 days to notice
<smb> apw, but my scrollback here does not seem to repeat
<apw> smb, heh no it is deffo a local issue, not saving scrollback or something
<apw> or bip has lost its mind, or something
<smb> always "or something"
<apw> biund to be indee
 * apw tries hands for type, yes much better than toes
 * henrix reboots
<henrix> brb
<hrw> hi
<hrw> does launchpad keeps all previous builds?
<zequence> apw: There's a bug in linux lowlatency headers. Bug #1165259. I think maybe Q and R are affected both. Had a look at debian/rules.d/2-binary-arch.mk, line 238 (Raring). But, unsure how to fix it from there.
<ubot2> Launchpad bug 1165259 in linux-lowlatency (Ubuntu) "13.04 Beta1 -- symlink missing for Linux Headers /usr/src" [Undecided,Confirmed] https://launchpad.net/bugs/1165259
<zequence> The symlinks become pointed towards linux-headers-<version>. 
<zequence> I wonder if the -lowlatency and -generic headers are the same.
<apw> zequence, i'll look into it, they should be similarly broken i expect
<hrw> when I boot 3.8.0-7.15 I get low res FB and no usb. ideas?
<hrw> it worked month ago and had working usb3 (which -13+ do not have)
<apw> zequence, ok i think i can see how this happens, and am fixing
<apw> ogasawara, did i hear you intended another upload 'soon' ie before tommorrow ?  if so i may have something i want in it
<zequence> apw: thanks
<ogasawara> apw: indeed, I was thinking of an upload today before kernel freeze tomorrow
<ogasawara> apw: feel free to drop anything on master-next that you'd like to see in
<apw> ogasawara, in progress now, making sure it doesn't break master
<rtg_> apw, just pushed some haswell audio patches
<rtg_> ogasawara, why are we in a yank to upload today ? nothing in master-next appears all _that_ important.
<ogasawara> rtg_: kernel freeze is tomorrow
<rtg_> yeah,so what? we just upload tomorrow ?
<rtg_> doesn't freeze take effect EOD ?
<ogasawara> rtg_: usually 2200 UTC
<ogasawara> rtg_: so we could upload tomorrow
<rtg_> translate that for me
<rtg_> thats like 4P my time
<ogasawara> rtg_: I always assumed that meant we had to have the builds done and the package out of -proposed by that deadline
<ogasawara> rtg_: so I always err'd on the safe side and gave us a day cushion
<rtg_> dunno. we're special though, so we can pretty much interpret as we please :)
<ogasawara> rtg_: indeed.  if we want to upload tomorrow I've no big problem with that either.
<rtg_> ogasawara, you just _know_ someone will come crying at the last possible hour, so waiting a bit shouldn't hurt.
<ogasawara> rtg_: ack
<rtg_> apw, re: bug #1073499. it appears that there are a boatload of USB options to enable. How do we reconcile them against our mainline kernel config set ?
<ubot2> Launchpad bug 1073499 in linux-nexus7 (Ubuntu) "please consider turning on all possible modules for external USB devices" [Undecided,In progress] https://launchpad.net/bugs/1073499
<arges> slangasek: hello. Are you still hitting bug 1157678 ? I can reproduce now using an xrandr command, and was going to file a new upstream bug.
<ubot2> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678
<apw> rtg_, i'll handle that in my review, i am doing that next anyhow
<apw> rtg_, we'll need to do the same to N4, though i hear bad things for our current kernel
<rtg_> apw, OK. I was just gonna start with the Raring armhf USB config set and cat it onto the nexus7, updateconfigs, etc
<apw> rtg_, well i would want to maintain the current ones, and one has to be a bit careful as the naming of osme of the usb things are dumb
<apw> ie they are in the menu w/o usb sounding names, and not in it with usb sounding names
<rtg_> apw, so perhaps I should wait until you've produced the config review ?
<apw> rtg_, i'll do that one first how about that
 * apw assigns the bug to self
<rtg_> sure, I'll stick your name on the bug as an assignee
<apw> ok ...
<rtg_> apw, have you been chatting with ppisati about the state of the N4 kernel ?
<apw> rtg_, when jani talks about the staging PPA is that something 'we' do or something they do
<apw> rtg_, i asked him, he hasn't used it :)
<rtg_> heck if I know
<rtg_> must be something they do
<apw> it was cking who was mentioning it was a bsod job
<apw> rtg_, ack
<apw> b == black
<rtg_> if figured that meant something pejorative
<apw> black-screen-of-death
<cking> the "oh no, I have to reflash it again" scenario
<smb> rtg_, He was there this morning
<smb> rtg_, And I cannot mumble an git push
 * smb just forgets always
<apw> ogasawara, ok pushed
<apw> ogasawara, when you are test building you might want to just check the header symlinks are right in the flavour specific packages... they looked right to me, but the extra eyes are always helpful
<rtg_> apw, that should get applied to unstable-3.9 as well
<rtg_> apw, P.S. I've been setting commits that only affect the generic debian rules to '(debian)' as opposed to '[Packaging]' just to have some consistency.
<apw> rtg_, ok
<james_w> hi everyone, my wife is affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716 do you know when the fix will be released to quantal? She'll probably run a  test kernel if it will be a while
<apw> rtg_, are you fixing my last commit ?
<ubot2> Launchpad bug 1140716 in linux-lts-quantal (Ubuntu Precise) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed]
<rtg_> apw, I have not.
<apw> rtg_, ok will do
<rtg_> james_w, bjf would be happy to answer your question.
<apw> rtg_, re-pushed
<james_w> thanks
<rtg_> james_w, or even sconklin sicne they know what the Q/A cadence is right now.
<rtg_> apw, pushed for unstable-3.9 as well
<bjf> james_w, we should have a new kernel in proposed today
<bjf> james_w, if it's Q that she's running
<james_w> it is
<james_w> thanks
<bjf> np
<bjf> james_w, it's in our ppa ready to be copied to -proposed when infinity gets to it (which won't be long)
<sconklin> Quantal built overnight, I'm preparing quantal backport now
<bjf> james_w, *don't* use our ppa please (that road leads to madness) though you could pull the .debs from there if you really wanted
<james_w> yeah
<apw> james_w, if you are going to expose those .debs then make a new ppa and copy them with binaries to it or something
<slangasek> arges: yes, I still see it with the drm-intel-nightly kernel; I haven't tested 3.8.0-17 yet, but if you're seeing it there I assume I will also
<arges> slangasek: filed a new upstream bug, will re-visit when I have some more time.
 * slangasek nods
<slangasek> arges: should we perhaps split my bug off from that one, since the original submitter hasn't really commented on reproducibility?
<arges> slangasek: possibly. I see two distinct bugs.
<ppisati> cking: http://paste.ubuntu.com/5695685/
<ppisati> cking: 3.4.y is ok wrt ftrace
<cking> ppisati, ok, it may be then a problem with that android kernel or the way I configured ftrace in the build (at a guess)
<ppisati> cking: yep, i'll spend a bit more time on it
<cking> ppisati, thanks, at least we know 3.4.y is reliable in this respect - which is a relief
<ppisati> cking: yep, let's see if we can fix it
<jsalisbury> bjf, henrix fyi: bug 1167114  I can bisect, but still gathering initial triage info.
<ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Linux 3.5.0.27.43 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
<henrix> jsalisbury: ack, thanks. i'll go take a look at that
<bjf> jsalisbury, ack. there will be a new Q kernel in -proposed shortly which should get tested there were a bunch of upstream commits and it's possible this got fixed
<bjf> jsalisbury, so that should be the first thing
<jsalisbury> bjf, henrix, ack.  thanks
<jsalisbury> henrix, bjf, I marked a couple of other bugs as duplicates as well.
<ppisati> my webcam and google hangout don't like each other... bah...
<apw> jsalisbury, it would be good to have the kernel version not the -meta version on that title
<ppisati> rtg_: ping
<rtg_> ppisati, yo
 * rtg_ -> lunch
<jsalisbury> apw, for bug 1167114, you mean 3.5.0-27 instead of 3.5.0.27.43 ?
<ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Linux 3.5.0.27.43 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
<rtg_> jsalisbury, yes
<jsalisbury> rtg_, ok, done.
<ppisati> rtg_: the nexus4 tree, it's actually a plain vanilla 3.4 kernel
<ppisati> rtg_: am i missing something?
<rtg_> ppisati, master-next
<ppisati> rtg_: ah ok
<rtg_> ppisati, I won't update master until we actually upload
<ppisati> rtg_: ok
 * rtg_ -> EOD
<skaet> bjf, just applied latest updates to 12.10 system, and its continually throwing out GPU errors now.   known problem?
<bjf> skaet, version number ?
<skaet> bjf, Linux 3.5.0-28-generic
<bjf> well, crap!
<bjf> infinity, ^
<bjf> infinity, i'm thinking we need to pull that kernel
<sconklin> that's the one we just pushed, all right.
<bjf> help me, help me, save me, save me
<sconklin> skaet: are you able to file a bug so we can see the logs?
<bjf> skaet, intel video?
<skaet> bjf, sconklin - filing bug,   and yes  snadybridge-m-gt2L   False GPU lockup IPEHR... etc.   will see if I can coax a bug out of this systemm
<infinity> That's not a new bug, if it's the lockup I'm thinking of.
<skaet> no,  its showed up as duplicate of existing.  But it just started up after the last update.
<bjf> skaet, i'll have a test kernel for you in a bit
<skaet> bjf,  thanks.   standing by.
<infinity> bjf: raring userspace and quantal kernels should get along basically fine, right?
<infinity> bjf: I have the dreaded sandybridge lockup hardware of doom here, I can give it a spin.
<infinity> (Whatever's finally been fixed in 3.8, I don't get the lockups anymore, but I used to get them constantly in Q and R both)
<bjf> infinity, we pulled 5 commits from 3.8/3.9 back to fix a regression. i'm suspecting them.
<infinity> Fun, fun.
<skaet> bjf,  system is getting part way through generating the bug, and then tripping over the error again, so nothing's going out from the automated system.   What logs do you want me to collect?
<bjf> skaet, just boot the previous kernel, do an apport-collect and fudge it by hand (i guess)
<bjf> skaet, are you seeing a chain of "you've experienced a lockup" dialogs that keep "interrupting" each other?
<bjf> skaet, if you are then try deleting everything in /var/crash/ and rebooting
<skaet> bjf,  yes,  seeing that chain.   will do.
<skaet> bjf,  rebooted,  behaving better so far.
<infinity> skaet: So, that might have actually been the apport bug/misfeature where if you've at some point in the past dismissed (or minimized, or something) a report dialog, you then don't get any new ones until reboot.
<infinity> skaet: And what it was actually doing was grinding your machine to a halt trying to report all the OLD lockups from your previous kernel.
<infinity> But time will tell.
<infinity> skaet: Under the previous kernel, did you ever have moments where all your windows would just freeze for a bit inexplicably, and then start working again after a few seconds/minutes?
<infinity> (Or, potentially, the desktop seemed to "freeze", but a VT switch made it happy again, that sort of thing)
<skaet> infinity,  yes, there were a couple of times like that,  esp. when using google docs from firefox.
<infinity> Yeah.  Probably should have gotten you to check timestamps on /var/crash/* before deleting them, but my bet is that apport was reporting old lockups, not new ones.
<infinity> On boot, the first thing update-notifier does is check /var/crash for unreported crashes and unhelpfully spawn a few dozen python processes to report them all in parallel.
<infinity> Which, it turns out, is a bad idea.
<infinity> skaet: Anyhow, if you still get the occasional lockup (though, hopefully not), that's likely not a regression.  If you start seeing a ton of them, yell at bjf to go a-revertin'.
<skaet> infinity, indeed.   I saved off the logs before deleting,   xserver-xorg-video-intel.2013-04-10_11:49:14.495521.uploaded  <-- which was from before I updated this afternoon.
<infinity> Ahh, good deal.  That lends some peace of mind to my hypothesis.
<bjf> skaet, i'll have a kernel standing by if you start seeing true lockups with this version
<infinity> bjf: She may well still see lockups, since she clearly did before.  It's the frequency that should be a concern. :)
<skaet> bjf,  thanks,  if it starts up again - you'll hear from me. 
<infinity> bjf: (Though, I'll be overjoyed if that lockup bug is actually fixed in the new kernel)
<skaet> infinity,  might be worth putting out some sort of notice about this though,  since I doubt I'll be the only one encountering it.
<skaet> ??
<infinity> That apport misfeature has existed for ever.  It's just unfortunate when it bites people who have a bunch of old reports lying around. :/
<skaet> yeah but the combination of that misfeature and the latest kernel is quite ugly from a user's perspective... :P
<earthling_> hello, I have a question. I notice in security updates there are header files for 3.2... and 3.5 kernel versions. Should I install both updates?
<infinity> Sure, my point is that it may have happened to others on the last kernel reboot, or the one before.
<infinity> earthling_: Which kernel are you running?
<earthling_> 3.5
<earthling_> on Precise
<infinity> earthling_: Do you have linux-generic-lts-quantal installed?
<infinity> earthling_: If so, that'll be keeping your headers and kernel in sync.
<infinity> earthling_: If not, you should probably install it.
<earthling_> I'm running precise 12.04.2 LTS
<infinity> earthling_: Right, I mean the package.  "apt-get install linux-generic-lts-quantal"
<earthling_> hmm
<earthling_> I did a standard install 2 weeks ago
<infinity> Then you probably have that package installed.
<infinity> Unless you forcefully removed it at some point.
<earthling_> installed through update manager?
<infinity> So, I guess the real point here is that security updates will upgrade things correctly without you manually installing packages.
<earthling_> I'm looking at history
<infinity> Oh, wait.  Do you mean that you have both 3.2 and 3.5 headers installed and update-manager is upgrading both?
<earthling_> march 27 yeah
<infinity> That would be either a bug on your end, or ours.  But you can safely remove the 3.2 ones if you're using 3.5
<Sarvatt> speaking of that, i noticed old headers were getting updated in 12.04.2 too
<earthling_> infinity, when I access the grub menu there is no version 3.2
<Sarvatt> after a fresh install with no 3.2
<infinity> Sarvatt: Curious indeed.  I took great pains to make sure the 3.2 headers weren't on the install media, but maybe something went weird.
<infinity> Oh.
<infinity> Or it's a dkms module pulling them in.
<infinity> We haven't yet SRUed them all to get rid of that stupid dependency.
<infinity> That's probably it.
<infinity> earthling_: So, the short answer is "it's not a big deal".  The longer answer is "you can remove the 3.2 header packages, just make sure they don't seem to remove something else, like a driver package, but it shouldn't".
<infinity> And I'll have to scour the archive to get this all sorted, if we still have a few broken packages.
<earthling_> ok, that makes sense
<earthling_> hmm update manager a bit frozen or slow
<earthling_> restarted, its fine
<earthling_> rebooting, thx
<maxb> Huh, this is weird. Some of my boot items are not visible in efibootmgr - neither are they visible in /sys/firmware/efi/vars/ - yet they are in /sys/firmware/efi/efivars/ !
<maxb> Although trying to read the files in efivars/ results in the processes getting SIGKILL or SIGSEGV
<Kano64> hi, just build unstable-3.9 with uvd patches, but the name is uncommon
<Kano64> cmd: CPU[x Intel Core i7-3770S @ clocked at 1600.000 Mhz]  Kernel[Linux 3.9.0-0kanotix1-generic x86_64]  Up[-4min-]  Mem[-771.7/7952.8MB-]  HDD[-188GB(48%used)-]  Procs[-217-]  Client[Shell wrapper]
<Kano64> why is -generic at the end now?
<Kano64> hm generic was always at the end, but never the kanotix1 in the middle
<Kano64> every kernel has kanotix1 in the changelog here
<infinity> Kano64: Did you used to version it as 0.kanotix1 instead of 0kanotix1?  The kernel packages split on '.' and slap the first part in the kernel version, the latter part is the build number.
<infinity> s/slap/slaps/
<Kano64> no, since when is a . needed?
<infinity> Well, if the intent is to get abi.build, always.
<infinity> For example:
<infinity> linux (3.8.0-17.27) raring; urgency=low
<infinity> Linux cthulhu 3.8.0-17-generic #27-Ubuntu SMP Sun Apr 7 19:39:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<infinity> Your 0kanotix1 is all being tacked on to extraversion.
<Kano64> usally only in the changelog
<Kano64> no extra package for 3.9?
#ubuntu-kernel 2013-04-11
 * apw fights hanging X after resume ...
<apw> give ... me ... my ... computer ... back
 * smb does not want it
<apw> arn't you mean today
<apw> ppisati, moin
<ppisati> apw: hey
<apw> ppisati, i take it we are keeping linux-ti-omap4 in raring as well as -generic ?
<ppisati> apw: nope, it's going away
<ppisati> apw: i think rtg already wiped it
<smb> apw, today?
<ppisati> apw: we copy the Q/omap4 kernel to the R archive for therelease
<apw> it is still in raring-proposed right now
<apw> ppisati, so we will have linux-ti-omap4 in raring, just the quantal one
<ppisati> apw: yep
<apw> ppisati, is it binary drivers stopping us using -generic ?
<ppisati> apw: yes :(
<ppisati> apw: pvr-omap4
<ppisati> ogra_: can we have abootimg builtin by default?
 * henrix will be away for a while
<ogra_> ppisati, buildin ? in phablet ?
<ppisati> ogra_: if it would be for me, i will seed it in every arm/android images
<ppisati> ogra_: since we need it everytime we update a kernel
<ogra_> ppisati, +1 ... i'll talk to rsalveti once he is up to add it to the seeds
<ppisati> ogra_: nice
<ogra_> i'm not sure it works on all devices though
<ogra_> i.e. i cant make it work on my galayx S2 here 
<ppisati> ogra_: nexus4/7, it works
<ogra_> yep, i know
 * ppisati has got the nexus4 kernel to work
<ppisati> allelujah
 * ogra_ applauds
 * ppisati goes to trim the config changes
<psino> looking at https://lkml.org/lkml/2013/4/10/757 and https://lkml.org/lkml/2013/4/10/756, the two commits are in a "linux/kernel/git/tip/tip.git" repository, but does that mean those commits have landed in "upstream linux kernel", or are they still pending more review/verification?
<apw> psino, if they are in tip, they are not yet in linus' tree which is where we like them to be
<psino> is the tip merged into linus' tree regularily?
<apw> henrix, bjf, sconklin, just a heads up i have fixed up the relationship between linux-ti-omap4 in quantal and raring so you should see a big jump from pending to not-affected in that column
<apw> psino, it is merged in the merge windows generally, so every 10 weeks or so
<apw> psino, well sub branches which are ready from it are merged in each merge window
<psino> so, as it stands now, I might have to wait up to ten weeks for those commits to make it into linus' tree, and then a ubuntu kernel build?
<apw> psino, that would be the implication indeed
<apw> psino, and to be honest as raring has forked off onto 3.8.x stable if it doesn't go there (and it is not clear it would from the commit message) then unless someone asks for it and says why it is worth carrying it won't make raring
<henrix> apw: i believe you're referring to CVEs, right?
<apw> henrix, yes the cve matrix
<henrix> apw: ack. thanks
<apw> henrix, bjf, sconklin, just a heads up i have fixed up the relationship between linux-ti-omap4 in quantal and raring so you should see a big jump from pending to not-affected in that column (of the CVE matrix)
<apw> better
<henrix> heh
<jwi> psino: x86/urgent sounds like a branch for rc-fixes, so maybe they'll take the short route and land in 3.9 before it's released
<apw> even if they hit 3.9 that is not going into raring any time soon
<psino> ok, so the bug manifests in kernel crashes on current 13.04 randomly when starting/stopping lxc containers. without the patch, running lxc on a kernel is pretty much like playing russian roulette with your server. it might work, but it might crash.. fedora accepted the original patch pretty much straight away, but I don't think anyone has been willing spearhead a similar approach for ubuntu (yet). as such, it would seem that my options regarding lxc
<psino>  either 1) go through the process of getting the patch into an ubuntu-specific kernel change (creating a lp-ticket etc?) or 2) build a custom kernel or 3) change to another distro which already has this patch
<psino> if it's not obvious I mean no offence to ubuntu or the ubuntu kernel team with the above. I'm just not very familiar with the process of getting patches into the kernel, nor building my own kernel, so it's uncharted territories for me.
<psino> out of these options, building a new kernel sounds like the easiest route, as changing distros has too many ripple effects through my infrastructure
<apw> psino, well if it is that bad i am sure the server team would be interested anyhow
<apw> psino, but yes, i would suggest fileing a bug with the details 'ubuntu-bug linux'
<apw> and let me know the number so i can investigate
<psino> I'm pretty sure they'll ask about "have you tested the patch", so that's what I'm doing right now -- trying to build a new kernel with the patch applied
<jodh> apw: are you still seeing bug 1103406 on your server?
<ubot2> Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed] https://launchpad.net/bugs/1103406
<apw> jodh, i was seeing that on one of my servers ?
<jodh> apw: I thought so as initially it looked like an upstart issue?
<jodh> apw: if not, can anyone offer any further thoughts on it.
<apw> jodh, it is unclear from the last comments wehter the issue is present with current kernels
<apw> jodh, or are you saying its broken in non-recovery and ok in recovery
<jodh> apw: I *think* I saw it in recovery mode once or twice, but I'll do some more testing. It's certainly 99% more reliable booting in recovery than non-recovery (which is almost guaranteed to fail on the 1st attempt from cold boot).
<apw> jodh, and fail how
<apw> jodh, 'kernel disables console output' what does that mean
<jodh> apw: I get no screen output - just a blank purple screen. I'm just checking if it boots far enough to get a wifi connection...
<jodh> apw: usb serial gives no output either.
<apw> so purple would be the handoff screen
<jodh> apw: it hasn't booted (far enough) to get on the network and, helpfully, none of the keyboard lights work when this problem is hit either :(
<apw> does editing the kernel commandline to remove vt.handoff=7 from the normal boot line, make the issue go away
<jodh> apw: let me check...
<apw> jodh, it is known to affect some h/w and that h/w can then be blacklisted
<jodh> apw: it doesn't specify vt.handoff=7 at all.
<apw> jodh, no of course it is added later ...
<apw> there is set gfxsomething=keep, change that to =text
<jodh> apw: k
<apw> shows you just how long it is since we had issues with this, that it has gone from my memory
<apw> jodh, that said in your menu mode, it still ahngs and display has successfully been initialised
<ppisati> more mumble fun...
 * smb was surprised it lasted that long
<jodh> apw: sorry - just updating to latest kernel - problem still persists. I only have gfxmode $linux_gfx_mode in the non-recovery kernel
<apw> change that to gfxmode text
<jodh> apw: 3 successfuly boots with "text", but the 4th failed (hangs with kernel splat over my menu).
<apw> well kernel splat sounds useful ... piccy
<jodh> apw: it's identical in content to the image already on the bug: https://launchpadlibrarian.net/129183769/IMG_0541.JPG
<jodh> apw: although I've now got a lovely purple background rather than the old blue :-)
<apw> jodh, so nothing useful then, just usb async aquirey
<jodh> apw: it's kinda surprising that I'm the only person running raring on this h/w and seeing the problem.
<apw> jodh, that noone but you is testing is no supprise to me
<apw>  /b 34
<jodh> apw: ru surprised that I'm surprised it's no surprise? :)
<apw> jodh, frankly yes :)
<apw> we don't need to test now, we have rolling stability guarenteed by ... erm ... testing
<jodh> apw: would dmidecode output be of use to compare to anyone with a working macbook air maybe?
<apw> jodh, if you know of a working macbook air ... sforshee you still ahve one ?
<sforshee> apw, yeah I still have an air
<apw> sforshee, any issues booting it ?
<sforshee> apw, I've got raring on it, updated yesterday and no issues
<apw> jodh, cna you point sforshee to your bug, sforshee perhaps you can compare your machine to his (which is a crashy bag of dung)
<sforshee> apw, there were some problems a couple of weeks ago due to efivars stuff
<jodh> sforshee: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1103406
<ubot2> Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed]
<jodh> sforshee: my system is current but booting is still highly unreliable.
<ppisati> i think we should tackle this: http://www.theregister.co.uk/2013/04/11/dell_sputnik_review/
<sforshee> jodh, mine is the newer model than yours. We had one of your model floating around in the company, not sure where it ended up though.
<sforshee> also I think bjf has that model but in the 13-inch
<jodh> sforshee: I've added dmidecode output to the bug - could you compare with your system.
<jodh> sforshee: fwiw, I dual boot using rEFIt.
<jodh> sforshee: I think I pulled the short straw. Base "dung" model'n'all :)
<sforshee> jodh, already compared. You have the 4,1 which iirc is the sandy bridge model. I have the 5,1 which is the ivy bridge.
<sforshee> I dual boot, but not with refit
 * sforshee reads the backscroll to avoid asking duplicate questions
<sforshee> jodh, at this point I'd probably suggest a bisect
<rtg_> ogasawara, actually, I was gonna question David on that patch. it seems over engineered to me.
 * rtg_ works on ALPS pull request
<ogasawara> rtg_: I thought it seemed fairly well contained and tested
<ogasawara> rtg_: it's not too late to yank it if you have reservations
<jodh> apw: I've just found http://irclogs.ubuntu.com/2013/01/22/%23ubuntu-kernel.html#t14:17 where you seemed to be having the same issue as I'm having on the macbook.
<rtg_> ogasawara, in that it only affects haswell. however, why not just force the D0 and mute settings rather then interrogate the HW ? less code I think.
<jodh> sforshee: tell me there's a kexec bisect tool please!! :-)
<ogasawara> rtg_: it's a valid question, want me to punt it till we get clarification?
<rtg_> ogasawara, if we can get ahold of him today.
<rtg_> ogasawara, by collapsing the code into a more definitive form I might worry about audio artifacts such as pops and clicks whilst programming those registers. thats really what I'd like to confirm from him.
<sforshee> jodh, nothing I know of, but one of us can feed you the builds if you want. jsalisbury is quite adept at running bisects.
<jodh> sforshee: cool - thanks.
<apw> jodh, there you say you are sure i am not having the same issue
<apw> jodh, that issue as i recall was not dead kernel side anyhow
<sforshee> jodh, to start you probably want to identify when the regression appeared upstream. We already have builds for all the -rc kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/
<sforshee> jodh, what's the last ubuntu kernel version you know to work?
<jodh> sforshee: that's a problem - I don't think any of the raring kernels I have installed work reliably - this is a test machine so I'm not using it daily.
<sforshee> jodh, oh. Well having a known good kernel is kind of critical to running a bisect ...
<jodh> sforshee: the quantal kernels worked fine :)
<sforshee> jodh, quantal kernels with everything else raring?
<smb> henrix, congrats for making it to lwn. :)
<henrix> smb: hmmm? me? what have i done wrong this time?
<henrix> :)
<jodh> sforshee: no - pure quantal install. I think the ideal would be we find someone else with the identical hardware to compare notes with.
<smb> henrix, Nothing, just noted that this time they acknowledged us/you doing a stable tree
<sforshee> jodh, well like I said we've got one of those machines somewhere in the company, if we can find it. Unless that's the one you have ;-)
<henrix> smb: oh, ok. yeah, that was last week, wasn't it?
<jodh> sforshee: mine is indeed a company machine :)
<smb> henrix, Yeah, if you have not messed up the paid subscription thing
<sforshee> ah
<sforshee> so we found it :-)
<henrix> smb: yeah, i saw that last week. haven't took a look at this week yet
<smb> henrix, I would not know until next week :-P
<apw> ogasawara, poke me when you have pushed the propose upload to the repo, so i can get the lowlatency in sync pls
 * apw moves
<ogasawara> apw: ack
<sforshee> jodh, well the first step to bisecting would be to find some kernel which boots fine with everything else being the same
<Nafallo> hi :-)
<Nafallo> anyone up for building me a test-kernel with a one-line change in a certain module? ;-)
<Nafallo> or would be willing to instruct me how I build this thing without having to build the whole kernels+flavours?
 * ogasawara back in 20
<arges> Nafallo: hi. https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might be a place to start
<rtg_> ppisati, nice job on the N4
<ppisati> rtg_: thanks
 * rtg_ rebuilds a SabreLite after disk failure
<cking> rtg has all the fun
<rtg_> cking, the dang thing ran unattended for about 6 months.
<ogra_> hmm
<rtg_> it was a good drive, SATA Seagate Momentus
<ogra_> ogra@anubis:~$ ssh sabre
<ogra_> ssh: connect to host sabre port 22: No route to host
<ogra_> *sniff*
<ogra_> seems mine died too 
<rtg_> ogra_, the rootfs is OK. I'm just having to rebuild a raring chroot that was on the external SATA
<ogra_> i must admit i havent used mine in months ...
<smb> rtg_, always very annoying. burnt one drive last month, too
<ogra_> the chromebook with USB 3.0 stick is so much faster
<rtg_> I've been doing full test builds on it
<ogra_> yeah, me too until i got a chromebook
<rtg_> ogra_, aren't the chromebooks kind of expensive ?
<ogra_> $299
<rtg_> hmmm...
<ogra_> $349 for the 3G model
<rtg_> maybe if I start whining right now ogasawara will take pity on me :)
<ogra_> and it comes with a flashplayer the chromium browser in ubuntu can happily use
<ogra_> if we all get chromebooks it might finally make sense to roll an image for them :) 
<ogra_> (especislly since we already have the kernel source in the distro (or at least will sonn have it) ... its identical to the nexus10)
<ppisati> *lol*
<ppisati> turning of function tracing in the nexus4 kernel results in an infinite reboot loop
<ppisati> *turning on
<apw> ppisati, heh ...
<ppisati> and we don't know why
<rtg_> ogasawara, just pushed a patch for https://bugs.launchpad.net/intel/+bug/1031173
<ubot2> Launchpad bug 1031173 in intel "[Feature] Haswell ULT - SATA DEVSLP (aka LPM) host side enabling" [Undecided,New]
<ppisati> because there's no srial
<ppisati> is it the kernel? the binary gfx driver? or what else?
<ogasawara> rtg_: ack
 * apw whines about the kernel partition size on the n7
<ogra_> haha
<ogra_> welcome to my world 
<ogra_> you need to cur down the initrd 
<ogra_> apw, http://paste.ubuntu.com/5698794/
<ogra_> (from the ac100-tarball-installer source)
<ogra_> s/cur/cut/
<rtg_> ogasawara, wanna have a look at git://kernel.ubuntu.com/rtg/ubuntu-raring.git dw-dma-lp1031163 ? I'll be back in a few minutes. gotta house full of family that are preparing to take off (finally).
<davmor2> ogra_: what would be nice is a clean up script that remove all but, the shipped kernel, the current kernel and the last kernel. then there are only ever 4 kernels on the system, the first one, the one you just upgraded from, the one you just installed and one about to be deleted :) 
<ogra_> davmor2, that doesnt help if your bootimg partition can only carry 8M in total (including the initrd) :)
<ogra_> note we're talking about android partitioning
<davmor2> ogra_: it would at least cut it down a bit  :)
<ogra_> and the bootimg is a raw space on the MMC wheer you dd your kernel/initrd to and that you cant resize
<davmor2> ogra_: ouch
<ogra_> yeah, it would surely save space on the rootfs
<Nafallo> davmor2: current kernel pre-ksplice? ;-)
<ogasawara> rtg_: looking now...
<rtg_> ogasawara, they appear to be well isolated.
<rtg_> the 2 back ports were trivial context changes
<ogasawara> rtg_: and pretty straightforward too (at least the first half I've looked at)
<ogasawara> rtg_: push it
<rtg_> ogasawara, ack
<ppisati> brb
<rtg_> ogasawara, slapped a bow on raring master-next. gonna quick build test and upload. looks like we've got everything thats gonna make it in time.
<ogasawara> rtg_: awesome, thanks
<joshhunt> i've got a question about USN-1793-1. the way in which the usn patch is delivered seems to have deviated in this usn from the std way of doing things. https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64
<joshhunt> we are used to received a cumulative diff to apply to a vanilla kernel, but in this case there appears to be an incremental diff to be applied to some non-vanilla base tarball
<joshhunt> looking at the other kernel usns released this week they are using the method i'm used to
<rtg_> joshhunt, it should be the diff against the kernel version in the updates pocket
<joshhunt> 3.5 ex: https://launchpad.net/ubuntu/+source/linux/3.5.0-27.46
<Nafallo> rtg_: hrm. I'm just testing a one-liner for a new card I picked up today. worth waiting to support a card that has been out for a few years?
<Nafallo> I've just added the pciid to the module
<joshhunt> rtg_: so are you saying the 3.2 usn's format is correct?
<rtg_> Nafallo, send the patch to the k-team list with supporting test documentation, etc
<joshhunt> rtg_: if so, do you know why there is a deviation from the normal process with this usn?
<Nafallo> rtg_: okay. how long do I have? :-)
<rtg_> Nafallo, mere moments
<Nafallo> rtg_: building headers+generic on a HP mini...
<rtg_> joshhunt, perhaps we should get jjohansen involved since he does the USNs
<joshhunt> rtg_: is there a better channel i should be asking this question?
<Nafallo> rtg_: to be fair, if this works it could just go in -updates I guess :-)
<rtg_> joshhunt, no, this is the likely the right place.
<joshhunt> rtg_: ok cool, thanks
<rtg_> Nafallo, yeah, its getting close to the wire. I plan to upload within the next hour or two
<Nafallo> rtg_: pretty sure I'm far from there... at around   CC [M]  fs/squashfs/lzo_wrapper.o
<jjohansen> joshhunt: as rtg_ said the USNs aren't a cumulative diff against vanilla, they are against the kernel in the updates pocket. It just works out that they usually can also be taken and applied against vanilla
<Nafallo> rtg_: so yeah, post-release update should be fine.
<joshhunt> jjohansen: i've been pulling usns for a while and this is the first that looks like this, which is why i'm asking the question.
<joshhunt> jjohansen: kernel usns. also the 2.6.32 and 3.5 appear to be using the old format
<jjohansen> joshhunt: it has happened before
<jjohansen> joshhunt: old format?
<joshhunt> jjohansen: old format may be a bad way to say it, but vanilla + diff
<joshhunt> jjohansen: it appears that 3.5 offers vanilla + diff, and also the incremental diffs
 * ppisati -> EOD
<jjohansen> joshhunt: like I said they have never been vanilla + diff, they are always done against the ubuntu kernel in updates. It just so happens that they usually work out so that they will apply against vanilla
<joshhunt> jjohansen: maybe i'm wording it wrong, but please take a look at the 3.5 usn here: https://launchpad.net/ubuntu/+source/linux/3.5.0-27.46
<jjohansen> joshhunt: we pull in the majority of the updates from upstream sources against the vanilla tree and seldom have to modify them
<joshhunt> jjohansen: under downloads there are 3 files, 3.5.0.orig.tar.gz, and a diff, along with the dsc
<joshhunt> jjohansen: for 3.2 https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64 it is different
<joshhunt> jjohansen: i would call linux_3.5.0.orig.tar.gz a vanilla kernel and linux_3.5.0-27.46.diff.gz the diff
<joshhunt> jjohansen: for 3.2 there's a kernel in this format: linux_3.2.0-40.64.tar.gz
<joshhunt> jjohansen: and a dsc file
<rtg_> jjohansen, that looks like an upload botch. sconklin ^^
<rtg_> missed the orig tarball ?
<joshhunt> rtg_:yes no orig tarball and no cumulative diff against orig
<sconklin> looking
<jjohansen> joshhunt: ah got it you are looking at a packaging issue. I was totally coming at it from a how we apply the patches and dev the USN
<joshhunt> jjohansen: ok cool. the 3.2 usn's download files are non-std compared to what i'm used to seeing. which is what i'm asking about.
<joshhunt> jjohansen: sorry i didn't make that clear originally.
<rtg_> joshhunt, looks like a mistake on our part. it ought to be back to normal for the next upload
<sconklin> rtg_: weird, I have the orig present and I don't think I changed anything in how I prep. Let me do a test
<joshhunt> rtg_: cool, will you repost the usn? or at least update the page?
<rtg_> joshhunt, likely not. it is what it is for the present. you cannot correct these kinds of errors once upload to the archive.
<jjohansen> joshhunt: we could update the USN text but the upload can't be changed
<rtg_> joshhunt, the kernel is correct. its just the packaging thats a little screwed.
<joshhunt> rtg_: is there any way I can get the diff? this becomes a large pita for our update process
<rtg_> joshhunt, perhaps sconklin could provide you with a diff once he figures out what went wrong with the stable process.
<sconklin> joshhunt: I can probably rebuild it with the diff, it just won't get uploaded that way
<jjohansen> joshhunt: You can pull the git tree and get either an incremental diff from the previous update or the full diff from the base kernel
<sconklin> I'm investigating now
<joshhunt> jjohansen: we are moving to doing git pulls, but have noticed that the diff and git tags aren't exactly the same (i think maybe it's firmware) and so i can't do that for this particular kernel ver. we've moved to git pulls for 3.5
<joshhunt> sconklin: if you can provide me a diff i'd really appreciate it
<sconklin> joshhunt: no problem, it'll take a few minutes
<rtg_> sconklin, -41.65 looks like it was correctly packaged.
<sconklin> rtg_: I think I know what happened, I need to package twice more to confirm
<rtg_> sconklin, -40.64 is definitely hosed.
<rtg_> joshhunt, try http://kernel.ubuntu.com/~rtg/linux_3.2.0-40.64.diff.gz
<sconklin> rtg_: I can't reproduce the error. But the latest one I packaged is ok.
<rtg_> sconklin, does the packaging script check for the orig tarball ?
<sconklin> there is no packaging script, it's just the dpgk command line. I'll check whether out post-build source package checker tests for that
<rtg_> sconklin, that should definitely be a check somewhere in the process.
<sconklin> rtg_: actually, we ~just~ switched to a dpgk command line that does warn you in the case of a missing orig. And it was that release that I noticed it on. But I thought that I had fixed it and uploaded the fixed package, and not the bad one.
<sconklin> so fyi:
<sconklin> dpkg-buildpackage -S -us -uc -sa -rfakeroot -I -i -v<whatever>
<sconklin> will NOT stop, and the warning is buried in out put.
<sconklin> but:
<sconklin> debuild -S -I -i -uc -us -sa -v<whatever> will
<sconklin> kamal helped me out on that 
<rtg_> sconklin, so debuild bitches if the orig tarball is not present ?
<sconklin> rtg yes
<sconklin> and also runs lintian, which is a good idea
<rtg_> interesting, I did not know that
<sconklin> what you get from debuild if the orig is missing is this:
<sconklin> This package has a Debian revision number but there does not seem to be
<sconklin> an appropriate original tar file or .orig directory in the parent directory;
<sconklin> (expected one of linux_3.2.0.orig.tar.gz, linux_3.2.0.orig.tar.bz2,
<sconklin> linux_3.2.0.orig.tar.lzma,  linux_3.2.0.orig.tar.xz or ubuntu-precise.orig)
<sconklin> continue anyway? (y/n) 
<kamal> rtg_: ... y'know how every six months or so, I start whining about "can we get an orig tarball?"   ;-)
<sconklin> So apparently I caught that, fixed it, and then uploaded the wrong package during the .64 cycle
<rtg_> kamal, don't I _always_ do it as soon as you whine ?
<sconklin> All credit goes to kamal for educating me on this
<kamal> rtg_: and I thank you for that!   (as does my debuild command, which no longer stops to make me type 'y')!
<joshhunt> sconklin: i got knocked offline for a while. please ping me when you have the diff avail. i appreciate your help.
<rtg_> joshhunt, http://kernel.ubuntu.com/~rtg/linux_3.2.0-40.64.diff.gz
<sconklin> joshhunt: http://people.canonical.com/~sconklin/ 
<sconklin> heh either one
<joshhunt> thanks guys
<sconklin> joshhunt: actually, use rtg's
<joshhunt> i really appreciate it
<joshhunt> sure
<sconklin> Mine is from this week's build
 * rtg_ -> lunch
<manjo> rtg_, should the dkms package have a dependency on kernel headers ? seems like on raring they don't have any dependency 
<manjo> rtg_, so if I install virtualbox for instance it fails to register the dkms modules coz the headers were not installed 
<manjo> rtg_, seems like if you have dkms then you might need kernel headers anyways
<apw> manjo, nope they should not
<apw> manjo, as there is no way to specify the right ones ... you should have headers installed on any raring install
<manjo> apw, should or should not ? 
<apw> manjo, unless you installed when there was a installer bug which deinstalled them
<manjo> kernel headers (linux-headers-3.8.0-17-generic) was not installed in my case 
<apw> manjo, dkms packages should not have header dependancies.  there is no way to specify correct dependancies
<manjo> I had the same problem when I installed 11.10 as well 
<manjo> apw, ok I see what you are saying 
<apw> manjo, a correctly installed system will have linux-generic or wahtever installed which installs the headers
<apw> this is a change for raring, and there was an early raring installer bug which removes the headers incorrectly
<manjo> apw, but the issue still remains that I did not have kernel installed ... it might be the installer bug issue then 
<apw> you should have linux-image-<flavor> and linux-headers-<flavour> installed, anything else is a bug
<apw> if you install now it should leave them installed, it was a window in early raring where they got zapped
<manjo> apw, ok I did an upgrade on this machine from 12.10 to 13.04 yesterday 
<apw> i am less clear what an update should do, if the headers were not installed before upgrade
<apw> i would suggest a bug against update-manager on this so it can be investigated
<manjo> apw, ok sound good I will open a bug 
<rtg_> manjo, yeah, what apw said
<manjo> :) 
<rtg_> ogasawara, jsalisbury: bouncing gomeisa for kernel update
<jsalisbury> rtg_, ack
<ogasawara> rtg_: ack
<rtg_> jjohansen, kamal: rebooting tangerine for kernel update
<kamal> rtg_: thanks
<tedg> Hey folks, I'm hearing there is no standard way to expose an ambient light sensor.
<tedg> Which seems a bit crazy to me.  Is that true?
<tedg> Is there a good reason or just a "no one's bothered" reason?
<rtg_> sforshee, ^^
<sforshee> tedg, there's an iio driver subsystem in staging that I think targets devices like this
<sforshee> I've seen some android devices are using this for ALS devices
<tedg> Hmm, found an article from 2011: http://lwn.net/Articles/433601/
<tedg> Yeah, it seems to be very fractured on the Android side of things as well.
<sforshee> well, lot's of things are very fractured in Android :-P
<tedg> This looks more recent, which implies they're on the kernel schedule: http://blog.gmane.org/gmane.linux.kernel.iio
<sforshee> tedg, iio _is_ in mainline, it's just in the staging tree right now
<tedg> sforshee, Educate me a bit on what that means.  Does that mean it's in the ubuntu kernel?
<sforshee> tedg, the source is there at least
<Nafallo> I don't quite get what the staging tree does either. looks like kernel-experimental :-P
<sforshee> oh, maybe the core isn't in staging anymore
<sforshee> there's a drivers/iio now
<sforshee> tedg, raring at least has iio enabled in the kernel
<tedg> sforshee, Ah, cool!
<sforshee> tedg, however that doesn't necessarily mean that every ALS driver in the kernel is using it though
<tedg> sforshee, Sure, but it means we can start to talk about it as a feature.  And handle those that don't as exceptions.
<tedg> sforshee, I can look, but do you have a quick way to figure out if there are any that do?
<sforshee> tedg, well there's drivers/iio/light which looks promising
<sforshee> and drivers/staging/iio/light
 * tedg is trying to figure out how to get a kernel :-)
<sforshee> source you mean?
<tedg> Yeah, using apt-get source now.
<tedg> Figured for one-off that makes sense.
<sforshee> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git
<sforshee> for example
<tedg> Ha, no I'd rather use apt than have to use git :-)
<tedg> Hmm, chip numbers aren't as useful as I'd hoped.
<GrueMaster> Question for one of the kernel gurus.  I need to build a custom kernel package with minor modifications, but I want this modified kernel as a separate package vs default.  I.e. -custom instead of -generic.  What's the easiest way to do this with the apt-get source linux-image-`uname -r` package?
<rtg_> GrueMaster, there isn't an easy way to create a new flavour, but you can create a relatively unique version by appending (for example) ~grue1 to the version in debian.master/changelog
<rtg_> an alternative is to 'make deb-pkg' which will give you a completely non-conflicting package name
 * rtg_ -> EOD
<GrueMaster> thx
#ubuntu-kernel 2013-04-12
<joshhunt> sconklin: around?
<psino> I've tried building an ubuntu kernel with a local version string (both by configuring the local version in the kernel menu config (general -> local version) and by using dch, but both methods give me the following error: https://gist.github.com/nkvoll/46509fa1aaaeda5441ef
<psino> i've tried searching for a solution, but I've been unable to find a way to build a kernel with a custom name so that I can distinguish it from the default, official one
<psino> I've successfully built a kernel without modifying the name in any way (following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel), but it makes my custom kernel a bit hard to differentiate from the official ones
<apw> psino, so you changed the flavour name ?
<apw> 3.8.0-17-generic-mmu
<apw> and i would guess you didn't change the list of flavours?
<smb> psino, You probably just want to modify the version number in the debian.master/changelog
<psino> first I tried only changing the local version during editconfigs, it failed, then I used "dch --local -mmu-patched" (which seems to ignore the -patched-part)
<apw> psino, what is the version number as shown in the top of debian.master/changelog
<psino> linux (3.8.0-17.27) raring; urgency=low
<apw> dch doesn't really work with the kernel, cause debian/changelog is not the master
<smb> So  change that into 3.8.0-17.27+mmupatched
<apw> psino, using a - in that string is destined for failure
<psino> ok, do I need to do anything else other than change the first line in the changelog?
<apw> psino, to get a unique version, only to clean ... debian/rules clean
<smb> as long as the change itself would not change the abi, but you will notice that
<psino> it probably doesn't, since I managed to build a working kernel (booted on two different instances) when I didn't change the version string
<ppisati> lp 1168039
<ubot2> Launchpad bug 1168039 in linux (Ubuntu) "highbank: network corruption" [High,Confirmed] https://launchpad.net/bugs/1168039
<apw> ppisati, i suspect you will have to build him some kernels with highbank config for that bisect to work
<ppisati> apw: yeah, already doing that :)
<ppisati> apw: we miss you in mumble
<smb> maybe he will be back on Monday ... maybe not
<ppisati> :(
<ppisati> apw: do you think it would be possible to have mainline compiled for armhf from now on?
<apw> ppisati, it does already in fact, but ... remember only ones built in raring and in raring since you added highbank to the configs would be a highbank compatible
<apw> ppisati, mostly we are building it for 'does it build' testing than for anything else
<ppisati> apw: yeah, from now on i mean
<ppisati> apw: we could build mainline for armhf using 'multi_v7_defconfig'
<ppisati> apw: or do we use our conig actually? /me never checked...
<apw> ppisati, we use 'our' config modulo any changes since then where we take the default answers
<apw> dk
<apw> k
<apw> bah
<rtg_> apw, how the N7 USB config stuff going ?
<rtg_> how is*
<apw> rtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big
<apw> rtg_, did you see: 14:02:33        apw | rtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big  
<rtg_> apw, nah, missed that. busy updating kernels etc
<apw> rtg_, enabling the filesystms we want triggers the initramfs to bloat needlessly and it won't fix, anyhow working on it
<rtg_> apw, given that the N7 isn't _really_ a general purpose platform, can we disable some of the cruft ?
<rtg_> apw, ppisati says the N4 is working for him, so I'm gonna get it in the archive.
<apw> rtg_, well the issue is that things which are modules get pulled in to initramfs, we need some way to say not to do that, i think we can say "just this list" and put nothing in it.  for now i have dropped out the fliesystems changes and moved on, and will come back to it
<apw> rtg_, great, now i have a 'proceedure' for this i can do the same to n4
<rtg_> apw, cool
<ppisati> rtg_: yep, n4 works here
 * ppisati is stuck with calxeda bugs else he would tackle the n[4|7] happily :(
<ppisati> ftrace is broken on n4
<rtg_> ppisati, did you update the wiki on how to install the new kerenl ?
<ppisati> the n7 has the touchscrenn patch problem
<ppisati> rtg_: i used that procedure
<ppisati> rtg_: i installed the .deb package
<ppisati> rtg_: then
<ppisati> rtg_: aboot -u /dev/block/mmcblk0p6 -k /boot/vmlinuz-foobar
<ppisati> *abootimg
<rtg_> I wonder if we could get ogra_ to update flash-kernel
<ogra_> for what exactly ?
<rtg_> ogra_, for the n4
<ogra_> get me the data :) 
<ogra_> shouldnt be any prob to add it to all.db
<rtg_> ogra_, how about if I send you a patch ? I've got an N4 to experiment with.
<ogra_> yeah
<ogra_> you should be able to just copy the db entry of grouper and minimally modify it
<rtg_> ogra_, ack
<bullgard4> Where is the function of the kernel process [netns] described?
<joshhunt> sconklin: i'm seeing differences b/t the diff you prepared and what's posted on the usn page.
<sconklin> the one I prepared, or the one rtg did?
<pmatulis> is this wiki [1] official and accurate?
<pmatulis> [1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<sconklin> joshhunt: ^^
<joshhunt> sconklin: good question, let me see which one i grabbed.
<joshhunt> sconklin: it's the one rtg provided the link for
<joshhunt> sconklin: i thought they were the same file
<joshhunt> sconklin: let me grab the one from your link and check
<sconklin> no, I linked to the wrong one. I'll take a look
<sconklin> no, Mine is from the wrong release, the latest one
<sconklin> joshhunt: ^^
<joshhunt> sconklin: ok, thx. one diff i see is this: linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h
<sconklin> let me prepare one for the correct release and compare it with the one rtg did
<sconklin> it'll take me a bit
<joshhunt> sconklin: that file exists in your patch, but not the kernel linked on the usn page
<joshhunt> sconklin: sure, np
<joshhunt> sconklin: let me know if you want a list of the diffs, if that will help pinpoint what went wrong, although it'd be good to verify the one on the usn page is correct also.
<sconklin> joshhunt: ack, thanks
<smb> pmatulis, Looks to me like the correct one / official one
<pmatulis> smb: thanks.  why does it mention only x86?
<smb> ogasawara, ^ 
<ogasawara> pmatulis: because we only provide HWE kernels for x86
<ogasawara> pmatulis: we don't provide backport HWE kernels for say our arm flavors
<pmatulis> ogasawara: ok, i was confused thinking x86 does not include amd64
<sconklin> joshhunt: can you point me to the exact usn page you're talking about? I want to make sure we're on the same page
<joshhunt> sconklin: sure, https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64
<sconklin> Thanks, now I'm sure I have the right tag
<smb> henrix, Hey just wanted to let you know that I have been running the master-next lucid in a xen pv and hvm guest. Ok, the hvm guest still has an eta of 80mins on the regression tests but in general I think we can say those xen ds  patch looks good
<henrix> smb: cool, thanks. i guess that if there was a prob with that backport it would crash ugly during boot :)
<smb> henrix, one would guess. Though it did not crash ugly on boot before either. :)
<henrix> smb: heh true :)
<henrix> thanks for testing that
<smb> no prob
<sconklin> joshhunt: ok, there was some confusion here. There are diffs that get generated as part of the packaging, which are diffs from the original tarball for for the series. We an reproduce these.
<sconklin> But the diffs on the page you linked are generated by launchpad as a consequence of the order in which packages are uploaded and copied to -proposed, and we cannot reproduce those
<sconklin> we'll try not to let this happen again
<joshhunt> sconklin: i'm not sure what you mean exactly. do you know why the diff rtg provided did not match what's on launchpad?
<ppisati> ok, friday evening here
<ppisati> gym -> booze -> EOW
<sconklin> joshhunt: show me precisely which diff you mean by "what's on launchpad"
<joshhunt> sconklin: if i take the diff rtg linked to and apply it to a vanilla kernel and then download https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz the contents do not match when I diff -Naur them
<sconklin> joshhunt: define "vanilla kernel" - do you mean the .orig tarball we use to package with? Because that's what those diffs are generated against
<joshhunt> sconklin: so the only reason this concerns me is it raises a question to me as to which one is "correct"
<joshhunt> sconklin: kernel.org tarball
<joshhunt> sconklin: i make an assumption that is the same as your .orig tarball
<joshhunt> sconklin: if you tell me what's on the launchpad page is correct, then i will just generate my own diff b/t 3.2.0 from kernel.org and linux_3.2.0-40.64.tar.gz and use that for this releaes
<sconklin> joshhunt: ok, now I get what you're asking, let me check on some things.
<sconklin> joshhunt: 1. Yes, our .orig is the same as upstream
<sconklin> 2. try the diff here and see if it looks better: http://people.canonical.com/~sconklin/
<joshhunt> sconklin: so it seems it's the same as the one rtg gave me yesterday
<joshhunt> sconklin: you can verify for yourself by downloading the file from https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz and diff'ing that with your patch + orig tarball
<sconklin> doing that
<joshhunt> sconklin: but i see things like linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h is in your diff, but not in the 40.64 tarball
<joshhunt> sconklin: hmm actually i think i worded that last statement incorrectly
<apw> sconklin, when you make an orig + patch version you will have files which would have been 'deleted' still present in the combination ... because the +diff cannot represent the removal
<apw> sconklin, so if that differs from one where you missed the orig, that is not unexpected.  you should compare to one before which has an orig
<sconklin> apw: maybe that accounts for it
<sconklin> thanks
<joshhunt> apw: just curious, why can't the diff represent the removal?
<joshhunt> sconklin: to correct my prev statement, arch/arm/mach-omap2/include/mach/omap4-common.h is actually not in the linux_3.2.0-40.64.tar.gz tarball.
<joshhunt> sconklin: apw seems to be onto something, when i go through the diff i believe the differences are only whole files which are not present in the linux_3.2.0-40.64.tar.gz
<kamal> joshhunt: I just came to the exact same conclusion -- its all just the deleted files which aren't represented in the diff
<sconklin> josh, our testing here (Kamal looked at this also) indicates that this is the case. All differences are attributable to deleted files
<sconklin> thanks, apw
<kamal> specifically, that list of deleted files (not counting a bunch of .gitignore files) is http://paste.ubuntu.com/5702168/
<joshhunt> kamal: yes that's the same list i get thanks.
<kamal> joshhunt: and just fyi, along the way I also verified that (a) our .orig tarball is identical to the upstream 3.2 tarball, and (b) the sconklin/rtg diff's are precisely what would have been produced, if that 40.64 package had been constructed with the .orig.
<joshhunt> kamal: ok thanks. i appreciate all (sconklink, apw, kamal) of your help
<sconklin> and in the process, uncovered an interesting side effect of our build process that resulted in my diff being different than rtg's
<joshhunt> are these deleted files usually present in diff you normally post for USNs?
<joshhunt> and i just didn't notice them
<rtg_> ogasawara, you can update a blueprint, I got the N4 kernel uploaded this AM. working on getting flash-kernel functional.
<ogasawara> rtg_: nice!
<rtg_> ogasawara, OMG! tl;dr - 'UBUNTU: SAUCE: cpuidle: Fix NULL pointer dereference when off-lining CPU's'  :)
<ogasawara> rtg_: way too long, just ack it
<rtg_> ogasawara, done
 * rtg_ -> lunch
 * henrix -> EOD
<joshhunt> sconklin: i'm just trying to make sure i understand what happened. how are you generating the diff you provided to me? git-diff?
<sconklin> joshhunt: I rewound the git repo to the tag we released from, then generated a source package with a diff against the .orig tarball (the way we normally package)
<sconklin> so it was generated by producing a source package just like a release.
<sconklin> joshhunt: I can give you instructions for how to do the same thing
<sconklin> if you want to verify it that far
<joshhunt> sconklin: that would be cool, as i'm trying to convert us over to pulling this stuff from git anyway. i'd be interested in your process.
<sconklin> joshhunt: you know how to clone our repo already?
<joshhunt> sconklin: yep
<sconklin> so basically, find the rigth tag and reset to that. In this case it was: git reset --hard 985689a
<sconklin> then follow the directions here:
<sconklin> https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePackageBuilding
<sconklin> which in this case was:
<sconklin> git clean -dxf
<sconklin> fakeroot debian/rules clean
<sconklin> debuild -S -I -i -uc -us -sa -v3.2.0-39.62
<sconklin> and if you have the .orig tarball in the directory above the repo, it should all work
<kamal>  sconklin, joshhunt: fyi, instead of the initial "git reset", it also works to just do:   git checkout Ubuntu-3.2.0-40-64
<joshhunt> sconklin: thanks so much, i appreciate it.
<joshhunt> kamal: thanks
<kamal> note also that the "-v" flag there is not relevant -- you'll get the same diff.tar.gz with or without it
<kamal> joshhunt: note also that the orig tarball in .. must be named "linux_3.2.0.orig.tar.gz" ... the debuild process won't find it if you leave named as kernel.org provides it.
<joshhunt> kamal: ok thakns
<joshhunt> will this process generate a package or a diff?
<sconklin> both
<joshhunt> awesome
<kamal> joshhunt: it will generate a "source package", which is comprised of a few files including the .diff.tar.gz
<joshhunt> ok so then if in this particular case if i were to apply the diff generated here to an orig tarball and diff that against the package which is created, we'd see the same thing with the deleted files not being in the diff. is that correct?
<joshhunt> if so then i think i finally understand :)
<kamal> joshhunt: yes, that's exactly the procedure I did
<joshhunt> kamal: awesome thanks so much for your help. i will leave you all alone now :D
<joshhunt> sconklin: thanks again
<kamal> joshhunt: no worries -- its helping us refine our process too, and that's a good thing
<sconklin> joshhunt: np.
<ogasawara> rtg_: I assume I can ping rsalveti to try rolling the N4 kernel into the phablet image?  or would you prefer I wait till we sort the flash-kernel bits
<rtg_> ogasawara, yeah, wait until I'm sure flash-kernel is correct. likely someimte next week when I sync up with ogra_.
<ogasawara> rtg_: ack
<ogra_> well, we dont have the n7 kernel in use on the touch images either, rsalveti can surely start playing woth it and test etc
<ogra_> flash-kernel will need adjustment for both 
<rtg_> ogra_, Paolo has to figure out the touch pad issue first.
<ogra_> ah, right, there was that
<rsalveti> ogasawara: flash kernel will only be useful when we finish the container work anyway, so we can at least use the same git tree
<rsalveti> while we make the package available and tune flash-kernel for later
<rsalveti> ogra_: waiting paolo ack on that as I don't have the hardware
<ogra_> rsalveti, why would the container have anything to do with it ?
<rsalveti> I only got galaxy nexus, nexus 4 and 10
<rtg_> rsalveti, I think I have it working on the N4 within the Ubuntu chroot.
<rsalveti> ogra_: because then the entire kernel and boot image is maintained by the ubuntu side
<ogra_> as long as we dont overwrite the initrd ... 
<rsalveti> sure, we'd need some temporary hack to reuse whatever it's available at the bootimg
<ogra_> right, but even in todays model we could updatte vmlinuz
<rsalveti> which doesn't make sense
<rsalveti> otherwise we'll replace the bootimg and the device will not boot
<ogra_> thats what i mean. you dont replace bootimg 
<rsalveti> if we get ubuntu as the main host, it'll all just work once we finish the flash-kernel piece
<ogra_> only vmlinuz
<rsalveti> right, which will not affect the device
<ogra_> on /dev/block/mmcfoo ...
<rsalveti> both kernel and initrd is part of the boot.img
<ogra_> i know 
<rsalveti> there's no single partition for the kernel
<ogra_> but initrd in android doesnt carry anything kernel relevant
<ogra_> there is the bootimg partition
<rsalveti> right
<ogra_> which abootimg can directly operate on
<rsalveti> we could extract, change and update, I'm just saying we don't need to do that now
<rsalveti> as we'll change it soon anyway
<ogra_> why ?
<rsalveti> once we start using our own initrd
<ogra_> abootimg -u /dev/block/mmcfoo -k /boot/vmlinuz-xyz
<ogra_> that works today
<ogra_> no need to extract 
<rsalveti> cool, that makes it easier
<ogra_> right
<ogra_> if we cant switch the container we can use that method
<rsalveti> sure
<ogra_> (and probably without even involving f-k)
<rsalveti> wouldn't it be better to just use f-k and make f-k call abootimg?
<ogra_> well ... abootimg has all checks we need ... and the kernel package knows which device we want to flash to 
<rsalveti> ogra_: right
<ogra_> i would just have the kernel package ship the proper postinsts
<rsalveti> ogra_: how this is done with nexus 7 for desktop?
<ogra_> and hooks for initrd ....
<ogra_> f-k using the ac100 method
<rsalveti> right
<ogra_> we can indeed use that 
<ogra_> but i find it less complex to have the kernel just ship the right thing in case we dont touch the initrd
<ogra_> if we flip the containers f-k might be better thanks to its initrd hooks and triggers
<rtg_> ogra_, rsalveti: so I should just quit messing with f-k and just build it into the kernel postinst ?
<ogra_> not yet ... we need to know what container model we will use 
<ogra_> i woudl prefer the direct methid if the images stay as is 
<ogra_> but f-k in case we can move android into its own container 
<ogra_> (since then we want initrd handling)
<rsalveti> right
<rsalveti> then we might know better next week
<rtg_> ogra_, well, I've gota functional Quantal version of f-k
<rsalveti> once mike finalizes his investigation
<ogra_> hopefully
<ogra_> time is getting short for uploads 
<rsalveti> yeah
<ogra_> i thinnk lfinal freeze is next thu (didnt check the schedule but it should be around next week)
<rsalveti> well, we don't necessary need to worry with raring anyway
<ogra_> and if we change f-k's android method that needs testting on ac100 and n7 desktop for verification
<rsalveti> right
<ogra_> true 
<rsalveti> you'll be testing that for us anyway :P
<ogra_> haha
<rsalveti> don't have n7 neither ac100
<ogra_> expectations :)
<ogra_> i dont even know if the archive kernel still works on the n7 
<ogra_> i guess i should test on the weekend :)
<rsalveti> :-)
<ogra_> i fear paolo uses the android config 
<ogra_> (though i think he said he tested it)
<rsalveti> brb
<janimo> rtg_, hi is there a more or less comprehensive list of ubuntu kernel security CVEs so far in a single place
<rtg_> janimo, you'd have to ask my security dude sconklin
<janimo> ubuntu-security-announce ml is what I see closest, but it is not kernel only
<janimo> rtg_, sconklin I am interested in aproximately how many of the security issues are arch or driver dependent vs those that affect any kernel
<janimo> to have an idea how vulnerable a random android or BSP based kernel for a single ARM SoC would be on average, knowing the kernel security fixes cover a much wider surface area than a single specialized kernel has built in
<rtg_> janimo, I guess you could grep commit logs looking for CVE.
<janimo> rtg_, yeah, that's why I asked for a preexisting list or even such a rough classification which may have already been done :)
<rtg_> janimo, I am not aware of any such classification.
<janimo> or a guesstimate of someone doing this on a daily basis who 
<bjf> janimo, you can also look at the changelog. cves are indicated
<janimo> s/who//
<janimo> bjf, right, I am aware of those too, but thanks :) . As you can see I am lazy and first look for anything that may be done already
<bjf> janimo, there is also http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
<bjf> janimo, but that doesn't cover ones that have been closed out
<janimo> bjf, I guess the UBuntu kernel CVE is more or less the same as upstream kernels right?
<janimo> CVE list that is
<bjf> janimo, i'd expect them to be very close if not the same
<janimo> hm, than this may be a good list
<janimo> http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html
<janimo> or something on that website anyway
<bjf> jjohansen, may know of something
<janimo> or this may be a cleaner list http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
<jjohansen> hrmm, I have really dived into that kind of data yet, it would be a good idea to shift through the CVEs we have had in the past and see what it shows
 * janimo is relieved to see there have been 0 CSRF vulnerabilities in the Linux kernel
<jjohansen> and yes our kernel CVEs are the same as upstream
<janimo> jjohansen, the cvedetails page seems really nice, but I do not see classification based on modules or other components. That may indeed need some extra greeping work, hopefully CVEs have the affected source file paths in a searchable location
<jjohansen> janimo: right I am not aware of anything breaking it down by module/driver/subsystem it would be interesting to see
<janimo> no idea if there's a CVE database in a machine-friendly format 
<jjohansen> ours isn't bad we process it with scripts, it does have some issues
<janimo> a more or less fixed form is good too, right
<jjohansen> sure
<jjohansen> I'm wondering how far bug our break-fix entries (git commits that caused the cve and ones that fixed it) go, I think its only a couple of years
<janimo> jjohansen, based on what you saw so far and with no such analysis being done, what would you estimate is the split between vulnerabilites that would affect almost every kernel and those that involve rarely used drivers or more obscure FSs or network fucntionality?
<janimo> jjohansen, I do not need too much history, just an idea of how much chance a given CVE has of affecting an ARM kernel built for a single SoC supporting only the drivers that areneeded on a single mobiel device
<janimo> so likely no advanced network or server storage stuff, no huge x86 or supercomputer data buses, etc
<jjohansen> hrmmm hard to say I would guess it tips to the obscure fs or network functionality, but I'm not sure how much 60/40, 70/30 ?
<janimo> just a random Android kernel from a mobile phone
<janimo> from the few android kernels I saw, their updates seem to cover hw enablement issues and not really securitty updates
<janimo> probably becasue user-space also has less chances of doing dangerous stuff
 * ogasawara lunch
 * rtg_ -> EOW
<yigal> To use an old device with 12.10 I need to patch its kernel.  Where can I find an up-to-date accounting on how the Ubuntu kernel should be patched and then (re)built?  Secondly, I need instructions specifically on compiling its kernel on another platform, as my desktop is much faster.
<yigal> I believe I need to for EZEX touchscreen
<yigal> unless someone else knows evtouch or other will work with tweaks?
<bjf> yigal, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<yigal> lol
<yigal> and then he's out
<yigal> It's just been a couple years since compiling and new tools seem to come more frequently than that so 
<yigal> So I've tried through the source in a i386 chroot environment to compile but have had issues.  Owell it's always fun to do this type of stuff.
#ubuntu-kernel 2013-04-13
<yigal> fantastic, so regardless it looks like the kernel is in its last stages of being built
<yigal> just scping the resultant builds over to the device for installation
<yigal> yay touch screen works, that's great
<yigal> ah such a dead channel
#ubuntu-kernel 2013-04-14
<deffrag> Hi! I've been this question in #ubuntu in last two days. I hope I can get answer here.
<deffrag> I'm using Ubuntu 12.10 and while updating and upgrading packages I got errors as pasted here - http://paste.ubuntu.com/5703828/ .Its around grub as far as I could understand. /etc/grub.d/40_custom.save - http://paste.ubuntu.com/5703837/ . Could anyone help understand the problem and solve it?
<deffrag> For reasons other than upgrade, I have to restart system. I'm bit unsure if grub would load properly or not. Hence, would like to fix those errors around grub before restart.
<maxb> /etc/grub.d files are supposed to be executables that emit grub configuration fragments when executed. 40_custom.save isn't
#ubuntu-kernel 2014-04-07
<ppisati> yo
<smb> ppisati, no! (too early)
<apw> yeah that is far toooo early
<RAOF> But not too early for the BEES!
<amitk> apw: any chance of this patch getting into trusty? https://bugs.freedesktop.org/show_bug.cgi?id=58378
<ubot2> Freedesktop bug 58378 in Driver/nouveau "[NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.5.x (and RHEL 6.5) or later" [Normal,Resolved: fixed]
<amitk> apw: I've not been able to use the ubuntu dashboard (switched to i3) due to corruption issues since 12.04
<amitk> the patch made it into 3.14-rc1
<amitk> related ubuntu bug I filed (and ignored eventually): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158689
<ubot2> Launchpad bug 1158689 in linux (Ubuntu) "10de:0422 bringing up dash causes screen corruption on nouveau" [Medium,Incomplete]
<amitk> or perhaps you look into graphics RAOF?
<RAOF> If you need a kernel patch, you need apw!
<apw> well there is little change for the release kernel, but ... for an sru i can have a look
<RAOF> (Or someone else on the kernel team âº)
<apw> amitk, could you add the details to the bug as well
 * smb wonders whether amitk remembers that deadline thing in general
<amitk> apw: what details do you need? I'll link to the freedesktop bug
<apw> amitk, that'll do i recon
<amitk> smb: its done when its done ;) I can't promise deadlines for scheduler changes ;)
<smb> amitk, Just wondering about a patch that you say made it into 3.14-rc1. Thought that was a bit ago. 
<amitk> smb: I haven't tracked this bug for a while since I don't use the ubuntu dashboard anymore. This came up again when I was testing out Trusty images over the weekend and I decided to look if it was fixed anywhere
<amitk> smb: and I knew you were getting close to a release, but no I didn't know when exactly
<amitk> :)
<smb> amitk, So quick to forget. :)
<amitk> smb: hardly forgotten, more like I don't upgrade my devbox on a 6-monthly cadence anymore ;)
<amitk> apw: done linking against the upstream bug
<apw> amitk, this is going to be a hard ask, it is rather large:
<apw>  33 files changed, 500 insertions(+), 308 deletions(-)
<amitk> apw: did you look at commit 4019aaa2b314a5be9886ae1db64ff8c6d3c060ed?
<amitk> apw: I only see  17 files changed, 287 insertions(+), 35 deletions(-)
<amitk> apw: or is there a dependency patch that I missed?
<apw> amitk, yes, there are two, one of which 'rewrites most of the quirk init code'
<amitk> apw: aah
<apw> though even the 17 is pretty invasive
<amitk> apw: true
<amitk> apw: the patch itself is important for nouveau users that are currently seeing errors in their logs because the driver tries to use HW blocks that aren't even present
<amitk> apw: I'll just switch to mainline kernels
<apw> amitk, i'll spin a test kernel and you can test it, at least we will know for sure it is the fix
<apw> i can then propose it and see what happens
<amitk> apw: thanks
<jpds> Can someone take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1303419 ? I found a workaround but it'll be nice to have it as default.
<ubot2> Launchpad bug 1303419 in linux (Ubuntu) "Brightness keys don't work on HP Elitebook Folio 1040 G1" [Undecided,Confirmed]
<apw> jpds, will have a look
<jpds> apw: Thanks.
<apw> amitk, test kernels linked in the bug
<amitk> apw: will test soon and get back, thanks again
<apw> jpds, possible fix applied to test kernels, urls in the bug
<jpds> apw: Testing...
<apw> jpds, it is not 100% clear from the description which ids are covered, so it may not, we shall see
<jpds> apw: It worked.
<jpds> \o/
<apw> jpds, ok ta, put that in the bug for me
<jpds> apw: Already done.
<apw> jpds, submitted to our list for consideration, shame you didn't get this in before freeze, but hey
<jpds> apw: I got the laptop yesterday!
<jpds> ;-)
<apw> jpds, heh
<apw> rtg, i just slammed head to fix a bug number in one of my patches
<rtg> apw, ack
<rtg> apw, did I mark the wrong bug fix committed then ?
<apw> rtg, you did on my error, i fixed that up as well
<rtg> cool
<apw> rtg, you seem to have skipped over "rds: prevent dereference of a NULL device in rds_iw_laddr_check", i was going to apply that if you arn't doing it ... its a big heap of applying i don't want to duplicate :)
<rtg> apw, I just haven't gotten to it yet, but go ahead.
<apw> rtg, ack
<rtg> I was busy updating kernels and such.
<rtg> in fact, I'm about to reboot now.
<brendand> is there a difference between checking for 'mem' in /sys/power/state vs using pm-is-supported --suspend?
<brendand> i'm sure there is a difference, but i'd like to know what that is
<brendand> if mem exists but pm-is-supported fails, does that mean suspend *can't* work on that system, or might it mean there's a bug?
<brendand> similarly, if mem doesn't exist, might it be possible for pm-is-supported to succeed?
<apw> brendand, it checks mem in /sys/power/state as one of the options, there are two others, so to answer your questions, yes and yes
<apw> it is not clear how pm-is-supports --suspend could fail if mem is in /sys/power/state however
<rtg> apw, when installing from the server ISO having a driver referenced in d-i/modules/nic-modules should be sufficient for network access, right ? For example, 'debian.master/d-i/modules/nic-modules:mlx4_en ?'. 
<apw> rtg, i believe so indeed
<rtg> apw, and it _should_ get bundled into the initrd when the kernel is installed on the target disk.
<apw> the criteria there are unrelated, networking is not normally seen as boot essential is it ?
<rtg> apw, Infiniband might be. Guess I'd better find out.
<apw> nor would it normally be, given you open the real disk, and find the drivers there
<apw> yeah ... that
<smb> apw, netboot?
<brendand> oh dear, if pm-suspend can't do real hybrid sleep then it cheats :/
<apw> smb, that has a different initrd
<apw> brendand, "oh dear" ?
<smb> apw, hopefully one that considers networking as boot essential
<apw> hopefully nideed
<brendand> apw, from the point of view of someone testing that hybrid sleep works, yes
<apw> smb, i just updated "clark" and rebooted, on startup i can now seem my old VMs, good, but they do not start
<apw> Error starting domain: internal error: libxenlight failed to create new domain 'grovel-r64'
<smb> apw, Would be nice to have some more useful messages. Unfortunately those hide usually in /var/log/libvirt/libxl/... on the host
<rtg> tseliot, have you heard any howling about 4K monitor support getting broken with this last nVidia-331 update ?
<apw> smb, yeah that is crap, it may be an old VM with "pre VG rename" paths in it
<bjf> rtg, i don't think it's 4k support. i think nvidia is borked
<bjf> rtg, i'm guessing you are in low-res mode
<smb> apw, True. Well it could be anything. Sadly the error reporting through virt-manager is... suboptimal
<bjf> rtg, and your jumbo-tron doesn't have a low-res support
<tseliot> rtg: the driver we have in Ubuntu is not the latest from Nvidia. I haven't tested it with 4K but 2560x1440 works fine here
<rtg> bjf, oh, you mean altogether borked ? I'm in "no mode" black screen
<apw> rtg, is your monitor "black" or "off", mine seems to be off
<apw> smb, ok this was "my fault"
<rtg> apw, black
<apw> they seem converted just fine
<bjf> rtg, i'm in low-res on a "normal" monitor which might be different on the jumbo-tron
<tseliot> rtg: in the latest update I only added support for Linux 3.14
<smb> apw, Uh, what kept them from starting then?
<apw> somewhen back in the mists of time (read more than 2 weeks back) i renamed my datavg to clarkvg
<apw> and this had the old, you cannot have inserted the wrongo path
<smb> apw, Ah! Ok, makes some sense then. Just not the nicest thing on earth when it comes to errors. As much as a python stackrace can ever be called nice
<apw> ok this was a raring machine, that makes sense being as it isn't supported any mroe, /me tries an s instance
<smb> apw, No the convertion should not change anything there
<apw> smb, ok my S which i had fixed previously appears correctly and starts correctly.  i'd say that is success, got a bug # i can report that testing in ?
<smb> apw, No, I probably should open one... and maybe ... hm... just occured to me that re-creating those VMs that are in the old path but not the new may be annoyingly bringing back things on every upgrade
<apw> smb, you have to mark that you have done it and do it just once indeed
<smb> apw, except maybe when adding a '--force'
<apw> smb, or rename the previous ones to .old sort of thing
<apw> so you can rename them back if you need to but only process the ones not .old
<smb> apw, I would be careful there. As I cannot be 100% sure what the old xend does with those.
<apw> smb, move them from like /foo/bar/machines/* to /foo/bar/machines.old/*
<smb> apw, If I do that, and someone switches back to the old toolstack, the domains are gone there. 
<apw> smb, yes but i may have changed them anyhow, so you need to convert them back
<apw> smb, which is why i think we should convert them, pop somethign up to tell you that, so you arn't supprised they are gone when you downgrade
<apw> smb, but overall they work well so that at least is good
<smb> apw, it already tells you about the conversion in the log. And I rather won't go on a reverse. Thats deprecated anyhow
<smb> And adds too much complexity
<apw> smb, right that is why i don't think we care that they are gone if you go back, that can be documented on something the log points to perhaps
<apw> like a wiki for downgraders
<apw> or something
<apw> smb, though your bug should have a release notes task so we can warn people this is going to happen to them in advance as well
<smb> apw, Hm, I am rather adding something preventing a second convertion. Feels more straight forward
<apw> we should still release note the conversion so people can think about the risks, as they will be higher than normal for xen use, which is almost noone of course
<smb> apw, Agreed. I think that bug I am reporting right now can also get a release-notes task
<apw> smb, yeah agree
<smb> apw, bug 1303886 created
<ubot2> Launchpad bug 1303886 in xen (Ubuntu) "[Trusty] Xend managed domains disappear after upgrade" [Undecided,New] https://launchpad.net/bugs/1303886
<smb> apw, Oh one thing that prevents the renaming. Unfortunately I have to take care about xen only and xen with libvirt and I would not know in the postinst which case
<apw> smb, i've added the release notes task
<smb> apw, ok
<apw> smb, if you can only "do it" once ever that seems fine, and safer
 * cking drops in to listen to the canonical "plan" via icecast.. 
<cking> oops
<smb> cking, New level of annoying elevator musak
<cking> arggh
<amitk> apw: bugfix confirmed and commented on bug
<amitk> apw: thanks
<bjf> zequence, BenC new SRU cycle just started
<zequence> bjf: Yep. I'm all done except for testing.
#ubuntu-kernel 2014-04-08
<ppisati> creepy: http://heartbleed.com/
<eolien> Hi everyone, i come from ubuntu-fr with a pb that we didnt resolve yet
<eolien> on my dell 7010, with xubuntu 12.04.3 64 bits, reboot blocks
<eolien> i have 30 computers, same problem
<eolien> i had the same problem before, with 32 bits image, but i found a solution
<eolien> i had to add "acpi=force reboot=bios" options in /etc/default/grub
<eolien> but it doesn't work on 64bits image
<eolien> i tried every "reboot" parameter without success
<eolien> (see http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/)
<eolien> has anyone have an idea ?
<apw> eolien, not anything i have heard of, is there a bug filed for this specifici issue on 64bit
<eolien> didn't find it
<eolien> i'm searching for
<apw> then i would suggest filing one againt the apckage "linux"
<eolien> sorry, dont know how to do it
<eolien> can you help me ?
<eolien> i need to do it on launchpad ?
<apw> run "ubuntu-bug linux" in a terminal window
<eolien> done
<eolien> thx
<apw> eolien, might be worth letting us know the number here, as we get a heck of a lot of bugs
<eolien> 1304246
<apw> bug #1304246
<ubot2> Launchpad bug 1304246 in linux (Ubuntu) "Reboot hangs with Dell computers on 64 bits" [Undecided,Confirmed] https://launchpad.net/bugs/1304246
<apw> eolien, i am confused, the data in this bug implies this is running on KVM or similar ?
<apw> bios.vendor: Bochs
<apw> ppisati, seen lp #1303657 ?
<ubot2> Launchpad bug 1303657 in linux (Ubuntu) "Cannot boot trusty kernel on qemu-system-arm" [High,Confirmed] https://launchpad.net/bugs/1303657
<ppisati> apw: watches
<ppisati> u-boot
<ppisati> uhm
<apw> ppisati, if you are able to boot an image with qemu we are good regardless i am sure
<apw> ppisati, if that is osmething we are able to do normally :)
<ppisati> apw: yes we normally do
<ppisati> apw: testing now
<apw> ppisati, thanks indeed
<infinity> ppisati: If I had to guess, I'd assume it's because of the mandatory fdt requirement in 3.13, and he's neither appending an fdt to his kernel, nor loading a (correct) one from u-boot.
<ppisati> infinity: we were appending fdt since 3.11 iirc
<infinity> ppisati: It wasn't required in 3.11
<ppisati> infinity: and if he used flash-kernel (as it seems since it's using a flash-partition), thr fdt should be there
<infinity> ppisati: Anyhow, when he's booting raw, I guarantee he's not appending one (he certainly doesn't mention it), and I suspect there isn't one in play when he's booting with u-boot.
<ppisati> wait
<infinity> ppisati: Does flash-kernel actually deal with qemu machines properly?
<ppisati> he is using it
<ppisati> fatload mmc 0:1 0x62008000 board.dtb
<infinity> ppisati: That doesn't mean it's the *right* one.
<ppisati> infinity: neither it says it's the correct kernel, one has to trust the bug reporter and hope that he updated kernel/initrd/dtb in accordance
<infinity> ppisati: Well, I see exactly zero entries in flash-kernel that match his cpuingo.
<infinity> cpuinfo, even.
<infinity> So, how would the right dtb ever get there? :P
<ppisati> infinity: forget about the attached dtb, he is explicitly passing one
<infinity> ppisati: Yes.  And?
<infinity> ppisati: Where is that coming from?
<ppisati> infinity: i don't know i'm not the bug reporter
<infinity> :P
<rtg> apw, have you noticed bug #1301496 ?
<ubot2> Launchpad bug 1301496 in linux (Ubuntu) "kernel crash: Unable to handle kernel paging request for data" [High,Confirmed] https://launchpad.net/bugs/1301496
<apw> rtg, looking
<apw> rtg, yeah i have seen this one ... i think the logical change is to do the same test on 4K kernel, as it seems pretty reproducible
<rtg> apw, guest or host  or both ?
<apw> for me, guest, the host we do not supply the kernels there
<apw> rtg, i've added a note, and i'll go and look at dpkg as well
<apw> slangasek, this dpkg thing, is dpkg the only thing affected or are other things unhappy ?
<tseliot> apw, cking: are you familiar with "dpm_run_callback(): pnp_bus_resume+0x0/0xa0 returns -19". I think it's what's preventing the system from resuming correctly in LP: #1300568
<apw> tseliot, not familiar no
<apw> bug #1300568
<apw> ou
<cking> me neither, wonder why it is returning No such device
<rtg> dead bot
<apw> oi ubotu where are you
<apw> and could someone fix the "diable touchpad while typing" so oh i don't know, it disables the touchpad when typing
<rtg> apw, just quit dragging those huge thumbs around
<apw> you've seen my thumbs, i'd need like helium balloons attached to each
<tseliot> https://bugs.launchpad.net/kittyhawk/+bug/1300568
<ubot2> tseliot: Error: launchpad bug 1300568 not found
<tseliot> apw, cking ^
<tseliot> BTW the disable touchpad when typing sounds like a problem with palm detection in the driver
<cking> isn't that PNP device a keyboard?
<apw> cking, it is the id for the i8042, i wonder if it even has one
<cking> maybe it popped offline, EC error etc
<apw> or maybe it just has none at all, i didn't think most new kit did
<cking> i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
<cking> in the kern log at boot
<apw> oh just the keyboard at that
<cking> i wonder if i8042.nopnp may show different behaviour
<tseliot> I can ask the engineer to try that
<apw> cking, yeah ...
<cking> maybe the bios folk in HWE will have some ideas too
<cking> wrt EC foobars
<apw> yeah
<apw> cking, seems there is a quirk table for that option if it is that
<cking> yup, but if this is a EC bug in new kit I guess we can get it fixed in the firmware before worrying about that
<apw> yep that
<tseliot> in the firmware?
<cking> in the EC firmware 
<tseliot> ok
<bjf> rtg, did you get anywhere bisecting your kernel for the nvidia issue?
<rtg> bjf, I power cycled the jumbotron and then it started working
<bjf> huh
<rtg> same kernel, now no problems
<bjf> that's special
<rtg> with I'd have thought of that 3 1/2 hours earlier
<apw> it has a life of its own
<bjf> rtg, makes no sense to me but .. i was unable to get anything but low-res and only 1 monitor recognized. i shutdown the system and power-cycled the monitors and now the system recogizes them both and i'm back to hi-res
<rtg> bjf, I guess these monitors have buggy firmware too
<bjf> rtg, i've never had this problem until this new HEDT
<apw> bjf, do you have the same monitors as tim ?
<bjf> apw, no
<bjf> apw, mine is a 27" dell
<apw> i don't think i want to work out how that can be that you both are affected by the same issue on the same day with different h/w
<rtg> bjf, nor have I, which is why it took me so long to try a simple power cycle.
<bjf> apw, but we both are using an intel HEDT with the same nvidia card (i believe)
<apw> yeah, but the issue was that the machine somehow made the monitors cry, but only once, it makes my head hurt
<rtg> bjf, this wasn't happening on an HEDT. Its a generic Gigabyte MB with a GeForce GTX650 display adapter.
<apw> wierd
<bjf> rtg, ok, that's even more odd
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<slangasek> apw: I imagine other things are unhappy, but it's really easy to notice with dpkg because one bit flip per page causes a segfault on startup
<apw> slangasek, ok, yeah i vaguely wondered if the zero page could have stopped being all zero, and if we could detect that elsewhere
<apw> slangasek, as the dpkg init there is pretty simple and it finds the "static variable" non-zero
<apw> slangasek, i guess i would like to see one of these in the flesh when it is unhappy
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 15th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
#ubuntu-kernel 2014-04-09
<RAOF> smb: looks like you left some detritus in your drbd8 upload?
<jarkko_> http://lkml.org/lkml/2014/4/8/556
<smb> RAOF, If you can elaborate on that, I may understand
<RAOF> smb: There seemed to be a patch file called âbahâ shipped in debian/patches, but not applied.
<smb> RAOF, Oh ok... :-P Bah!
<smb> hm... bla not better
<smb> And I am not sure how I did that
<smb> if I did that
<smb> RAOF, Looks like my backport was too good... the same file exists in the saucy version, too (which was my source)
<RAOF> Heh.
<rtg> apw, pushed master-next for build testing
<apw> rtg, rebooting onto it now
<apw> rtg, seems to work for me ...
<miseria> "los discursos politicos y su demagogia, para torturar un pueblo, son decorados con la frase: *derechos humanos*" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-04-10
 * apw yawns
 * smb throws little reminders
<apw> smb, did those (xen libvirt) build ok in the PPA ?
<smb> apw, It built locally. I started a ppa build as well
<smb> apw, You might check whether you got a "Breaks" in the libvirt version I got on chinstrap for you to make sure I did not only dream of pushing it there
<smb> apw, The laptop I was provisioning just got near ready for testing
 * apw fights his test box wh
<apw> which has decided that losing grub is a good plan
<jsalisbury> rtg, there are a bunch of duplicates of bug 1305480  I linked all the dupes to your bug.  Just let me know if you need me to do anything on that bug.
<ubot2> Launchpad bug 1305480 in linux (Ubuntu Trusty) "BUG: pcmC0D0p:0, pos = 16390, buffer size = 16384, period size = 1024" [Medium,In progress] https://launchpad.net/bugs/1305480
<rtg> jsalisbury, ack
<bjf> hatch, did you ever get your haswell macbooks booting properly?
<hatch> bjf you bet! http://fromanegg.com/post/82251710943/how-to-install-ubuntu-on-a-mac-or-macbook :-)
<bjf> hatch, had you filed a bug on that issue?
<bjf> sforshee, ^
<hatch> bjf the bug was filed by someone else
<bjf> ack
<hatch> bjf it boils down to two things, not picking the +mac image and using the EFI installer
<bjf> hatch, ack. seems like that +mac image isn't needed like it used to be
<sforshee> bjf, hatch: it's bug #1284085
<ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed] https://launchpad.net/bugs/1284085
<hatch> yeah it's pretty confusing because the docs say to use that one if you have a mac :)
<sforshee> I asked for testing of processor.nocst to see if that makes a difference, but no response from anyone yet
<hatch> yeah thats the one
<hatch> sforshee ohh I missed that - I don't have the legacy install any longer sorry
<sforshee> bjf: note that I think apw was working to de-emphasize the +mac iso and possibly to get a release note
<sforshee> he added a release note task at least
<bjf> sforshee, yes, i think i saw that email
<hatch> yeah that would really help 
<sforshee> would be nice to fix the bug, but most of the time I think the efi install is a better option anyway
<hatch> yeah it looks like the mac needs to be at least a few years old now to not use the EFI option
<hatch> and who uses computers that long :P
<hatch> could a guy write a script that someone could run in osx to tell them what kind of install to use?
<sforshee> hatch: I have no idea, I'm not really familiar with the reason the +mac image was needed in the first place
<hatch> gotcha
<hatch> it looks like the regular version has both installers 
<hatch> so yeah....not sure :)
<hatch> Right now I'm just trying to figure out how to get my battery life back :)
<sforshee> hatch: does your machine have hybrid graphics?
<hatch> sforshee yep it has the new nvidia discrete card and the haswell iris gpu
<sforshee> yeah, you'll only be able to use the discrete graphics and often power management there is poor
<hatch> hmm....that's not really any goood :)
<hatch> is this because noone has written a proper driver?
<sforshee> there's a driver, but there are some issues with getting the discrete graphics working that haven't been fully solved yet
<sforshee> there's been some progress recently, but afaik nothing that's in upstream linux yet
<hatch> ahh ok, if I wanted to follow the development on this, where might I look?
<sforshee> hatch: not sure if there's any discussion going on. Last thing I know about it was that mjg59 had some patches which were working for him.
<sforshee> hatch: http://www.codon.org.uk/~mjg59/tmp/retina_patches/
<hatch> hmm cool, looks like there is some thunderbolt stuff here too, that's great becuase those also don't work :D
<bjf> hatch, when you say thunderbolt doesn't work, there have been problems with it hotplugging in the past. i have to plug mine in and reboot.
<hatch> bjf yeah that's what I have to do too, which is no good unfortunately
<hatch> if we are going to convince people to run ubuntu over osx it's got to be pretty flawless imho
<hatch> not that it's anyones fault of course
<bjf> hatch, i talked to the intel folks about it. it's an issue with the apple firmware. not sure there is anything to be done about it.
<hatch> ohhh ok, that's unfortunate, maybe someone will make some nice hardware like this without all the proprietary business :)
<mjg59> "issue"
<mjg59> Apple chose not to implement Thunderbolt in System Management Mode
<bjf> mjg59, yes :-)
<mjg59> Which is obviously the correct choice
<mjg59> But Intel
<hatch> seems like an odd choice
<mjg59> hatch: It means you can do things like tell the user when they've connected too many devics
<hatch> ahh, I suppose that would be nice :)
#ubuntu-kernel 2014-04-11
<pmatulis> will 12.04.5 include an upgraded kernel and xorg stack (ex: include the trusty xserver-xorg-video-intel)?  also, what is the ETA for 12.04.5?
<RAOF> pmatulis: I don't think we'll be spinning a 12.04.5; that would be after 14.04 release. If you need newer hardware support to install than in 12.04.4, then 14.04 is your oyster.
<RAOF> ...aha.
<RAOF> Or perhaps I missed that thread :)
<RAOF> pmatulis: So, now that I've remembered the âshould we do a 12.04.5 releaseâ thread; your answers are: (a) Yes, using the Trusty stack is the whole point, and (b) Probably August or September or such. Post 14.04.1
<pmatulis> RAOF: thanks!
<jarkko_> Bus 002 Device 003: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter spams 16913.608602] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 13 in queue this is reported and known issue could you do something about it?
<jarkko_> it weakens the transfer speed also realibity 
<jhenke> hi folks, bug 1294283 just reappeared after the latest kernel upgrade on 14.04 (3.13.0-23)
<ubot2> Launchpad bug 1294283 in linux (Ubuntu) "Memory balloning in Hyper-V generation 2 does not work" [Medium,Confirmed] https://launchpad.net/bugs/1294283
<jhenke> the vm is not able to get any more memory from the host, yesterday before I installed the latest updates all still worked
<henrix> kamal: could you please take a look at this kteam-tools patch: http://pastebin.ubuntu.com/7234771/
<henrix> kamal: if you're ok with it, i'll just push it
<kamal> henrix, your change omits the stripping of "[PATCH]" from the Subject: line ... but (?) that shouldn't be on the subject line by this point anyway, so its doesn't matter?
<henrix> kamal: this will be used to build the email subject in the format: '[3.11.y.z extended stable] Patch "<SUBJECT>" has been added to staging queue
<henrix> kamal: and this never contails the '[PATCH]' in the <SUBJECT>
 * kamal has another sip of coffee and looks again
<henrix> (maybe i'm just confusing you :) )
<kamal> henrix, I'm talking about this line from your diff, which (before your change removes it) seems to exist in order to try to strip off "[PATCH]" in order to extract the rest of the subject line ...
<kamal>     -            subject = sub("Subject: (\[PATCH[^\]]*\] )?", "", line.rstrip())
<kamal> I'm saying, "hey, you removed that line, so the script won't strip 
<henrix> ugh
<kamal> '[PATCH]' anymore like it used to do.
<henrix> kamal: i see what you mean now
<kamal> ...  but I'm then also saying ...
<kamal> I bet henrix has determined that that line was pointless anyway, since we *shouldn't* have [PATCH] on the subject lines at this point anyway.   yes?  no?  more coffee?
<henrix> kamal: no, i believe you're absolutely correct. however....
 * henrix goes look at the code again
<kamal> henrix, ok, well despite my ramblings above, I think your change is actually fine -- so unless you find something actually wrong with it, you have my "ack"
<henrix> kamal: cool, thanks! i'll just go fix the code (adding the '[PATCH]' removal from subject) and push it
<kamal> henrix, that's fine
<henrix> kamal: ok, pushed fixed patch to kteam-tools. thanks for reviewing!
<infinity> BenC: Any chance of one more saucy/ppc update? :P
<sconklin> o/
<miseria> "disfruto como pasajero de la capsula terrestre, los ranchos viejos de paris o roma no son mas lindos que los que veo aqui" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2014-04-12
<odkazeem> Hi, I recently been getting kernel panic - not syncing vfs unable to mount root fs on unknown block (0,0)
<odkazeem> And I have tried reading on stackexchange to find a solution; however, I am new to ubuntu and would appreciate any pointers on how to fix this.  I don't want to have to reinstall the OS and loose all my files.  Does anyone have any pointers
<odkazeem> ?????
<odkazeem>  Hi, I recently been getting kernel panic - not syncing vfs unable to mount root fs on unknown block (0,0).  And I have tried reading on stackexchange to find a solution; however, I am new to ubuntu and would appreciate any pointers on how to fix this.  I don't want to have to reinstall the OS and loose all my files.  Does anyone have any pointers?????
<miseria> "disfruto como pasajero de la capsula terrestre, los ranchos viejos de paris o roma no son mas lindos que los que veo aqui" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<xnox> how can i query NVMe's device namespace identifier and EUI-64 identifier?
<apw> xnox, not sure i know, cking would be the best one to ask though ^^
<apw> odkazeem (if you read the logs), that osunds like your initramfs is missing/not being loaded, i would boot a usb stick and poke about
<xnox> i'm guessing i'll need to issue nvme admin command identify for that to return me something but all the documentations are fuzzy.
<apw> yeah its all new shineys, it is bound to all be missing, wrong, usless, or ... missing did i mention missing
#ubuntu-kernel 2014-04-13
<xnox> apw: are things like this at all acceptable http://paste.ubuntu.com/7242271/ ?
 * xnox doesn't want to be torn into shreds for sending above patch out.
<apw> xnox, assuming the 32 there represents an offset and is meant to, that sounds reasonable, if you have a public link to the spec i would include it in the commit i think other than that it looks reasonable
<apw> xnox, and having found the spec, it looks like you hit correctly to me
<xnox> apw: right, i think i'll update other structs as well per 1.1a spec, but it looks like qemu implementation is 1.0e compliant as the old reserved fields are all set to zero =(
<xnox> apw: hence either qemu & real devices need updating - and/or i need some other way to address 1.0 devices in efibootmbr.
<xnox> but it's a start.
<phillw> hi good people... very quick question.. which script checks for the presence of PAE flag in the alternate (server) installer ISO system. I need to disable it as I have a non-pae kernel :)
<kdeuser56> will https://github.com/torvalds/linux/tree/master/kernel become 3.15?
<kdeuser56> or is this just a branch of 3.14 ?
<JanC> phillw: you might want to ask that in #ubuntu-installer
<phillw> JanC: okies, thanks!
#ubuntu-kernel 2015-04-07
<rtg> apw, bug #1374759 is benign, right ?
<ubot5> bug 1374759 in linux (Ubuntu) ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old" [Medium,Triaged] https://launchpad.net/bugs/1374759
<rtg> cking, do you know anything about btrfs transid patches ? See bug #1441150
<ubot5> bug 1441150 in linux (Ubuntu) "Problems with transid in btrfs (linux 3.13)" [Undecided,Confirmed] https://launchpad.net/bugs/1441150
<cking> rtg, I'll pick that one up and look at it
<rtg> cking, thanks
<rtg> apw, nm, you said as much: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1374759/comments/4
<ubot5> Ubuntu bug 1374759 in linux (Ubuntu) ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old" [Medium,Triaged]
<rtg> apw, just update unstable to v4.0-rc7
<rtg> updated*
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 14th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
#ubuntu-kernel 2015-04-08
<furkan> hi, i'm just trying to test a regression before submitting a bug report for 3.19.0-12, but i can't seem to download 3.19.0-10 any longer via apt-get - any advice?
<furkan> the problem is basically that dpms no longer works - it still works on mainline 4.0 rc7, and it used to work on the vivid 3.19 kernel, so it's definitely an update that broke it, but i just don't know which one
<furkan> on 4.0 rc7 it also stops working after suspend/resume, which is how it was originally with vivid's 3.19, but now it doesn't work at all, even after a fresh boot
<tmpRAOF> furkan: You can get it from launchpad directly.
<RAOF> furkan: Start at https://launchpad.net/ubuntu/vivid/+source/linux and work through the âreleases in ubuntuâ links.
<furkan> thanks RAOF i'll work through those when i get the chance
<rtg> henrix, what are those CVE numbers so I can get them in the commit log ?
<henrix> rtg: CVE-2015-2666: f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4; CVE-2015-2922: 6fd99094de2b83d1d4c8457f2c83483b2828e75a                                                                 
<rtg> henrix, thanks
<henrix> rtg: i can also give you the bug # in a min...
<henrix> for CVE-2015-2922: bug #1441103
<ubot5> bug 1441103 in linux-manta (Ubuntu Vivid) "CVE-2015-2922" [Medium,New] https://launchpad.net/bugs/1441103
<henrix> and bug #1438504
<ubot5> bug 1438504 in linux-manta (Ubuntu Vivid) "CVE-2015-2666" [Medium,New] https://launchpad.net/bugs/1438504
<rtg> henrix, done
<henrix> rtg: cool, thanks
<mssbrg> Hi, I'm doing some testing with thunderbolt on a 14.10 machine, kernel 3.17.8 and I'm experiencing some odd behavior. When I connect my machine to a thunderbolt display, the display works, however there is no thunderbolt driver loaded. Any help?
<mssbrg> I'm really just curious how this is happening
<apw> mssbrg, well the display is probabally exposed using another driver, and the bus itself is builtin
<apw> so you don't necessarily expect to see a driver for the bus enumerator
<mssbrg> i would expect to see `thunderbolt` in lsmod, no?
<mjg59> No
<mjg59> Unless it's an Apple
<mssbrg> this is all apple hardware
<mjg59> And also still no unless you're running 3.19
<mssbrg> apw: also, i don't really follow what you mean by display exposed using another driver/bus is builtin
<mssbrg> mjg59: why is that?
<mjg59> mssbrg: The Thunderbolt hardware isn't exposed to the OS until we start pretending to be Darwin
<mjg59> The hardware itself will handle the displayport layering setup
<mssbrg> by hardware, do you mean the intel thunderbolt controller? then what kind of interface is exported to the OS?
<mjg59> It just looks like Displayport to the OS
<mssbrg> mjg59: so if I upgrade to 3.19 can I expect to see a thunderbolt driver?
<mjg59> mssbrg: Yes
<mssbrg> mjg59: also, should I currently expect to see a displayport driver in lsmod?
<mjg59> No
<mjg59> That's handled by the individual graphics drivers and the drm core
<mssbrg> ah interesting. but there is /some/ driver in lsmod I should see that is handling the display, right?
<mjg59> Yeah, either nouveau or i915
<mssbrg> ok cool, i see i915
<mssbrg> mjg59: and so in 3.19, I would potentially see thunderbolt instead of i915?
<mjg59> mssbrg: No, as well as
<mjg59> The thunderbolt driver handles the PCIe hotplug part of Thunderbolt (on Apple - on other systems it's managed by the firmware)
<mssbrg> ah ok
<mssbrg> unrelated, but are there logs for this channel anywhere?
<mssbrg> mjg59: out of curiousity, if I plugged in a non-display thunderbolt device would things be different? still no thunderbolt driver in lsmod?
<mjg59> On that kernel? Yeah, and also it wouldn't work.
<mssbrg> oh. i thought 3.17 was the first to support thunderbolt
<apw> mssbrg, yes this is logged, erm
<mjg59> mssbrg: Kind of
<mssbrg> apw: are they available? I don't see a url in the topic.
<mjg59> It'll work if there's a Thunderbolt device plugged in at boot
<mjg59> And it'll stop working if you suspend
<apw> http://irclogs.ubuntu.com/2015/04/08/%23ubuntu-kernel.html
<apw> mssbrg, ^ they are logged in the same place as "all" ubuntu channels
<mssbrg> apw: ty
<mssbrg> mjg59: so if I understand correctly, the driver itself only implements the low level pcie communications, and the actual functionality of whatever device is always implemented by another driver?
<mjg59> Yes
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 14th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<mssbrg> mjg59: hm, still no thunderbolt driver in lsmod in 3.19. hotplug also doesn't work, even with it manually loaded in. any thoughts?
<mjg59> mssbrg: Huh. That surprises me. I'm afraid I don't have time to look at it right now, though
<mssbrg> No problem! Any recommendations on anything to try on my own? Either way, thanks for all the help!
<RAOF> Oh, that's right. Attempting to restart this box will hang because btrfs has blown up.
<RAOF> Damn you, cking, for asking me to test that! :)
#ubuntu-kernel 2015-04-09
<RAOF> Days since btrfs has eaten any of my data: 0.
<smb> tseliot, just as a bit of feedback the nvidia-340-updates variant of the binary driver for vivid at least seems to have only one dkms module producing both kernel modules in vivid. The uvm one is not loaded on that particular system but that might be related to the gpu variant. I am not sure when it should be loaded
<tseliot> smb: does dmesg say anything interesting about uvm? Also, you shouldn't notice any problems unless you decided to use CUDA
<smb> tseliot, nothing about uvm... and since cuda does not ring a bell immediately I suppose I have not decided to use that
<smb> :)
<tseliot> smb: yep, most users don't use the GPU that way ;)
<smb> tseliot, so meh. :) I guess then it looks good to be backported into the Trusty version of the updates driver as you surely also noticed people start complaining about that. 
<tseliot> smb: yes, I want to backport all the new drivers too. This will take a little longer but it will be worth the effort
<smb> tseliot, Yeah, since long-term this will let things cope better with hwe kernels. Hopefully power users have some amount of patience. Hm... maybe it is worth documenting how to manually resolve things until it gets fixed. I would not want to overestimate the patience of gamers. :-P 
<tseliot> smb: right now it's a bit of a random failure. At times it's even a false positive, meaning that, at times, dkms will complain even when the module is built
<smb> tseliot, exactly. Even if one of the modules permanently failed it might be the uvm and if that is rarely used anyway most people won't care.
<tseliot> smb: right
<smb> apw, Hm, not sure I just did not see those before but udev rules seem to produce "error: /dev/sd*: No medium found" style message on usb card reader devices (without card) though this should be obvious by capacity 0 ... (vivid that is)
<apw> smb, not sure i have either now
<apw> no
<smb> apw, yeah, likely only observable with hw that creates disk devices that has ejectable media
<smb> apw, Oh,,, hm... so 60-persitent-storage.rules does have some checking on ATTR{removable}=="1" ... guess I have to run with debug to get any idea what part really does the access
<mssbrg> Hi, I'm trying to build an in-tree driver via `make modules SUBDIRS=drivers/thunderbolt` but I get a "disagrees about version of symbol module_layout" in dmesg upon insmod. What build files should I check to make sure I'm building for the right kernel? .config? Module.symvers?
<apw> mssbrg, you need to make sure it is the exact version that was built, and the compiler matches iirc
<mssbrg> apw: the compiler should be the same. as for version, I'm currently running this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/, and I've checked out to tag v3.19 in the tree
<mssbrg> so it seems like those should match. I noticed that there were no *patch files for reconstructing the source tree though
<apw> mssbrg, there really ought to be ... hmmm
<mssbrg> apw: if you happen to investigate/have any more info, please let me know :)
<apw> mssbrg, oddly the patches are there for .2 and .3
<apw> mssbrg, oh ... well thats strange, it seems the kernel user on one of our builders doesn't have an "real name", and that has hosed the patches for those builds ... so i am rebuilding the two i noticed which are affected, though i am sure there are others
<hanfm> Hello, i have a problem in ubuntu 10.04, /var/log/messages is full of entries like this:
<hanfm> Apr  9 21:55:01 <myserver> kernel: [1708785.301163] cron[17345] general protection ip:7f9b28621786 sp:7fff2d524b20 error:0 in libpthread-2.11.1.so[7f9b2861c000+18000]
<hanfm> does anyone know, how to solve this  issue?
#ubuntu-kernel 2015-04-10
<apw> hanfm, that is most likley to be a bug in either cron or libpthread i would assume, it is reporting that that application core dumped
<popey> are we including https://git.kernel.org/linus/9c4f61f01d269815bb7c37be3ede59c5587747c6 in 15.04? (ref https://btrfs.wiki.kernel.org/index.php/Gotchas)?
<stgraber> ogasawara: hey, any chance we can reschedule the lxc/lxd sync to be earlier on Tuesday? hallyn will be around on Monday and Tuesday but has to leave around 3pm.
<ogasawara> stgraber: sure, lemme shuffle things around
<stgraber> ogasawara: thanks
<hallyn> thanks
<pepee> apw, are you here?
<infinity> pepee: It's 1am for him, I'd guess "no".
<pepee> oh, sorry
<pepee> anyway.. I was wondering, will there be a fix for this bug in trusty, too?  https://bugs.launchpad.net/ubuntu/utopic/+source/linux/+bug/1313804
<ubot5> Ubuntu bug 1313804 in linux (Ubuntu Utopic) "[HP Pavilion dv6-6145eo Entertainment Notebook PC] Laptop display does not turn back on after resuming from suspend" [Low,Fix committed]
<infinity> zequence: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1442400
<ubot5> Ubuntu bug 1442400 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> pepee: You might want to comment on the bug and mention that it's a problem in the trusty kernel.
<pepee> the bug report itself includes that info, infinity 
<pepee> the "feature" never worked in these laptops, with the radeon driver, afaiu
<infinity> pepee: Ahh, indeed, I missed the 3.13 reference.
<infinity> pepee: Added a trusty task, we'll see.
<pepee> thanks
<pepee> yeah, I didn't understand why it wasn't added
#ubuntu-kernel 2015-04-11
<pepee> there are similar bug reports in launchpad.net
<pepee> anyway, thank you infinity 
<pepee> heh, there are lots of reports...
#ubuntu-kernel 2016-04-11
<genkgo> jsalisbury: any more news on the backup issue? you were pretty close last time
<rtg> slangasek, is https://wiki.ubuntu.com/UEFI the most current info ? 
<jsalisbury> genkgo, I have one or two more kernels to test and that should tell me the commit
<genkgo> jsalisbury: alright, any idea yet?
<jsalisbury> genkgo, the bisect pointed to an ath9k patch, which makes no sense.  So I think there is on or two tests I did not let run long enough to fail.
<genkgo> jsalisbury: ok, will wait for it :)
<jsalisbury> genkgo, I hope to know today.
<genkgo> jsalisbury: would be awesome :)
<leitao> rtg, hello. Can we expect to see LP#1567581  fixed in the next kernel (-19) ?
<slangasek> rtg: https://wiki.ubuntu.com/UEFI> I haven't checked it lately to know if it's accurate, but there's nothing newer
<xnox> rtg, apw - i have a n00b question - do we support "vdso" and do we support it on s390x?
<apw> xnox, we have and use vdso on other arches, i would assume we do also on s390x
<xnox> apw, 
<xnox> cool.
<rtg> leitao, it'll make it into the -19 kernel (just committed and pushed)
<leitao> rtg, good. Any idea when -19 will be released?
<infinity> xnox: The answer to the first half of your question is found in "ldd /bin/mv"
<infinity> apw: I don't actually see a vdso on s390x, curiously.
<xnox> rtg, yackes. does it per-chance also build an unversioned zfcpdump kernel? and are you targeting -19 as an SRU or a release kernel?
<rtg> leitao, it'll be in the GA kernel.
<rtg> xnox, -19 should be the release kernel
<xnox> infinity, thanks. I see that we don't on s390x =/
<xnox> what's missing?
<leitao> rtg, thank you!
<infinity> A vdso, presumably. :P
 * xnox has no idea what vdso even is
 * xnox summons google
<infinity> xnox: vdso is the kernel exporting some libc functions.
 * xnox types "linux from scratch vdso"
<rtg> xnox, I doubt we'll get the zfcpdump kernel built and packaged for release, but apw is working on that.
<infinity> xnox: A shortcut to hardware-specific functions that are better maintained in the kernel than in glibc, basically.  Saves some cycles.
<infinity> xnox: Not all arches have a vdso, but most do for some time-related functions and such.
<infinity> xnox: Is this a curiosity thing on your part, or a question from IBM that they should know the answer to?
<xnox> rtg, apw - from conversation with slangasek - "zfcpdump kernel should probably be build by src:linux and generate linux-zfcpdump package or some such, which ships latest zfcpdump kernel, as a real unversioned file."
<xnox> infinity, right. looking at manpage there are only three calls.
<xnox> infinity, reading meeting minutes of a sales call and it has "VDSO?" as a bullet point.
<xnox> rtg, apw - that way it's always built, always latest (no symlinks no nothing) no separate package
<xnox> rtg, did you take my compressed kernel image request into -19 or no?
 * xnox thought there will be no -19
<rtg> xnox, we believe the zfcpdump should be built once from a standalone package and not changed unless there are bugs found. there is no need to keep it up to date except perhaps at major release times.
<rtg> up to date wrt to the kernel ABI, etc
<xnox> rtg, slangasek argument is that a separate package is an extra maintainance we don't need nor want.
<xnox> (separase source package)
<xnox> but yeah, i'm just the messenger here.
<xnox> rtg, is the cost having it in src:linux too much?
<rtg> xnox, there is only a place for _one_ zfcpdump kernel. you cannot have multiple copies as I understand it
<xnox> rtg, correct and that's what we need and want. IBM confirmed zfcpdump kernel version doesn't matter
<rtg> so, do you plan to update it ever time linux-source changes ?
<xnox> and hence we want e.g. src:linux build a package called "linux-zfcpdump" with version number X.Y.Z-ABI such that the largest/latest version kernel is the one that is provided as the zfcpdump kernel image.
<infinity> rtg: His plan was to generate it unversioned from src:linux
<infinity> rtg: Like linux-libc-dev.  Not tied to ABI.
<xnox> yeah, that.
<infinity> That said, who is validating this kernel?
<infinity> I still think it's silly to have Yet Another Kernel that someone needs to QA and make sure DTRT.
<rtg> hmm, well I'm gonna leave it up to apw as it is on his work list. I've got other tasks.
 * rtg ducks the issue
<xnox> infinity, so vdso... i don't see it in ldd output on s390x. But i have no idea if that's difinitive way to have it.
<xnox> rtg, i don't expect that kernel team will need to validate zfcpdump kernel.
<infinity> xnox: Well, someone needs to validate it.
<rtg> nxonce we have t working it should not change until perhaps the next release.
<rtg> xnox, ^^
<infinity> Like, someone needs to validate the actual binary.
<rtg> xnox, pushed your bzImage patch
<infinity> Which makes a good argument for not revving it on every kernel update, if no one's willing to do so.
<xnox> rtg, tah.
<xnox> infinity, ack so automated validation is on me, and then we can fire and forget it and update it automatically.
<xnox> i suspect they will notice it's not updated and will flag it up.
<xnox> ..
<xnox> back to vDSO
<xnox> we target 3.2 with glibc, vdso things for s390x were introduced in 2.6.29, but I don't see our ld pre-loading those functions from kernel.
<xnox> infinity, i see object=linux-vdso64.so.1 [0] in LD_DEBUG=all /bin/true output
<xnox> so it's being done. However, I guess it's not actually used because of bind now & pie on s390x?
<xnox> as in glibc is getting bound, rather than vdso?
<infinity> glibc isn't built any differently on s390x.
<xnox> tah tah
<xnox> i guess i need to poke a thing which uses one of the vdso symbols.
<xnox> used codesearch to find that sshfs uses gettimeofday 
<xnox> .... and i should really have run this on s390x
<xnox> and ldd /usr/bin/sshfs doesn't show vdso.
<xnox> infinity, right glibc isn't, but our toolchain is. everything is built with bind now.
<infinity> xnox: Hrm.
<xnox> WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1.
<xnox> no idea what that is about
<infinity> xnox: What's the opposite of bind now, if we wanted to test build another glibc?
<xnox> http://paste.ubuntu.com/15766287/
 * infinity wonders if that can even be reverted on the commandline.
<xnox> on e.g. amd64 it instead does
<xnox>       8481:     symbol=__vdso_time;  lookup in file=linux-vdso.so.1 [0]
<xnox>       8481:     binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6]
<infinity> I also wonder if it actually matters.
<infinity> Since glibc __vdso functions are just ifunc wrappers to linux-vdso anyway.
<xnox> dunno
<davmor2> infinity: pfff this is linux I'm more amazed when you can not do something in the cli :D
<infinity> davmor2: :P
<infinity> Undoing compiler options is easy, almost all of them have a negative value to match the positive.
<infinity> Linker options, not so much.
<xnox> infinity, opposite of bind now is debian chroot =)
 * xnox does that.
<xnox> infinity, on debian it gets bound to __vdsO_ private libc symbol too. I guess htat's how things are done on s390x.
<xnox> hence vdso is not shown in ldd output, but clearly is used in LD_DEBUG=all
<infinity> xnox: Kay.  So perhaps a non-bug.
<xnox> learned something new today.
<xnox> i was wondering what that magical vdso thing is in the ldd output, and not on disk... =)
<infinity> vdso is one of the weirdest, ugliest hacks out there.
<xnox> i was suspecting "oh we are linking kernel into all binaries, let's pretend that makes sense"
<infinity> We carry gross patches all over the place to cope with it.
<infinity> Turns out that things like gdb and valgrind don't like you linking to libraries that EXIST ONLY IN YOUR MIND.
<xnox> "EXIST ONLY IN YOUR MIND." ahah
<gpiccoli> Him sorry to bother. Where do I find the 4.4.0-19 kernel on git?
<gpiccoli> I cloned ubuntu-xenial repo, but the most recent tag seems to be Ubuntu-4.4.0-18.34
<gpiccoli> s/Him/Hi I'm/g
<rtg> gpiccoli, 4.4.0-19 has not been uploaded yet, though it is currently staged in master-next
<gpiccoli> Ok, thanks rtg! So, I can checkout master/next to take a look?
<rtg> yes, you can get it from git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
<apw> infinity, why didn't we make a real library with a page of nothing in it i wonder ...
<gpiccoli> rtg, thanks a lot! Worked here, I could check what I was interested =)
<rtg> gpiccoli, glad to hear it
<gpiccoli> =)
<gpiccoli> Thanks
<flamesage>  I'm trying to download v4.6-rc3-wily and it doesn't appear to have hit the mainline ppa?  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc3-wily/
<rtg> flamesage, its got some build problems that we haven't fixed yet
<flamesage> okay, thanks.
#ubuntu-kernel 2016-04-12
<Kano> hi, did anybody notice that since 7th the daily kernel does not build?
<apw> it has not been mentioned
<apw> Kano, it is occuring seemingly because there is something wrong with that keyspan firmware, which we by happenstance remove as redundant against linux-firmware
<apw> or ... all firmware builds are broken
#ubuntu-kernel 2016-04-13
<apw> tjaalton, i am seeing some graphics corruption in firefox in the last few kernels ... looks a bit like the sort of mushing of "active" areas what we saw when we had fence issues before
<apw> Kano (N,BFTL) dailies should now be fixed
<tjaalton> apw: what's your gpu?
<apw> Intel Corporation Broadwell-U Integrated Graphics [8086:1616]
<apw> tjaalton, ^
<tjaalton> I got a ping about https://lists.freedesktop.org/archives/intel-gfx/2016-April/092300.html
<tjaalton> yesterday
<tjaalton> you could try that, though I believe it's probably caused by the x driver
<apw> well that is a believeable description ...
<rbasak> Minor mistake in https://wiki.ubuntu.com/Kernel/LTSEnablementStack: In the 14.04.x Ubuntu Kernel Support Schedule diagram, it says 15.04 against Wily, not 15.10.
<apw> ogasawara, ^
<ogasawara> rbasak: ah, thanks, I'll fix that up
<rbasak> np. It confused me for a bit until I figured it out, so thought I'd mention it.
<ogasawara> I'll add 16.04 related diagrams while I'm at it
<rbasak> They are really helpful diagrams BTW, so thanks :)
<lamont> jsalisbury: am I stuck running a forked kernel?  bug 1543683
<ubot5`> bug 1543683 in linux (Ubuntu Xenial) "Fails to detect (second) display" [Medium,In progress] https://launchpad.net/bugs/1543683
<jsalisbury> lamont, you won't be forever.  We're still waiting for an update from upstream on how to proceed.  I'll ping em again.
<lamont> jsalisbury: ack
<lamont> jsalisbury: in the meantime, it sounds like I want xenial/current with 237ed86c reverted, yes? or do I need to also revert the partial fix, too?
<lamont> Apr 13 13:06:07 tigernut kernel: [165764.303718]  [<ffffffff81711fe8>] netdev_rx_csum_fault+0x38/0x40
<jsalisbury> lamont, yes,  xenial/current with 237ed86c reverted
<lamont> is there any way to tell with any degree of accuracy (understanding that bit rot is a real thing there) what mac the bad packet came from?
<lamont> (topic changed, of course)
<jsalisbury> hmm, I'm not sure off hand
<lamont> awk '{print $5}' /var/log/syslog | sed 's/\[.*$//' | sort | uniq -c | sort -nr | head
<lamont>   57590 kernel:
<lamont>    2668 lldpd
<lamont> because the kernel is totally winning
<lamont>    1468 snmpd
<lamont> and yes, there's undoubtedly crap wire involved in this fine vintage building
 * lamont is playing cable monkey this weekend, and would love to have a target or two to attack
<ehegnes> Does anybody know how to generate a kernel source package with a .changes or .dsc file?
#ubuntu-kernel 2016-04-14
<infinity> ehegnes: fakeroot debian/rules clean && debuild -S
<genkgo> jsalisbury: What is going with the backup thing? I don't get it. Flabbergasted.
<ehegnes> infinity: Thank you! I got that working in a round-about way with your advice.
<kirkland> on s390x, do I need to do anything to make changes take effect in /etc/zipl.conf?
<kirkland> i'm thinking of the equivalent of a update-grub or something
<kirkland> because I keep booting into a 4.3 kernel, instead of 4.4
<kirkland> apw: ^ ?
<pkern> kirkland: Running zipl
<pkern> kirkland: It's like lilo.
<kirkland> pkern: bingo, thanks!
<pkern> kirkland: I mean there might be a bug in your kernel packaging so that the kernel doesn't call zipl upon install.
<kirkland> pkern: it was a weird setup, this is perfect
<pkern> On Debian there's a /etc/kernel/postinst.d for it.
<kirkland> 1 ubuntu@ubuntu:~â« grep VXLAN /boot/config-4.4.0-1004-raspi2 .
<kirkland> /boot/config-4.4.0-1004-raspi2:# CONFIG_VXLAN is not set      
<kirkland> can someone get VXLAN turned on (or a module, rather) in that kernel, please?
<kirkland> rtg: ^
<kirkland> bjf: ^
<rtg> kirkland, looking
<kirkland> rtg: thanks.
<rtg> kirkland, patch committed, should make the release kernel
<kirkland> rtg: ack, thanks.
<bdmurray> rtg: Hi, would somebody other than colin know of a test case for bug 1547594?
<ubot5`> bug 1547594 in thermald (Ubuntu Wily) "thermald bios_locked is not initialised" [Undecided,New] https://launchpad.net/bugs/1547594
<rtg> bdmurray, unlikely. he's about the only one on the team that deals with that package
<bdmurray> rtg: okay, I'll just comment on the bug then
<infinity> bdmurray: He may not have a test case for it, it's the sort of bug that's "obviously a bug" but one might not know precisely how to make it do bad things.
<bdmurray> infinity: Yeah, I decided to actually read the patch!
<DalekSec> apw: Do you generally review how Debian does post/pre scripts in the kernel package?  Noticed they upgraded a little bit ago, and don't seem to call update-initramfs themselves anymore at that.
#ubuntu-kernel 2016-04-15
<LocutusOfBorg> hi folks, pretty please update virtualbox kernel modules for xenial?
<rtg> LocutusOfBorg, it is currently at 5.0.16-dfsg-2 - Is there some serious bug ?
<LocutusOfBorg> not sure
<LocutusOfBorg> kernel fixes for 4.6
<rtg> LocutusOfBorg, are you talking about the DKMS package ?
<LocutusOfBorg> yes, and guest-dkms
<LocutusOfBorg> uploading a new virtualbox now
<rtg> ok - so the kernel team does not maintain that package. I'm mostly concerned about the in-kernel version.
<LocutusOfBorg> oops
<LocutusOfBorg> the dkms and guest-dkms are provided by me
<LocutusOfBorg> I mean virtualbox-modules
<LocutusOfBorg> and virtualbox-guest-modules
<rtg> smb, re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1570441/comments/3 - are you saying all of those patches are relevant and should be applied as well ?
<ubot5`> Launchpad bug 1570441 in linux (Ubuntu Xenial) "Kernel Panic in Ubuntu 16.04 netboot installer" [Undecided,In progress]
<smb> rtg, I was before I realized that somehow the patch which is claimed to break things is unlikely applied to Xenial
<rtg> smb, we do have 'x86/topology: Create logical package id' in Xenial as of -18
<smb> rtg, oh ok... was I looking at the wrong branch then? I did pull master this morning...
<rtg> smb, always master-next
<smb> rtg, Ok, sorry. So if we have that one we probably want the whole bunch of fixups
<rtg> smb, it was applied for bug #1397880
<smb> :/
<ubot5`> bug 1397880 in intel "[Feature] Memory Bandwidth Monitoring" [Undecided,New] https://launchpad.net/bugs/1397880
<rtg> looks like it was a scaffold patch
<smb> If scaffold means pretty bad, yeah
<smb> Only looking at the commit messages of the follow-up it feels like a case where they realized only in hindsight how much breakage this caused
<rtg> smb, well, lemme look at those other patches as well
<smb> rtg, The Xen one was the only one that did not have a fixes lin in the commit. But then reading through the description I had a feeling it might still be better to proactively apply it too
<rtg> smb, or I could just try to revert that topology patch and fixup the memory bandwidth monitoring code.
<smb> rtg, Hm, do you think that is possible?
<rtg> smb, dunno, I'll try it out. Seems like a safer move at this point
<smb> rtg, I agree. If the monitoring can be made working without this it seems safer. 
<smb> rtg, amazing. for the amount of follow-ups this produced the change looks pretty harmless
<rtg> smb, well, there is a fair bit of code movement in that patch
<rtg> whoops, looking at the wrong one.
<rtg> you are right, it is simple
<smb> rtg, ah ok. I only saw additions
<rtg> smb, it reverts cleanly, which means the compile will likely fail 'cause there is a missing function or header
<smb> rtg, Right there was a new structure field and a bunch of functions in it
<rtg> smb, topology_max_packages is missing. that might be simple enough.
<smb> rtg, except if the monitoring is based on assumptions about available packages... 
<rtg> just checking when that appeared
<rtg> smb, drat, it all seems kind of interdependent
<cking> that's a hairball
<smb> Yeah I could imagine that bandwith monitoring is depening on some more specific topology info
<smb> So lets try all currently known follow-ups and pray/hope for the best
<manjo> apw, rtg, I am looking for an Ubuntu-4.5 tag on unstable tree ... and I am not seeing one.. if  I apply the 3 patches in http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5.1-wily/ will that be close enough to an Ubuntuized kernel ? 
#ubuntu-kernel 2016-04-16
<apw> manjo, there is not tags on unstable ... you'd be better off basing them on where you want them applied
<LocutusOfBorg> please please take the virtualbox modules from xenial and put in kernel
<LocutusOfBorg> serious fixes for xorg 1.18 and rootless mode
<LocutusOfBorg> you don't need the xorg-legacy package anymore
<LocutusOfBorg> (guest-modules of course)
<LocutusOfBorg> you can even see the patch (diff from the -2 and -3)
<infinity> Might be a bit late for that.
<apw> infinity, i guess i should at least queue those up in case there is any kind of respin for some other reaosn
 * infinity nods.
<infinity> apw: And test build it for sanity.  The update is rather... Extensive.
<apw> sigh
<apw> we love extensive changes after freeze, please bring it on
<infinity> Yup.
<infinity> apw: I love how the update script tells you how to grab and unpack the deb instead of just, y'know, grabbing and unpacking the deb.
<apw> oh it has no version
<infinity> If it took a version arg instead of a path, it could wget and unpack and import.
<infinity> Or if could just pull-lp-source the latest from the current series with no args.
<infinity> s/if/it/
<infinity> But whatever.  I just always find it entertaining when the comments of a shell script are effectively more shell script. :)
<apw> yeah lazyness on my part for sure
<infinity> "Execute these shell commands before calling this shell command."
<infinity> Err, pull-lp-source wouldn't work.  But you know what I mean.  Query the version somehow and wget from the pool, I guess.
<infinity> I wasn't being critical so much as amused, though. :)
<apw> yep, it clearly should take a version at least
<apw> LocutusOfBorg, gads why is this about 10 billion lines
<LocutusOfBorg> apw, I think the kernel module is not so extensive
<LocutusOfBorg> unfortunately I had to take the whole patch, to be safe ;)
<LocutusOfBorg> they had to implement a new driver, working with rootless xorg
<LocutusOfBorg> otherwise it wouldn't work at all
<LocutusOfBorg> looking at src/Vbox/Additions/linux changes, it isn't so scary
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=cc16e5049641855149fe9d6b091415bebcc58d3d
<LocutusOfBorg> and many fixes are ifdefs for the kernel 4.6 (sigh I already got two bug reports about people not being able to build it damn)
<infinity> Oh?
<infinity> Built fine for me.
<infinity> Won't insert, because I have secureboot enabled, but... :P
<apw> infinity, heh
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1569989
<ubot5`> Launchpad bug 1569989 in virtualbox (Ubuntu) "virtualbox-dkms 5.0.16-dfsg-2: virtualbox kernel module failed to build for kernel 4.6 [error: implicit declaration of function âpage_cache_releaseâ]" [Undecided,Fix released]
<LocutusOfBorg> I remember another one with the same issue, but on guest-dkms
<LocutusOfBorg> it affect host and guest, by sharedfolders module as you can see with a find on the above commitid on virtualbox.git
<LocutusOfBorg> that page_cache_release is used in three places
<LocutusOfBorg> infinity, you might have built only the video driver? :)
<apw> infinity, LocutusOfBorg, ok build tested and pull-request out .. if we have a respin we can try and slip it in
<LocutusOfBorg> <3 apw 
<LocutusOfBorg> apw, do you have any git link? I would like to one day understand more about the ubuntu kernel
<LocutusOfBorg> and maybe ask pull-requests by myself :)
<apw> LocutusOfBorg, is on our kernel-team@ list
<LocutusOfBorg> oh... no git?
<apw> the pull request contains the git
<LocutusOfBorg> thanks
<LocutusOfBorg> yeah
<LocutusOfBorg> so you just grab the virtualbox-guest-source and commit the files?
<LocutusOfBorg> BTW I'm not upstream, but meh :)
<apw> LocutusOfBorg, you are "my upstream" though
<LocutusOfBorg> :)
#ubuntu-kernel 2016-04-17
<post-factum> is it safe to call set_cpus_allowed_ptr under spinlock?
<denlud> Hey guys, i have a problem by building my custom Kernel.
<denlud> I want to build the Kernel 4.4.0 with the Option CONFIG_MMC_UNSAFE_RESUME in .config on
<denlud> But everytime I start to build the new Kernel he overwrites my config.
<denlud> The steps I made was: I installed a clean Ubuntu 15.10. Then i make the following commands: sudo apt-get install linux-source build-essential kernel-package && mkdir kernel && cd kernel && tar xvjf /usr/src/linux-*tar.bz2 && cd linux-source* && cp /boot/config-* .config && gedit .config && make-kpkg --initrd buildpackage
<denlud> But he overwrites my config everytime.....what am i doing wrong?
<ogra_> https://help.ubuntu.com/community/Kernel/Compile
<ogra_> (and https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel )
<denlud> I already read that
<denlud> But I dont see my fault...
<ogra_> you read the second one (your commands dont look like that)
<denlud> I red it, but i dont understand everything...
<ogra_> sudo apt-get build-dep linux-image-$(uname -r); apt-get source linux-image-$(uname -r) ... cd to the dir that command created .... fakroot debian/rules editcofigs .... select the config option you want to change ... 
<ogra_> and run: fakeroot debian/rules binary
<ogra_> that creates the new deb
<denlud> Hm
 * ogra_ vanishes back into the sunday evening ...
<denlud> Isnt it enough to edit the .config file with gedit?
<ogra_> no, you need the fakeroot debian/rules editconfig command, the configs are assembled from multiple files and each config can have dependencies ... 
<ogra_> (really off now) 
#ubuntu-kernel 2017-04-10
<hallyn> hm, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481723 is still happening to me in a zesty vm
<ubot5> Ubuntu bug 1481723 in linux (Ubuntu) "can not build kernel image from source package" [Medium,Confirmed]
<pjf> apw: Thank you for looking into the mainline kernel repo! ( #1681183 )
<apw> pjf, np.  very odd that the sync just stopped working, seems we lost a rule or something a few weeks back and as it is only am mirror things kept working
<pjf> apw: I'm just glad I found the right place to report it. :)
<leitao> I understand that the kernel for 17.04 GA is already on freeze since April 6th, right?
<leitao> Any new patch will be only accepted in next SRU, rigth?
<apw> leitao, it would normally take something boot essential to repin the kernel now in the release images.  we do sometimes queue up a day0 SRU kernel if there are urgent non-boot-essential changes.  otherwise we are in SRU mode, so in the next SRU cycle.
<leitao> apw, got it.
<apw> leitao, if you do have something you want considered we do that in the normal way, bug and email to the list
<leitao> apw, sure, I think we can way the first SRU.
<leitao> thanks!
<acheronuk> Hi. is there any documentation explaining the switch to CFQ for 4.10?
<apw> acheronuk, i believe that we did some significant testing on that, based on performance.  we moved to deadline previously because performance sucked with cfq
<apw> acheronuk, is it causing some sort of issue ?
<acheronuk> apw: no problem. just a forum user posing the question... https://www.kubuntuforums.net/showthread.php?71686-Stll-wrong-i-o-scheduler-used-in-17-04
<apw> which "right" scheduler do they want
<hallyn> apw: does anyone on kernel team do somewhat regular testing with ltp?
<apw> hallyn, ltp is a pretty poor test suite in the main
<acheronuk> apw: as usual,depends which random blog from someone who thinks they know you read :P
<apw> acheronuk, indeed they are quoting cking who is the one who does those kinds of analysis
<apw> acheronuk, and frankly they can change the default live iirc let alone at boot time
<acheronuk> they wanted kubuntu to switch from CFQ to deadline, and I just pointed out that ubuntu had just gone the other way
<acheronuk> so I was looking for a more detailed explanation
<acheronuk> that is all
<apw> i thought kubuntu was the one which was overriding us from deadline to cfq because you rely on some specific feature of cfq
<apw> something to do with being able to hammer the disk and only use idle cycles
<ogra_> yeah, wasnt that nepomu (or some other tool with N) that was indexing the disk content
<ogra_> *nepomuk
<acheronuk> apw: we have such an override in our setting, yes. that was the OP's point in the thread. they wanted us to stop that now
<apw> which as you say would leve them as cfq anyhow
<apw> but i think you needed it for reasons that deadline can never offer
<acheronuk> that decision was before I was involved
<apw> acheronuk, yeah, but i think i was involved on this side :)
<acheronuk> I'm sure :P
<hallyn> apw: yeah, that's what i thought.  but i'm pushing extension of filecaps in kernel - current filecaps tests are in ltp.  i could either extend those in ltp, or port them all to run standalone and add them to the kernel source.  (or something else)
<hallyn> advice? :)
<acheronuk> apw: anyway, just wanted to know why the change on the other flavours to CFQ now with 4.10, so I could explain why kubuntu should probably not buck the trend once again  
<hallyn> think i'll port it all to linux/tools/testing/
<hallyn> which will slow me down a bit...
<apw> acheronuk, there is a fair write up in the commit.  cking did boot and performance testing
<apw> acheronuk, for the issues we have moved away from cfq for.
<apw> acheronuk, cfq is our natural default for our work-loads "nominally"
<acheronuk> apw: yep. had just this second found it! http://kernel.ubuntu.com/git/ubuntu/ubuntu-zesty.git/commit/?id=af80b83a2b6184fea27f050948146fcd9a28070d
<acheronuk> thx
<apw> hallyn, there is some sanity in those being in the kernel self-tests in my mind
<apw> hallyn, but i think ltp is one of the tests you can in theory run, and perhaps we can engineer a run with just hte tests you add if they end up in there
<apw> hallyn, cking again is my expert at ading tests
<apw> hallyn, so can perhaps give you a more targetted answer as to which is better
<hallyn> apw: ok, thx.  i know i rarely run ltp tests (despite having written quite a few), and havne't heard of anyone who does..  now if it once gets integrated into ubuntu automated tests then maybe that's a good thing, but...
<apw> hallyn, the issue is it has a crap-ton of tests many of which fail and that is "right" and there is no way to know
<apw> hallyn, well that _was_ last time i worked with it
<hallyn> apw: yes, though you can easily specify the testsuites to run, and only run the ones you're interested in.  But if most are not interesting then it doesn't really make sense
<ogasawara> bug 1672850
<ubot5> bug 1672850 in linux-aws (Ubuntu) "[MIR] linux-aws" [Undecided,Fix committed] https://launchpad.net/bugs/1672850
<ogasawara> cyphermox: ^^ random question, I see that is 'Fix Committed', what's the next step here?  Is there anything I need to do to shepherd that over the goal line?
<cyphermox> ogasawara: not really, aside from kicking slangasek to do his magic. From that point you need an archive admin to apply the change.
<ogasawara> cyphermox: ack, thanks
<cyphermox> I guess apw could do that too
<slangasek> ogasawara, cyphermox: is it seeded in zesty?
<ogasawara> slangasek: I don't know
<slangasek> it's not in zesty at all, so that answers that
<cyphermox> no itÅ for xenial AFAIk
<slangasek> right
<slangasek> so that would've been invisible to the AA team without a ping, fwiw - doing now
<cyphermox> ah, good to know, thanks.
<ogasawara> indeed, /me makes a note, thanks slangasek
<Tahvok> Hey guys!
<Tahvok> ubuntu-support-status is showing a wrong support time for hwe kernel. For example it shows that kernel 4.8 is supported till' April 2022.
<Tahvok> I just can't find hwe-support-status package anywhere for 16.04, so maybe I used a wrong tool?
#ubuntu-kernel 2017-04-11
<Sargun> Any reason why Ubuntu doesn't turn on CONFIG_LOCKDEP?
<Sargun> or have a kernel variant with it enabled?
#ubuntu-kernel 2017-04-12
<apw> Sargun, my understanding is it is a non-trivial cost to have it enabled; as to why we do or do not have a variant with that is about build and qual time
<lostgoat> LOCKDEP is a very developer centric feature IMHO. If you are interested in lockdep, you are probably building your own kernel to begin with
<Sargun> apw: Is LOCK_STATS a expensive?
<Sargun> *as expensive
<manjo> apw, any reason why we still have CONFIG_EFI_VARS=y  now that we have CONFIG_EFIVAR_FS=y ? 
<manjo> bjf, ^
<manjo> arges, ^ ? 
<chiluk> manjo:  you probably want rtg^ highlighted on that..maybe cking..
<manjo> he is not online I checked 
<manjo> I can ask tomorrow during work hrs 
<manjo> I built and booted a kernel without efi_vars and it looks ok to me .. so looks like it is a vestige lying around 
<manjo> https://pastebin.ubuntu.com/24370187/
<manjo> this is on an arm64 system
#ubuntu-kernel 2017-04-13
<xnox> apw, cking - so i upgraded my laptop to a more recent zesty (used to be running 4.8 kernel, and finally got the 4.10 kernel)
<xnox> have you been noticing weird stuff going on with nvme drives?
<cking> xnox, my NVME drive died a while ago, so I've not seen this
<xnox> my controller gives up, and then ext4 goes nuts, fails to write a journal, and then remounts RO and then things fail.
<xnox> http://paste.ubuntu.com/24373466/
<xnox> well it looks like 4.10 is killing me; or my drive is just dieing.
<xnox> but this is like a one year laptop.....
<cking> xnox, do you force anything on like PCIe ASPM?
<xnox> cking, i'm not sure what you mean.
<apw> xnox, well if you are seeing it 'regularly' booting back to a 4.8 kernel would cirtainly tell us if it was 4.10 or not
<cking> xnox, if you don't recognise what I'm saying about PCIe ASPM then probably not
<xnox> cking, in my bios i can choose driver type for disk drive - e.g. Off, ACHI, Raid (Intel Rapid something bullshit)
<xnox> the default for RAID, but linux at the time then did not see any drives
<xnox> i am now rebooted into 4.8 and will use 4.8 for now, to see if this is reproducible or not.
<cking> xnox, I was wondering if fancy PCIe power saving is making the drive go offline
 * xnox ponders if kernel at all is at fault though
<xnox> [ 2055.007879] nvme 0000:04:00.0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff
<xnox> cannot be kernel initiated can it be? e.g. deciding to power down the drive just for funzies.
<xnox> ah that
<apw> well it depends what the 'down' in that sentence means
<cking> xnox, sometimes the BIOS may hint its fine to do it when in fact it's not
<apw> and we might have just started noticing it says we can
<xnox> hm
<cking> xnox,  "pcie_aspm=off" is the way to force it off just in case
<xnox> let me do that in my grub config
<xnox> and naturally i have lvm, and full disk encryption
#ubuntu-kernel 2017-04-14
<ccheney> anyone know if it is possible to change a setting in LnkCap on a pci device? My pcie ports apparently have 'ASPM not supported' set and I need to turn it on somehow
<ccheney> its on a skylake system
<mjg59> ccheney: It's set by either the firmware or the chipset itself
<ccheney> the FADT doesn't have aspm disabled but its not enabled on the ports or the devices, setpci seems to be able to turn it on for LnkCtl but LnkCap seems to be overriding it?
<mjg59> lnkcap represents what the link is capable of
<ccheney> mjg59: is there anyway to force enable it afterwards via initrd (similar to acpi replacement tables) or something like that?
<mjg59> ccheney: Nope
<ccheney> ugh :(
<mjg59> Not that I know of
 * ccheney kicks lenovo hard
<ccheney> so they would need to enable it during pcie setup in uefi?
<ccheney> their front line contact had a modified version of the bios that let him enable aspm but i suspect they didn't remember to enable it for the port itself, he said it didn't make any difference in temperatures, and couldn't release the test image to me to look into
<ccheney> mjg59: thank you very much for the help :)
#ubuntu-kernel 2018-04-09
<s10gopal> apw, jsalisbury TJ how to fix it https://paste.ubuntu.com/p/MJQRM28W3z/ ?
<s10gopal> anyone online ?
<s10gopal> how to patch a kernel for ubuntu ?
<f_g> s10gopal: please stop spamming, your behavour in here is very rude. asking once and waiting for a reply is how it's done - even if it takes hours or days. lots of people here are not on IRC over the weekend, so please be patient.
<s10gopal> f_g, sorry 
<s10gopal> #ubuntu
<s10gopal_> jsalisbury, bios update can fix it too ?
<dijuremo> @apw and @tyhicks: Left the DELL T3610 running prime95 torture since last week using the patched 4.13.0-38 Kernel and the machine did not freeze. So we defintively have a WINNER!
<tyhicks> dijuremo: that's great to hear - thanks for the testing feedback
<apw> tyhicks, sounds excellent, good work, it is appreciated
<tyhicks> thanks!
<s10gopal> jsalisbury: apw TJ- can you please tech me how jsalisbury revert the commit ? he did it by using patch -p1 -R < patch.txt ?  he did it by removing all information before line 23 of http://paste.ubuntu.com/p/6y3XBgs5xJ/ ?
<apw> s10gopal, more likley a git revert <sha1>
<s10gopal> thx
<s10gopal> apw, jsalisbury it do not resolves the bug.
<s10gopal> apw, jsalisbury it can be fixed ? 
<s10gopal> more kernel to test ?
<jsalisbury> s10gopal, it sounds like you're bisect may have been given an incorrect good/bad.  
<jsalisbury> s10gopal, can you run 'git bisect log' and post the output to the bug?
<s10gopal> i did git checkout v4.13 to build 4.13 kernel
<s10gopal> how to move back and get the v4.12 logs ?
<s10gopal> cd jsalisbury done http://paste.ubuntu.com/p/jHdRP8CwgX/
<jsalisbury> s10gopal, check the v4.12 branch back out and maybe the bisect info will still be ther?
<jsalisbury> s10gopal, thanks.  I'll compare that to where I was in the bisect.  We may have to start back up again where we left off.
<s10gopal> jsalisbury, i am going to sleep in 30 minutes , any kernel to test ?
<s10gopal> jsalisbury, ?
<jsalisbury> s10gopal, Not yet.  I will review the logs and figure out the next one to build.  I'll post it to the bug.
<s10gopal> jsalisbury, if battery drain will kill my battery ? any temp solution without removing battery ?
<jsalisbury> s10gopal, keep it plugged in?  Or boot one of the previous kernels that was good?
<s10gopal> boot on previous kernel is good but when i boot in older kernel on 16.04 , laptop becomes super laggy
<jsalisbury> s10gopal, The last mainline kernel you tested was 4.15.  I guess it would be worthwhile to test 4.16 to see if this bug was already fixed.  It is aviable from:
<s10gopal> jsalisbury, already tested it
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16.1/
<jsalisbury> s10gopal, since the bisect pointed to a commit that did not fix the bug when reverted, we may have to retest all of the kernels in the bisect.  
<jsalisbury> s10gopal, to make sure we didn't accidentally mark one good when it was bad or vice versa.
<s10gopal> jsalisbury, ok , which kernel i haveto test now ?
<jsalisbury> s10gopal, did you run uname -a when you booted into my last kernel that had the revert?  Just to confirm it was the correct kernel?
<s10gopal> yes it was linux gopal-HP-Notebook 4.13.0-38-generic #43 
<jsalisbury> s10gopal, Ok.  Let me build you one more kernel before we retest the bisect kernels.  I'll have it ready and posted in about 20 minutes.
<s10gopal> jsalisbury, today i have also updated my bios after testing your kernel
<jsalisbury> s10gopal, I'll post the link in the bug.
<s10gopal> jsalisbury, the commit came in git bisect is also related to battery ?
<jsalisbury> s10gopal, It's a power management commit so possibly.  I'm going to build the next test kernel with a few of those PM commits reverted.
<s10gopal> jsalisbury, need to install both files ?
<jjohansen> sforshee: http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=bionic2
<jjohansen> I still need to cleanup the commit messages and fold the a couple fixups in
<jjohansen> but it has been passing my testing
<jjohansen> also would you like the fixes from the 4.17 PR thrown on top or done as a separate pull request
#ubuntu-kernel 2018-04-10
<sforshee> jjohansen: it doesn't matter much to me if it's all one PR or separate, whatever is most convenient for you
<jjohansen> sforshee: okay, I'll get something together after I get my kids to bed
<jjohansen> sforshee: sent, I didn't include the apparmor fixes, I'll send those once I have the 4.17 shas
#ubuntu-kernel 2018-04-11
<s10gopal> jsalisbury, apw 4.13.0-38-generic #43~lp1745646ThreeRevert fixed the bug
<jsalisbury> s10gopal, that's good news.  So multiple commits are at fault here.  That kernel had 3 reverted, so I have to review them to narrow it down further.  I'll post another kereel in a bit.
<s10gopal> jsalisbury, :) it will be fixed on ubuntu 18.04 ?
<jsalisbury> s10gopal, eventually. Still more work to do first.
<ntd> anyone alive? both hwe-16.04 and -edge are broken for thousands
<TJ-> ntd: bug report reference?
<ntd> and if you publish 18.04 with current kernel you're in for a nasty surprise
<ntd> lemme dig em up, red hat/centos went through these issues a while back
<TJ-> ntd: we're not seeing any reports in #ubuntu+1 or #ubuntu
<ntd> it's not like i haven't tried to mention these issues
<ntd> i was referred to this channel which has been dead at every visit
<ntd> https://bugzilla.redhat.com/show_bug.cgi?id=1549042
<ubot5`> bugzilla.redhat.com bug 1549042 in xorg-x11-drv-intel "Kernels 4.15.x are not booting on docking" [High,Closed: errata]
<TJ-> ntd: that's not an Ubuntu bug report
<ntd> broad strokes, every => haswell thinkpad user with a dock won't be able to boot
<ntd> still applies to your kernel
<ntd> and between 4.13.0-37 and -38 networkmanager no longer works for wired interfaces for the same users
<ntd> TJ-, they fixed it, you haven't. who can i talk to about this?
<TJ-> ntd: we need an Ubuntu bug report and the evidence from logs and so forth
<ntd> you have a redhat bugreq with three duplicates with logs and such
<ntd> and since the system won't boot, how are users supposed to provide relevant logs?
<ntd> TJ-, any such system won't boot and there will be no screen output
<TJ-> ntd: we're already carrying the patch
<ntd> as of version?
<TJ-> it's in master-next
<ntd> ok, which version number will this be? current is 4.15.0-13
<TJ-> It'll be the next release
<ntd> k, thanks
<ntd> i saw BB beta2 yday, fixed kernel?
<ntd> TJ-, now, for 4.13.0-38 breaking networkmanager for wired NICs?
<TJ-> !bug | btd
<ubot5`> btd: If you find a bug in Ubuntu or any of its derivatives, please report it using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs.
<TJ-> oops, typo!
<jjohansen> sforshee: I still don't have upstream sha1s for the apparmor bug fix pull, should I wait a few hours, or pull a patchset together without the upstream shas1
<sforshee> jjohansen: are they in a maintainer tree? Even if not we can apply them as sauce though.
<jjohansen> sforshee: yes, and the pull-request is upstream, its just waiting for them to be merged. I know we can do them as sauce, its just nice to have upstream shas
<jjohansen> but it is getting very late
<sforshee> jjohansen: you can cherry pick them from the maintainer tree and make the provenance say "cherry picked from commit xxx <git-url>", we do that quite frequently
<jjohansen> yeah I'll do that
<sforshee> plenty of examples if you run git log
<TJ-> will ubuntu-bionic/master-next make it's way to  xenial hwe-edge packages?
<sforshee> TJ-: yes, around the same time it makes it's way into bionic
<sforshee> so if it's in the current -proposed kernel that should be fairly soon
<sforshee> if not a bit longer
<TJ-> sforshee: thanks. That clears up my last check vis-a-vis ntd's 'bug report' earlier today about the docking station 4.15 bug
<sforshee> TJ-: yeah that one is not in -proposed I think. We'll likely spin a new kernel for -proposed before much longer, with the kernel freeze being tomorrow and all
<TJ-> iirc the commit is currently at HEAD in master-next, or was a few hours ago
<sforshee> not anymore, we've shoved a lot of stuff on today
<TJ-> I start early :)
<sforshee> the last minute rush before kernel freeze
<jjohansen> sforshee: sent
<sforshee> jjohansen: thanks
#ubuntu-kernel 2018-04-12
<Whoopie> Hi, LocutusOfBorg asked me to address a current issue here: the kernel now has the modules for a Virtualbox guest included by default. What is missing, is the udev rule which is part of the virtualbox-guest-dkms package. I recommended to put it into the virtualbox-guest-x11 or virtualbox-guest-utils package. What's your opinion on that?
<TJ-> Whoopie: it doesn't sound like something for the -x11 package, that's GUI/X-server specific isn't it?
<Whoopie> yes
<Whoopie> there're the libraries for 3D acceleration and some config files.
<Whoopie> TJ-: in the virtualbox-guest-utils package, there's also /sbin/mount.vboxsf, which doesn't work properly without the udev rules.
<TJ-> Whoopie: that seems to seal the decision then :)
<Whoopie> or put the udev rule into the kernel package?
<TJ-> I don't think so - the linux-image-* packages don't carry any udev rules currently
<LocutusOfBorg> problem is the dependency chain
<LocutusOfBorg> dpkg depends on utils, not the opposite
<TJ->  is it for /lib/udev/rules.d/60-virtualbox.rules ?
<Whoopie> TJ-: /lib/udev/rules.d/60-virtualbox-guest-dkms.rules
<Whoopie> LocutusOfBorg: but -x11 depends on -utils, so it's always installed.
<TJ-> dpkg depends on it?
<LocutusOfBorg> people might have the utils without x11 and without dkms
<TJ-> oh, DKMS not dpkg you meant?
<LocutusOfBorg> yep
<LocutusOfBorg> virtualbox-guest-dkms
<Whoopie> LocutusOfBorg: then it doesn't hurt at all.
<TJ-> hang on, if the kernel module is now in the linux-image then is there any need for virtualboc-guest-dkms at all? ?
<LocutusOfBorg> TJ-, probably none, except for udev
<TJ-> I don't see anything in the virtualbox-guest-dkms other than the udev rule that needs relocating, so that package could become virtual/meta(?) if the udev rule moved to virtualbox-guest-utils. 
<LocutusOfBorg> well, I don't usually trust the module on the kernel, I mean, kernel updates might break stuff, I prefer to have the possibility to choose my version in case of issues
<LocutusOfBorg> the kernel modules are not mainline, they are updated from time to time
<TJ-> My observations - probably needs someone more aware of the intricacies of package reorg than me, but I don't think the udev rule belongs in the linuximage package - certainly no others are currently
<TJ-> LocutusOfBorg: ahh, i see, so just move the udev rule to virtualbox-guest-utils and keep guest-dkms as is otherwise
<TJ-> if v-g-d gets installed on it's own with no other VB guest packages that's just the same as having linux-image-* installed; the udev rule is only required when of the v-g-{utils,x11} packages is installed, and -x1ll depends on -utils, so that sounds correct
<TJ-> s/when of/when one of/
<LocutusOfBorg> so x11 depends on utils, utils depends on dkms/source/virtual meta package
<LocutusOfBorg> and the dkmd itself doesn't depend on anything else
<LocutusOfBorg> *dkms
<LocutusOfBorg> because also guest-source might provide kernel modules
<LocutusOfBorg> "virtualbox-guest-modules" is provided by virtualbox-guest-dkms, virtualbox-guest-source -> (the deb created after the build), and the one provided by src:linux
<TJ-> how will it work if the -dkms is installed - the kernel will have 2 identical modules, does modprobe know to prefer the /lib/modules/*/updates/dkms/ path to /lib/modules/*/kernel/ ?
<LocutusOfBorg> yes the kernel will prefer the updates
<LocutusOfBorg> I also patched dkms to not error out in case there is already one installed
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/dkms/2.3-3ubuntu5
<TJ-> how does depmod handle that? there'll be 2 modules with identical symbols/aliases won't there?
<LocutusOfBorg> the updates version is preferred, depmod knows that newer kernel modules might appear
<LocutusOfBorg> we hacked some versioning inside the module, to make them differ in version
<LocutusOfBorg> that dkms upload was to fix exactly that versioning check
<TJ-> yeah, just been playing about with it to check
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/virtualbox/5.2.8-dfsg-7/buildlog
<LocutusOfBorg> let me see
<LocutusOfBorg> Whoopie, TJ- uploaded in unstable, will sync in Ubuntu if nobody complains
<LocutusOfBorg> thanks for your help!
<LocutusOfBorg> https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=a58ce37a83a281baa85db238d28e6bc82b49114c
<LocutusOfBorg> this is the diff
<LocutusOfBorg> fortunately the udev rules has packagename in filename, so the mangling avoids me to add breaks+replaces
<LocutusOfBorg> apw, ^^ so now we should have fixed that issue in the kernel
<LocutusOfBorg> thanks to Whoopie and TJ- :)
<apw> LocutusOfBorg, sounds good, i think
<Whoopie> LocutusOfBorg: thank you!!!
<Whoopie> LocutusOfBorg: "Make the guest-utils depends on dkms not vice-versa" -> so -utils always installs -dkms?
<LocutusOfBorg> nope, utils depends on -dkms | -source | virtual version provided by dkms or source or kernel
<LocutusOfBorg> virtualbox-guest-dkms (= ${source:Version}) | virtualbox-guest-source (= ${source:Version}) | virtualbox-guest-modules,
<LocutusOfBorg> thi is the dependency
<LocutusOfBorg> actually I could even remove and just depend on "virtualbox-guest-modules", because it is already provided by dkms
<LocutusOfBorg> the problem is that installing guest-source is not sufficient to have a kernel module
<LocutusOfBorg> you have to install guest-source, use module-assistant to build a custom .deb kernel module file, and then dpkg -i it (and this custom deb has the "Provide: virtualbox-guest-modules" )
<LocutusOfBorg> so, depending on guest-source is theoretically wrong
<Whoopie> ok, thanks for the explanation.
<LocutusOfBorg> but I couldn't find a better 
<s10gopal> jsalisbury, tworevert is bad
<phil42> if bionic will be on kernel 4.15,  why wasn't a longterm kernel chosen?
<TJ-> phil42: because the mainline release cadence doesn't match Ubuntu releases.
 * trippeh_ mumbles something about people wanting support for the latest radeons and stuff
<phil42> it just seems to me like letting the kroah-hartman et al backport the fixes would be better
<TJ-> The kernel team already does that and a lot more
#ubuntu-kernel 2018-04-13
<purple1> can 64bit binars run on 32bit with some emulator
<smeso> yes, you can use qemu
<aaa_> Cannot join #mysql (You are banned).
<aaa_> :'(
<apw> phil42, what TJ- said, you traid one kind of backporting for another, backporting lots of needed h/w changes against backporting fixes in the life of the release
<apw> phil42, generally speaking ubuntu prides itself on having the latest of things in its releases
<phil42> idunno,  just seems a longterm kernel would be better for a longterm release
<apw> phil42, it we didn't have people supporting the kernel you would be right, but we do
<phil42> still...
<apw> you can make your own kernel on 4.14 if that makes you happy 
<phil42> no, thanks anyway
<apw> all they are doing in upstream stable is collecting patches marked for stable
<apw> that isn't in and of itself a hugly hard task, yes there are some backports to be done
<TJ-> phil42: kernel.org LTS kernels are intended for embedded device manufacturers in the main, so they can easily add security/bug fixes without needing to do major changes, which should feed through to device owners being able to receive security updates
<apw> but it is a patch collection process
<TJ-> Devices where the hardware isn't changing
<apw> and yes, us taking 4.15 is more work for us no doubt about it
<TJ-> And where the manufacturer doesn't have kernel developers, just devs who can tweak and package it
<apw> but it meets our goals for hardware support
<phil42> that's all i'm saying
<apw> we are already carrying huge backports for things even in 4.15
<apw> and even then the oem people are getting ahead of us
<purple1> smeso what is the package name?
<apw> but particularly after the meltdown nightmare we have thought hard about it
<phil42> they say being a night owl is bad for your health
<purple1> how finding the iso with 64bit 14.04 LTS, running the 3.13.0-57-generic kernel.          
<purple1> ubuntu has simple beginner webpage
<purple1> not sort by kernel version
<TJ-> apw: meltdown vis-a-vis backporting to 4.4/4.13 ? 
<apw> yeah, getting non-aligned kernels fixed was clearly more work than those in sync
<phil42> 3.13.0-57 was near june 19, 2015
<apw> though with some wood tapping and crossing of things we won't have anything of that magnitude for a few years
<purple1> yeah phil42
<purple1> old hardware
<purple1> what 64bit cpu I have
<purple1> tested on that kernel 
<purple1> how finding
<TJ-> purple1: via old-releases, see for 14.04.0 (original release) http://old-releases.ubuntu.com/releases/14.04.0/
<TJ-> purple1: go up to the parent directory to see *all* release versions
<TJ-> apw: are you aware of issues with nouveau ? We're seeing quite a few users in #ubuntu+1 reporting severe problems on some devices, segfault-ing, or "trapped write/read" spam in the thousands, causing failure to boot.
<purple1> searched hard for the even older hp factory ubuntu with the mobile internet interface
<purple1> the newer versions gloss over rare hardware
<purple1> how can tell if it has the same kernel version
<purple1> before download near 1gb
<phil42> i doubt it does,   the dates don't match
<phil42> maybe try it,  it might also work
<TJ-> purple1: read the matching .manifest file which lists all included packages and their versions
<TJ-> purple1: shows me "linux-image-3.13.0-24-generic 3.13.0-24.46" for  in ubuntu-14.04-desktop-amd64.manifest
<purple1> how finding which pack contains iso-hybrid
<TJ-> purple1: all ISOs are hybrid images. They are designed to boot in ISO-9960/El Torito, BIOS/MBR, BIOS/GPT, UEFI/MBR UEI/GPT modes
<purple1> file says dos mbr
<TJ-> purple1: you should move to the #ubuntu channel; this channel is for kernel development issues
<apw> TJ-, i have not heard any complaints on nouveau no, i'll ask about
<apw> TJ-, any particular series ?
<apw> oh is #ubuntu+1 bionic focused
<TJ-> apw: it's generally the new beta testers
<TJ-> apw: might be something that'll appear more as folks start trying/installing 18.04
<TJ-> apw: yes, #ubuntu+1 is for people testing the in-devel version 
<TJ-> apw: in some cases it could be due to not having the (restricted) Nvidia firmware blobs
<purple1> sounds like bs
<purple1> you call that focused?
<apw> sforshee, ^ for awareness
<apw> who
<eyal> Hello! you probably get this asked frequenty, so apologies if this is documented (i have gone through the FAQ/triage texts). Anyway, I have filed a kernel bug report at the end of January, and have seen no indication of anything on it.
<eyal> The texts do indicate some automatic script is doing initial triaging... but haven't seen anything of the sort :)
<jsalisbury> eyal, what is the bug number?  I'll take a look.
<eyal> jsalisbury: bug #1746474. thanks!
<ubot5`> bug 1746474 in linux-hwe (Ubuntu) "unregister_netdevice: waiting for eth0 to become free. Usage count = 5" [Undecided,New] https://launchpad.net/bugs/1746474
<jsalisbury> eyal, ahh, wasn't on my radar because it was filed against linux-hwe instead of linux.  I"ll build a test kernel with that commit and post it to the bug.
<eyal> jsalisbury: cool. thanks. fwiw i filed it using 
<eyal> 'ubuntu-bug linux', so you could have more of those :)
<jsalisbury> eyal, ok, thanks
<tomreyn> -hwe has 200 "new" bug reports
#ubuntu-kernel 2018-04-14
<jjohansen> sforshee: heads up I am sending a patch for https://bugs.launchpad.net/apparmor/+bug/1750594, its really important to the snappy team and they are going to be poking leann
<ubot5`> Ubuntu bug 1750594 in AppArmor "Eventual OOM with profile reloads" [Undecided,Confirmed]
<jjohansen> the fix is pushed to http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=lp1750594
<jjohansen> and it will be on the ml in a minute
#ubuntu-kernel 2019-04-08
<LocutusOfBorg> hello folks, can you please sponsor the fix for bionic/cosmic? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921 ? anything we should do to have it?
<ubot5`> Ubuntu bug 1798921 in linux (Ubuntu Cosmic) "sky2 ethernet card don't work after returning from suspension" [Undecided,New]
<socratis> Hello everyone, slight problem with my Mint 19 (based on 18.04) and its sleep-wake-NoNetwork problem. Two Marvell 88E8053 with the "sky2" driver, both lose their network with a "Network cable disconnected".
<socratis> I found this workaround script that works great (https://askubuntu.com/questions/1029250/ubuntu-18-04-ethernet-disconnected-after-suspend) but it seems to me that it's a bug.
<socratis> And then I found the exact bug for the exact "sky2" driver: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921
<ubot5`> Ubuntu bug 1798921 in linux (Ubuntu Cosmic) "sky2 ethernet card don't work after returning from suspension" [Undecided,New]
<socratis> Now, since the Linux world is something far in the past for me, that I took a renewed interest upon, and since I'm on Mint but all the fingers point to Ubuntu, how does one handle this? What am I supposed to do? Create a new Mint ticket? Tag along the existing Ubuntu one? 
<socratis> Ticket 1798921 talks about the issue being fixed a week ago, on 2019-04-02, but it's only available on kernel 4.4.0-145.171. What's the norm in these situations? Do the changes/fixes propagate? Should I just stick with the workaround script and forget about the whole thing?
<socratis> TIA for any thoughts/comments on this...
<LocutusOfBorg> hello folks, can you please sponsor the fix for bionic/cosmic? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921 ? anything we should do to have it?
<ubot5`> Ubuntu bug 1798921 in linux (Ubuntu Cosmic) "sky2 ethernet card don't work after returning from suspension" [Undecided,New]
<LocutusOfBorg> socratis, I asked this before your join
<socratis> Ah, thanks LocutusOfBorg!!!
<socratis> It needs a ... sponsor? Like the Olympics? MasterCard and Heineken? :D
<socratis> Generally speaking, if I find an issue with the kernel, should I be talking to the Mint people or the Ubuntu people? Do the Ubuntu people "hate" the Mint people/distro? ;)
<LocutusOfBorg> arighi, ^^ maybe you are the best person to answer this... can you consider adding that one-line patch on next bionic/cosmic update?
<LocutusOfBorg> socratis, the kernel should be the same, so "we" are the best people to ask
<socratis> Excellent! Nice to know...
<LocutusOfBorg> smb, since you fixed it on trusty... may I ask why you didn't forward the patch to bionic, cosmic and disco?
<socratis> Funny you should mention that "nickname", I'm trying to solve a read-only SaMBa share issue! :D
<socratis> Oh, and since I have your attention, and since this is the Ubuntu channel, and since we've known each other for a long time from the #vbox channel...
<socratis> LocutusOfBorg: Did you get any reports from people that couldn't install VirtualBox 6.0.x on Ubuntu 16.04 LTS?
<socratis> Just since yesterday, I've had 3 reports already!
<socratis> (methinks I should double-post in #vbox or #vbox-dev just to be safe...)
<LocutusOfBorg> socratis, lets move on vbox
<socratis> Okie dokie...
<smb> LocutusOfBorg, if you talk about the sky2 bug, that was xenial. And as to why not port to newer releases, it seems nobody reminded us (in the sense of having the issue with those kernels) and there was just too many other things going on
<socratis> I do! Put me on the list smb... ;)
<LocutusOfBorg> smb, I see disco is already ok, so it should be a matter of bionic and cosmic, if you can add it to the patch queue...
<socratis> I'm simply a n00b in this and I didn't even know whether I should first talk to the Mint people (Mint19 here), the Ubuntu people or the kernel people...
<smb> LocutusOfBorg, I had already added nominations for those to the bug report. We will see whether this would be an easy pick. socratis you probably can help by adding a comment about having this on bionic/cosmic
<socratis> Okie dokie... On it. I have to register, right? (of course...)
<apw> socratis, is how we control spam indeed
<socratis> I know... ;)
<smb> socratis, ok, looks like simple pick and I sent it to our mailing list (the sky2 patch). So it should make it at some point
<socratis> Excellent! Thanks smb...
<TJ-> Is there a known issue with linux-headers-hwe-lowlatency-18.04-edge from bionic-proposed, via linux-headers-5.0.0-8-lowlatency, which is preventing DKMS module builds due to missing symlink targets. E.g. "lrwxrwxrwx 1 root root 39 Mar 19 21:22 /usr/src/linux-headers-5.0.0-8-lowlatency/block -> ../linux-hwe-edge-headers-5.0.0-8/block" ? apt-file search does not find the target path and I cannot find it
<TJ-> in a .postinst script either 
<smb> since edge is now coming from disco... sforshee, cascardo ^?
<cascardo> I will look at that soonish
<sforshee> TJ-, cascardo: I just downloaded and extracted linux-headers-5.0.0-8-lowlatency_5.0.0-8.9~18.04.1_amd64.deb and the symlink is there
<TJ-> sforshee: hmmm! let me check what's installed again
<TJ-> sforshee: whih package do you see the target path (/usr/src/linux-hwe-edge-headers-5.0.0-8/block) being installed/created from ? I can't see it here with the same package installed (Installed: 5.0.0-8.9~18.04.1) 
<sforshee> TJ-: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/16519051/+files/linux-headers-5.0.0-8-lowlatency_5.0.0-8.9~18.04.1_amd64.deb
<sforshee> I just downloaded and extracted it, I did not install it
<TJ-> sforshee: I don't see the path in the data.tar.gz of that package
<sforshee> $ wget https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/16519051/+files/linux-headers-5.0.0-8-lowlatency_5.0.0-8.9~18.04.1_amd64.deb
<sforshee> $ dpkg-db -R linux-headers-5.0.0-8-lowlatency_5.0.0-8.9~18.04.1_amd64.deb ext
<sforshee> $ ls -l ext/usr/src/linux-headers-5.0.0-8-lowlatency/block
<sforshee> lrwxrwxrwx 1 sforshee sforshee 39 Mar 19 16:22 ext/usr/src/linux-headers-5.0.0-8-lowlatency/block -> ../linux-hwe-edge-headers-5.0.0-8/block
<sforshee> TJ-: ^
<sforshee> typo, s/dpkg-db/dpkg-deb/
<TJ-> I got that one :D
<TJ-> as in, the typo
<sforshee> funny thing is that it was a copy/paste, so I have no idea where it went
<TJ-> sforshee: Sometihng weird going on, I replicated your commands and there is no ./usr/src/linux-hwe-edge-headers-5.0.0-8/ created
<TJ-> sforshee: in case there is some confusion here, the sym-links are there, the *target* is missing
<sforshee> TJ-: ok, I misunderstood I thought you said the symlink was missing
<TJ-> sforshee: no, target of the symlinks are all 'dead', and I can't find which package is supposed to install to /usr/src/linux-hwe-edge-headers-5.0.0-8/ 
<sforshee> TJ-: yeah that does look like a problem, I'd expect those headers to come from linux-headers-5.0.0-8 but that also produces symlinks
<sforshee> cascardo: ^
<TJ-> phew! not me going lala!
<TJ-> It knocked out wireguard else I wouldn't have noticed, which was unexpected since there is no problem with the mainline 5.0 builds and the OS had switched on last reboot
<sforshee> it should have been caught in testing, but it looks like adt has never run for that kernel for some reason
<cascardo> yeah, so I will look at the problem there, and probably have it fixed on a 5.0.0-9 upload
<sforshee> cascardo: or -10, I built a -9 in bootstrap but there's an apparmor regression that needs fixing so I don't plan to put that into -proposed
<sforshee> cascardo: for the main kernel that is, I didn't build an hwe-edge kernel
<cascardo> sforshee: ack, will work on the fixes, and wait for a -10 before rebasing
<cascardo> sforshee: I will drop snapdragon altogether from main and meta package
<sforshee> cascardo: hmm now that brings up a problem, I guess we've had hwe/hwe-edge packages for snapdragon but will not have them moving forward
<sforshee> apw: ^ any suggestions on how to handle that?
<apw> sforshee, keep building them in the -hwe ?
<cascardo> for the main package, I don't think that's an easy thing to do
<sforshee> apw: even if we don't expect they will work?
<cascardo> during rebase for 5.1, I had to drop them all, lots of snapdragon patches causing build failures
<apw> hmmm, are you intending to break them
<apw> oh
<sforshee> we dropped support for snapdragon from the main kernel branch and are using a topic branch now
<apw> we might need to ask pp for a 5.1 version
<apw> or whatever hwe is
<cascardo> and we will have double the work?
<sforshee> whatever we had for 5.0 was never confirmed to work, afaik
<cascardo> maybe we could have the hwe meta package point to the generic arm64 one
<apw> cascardo, that is at an older version no ?
<cascardo> though that would likely not work, or have lots of "bugs"
<sforshee> I think he means the generic arm64 5.0 kernel
<cascardo> yep
<apw> we signed up for double the work when we split it out ...
<cascardo> otherwise, just keep them at an older version, ie, do not provide a new meta package
<apw> that effectivly abandons them without cves
<apw> we will have a 5.1 and so on linux-snapdragon, right ?
<sforshee> I'm assuming we will
<cascardo> I don't disagree. but if we love those snapdragon hwe users so much, we will take not only double the work, but risk regressions for other users of the master kernel
<cascardo> apw: would you suggest we provide yet another repo for a snapdragon-hwe?
<sforshee> it's sounding to me like we'll have to start producing linux-snapdragon-hwe packages
<cascardo> based on disco/linux-snapdragon, for example?
<apw> cascardo, i am struggling to see how we can avoid doig something, if we supported snapdragon in an hwe kernel
<sforshee> too bad we just didn't support it
<apw> we may be able to leave them on this version and not roll them, but it is this version we are breaking
<apw> its a problem indeed, if we had never had hwe version of it, we would be better off
<apw> sforshee, you could look at the anonuncement to see if we ever said we supported it on snapdragon
<apw> sforshee, whetner we might expect anyone to be using it
<sforshee> apw: which announcement would that be? I do wonder whether anyone uses it at all
<apw> sforshee, that is the worry, that you have to do it, and it is never used
<sforshee> apw: I'm just wondering where we would have announced it. In the release notes for one of the point releases maybe?
<apw> sforshee, yeah it would be the point release announcement i guess
<apw> sforshee, that is the only place i can imagine it could have been listed
<sforshee> apw: it's all your fault - bug 1798352 ;-)
<ubot5`> bug 1798352 in linux-meta-snapdragon (Ubuntu Cosmic) "linux-snapdragon: missing meta packages for this flavour" [Critical,Fix released] https://launchpad.net/bugs/1798352
<apw> sforshee, i am sure i didn't do that off my own bat; i imagine i was doing it because someone noticed
<sforshee> apw: yeah and it wasn't just for -hwe. That bug was mentioned here - https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes/ChangeSummary/18.04.2
<sforshee> that's the closes I've found to us announcing anything
<sforshee> *closest
<apw> sforshee, yeah that was an adam request iirc
<cascardo> right now, 5.0 will work just fine with snapdragon, we haven't dropped patches yet
<cascardo> so, we could just leave them as it is, until we get to later kernels, like 5.1
<sforshee> cascardo: I did drop the patches. We could reapply them, but I had already had to drop some because of conflicts. Afaik the support we had in the 5.0 master kernel was never tested at all
<sforshee> even if we dodged the issue that way for 5.0 we have to solve it later
<cascardo> yeah, so we'd better just have that linux-snapdragon-hwe instead of reapplying them. if there are conflicts, it's not worth fixing them
<cascardo> TJ-: found the cause for the missing files on the headers package, will fix it on the next upload
<cascardo> apw: so, I will follow up with dropping the snapdragon flavour from the bionic/hwe-edge kernel, we'll have to sort it out some other way
<TJ-> cascardo: great news :)
#ubuntu-kernel 2019-04-09
<amitk> cascardo: apw: what does linux-snapdragon contain support for? db410c?
<amitk> cascardo: apw: Just FYI, we have an interest in getting the qualcomm 850-based windows laptop supported by distro out of the box (5.2/5.3 should just boot on it, if either becomes an LTS)
<|bkw|> Hello, is it possible to self-sign a kernel from mainline ppa, using a local self generated and enrolled cert? Perhaps with dkms? Or by extracting and repacking the deb before install? I am maintaining a fork of ukuu and it is a user request. (github.com/aljex/mainline)
#ubuntu-kernel 2019-04-10
<apb1963> 16.04, I'm experiencing weirdness.  I did a cp 18.04-image /dev/sdd and then installed it on a different machine ("blue"), booted it and all was well.  Then I realized I goofed and created the wrong username for myself; worse my password wasn't working; another goof?  So I figured I'd just reinstall; so I reinserted the USB flash drive and long story short, it wasn't booting off the USB.  So I brought it back to this machine 
<apb1963> (yellow) and did some testing.  I can mount /dev/sdd1 and ls shows files living there.  fdisk -l fails to show /dev/sdd    fdisk /dev/sdd1 shows multiple (secondary??) partitions on this 16GiB flash drive, adding up to over 1TiB.  gparted /dev/sdd1 shows 56MiB and an unknown filesystem, nothing else.   Using the exact same command as before, when it worked: cp ubuntu-18.04.2-desktop-amd64.iso /dev/sdd
<apb1963> cp: cannot create regular file '/dev/sdd': No medium found.  So I'm a bit conflexed.
<nacc> cascardo: any update on that makedumpfile update? I did another look (for something unreleated and ... `makedumpfile` seems to not support anything greater than 4.14.8 ...?
<nacc> the bionic version thereof. That seems like a rather glaring issue :)
<cascardo> nacc: it does support 4.15 bionic kernel
<nacc> cascardo: does that go through a different path? just looking at value of LATEST_KERNEL
<nacc> cascardo: just looking athe changelog entry for 1:1.6.3-1 ...
<socratis> Hey everyone, really n00b here, not sure if I'm on the right channel to begin with, feel free to correct me... On my Grub menu, I have (for example) two entries: 4.18.0-17 and 4.15.0-47. If I boot on either of those, and update the system, will I be updating 4.18* and 4.15* respectively? I.e. two different "generations" of the kernel? TIA.
#ubuntu-kernel 2019-04-11
<HFSPLUS> WHy isnt xfs defualt?
<cascardo> nacc: about the LATEST_KERNEL on makedumpfile, that should only cause a warning
<nacc> cascardo: understood, just ... confusing :)
<nacc> cascardo: and based upon upstream, does imply there might be dragons?
<cascardo> I would say that even if they tell you it is supported, there are going to be dragons!!
<nacc> heh
<nacc> cascardo: yeah after reading the source i see that it's just a warning.
<apb1963> 16.04, I'm experiencing weirdness.  I did a cp 18.04-image /dev/sdd and then installed it on a different machine ("blue"), booted it and all was well.  Then I realized I goofed and created the wrong username for myself; worse my password wasn't working; another goof?  So I figured I'd just reinstall.  I reinserted the USB flash drive and long story short, it wasn't booting off the USB.  So I brought it back to this machine 
<apb1963> (yellow) and did some testing.  I can mount /dev/sdd1 and ls shows files living there.  fdisk -l fails to show /dev/sdd    fdisk /dev/sdd1 shows multiple (secondary??) partitions on this 16GiB flash drive, adding up to over 1TiB.  gparted /dev/sdd1 shows 56MiB and an unknown filesystem, nothing else.   Using the exact same command as before, when it worked: cp ubuntu-18.04.2-desktop-amd64.iso /dev/sdd
<apb1963> cp: cannot create regular file '/dev/sdd': No medium found.  So I'm a bit conflexed.
<apb1963> ugh.  Meant to post this in #ubuntu, not here.  Sorry.
#ubuntu-kernel 2019-04-13
<electro2> hi all
<electro2> i'm trying to adapt a module with the new api libusb of the 4.9.0 kernel
<electro2> do you know what about the new libusb api ?
<electro2> i'm in two channel : here and linux-kernel
