[00:13] <doctormo> Ah found it, backports-modules damn it
[00:23] <ogasawara> rtg: so doko submitted bug 285779 yesterday.  patch is upstream to cherrypick.  what's the possibility of getting it into Intrepid prior to Intrepid final or will it need to wait as an SRU post Intrepid release?
[01:47] <TheMuso> Does anybody know how I may be able to debug an ExpressCard slot that seems to not be hot-pluggable in Linux? shpchp is loaded, but I have to start Linux with an ExpressCard in the slot for it to be detected and its driver loaded.
[02:25] <rtg> ogasawara: the xfs barrier detection patch is in 2.6.27.2, all of which I cherry-picked last night. 
[02:25] <ogasawara> rtg: ok cool.  thanks
[02:25] <rtg> wandering off now...
[06:11] <nigel_c> Apart from adding/removing/changing symbol exports, does anything else affect the ABI?
[08:18] <amitk> Ng: the boot crashes seem to automagically disappeared with the fix for e100e...
[08:36] <nigel_c> NCommander: got it building; thanks for the pointer. Now I'm seeking to figure out abi issues (as you'll see from above)
[09:09] <abogani> amitk: Sorry to bother you. I have a little question about lrm: Who could help me?
[09:12] <amitk> abogani: what is it about?
[09:13] <abogani> amitk: In debian/copyright i can find right information about broadcom and ltmodem but nothing about madwifi.
[09:15] <abogani> I know it is a silly thing but my package is blocked by that!
[09:16] <amitk> abogani: i though BenC fixed the copyright in the last upload. Maybe it still needs work
[09:18] <abogani> amitk: Where you downloaded that code? www.madwifi.org?
[09:20] <amitk> abogani: yes
[09:20] <abogani> amitk: Thanks. Sorry for disturb.
[09:20] <amitk> abogani: no worries
[09:25] <Ng> amitk: yeah, I guess it kinda makes sense that yanking a weird corruption causing bug settles down some other weird corruption issues :)
[09:25] <Ng> so now I'm down to just two weird bugs :)
[12:55] <NCommander> amitk, hola
[13:06] <amitk> NCommander: ahoy
[13:11] <NCommander> amitk, I plan on attending today kernel team meeting, SHould I add my work on the ports and lpia kernel to the team reports page?
[13:12] <amitk> NCommander: Team reports are generally meant for Canonical kernel developers to let community know what we've been upto
[13:13] <NCommander> I see.
[13:13] <amitk> But you could add a line to meeting agenda regarding your work on ports
[13:14] <amitk> and announce your intentions so that other developers know whats coming and there is less duplication of effort
[13:15] <rtg> amitk: are you having any success with ath5k?
[13:15] <NCommander> amitk, if I wish to apply to the kernel team, does that get brought up at the meaning or ...?
[13:16] <amitk> rtg: not really. We need new stuff from upstream. Are you done yet? :)
[13:16] <amitk> NCommander: wish to apply as in get an account on kernel.u.c?
[13:17] <rtg> amitk: I uploaded LBM, but I'm not sure its much better. I need to work on some key repeat issues today, so don't know if I'll get to it.
[13:18] <amitk> rtg: ar2424 loads up both ath5k and madwifi. Do we check for PCI id uniqueness in our driver lists? modules.alias perhaps?
[13:18] <NCommander> amitk, well, isn't that what kernel team membership is?
[13:18] <amitk> NCommander: BenC has already mentioned he is handling your account creation, right? 
[13:19] <NCommander> right, but I didn't know if this was like other teams where you had to be formally voted in or
[13:19]  * NCommander should just say he's extremely lost ;-)
[13:19] <rtg> amitk: there is no PCI uniqueness, which is kind of a problem. you don't know if madwifi supports the NIC until it looks at the RF chip.
[13:19] <amitk> NCommander: no it isnt. It will be done. Account creation processes take some time.
[13:19] <NCommander> oh, ok
[13:20]  * NCommander knew it took time, just wanted to make sure there wasn't nothing else I had to do
[13:20] <NCommander> I look forward to improving ports :-)
[13:20] <amitk> NCommander: I mean there is no voting. You have been 'approved' :)
[13:20] <NCommander> woooo
[13:20] <NCommander> amitk, and now ports has a 2.6.27.2 based kernel
[13:21] <rtg> amitk: do you know of the madwifi DKMS package on my PPA? It _does_ support the AR2424.
[13:21] <NCommander> so if it gets merged into the main line, it will be a matter of rebase and then merge
[13:21] <NCommander> (or life is easy)
[13:22] <amitk> rtg: i didn't know of DKMS package. But madwifi isn't a problem. Samsung Q1 AR2424 works with madwifi; doesn't with ath5k.
[13:22] <rtg> amitk: ah, ok. I'll be the ath5k ANI is failing to converge and it resets all of time?
[13:22] <amitk> rtg: on the other hand, the AR2425 chip on EEE PC seems to have same PCI id, but it works with ath5k
[13:23] <amitk> so I can't even remove that PCI id from the ath5k driver
[13:23] <amitk> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/284354
[13:23] <rtg> amitk: you might have to have a blacklist file specific to the platform. ugh!
[13:25] <amitk> rtg: how do I blacklist by platform? Do you mean add a blacklist-samsungq1 file in /etc/modprobe.d ?
[13:26] <rtg> amitk: Are you creating an image for this unit? Or is it running the standard distro install?
[13:27] <amitk> rtg: separate image. So you want to stuff a blacklist file into /etc/modprobe.d somewhere?
[13:28] <amitk> no way to do this in code then
[13:29] <rtg> amitk: yep - you'll have to have a patch in module-utils-init that blacklists the ath5k, but this only works if the image is unique to the samsungq1. 
[13:30] <amitk> rtg: it is a generic mobile image :-/
[13:30] <rtg> hmm, that is a problem.
[13:31] <rtg> amitk: you said ath5k _does_ work for some AR chips?
[13:31] <amitk> rtg: AR2425 on eee pc
[13:31] <rtg> amitk: have you tried LBM on the samsungq1?
[13:31] <rtg> we are talking Intrepid, right?
[13:32] <amitk> rtg: intrepid and no lbm attempted yet
[13:33] <amitk> rtg: looks like there are two opposing bugs - 284354 for samsung (madwifi works; ath5k does) and 182489 (ath5k works; madwifi doesn't)
[13:34] <amitk> rtg: and both don't work out of the box since they require to blacklist one or the other driver manually
[13:34] <rtg> hmm, need coffee.
[13:50] <rtg> amitk: maybe this is a case where we need jockey support, e.g., blacklist madwifi by default but allow jockey to change the blacklist to ath5k.
[13:50] <rtg> similar to the wl driver dilemma.
[13:55] <amitk> rtg: where are the jockey rules that would make the determination?
[13:56] <rtg> amitk: jockey is written by pitti to allow you to make choices as to which driver is used. consider the nVidia case where you have the 2-D and 3-D drivers available.
[13:57] <rtg> Its System->Administration->Hardware Drivers
[13:57] <amitk> rtg: I know about jockey. I was wondering if it can take platform specific rules
[13:58] <rtg> amitk: quirks? I dunno.
[13:58] <rtg> I sure am having Bresnan problems this morning.
[14:05] <amitk> rtg: bresnan? your isp?
[14:06] <rtg> amitk: yep. I had to switch to my alternate route
[14:49] <amitk> 10:46 < slangasek> the comments in bug #284109 say that CONFIG_FTRACE is a performance hit without CONFIG_DYNAMIC_FTRACE,    lieb           even when ftrace is not being used; can anyone confirm that?  Do we need to get CONFIG_FTRACE turned      lool           off for release?
[14:49] <amitk> rtg: ^
[14:49] <amitk> pardon the random nicks in between, cut paste issue
[14:52] <rtg> amitk: CONFIG_DYNAMIC_FTRACE is disabled as of 2.6.27-12
[14:52] <amitk> rtg: CONFIG_FTRACE is being questioned here
[14:52] <apt_get> Hi
[14:52] <rtg> amitk: uh, lemme look.
[14:53] <apt_get> I have two modems USB.   AIKO and YISO.  The 2 connection works.   but no at same time.
[14:53] <apt_get> can I modprobe usbserial two times? for the two vendor cards?
[14:58] <amitk> rtg: lbm fixes my samsung q1 problem. No chance we can get these changes into our kernel?
[15:00] <rtg> amitk: hmm, FTRACE is enabled. can you think of a good reason _not_ to turn it off?
[15:01] <rtg> amitk: if you copy the LBM ath5k over the kernel copy, does it still compile and work?
[15:01] <amitk> rtg: wasn't FTRACE being used by one of the other tracing systems?
[15:02] <amitk> rtg: will copy and test and provide diff if it works
[15:03] <amitk> rtg: no kernel uploads before release?
[15:03] <rtg> amitk: it seems like a total debug feature to me. if its causing performance hits, then I think it has to go.
[15:04] <amitk> rtg: no kernel uploads before release?
[15:05] <rtg> amitk: definitely. I'm think we ought to have one today.
[15:05] <rtg> s/think/thinking/
[15:05] <amitk> BenC1 seemed to disagree ^
[15:06] <rtg> amitk: I was off-channel, so didn't see  his arguments against.
[15:07] <amitk> rtg: he expressed surprise on #ubuntu-devel
[15:07] <amitk> rtg: I figured you would want to get in the stable updates in before release
[15:07] <rtg> amitk: surprise that we might want to upload a kernel? 
[15:07] <amitk> rtg: yeah
[15:08] <rtg> BenC needs to get over here and defend himself before I accuse him of smoking drugs.
[15:09] <amitk> rtg: disabling FTRACE might cause an ABI bump though?
[15:09] <rtg> amitk: possibly.
[15:13] <NCommander> amitk, wouldn't have FTRACE on cause some performance hit?
[15:13] <BenC1> rtg: I wasn't arguing against it, just didn't know one was planned
[15:13] <rtg> BenC1: since when do I ever plan anything?
[15:13] <BenC1> rtg: I thought you already disabled ftrace and it wasn't an ABI bump
[15:13] <amitk> NCommander: yes
[15:14] <amitk> BenC1: DYNAMIC_FTRACE != FTRACE
[15:14] <NCommander> amitk, ok, good, I am not loosing my mind
[15:14] <BenC1> Ah
[15:14] <rtg> BenC1: it was CONFIG_HAVE_DYNAMIC_FTRACE
[15:15] <BenC> which is the mechanism that will hopefully replace ptrace one day?
[15:15] <elmo> utrace
[15:16] <rtg> BenC: I think so. That was the presentation Rostedt gave at the plumbers conf
[15:16] <BenC> Am I correct that ftrace in general basically adds padding to function prologue/epilogue to insert instrumentation for debugging?
[15:17] <BenC> or am I thinking of some other debug crud?
[15:17] <rtg> BenC: yep - says it add 5 bytes to the prologue/epilogue
[15:17] <rtg> BenC: I'm thinking we want to turn it off.
[15:18] <BenC> If it doesn't exclude static functions, that sounds like a _huge_ waste of memory in the kernel
[15:18] <rtg> BenC: well, it is a debug function. I wonder how it got turned on in the first place.
[15:18] <BenC> IIRC, amitk asked for it to be turned on :)
[15:19] <rtg> BenC: disabling it is almost guarenteed to cause an ABI bump. I'm test building right now.
[15:19]  * amitk looks at BenC in shock
[15:19] <BenC> amitk: I could be remembering wrong (highly likely)
[15:20] <BenC> I know it was a request from someone, and there were good arguments for it
[15:22] <rtg> I'm sure not finding a log entry from Ubuntu regarding FTRACE.
[15:23] <BenC> pretty sure that was disabled way before intrepid
[15:23] <BenC> I'm wondering if the problem is more of a bad interaction with gcc than in ftrace itself
[15:24] <amitk> BenC: FTRACE wasn't in older 2.6.24 kernels.
[15:26] <BenC> rtg: I totally agree though, kill it
[15:26] <BenC> Although I'm sure it will break whatever userspace tools are there to use it
[15:27]  * NCommander checks to see the -lpia kernel has FTRACE enabled
[15:27] <rtg> BenC: Steve will be really happy about an ABI bump at this late stage (!not).
[15:27] <BenC> He may not even allow it
[15:28] <rtg> I can't see releasing a kerbnel with performance killing cruft in it.
[15:28] <rtg> kernel, even
[15:28] <NCommander> Yup, it does
[15:29] <NCommander> BenC & rtg, want me to go test build the lpia kernels w.o FTRACE?
[15:29] <amitk> Steve was the one who brought up this bug.
[15:29] <rtg> NCommander: can't hurt.
[15:30] <NCommander> yay, more kernel fun :-)
[15:42]  * abogani happy to have already done that work :)
[15:43] <rtg> BenC: looks like disabling FTRACE only removes one symbol (mcount), so we might be able to get by without an ABI bump.
[15:44]  * NCommander is now building the lpia kernels
[15:44] <NCommander> Just to confirm, DYMANIC_FTRACE is ok?
[15:45] <amitk> NCommander: no, turn it off
[15:45] <rtg> DYMANIC_FTRACE == much badness
[15:45]  * NCommander makes it go poof
[15:45] <amitk> NCommander: could you make sure that ports doesn't have it too?
[15:45] <NCommander> I doubt it, ports kernel is old
[15:46]  * NCommander was checking as soon as he got the lpia kernel going
[15:46] <NCommander> my build environment got screwed
[15:47] <BenC> rtg: Nope
[15:47] <BenC> rtg: mcount is most likely used by any module that was compiled against ftrace enabled kernel
[15:47] <NCommander> The ports kernel predates FTRACE
[15:47] <NCommander> (CONFIG_FTRACE IS MIA)
[15:48] <NCommander> Er
[15:48] <NCommander>  If it's runtime disabled
[15:48] <NCommander> (the bootup default), then the overhead of the instructions is very
[15:48] <NCommander> small and not measurable even in micro-benchmarks.
[15:48] <NCommander> (from CONFIG_FTRACE help)
[15:48] <rtg> BenC: so you think LRM/LBM stuff will be affected, huh. I suppose. drat.
[15:49] <NCommander> If its disabled by default on boot-up, do we really need to kill it?
[15:50] <BenC> NCommander: just the added bits to the function are what seem to be causing the problem
[15:50] <NCommander> I must have missed that part
[15:51] <NCommander> Whats the problem specificly :-)?
[15:51] <NCommander> oh, and lpia build underway
[15:51] <BenC> NCommander: ftrace instrumentation is causing random memory corruption problems
[15:51] <NCommander> Ew
[15:51] <BenC> well, not random, but it affects random things
[15:51] <NCommander> Ok, building now, it will take about two hours for the build run to finish
[15:53] <amitk> BenC: No. CONFIG_FTRACE wasn't causing the random corruption. CONFIG_DYNAMIC_FTRACE was. CONFIG_FTRACE was only adding overhead according to bug #284109
[15:54] <rtg> amitk: correct.
[15:54] <BenC> So if CONFIG_FTRACE isn't causing problems, why worry about it before release?
[15:54] <BenC> And what exactly does DYNAMIC_FTRACE do?
[15:54] <rtg> BenC: its not causing problems, just runtime overhead.
[15:54]  * NCommander looks
[15:55] <BenC> rtg: It's immeasurable according to docs
[15:55] <BenC> rtg: Not much more than a bit of memory waste
[15:55] <rtg> BenC: true, but Steve is the one that brought it up.
[15:55] <amitk> BenC: slangasek brought up the bug late last night.
[15:55] <NCommander> I could see FTRACE being usable, and we might be able to avoid an ABI bump if we just disable DYMANIC_FTRACE vs. FTRACE
[15:56] <rtg> BenC: its hard to imagine that it has only negligible impact. its on _every_ fucntion call.
[15:57] <BenC> rtg: but it's a set of nops, IIRC, and any decent CPU can pipeline that right through (no different than our dynamic UP setup for single cpu systems)
[15:58] <amitk> Documentation/ftrace.txt isn't very clear. I quote "If CONFIG_DYNAMIC_FTRACE is set, the system will run with
[15:58] <amitk> virtually no overhead when function tracing is disabled"
[16:00] <rtg> amitk: do you remember the LP bug number?
[16:00] <amitk> bug #284109
[16:00] <amitk> it seems mere speculation in the bug report, no hard numbers.
[16:01] <rtg> amitk: hmm, no real info there.
[16:02] <NCommander> so we kill just FTRACE_DYMANIC, or both FTRACE and FTRACE_DYMANIC?
[16:02] <rtg> BenC, amitk: I'm inclined to leave it alone until someone can prove or disprove a performance hit.
[16:03] <rtg> NCommander: just CONFIG_DYNAMIC_FTRACE for now
[16:05] <NCommander> With a little luck that will prevent the ABI breakage
[16:05] <amitk> NCommander: DYNAMIC_FTRACE doesn't bump abi
[16:06] <NCommander> THat's what I was hoping :-)
[16:23] <apt_get> I have two modems USB.   AIKO and YISO.  The 2 connection works.   but no at same time.
[16:23] <apt_get> can I modprobe usbserial two times? for the two vendor cards?
[16:26] <jdong> apt_get: the module should making devices for both cards
[16:27] <jdong> modprobing twice doesn't do anything that modprobing once doesn't.
[16:27] <amitk> rtg: diff between in-kernel ath5k and lbm version is quit large. It also depends on changed structures in include/net. So no easy way of just forward porting ath5k driver. It is all or nothing.
[16:27] <amitk> apt_get: do you need to use module params for usbserial?
[16:32] <apt_get> jdong i only can use the device if I 'modprobe usbserial vendor=0x0eab product=0xc893'
[16:33] <apt_get> but the other device use another vender and product
[16:36] <jdong> mm, I see, amitk is on the spot then
[16:37] <apt_get> amitk: can I use the both? at same time?   
[16:46] <Keybuk> rtg: I have to send the entire mail, again?
[16:46] <NCommander> brb
[16:54] <rtg> Keybuk: that is what greg k-h prefers. otherwise they have to keep track of it manually.
[16:55] <rtg> Keybuk: also, send it to the maintainer. otherwise it'll just get lost in the merge blizzard
[16:55] <Keybuk> I don't follow
[16:55] <Keybuk> so what should I do?
[16:56] <Keybuk> 1) mail the patch again
[16:56] <Keybuk> 2) cc stable@kernel.org ?
[16:56] <Keybuk> 3) cc someone else ?
[16:56] <rtg> Keybuk: add the Cc, change the subject to [PATCH v2], and email it To: the maintainer as well as Cc LKML.
[16:56] <Keybuk> how do I change the subject?  git auto-generates the [PATCH] bit
[16:57] <Keybuk> who is "the maintainer" ?
[16:57] <rtg> The 'Cc: stable@kernel.org' goes in the bosy of the commit.
[16:57] <rtg> s/bosy/body/
[16:57] <Keybuk> err, wtf?
[16:57] <elmo> it can't go into stable till it's in mainline?
[16:57] <rtg> elmo: correct
[16:57] <Keybuk> Cc goes in the header, no?
[16:57] <elmo> so why are we sending it to stable@ already?
[16:58] <rtg> Keybuk: tell you what, I'll format the patch and send it to you.
[16:58] <apt_get> i´m trying to make the both usb modems work. But or one or other!  at same time i cant do that
[16:59] <rtg> elmo: greg and chris have said they don't want a direct Cc, they prefer that it be in the body of the commit. that way it gets handled automatically.
[17:00] <elmo> rtg: sure.  I just thought you couldn't cc (direct or otherwise) stable until it was accepted into mainline
[17:00] <elmo> rtg: (which this hasn't been, yet, AFAIK?)
[17:00] <rtg> elmo: correct
[17:01] <apw> this allows whomeever merges it to decide if its still stable material, if they do they merge it with the Cc: and the stable people can pick those up programattically from linus' tree, thus only getting stuff which has hit mainline
[17:02] <rtg> Keybuk: the list of maintainers for most subsystems is kept in MAINTAINERS at the root of the kernel tree.
[17:02] <elmo> I'm pretty sure the maintainer for IPMI stuff is still Corey Minyard (sp?)
[17:03] <Keybuk> yes
[17:03] <Keybuk> the guy who's named just above the one line I added in my patch :-/
[17:04] <rtg> Keybuk: hmm, the email that I received did not have his address.
[17:05] <Keybuk> it's in the body ;)
[17:06] <Keybuk> plz wave magick wand to make kernel peeps merge patch kthx :p
[17:07] <rtg> Keybuk: in order for the patch to bubble up into mainline, it generally has to go through the subsystem maintainer. He's not likely to see it on LKML because of the volume, so you have to send it to him directly.
[17:08] <Keybuk> can you do that for me?
[17:08] <rtg> Keybuk: working on it.
[17:17] <apt_get> Cant I modprobe two times usbserial module?   i´m trying to make 2 usb modems work. 
[17:17] <mjg59> apt_get: No
[17:17] <apt_get> or I modprobe with onde vendor, or woth another
[17:18] <apt_get> =o(
[17:19] <Keybuk> ben
[17:20] <NCommander> what's beh Keybuk 
[17:21] <Keybuk> ww
[17:28] <apw> rtg your hardy-next tree, is that the latest kernel about for hardy or do we have a later one
[17:29] <NCommander> amitk & BenC disabling FTRACE_DYMANIC (without FTRACE) does not break the ABI
[17:29] <rtg> apw: I need to update it since its missing a couple of important patches, e.g. DYNAMIC_FTRACE
[17:30] <NCommander> ^on lpia
[17:31] <NCommander> DO we need any more changes to land in the tree, or should I submit the patchset?
[17:33] <rtg> NCommander: you might have to wait a bit for amitk to return. another 30 minutes perhaps
[17:33] <NCommander> rtg, is lpia going to be folded into the main kernel packages, or is that going to remain separate?
[17:34] <rtg> separate
[17:35] <NCommander> what was the rationale for keeping it separate?
[17:35] <rtg> disparate release schedules between lpia and distro
[17:37]  * NCommander is surprised it didn't get stuck in -ports
[17:37] <rtg> its not community maintained.
[17:37] <elmo> umm, what?
[17:37] <elmo> oh
[17:38] <NCommander> oh
[17:38]  * NCommander is learning a great many things from just two days in #u-kernel
[17:39] <apt_get> exist a way to make usbserial use two diferent devices?? please
[17:40] <apt_get> I remember that with NE2000 old driver we can make a copy of the module and modprobe the second... and make two cards to work together
[17:41] <NCommander> rtg, so if powerpc/sparc may be pulled back into main linux, then does that mean changes w.r.t to the support status on PowerPC and sparc?
[17:41] <BenC> apt_get: it automatically does
[17:42] <BenC> apt_get: I would be surprised if it didn't connect to both devices...it's hot-plug (and thus multidevice) capable
[17:42] <apt_get> no it doesnt 
[17:42] <rtg> NCommander: not for the foreseeable future
[17:42] <apt_get> with lsusb  i can see the 2 devices
[17:42] <BenC> apt_get: show me dmesg with both devices connected
[17:42] <apt_get> lsusb
[17:42] <apt_get> Bus 002 Device 003: ID 19d2:fffe
[17:42] <apt_get> Bus 002 Device 002: ID 0eab:c893
[17:42]  * NCommander feels somewhat confused then ....
[17:43] <BenC> apt_get: the old ne2k driver was ISA and also not hot-plug, so that's not even a comparison
[17:43] <apt_get> to make /dev/ttyUSB0 work, I need 'modprobe usbserial vendor=0x0eab product=0xc893'
[17:43] <apt_get> but the other card dont work. because usbserial only see the vendor i had specified
[17:43] <BenC> apt_get: please pastebin dmesg...I can't help much just based on what you are telling me
[17:44] <apt_get> ok
[17:44] <BenC> apt_get: then instead of passing it on the module command line, use the newid file in sysfs for that device
[17:46] <NCommander> rtg, I'm testing the bootability of the linux-lpia kernel, looks good so far
[17:46] <rtg> NCommander: did you ever have any failures while DYNAMIC_FTRACE was enabled?
[17:46] <NCommander> rtg, no
[17:47] <NCommander> Both lpia kernel flavors built fine
[17:48] <apt_get> newid file in sysfs?
[17:50] <BenC> apt_get: new_id
[17:50] <BenC> apt_get: /sys/bus/usb-serial/drivers/generic/new_id
[17:51] <amitk> NCommander: I am going to do a fresh rebase of the lpia kernel on top of the ubuntu intregrated tree once it is prepped for release.
[17:52] <amitk> NCommander: but your Kconfig changes can be applied as a separate patch in the meanwhile
[17:52] <NCommander> amitk, what Kconfig changes? I only changed the config files ...
[17:52] <amitk> NCommander: config file changes == Kconfig changes
[17:53] <NCommander> oh
[17:53] <NCommander> I'm just making sure the image boots right now
[17:57] <NCommander> what was the FTRACE bug number?
[17:58] <amitk> it was the e1000e bug, search for that on LP
[17:58] <NCommander> Oh, that was caused that?!
[17:58] <NCommander> Damn
[18:01] <amitk> meeting in #ubuntu-meeting
[18:46] <mnemo> amitk: I added more info about the patch in this bug --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/285572
[18:46] <mnemo> do you think you can push this patch given the additional information?
[18:53] <apt_get> BenC:  its working now.  with option module
[18:53] <apt_get> and with /sys/bus/usb-serial/drivers/option1/new_id  u have said
[18:55] <mnemo> im looking for someone who can help me review and push a tiny kernel patch for intrepid
[18:55] <mnemo> apt_get: do you know how to get stuff merged?
[19:03] <NCommander> That was educational
[19:03] <amitk> mnemo: i am going to add the x server guy on this bug. He has to agree to carry his side of the patch first
[19:05] <mnemo> amitk: bryce harrington has agreed to merge his part if you merge the kernel part
[19:05] <mnemo> bryce is online at irc as well if you want to talk to him (nickname "bryce")
[19:06] <amitk> mnemo: I know bryce :) In that case I can push it in.
[19:07] <mnemo> okay sweet... that's awesome... let's make it happen... :)
[19:08] <NCommander> arg, I closed the meeting window, who was talking about the kernel on arm?
[19:09] <amitk> NCommander: me. busy now. Lets talk next week or something. It isn't urgent
[19:09] <amitk> NCommander: re ARM
[19:12] <NCommander> amitk, I mailed you the lpia patch
[19:17] <amitk> mnemo: patch is in. Go after bryce.
[19:17] <mnemo> will do
[19:19] <rtg> amitk: can you copy the mailing list?
[19:20] <amitk> rtg: umm... I pushed the patch in. Do you want me to post the patch to ML instead?
[19:20] <rtg> amitk: mail it as well, so that it gets some notice.
[19:23] <amitk> rtg: ack
[19:30] <amitk> NCommander: thanks for patch. In future, send all patches to kernel-team@lists.ubuntu.com so that it doesn't get bottlenecked on me.
[19:31] <amitk> greaaaat
[20:40] <amitk> NCommander: thanks for patch. In future, send all patches to kernel-team@lists.ubuntu.com so that it doesn't get bottlenecked on me.
[20:41] <NCommander> amitk, alright
[20:43] <GnarusLeo> Hi geeks! I have been using the howto found on "https://help.ubuntu.com/community/Kernel/Compile#Alternate%20Build%20Method:%20The%20Old-Fashioned%20Debian%20Way" for building my own kernel.It is built out of the vanilla kernel. The kernel compiles, and install allright. The problem is when I want to build modules, I get an error of a missing /arch/Makefile_32.cpu" file. After som googling, I found that this is indeed a bug: "https:
[20:43] <GnarusLeo> //bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/195673" Is there any way around, without a real dirty fix? Thanks in advance
[20:44] <GnarusLeo> So the ASM bug posted on that site will be an issue for me as well
[22:13] <kirkland> what's the state of the e1000e driver in intrepid?
[22:15] <rtg> kirkland: its as good as it gets. root cause was DYNAMIC_FTRACE
[22:15] <NCommander> kirkland, I think its been unblacklisted since the issue was FTRACE_DYMANIC
[22:15] <NCommander> lol
[22:17] <kirkland> rtg: NCommander: cool, thanks, guys
[22:18] <NCommander> rtg, did that kernel get uploaded yet?
[22:19] <GnarusLeo> https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/195673 <-- really need a workaround. Anyone got anything? Would be much appriciated
[22:19] <rtg> NCommander: https://edge.launchpad.net/ubuntu/+source/linux
[22:20] <NCommander> nice
[22:21] <rtg> GnarusLeo: looks like to me that you're pointing to the wrong place for headers. It ought to be something like /usr/src/linux-headers-2.6.27-7-generic
[22:23] <GnarusLeo> but its on a custom build?
[22:23] <GnarusLeo> rtg, thanks for answering :)
[22:24] <rtg> GnarusLeo: it looks like you are trying to build against un-prepped headers.
[22:25] <GnarusLeo> so I have to prep the headers? Sounds difficult
[22:25] <rtg> GnarusLeo: what is custom abuot your build?
[22:26] <GnarusLeo> we are building a new kernel based upon  vanilla, for the acer aspire one. 
[22:26] <GnarusLeo> and we are really stumped on this
[22:26] <rtg> GnarusLeo: so why is this an Ubuntu problem? Are you starting with an Ubuntu package?
[22:27] <GnarusLeo> rtg, it is a custom kernel built off ubuntu
[22:27] <Syco54645_AAO> ok, GnarusLeo i am here now
[22:27] <GnarusLeo> actually, here is Syco54645, he was the one who actually built it, unfortunally, I have to leave in a few mins
[22:28] <rtg> GnarusLeo: I assume the customization is largely in the .config file?
[22:28] <Syco54645_AAO> and unfortunately i cannot reproduce the error
[22:28] <GnarusLeo> rtg, correct
[22:28] <Syco54645_AAO> rtg: it is completely in the config file, just removed unneeded things
[22:28] <rtg> Syco54645_AAO: did you start with one of the flavours, like generic?
[22:29] <Syco54645_AAO> rtg: i used vanilla from kernel.org
[22:29] <NCommander> oh yay, the powerpc 2.6.27.2 doesn't boot
[22:29] <NCommander> wooo
[22:30] <rtg> Syco54645_AAO: are you trying to build an out-of-tree module?
[22:30] <Syco54645_AAO> rtg: i used this to build fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers
[22:31] <Syco54645_AAO> rtg: not sure what you mean by that
[22:31] <GnarusLeo> rtg, he is trying to build just the plain old madwifi drivers
[22:31] <Syco54645_AAO> i did not modufy the source
[22:31] <GnarusLeo> kernel modules
[22:31] <Syco54645_AAO> but yes, trying to build madwifi is where the issue crept up, i assume any module will cause the issue
[22:32] <rtg> ok. madwifi is out of tree,e.g., its not part of the kernel. therefore it must use the correct headers. right?
[22:32] <GnarusLeo> yes
[22:32] <Syco54645_AAO> ah ok, that is what i thought out of tree meant...
[22:33] <GnarusLeo> rtg, actually, neither of us put the bug up on launchpad. It just came up on googling our issue
[22:33] <rtg> then, back to my original point. you have to have the headers package installed for the flavour against which you are building.
[22:34] <Syco54645_AAO> rtg: people did install the headers that were created by my compile, if that is what you meant.
[22:34] <Syco54645_AAO> when i compile, it produces two deb files, one is headers, the other is kernel image
[22:35] <rtg> Syco54645_AAO: so, if you get the Hardy kernel package, then 'debuild -b', you should get a number of .debs
[22:36] <Syco54645_AAO> ok
[22:36] <Syco54645_AAO> i have the generic kernel package on here
[22:36] <Syco54645_AAO> but am not in that kernel, in the one that i built
[22:36] <rtg> Syco54645_AAO: you have to have the Ubuntu kernel package.
[22:37] <Syco54645_AAO> rtg: well i didnt remove it, so it should still be there.  it is in /boot
[22:37] <rtg> Syco54645_AAO: the source package.
[22:38] <rtg> Syco54645_AAO: 'apt-get source linux-image'
[22:39] <GnarusLeo> rtg, why will we need the old kernel headers, if we made new ones?
[22:40] <rtg> GnarusLeo, Syco54645_AAO: maybe you guys ought to read https://wiki.ubuntu.com/KernelMaintenance 'cause I don't think we're on the same page.
[22:42] <Syco54645_AAO> rtg: i am honestly just confused as to why when i compile vanilla and create a header and image deb file and then install it with dpkg i can compile things, but give it out to others and they cannot.  it complains about the makefile_32 file in a location that i do not even have, but again, it works fine for me
[22:42] <rtg> dunno
[22:43] <Syco54645> like gnarusleo said, he found a bug report related to it.  others have found bug reports before related to it but no fixes.
[22:43] <Syco54645> so either i am doing something really wrong and missing something on the kernel compile page of the wiki
[22:43] <Syco54645> or it is missing something
[22:43] <Syco54645> or that method just does not work any longer
[22:43] <rtg> as far as I can tell, it folks trying to do things for which the package was not designed. you're on your own there.
[22:44] <amitk> Syco54645: hmm... can you acutally compile the kernel using this --> fakeroot make-kpkg --initrd --append-to-version=-some-string-here
[22:44] <Syco54645> amitk: that is how i did it, except with "kernel-image kernel-headers" on the end
[22:45] <amitk> Syco54645: that is probably a debian'ism. Not sure if it hits the right targets. Use 'debuild -b' and then report back.
[22:45] <Syco54645> ok
[22:46] <amitk> Syco54645: or 'fakeroot debian/rules binary-custom-<flavourname>' for a single flavour if you are using the custom-binary method
[22:46] <Syco54645_AAO> um said debuild is not there, and that it is not in apt
[22:47] <rtg> yum?
[22:47] <Syco54645_AAO> i am on ubuntu
[22:48] <rtg> sudo apt-get install devscripts
[22:49]  * amitk is outta here... good night folks
[22:49] <Syco54645_AAO> later amitk 
[22:49] <pgraner> amitk: night
[22:49] <Syco54645_AAO> rtg: that worked, running debuild -b now
[22:49] <rtg> rtg is outta here
[22:50] <Syco54645_AAO> well debuild failed
[22:50] <Syco54645_AAO> oh well
[22:50] <Syco54645_AAO> ill call it a night there