[06:58] <brendand> apw - hi
=== smb` is now known as smb
[07:20] <brendand> can someone have a look at this bug? https://launchpad.net/bugs/984387
[07:21] <ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [Undecided,Confirmed]
[07:21] <brendand> potential -proposed regression
[07:22] <brendand> probably a duplicate of this: https://launchpad.net/bugs/974412
[07:22] <ubot2> Launchpad bug 974412 in linux "System fails to boot after kernel upgrade to 3.0.0-18" [High,Incomplete]
[07:30] <ppisati> moin
[07:44] <smb> brendand, The second bug report does not really have useful information (like the stack trace), the first one has though the top part is missing and the question marks in the stack trace indicate that the locations printed may not be reliable. If they were it would look like a failure in the ite-cir (infrared dongle) driver.
[07:46] <smb> ppisati, morning
[07:49] <brendand> smb - by the second one, you mean the second one i pasted (i.e. the original?)
[07:49] <smb> yes
[07:50] <brendand> smb - right, yes the second one was raised agains the 3.0.0-18 kernel by someone from the community. it seems he was asked if he could test with 3.0.0-19 but didn't give a reply. we're still seeing it in 3.0.0-19
[07:50] <smb> brendand, Does this Dell have a infrared receiver built-in?
[07:51] <brendand> smb - i imagine so. we avoid using peripherals at all in our testing if possible
[07:59] <smb> brendand, If it could be disabled in bios it might be a way to verify the crash is related to that (or blacklist the ite-cir module)
[08:10] <brendand> smb - i'll ask the lab engineer to do that. we'll get an answer later today
[10:10] <ppisati> brb
[13:10] <pgraner> apw, ping
[13:16] <pgraner> sforshee, they look like this
[13:16] <pgraner> Apr 18 08:34:43 slickback kernel: [37846.980171] mei 0000:00:16.0: unexpected reset.
[13:16] <pgraner> Apr 18 08:35:13 slickback kernel: [37877.030615] mei 0000:00:16.0: unexpected reset.
[13:16] <pgraner> Apr 18 08:35:43 slickback kernel: [37907.081084] mei 0000:00:16.0: unexpected reset.
[13:23] <smb> pgraner, Out of interest, what would be pci 16.0? The generic chipset or something else?
[13:24] <pgraner> smb, here you go
[13:24] <pgraner> 00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller
[13:24] <pgraner>  #1 (rev 01)
[13:24] <pgraner> 00:16.3 Serial controller: Intel Corporation Panther Point KT Controller (rev 01
[13:24] <pgraner> )
[13:26] <smb> pgraner, Thanks, so coming out of the management controller. Still could be a result of something else
[13:37] <cking> pah, my AP needs some attention.. monthly reboot methinks
[13:37] <apw> cking, monthly ... i wish
[13:53] <brendand> smb - blacklisting ite-cir does stop the XPS 1340 from crashing
[13:54] <ogasawara> brendand: just commented to bug 984387, can you confirm if you see the same issue in Precise?
[13:54] <ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [Undecided,Confirmed] https://launchpad.net/bugs/984387
[13:55] <smb> brendand, So its is coming from there... I did not see a change in drivers/media thoug some in staging/media/lirc... 
[13:57] <ogasawara> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972723/comments/11 different bug, but looks like the same issue but seen on Precise
[13:57] <ubot2> Launchpad bug 972723 in linux "linux 3.2.0-18 - 22 kernel panic on boot, Alienware m17x, Dell xps 1340" [Medium,Confirmed]
[13:57] <smb> ogasawara, True, just reading trhough them
[13:57] <brendand> ogasawara, ok, turns out we've been seeing it in precise before
[13:58] <brendand> what are we going to do about oneiric though?
[13:58] <ogasawara> smb: analysis from an affected user there indicates it's a race in the ite-cir driver which seems to be triggered more frequently due to a fix from upstream stable
[13:58] <smb> ack
[13:59] <ogasawara> brendand: well, considering Precise it about to go out the door in 1 week, I'd like to get it fixed there asap.  Oneiric possibly has more wiggle room.
[14:00] <brendand> ogasawara, ok, i meant in terms of the SRU. the problem is only present in -proposed it would appear
[14:00] <smb> ogasawara, The analysis sounds quite likely
[14:00] <ogasawara> brendand: for Precise, I'd propose rather than backing out the patch from upstream stable, we temporarily disable the broken driver.
[14:01] <ogasawara> brendand: for Oneiric, I'd want to consult with herton, henrix, and bjf
[14:01] <brendand> ogasawara, sounds ok. the ir reciever is not something we certify anyway so it won't block certification
[14:02] <ogasawara> brendand: how many other systems in the lab does this affect on Precise?
[14:02] <brendand> ogasawara, no others that i know of. to be honest we haven't done a full test across all systems for precise yet
[14:03] <ogasawara> brendand: you haven't?  I assume it's going to happen between now and final release though yes?
[14:04] <brendand> ogasawara, no - not for every system until final release next week
[14:06] <ogasawara> brendand: hrm, seems there's an error in the process, as how are we going to be aware of any issues if it isn't tested until after the release goes out?
[14:06] <ogasawara> brendand: anyways, would you guys be able to do a test of a Precise test kernel if I built one for you?
[14:06] <brendand> ogasawara, yes
[14:08] <brendand> ogasawara, we have a tool which attempts to calculate the best coverage for us with as few systems as possible. it of course has some weaknesses so we can discuss it at UDS using this case as an example of why it might not be entirely effective
[14:10] <ogasawara> brendand: ack.  I thought at the previous UDS we did indeed agree that testing a subset of systems was reasonable through the Alpha's and even Beta-1.  But I thought that you'd at least start doing to a full run of tests against all systems as of Beta-2.
[14:14] <brendand> ogasawara, maybe there was some confusion there. bring it up at the UDS session about 12.10 testing
[14:14] <ogasawara> skaet: ^^ fyi 984387 also affects Precise.  I can get a fix and have brendand test asap, but it would then require an upload.
[14:16]  * skaet looking
[14:21] <skaet> ogasawara,  prep it up and test it - add to zero day SRU set.     So we have the option to react quickly,  prefer not to change the kernel at this point.
[14:22] <ogasawara> skaet: ack
[14:23] <skaet> if at all possible.
[14:23] <ogasawara> skaet: alternative solution would be to blacklist the driver for now in module-init-tools
[14:24] <ogasawara> skaet: but I'd prefer to keep it to the kernel if possible
[14:24] <skaet> ogasawara,  that might well be worth considering.
[14:41] <pgraner> smb, http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/DOCS/Implementation%20and%20Reference%20Guide/default.htm?turl=WordDocuments%2Fconnectingwiththeintelmeidriver.htm
[14:44]  * ogasawara back in 20
[15:05] <brendand> bjf, herton - have you been informed of the ir driver bug affecting the oneiric -proposed kernel?
[15:06] <henrix> brendand: yeah, we're looking at it atm
[15:07] <bjf> brendand: did the tracking bug get updated with the info ?
[15:08] <brendand> bjf - i was just waiting for some feedback, i'll update it now
[15:26] <ogasawara> brendand: Precise test kernel -> http://people.canonical.com/~ogasawara/lp984387/i386/
[15:52] <ogasawara> bjf: just fyi, patches -> http://people.canonical.com/~ogasawara/lp984387/
[15:55]  * cking reboots
[16:17] <henrix> ogasawara: have you seen the comment #5 in bug #972723?
[16:17] <ubot2> Launchpad bug 972723 in linux "linux 3.2.0-18 - 22 kernel panic on boot, Alienware m17x, Dell xps 1340" [Medium,Confirmed] https://launchpad.net/bugs/972723
[16:17] <henrix> ogasawara: i was looking through the driver code and it makes perfect sense
[16:17]  * ogasawara looks
[16:17] <henrix> ogasawara: the driver is installing an isr *before* being ready to serve an irq
[16:18] <henrix> this means the bug was there since the begining
[16:18] <henrix> oh, btw: all the other ir drivers seem to follow the same pattern
[16:20] <henrix> if you think its worth, i can build a test kernel (oneiric or precise, or both) moving the isr initialisation to a later stage
[16:20] <ogasawara> henrix: go for it
[16:20] <henrix> ogasawara: ack
[16:20] <ogasawara> henrix: we at least have access to the hardware to get it testec
[16:20] <ogasawara> s/testec/tested/
[16:20]  * bjf wonders how many other drivers this impacts
[16:20] <henrix> ogasawara: which one would you prefer to go 1st? oneiric or precise?
[16:21] <ogasawara> henrix: if we could get precise first, I'd appreciate it
[16:21] <henrix> ogasawara: ack
[16:21] <ogasawara> henrix: seems like we have a more urgent time crunch for precise
[16:21] <henrix> :)
[16:30]  * ppisati -> goes out for a bit
[16:30] <brendand> bjf, herton, ogasawara, henrix  - can i assume this is going to result in a respin of oneiric?
[16:31] <bjf> brendand: it's likely to, yes
[17:09] <henrix> ogasawara: i have the 32bits test kernel here: http://people.canonical.com/~henrix/lp984387-postponeirq/i386/
[17:09] <henrix> ogasawara: the amd64 version is still compiling
[17:09] <ogasawara> henrix: ack, thanks.  I'll get it posted to the bugs.
[17:10] <ogasawara> hrm, no brendand
[17:10] <henrix> ogasawara: ah, ok. i though you would ask the guys to test it
[17:10] <henrix> ogasawara: ah, right :)
=== Nafallo_ is now known as Nafallo
[18:22] <roadmr> hi folks! any way to load a blacklisted module? I pass ite_cir.blacklist=yes on the command line, and after the system boots I'd like to try loading the module, how to undo the blacklist/parameter setting?
[18:23] <henrix> roadmr: have you tried modprobe ite_cir ?
[18:25] <roadmr> henrix: yes, it says "error inserting - unknown symbol in module, or unknown parameter"
[18:26] <roadmr> henrix: dmesg says "ite_cir: unknown parameter 'blacklist'"
[18:26] <roadmr> henrix: so it looks like the blacklisting works but not for the expected reason :)
[18:27] <henrix> roadmr: what was the exact command you used?
[18:27] <henrix> roadmr: i'm not familiar with the 'ite_cir.blacklist=yes' thing...
[18:27] <roadmr> henrix: sudo modprobe ite_cir
[18:27] <henrix> roadmr: where did you used 'ite_cir.blacklist=yes'? in grub?
[18:27] <apw> henrix, he has made an invalid option and that aborts the load
[18:27] <roadmr> henrix: on the kernel command line I appended ite_cir.blacklist=yes
[18:27] <apw> henrix, he has mad the option on the kernle command line
[18:28] <roadmr> henrix: my reference is potentially outdated (8.04): https://help.ubuntu.com/8.04/installation-guide/sparc/boot-parms.html
[18:28] <roadmr> ah, and sparc. Yes, I suck :(
[18:28] <henrix> heh
[18:28] <henrix> right, so better reboot without that option
[18:29] <roadmr> henrix: the 11.10 i386 guide still says the same, though I'm on Precise so it *may* have changed
[18:29] <roadmr> https://help.ubuntu.com/11.10/installation-guide/i386/boot-parms.html
[18:30] <apw> roadmr, i can find no documentaiton on stopping modprobe using the kernel command line overrides once you have added them
[18:30] <henrix> apw: nice, i didn't new that invalid options would prevent modules from being loaded
[18:30] <roadmr> henrix: yes, well I'm doing some diagnostics for a crash related to this module, so it's not a big deal, was just curious about how to do this. 
[18:30] <henrix> roadmr: yeah, i'm aware of it ;)
[18:31] <roadmr> apw: hmm, thanks for looking into it! as I said, it's not a big deal :) rebooting is OK to "undo" the blacklisting
[18:31] <roadmr> apw, henrix : thanks :)
[18:32] <henrix> roadmr: anyway, *in general* the modprobe thingy should work
[18:32] <henrix> roadmr: i wasn't aware the invalid kernel param would prevent modprobe from loading it
[18:32] <henrix> roadmr: now we both know that :)
[18:32] <roadmr> henrix: yes, it works but for the wrong reasons I think :D
[18:33] <apw> roadmr, you may be able to insmod directly to avoid the issue
[18:33] <roadmr> apw: yay! ok, I'll try that
[19:22] <ogasawara> bjf: could I get a second Ack from you for henrix's patch he sent to the mailing list for the ite-cir driver
[19:24] <ogasawara> skaet: fyi, got positive test feedback for a proper fix for bug 984387.  roadmr also did a quick test against 83 systems in the lab and confirmed 3 variants of Dell XPS's were affected.
[19:24] <ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [High,Confirmed] https://launchpad.net/bugs/984387
[19:24] <ogasawara> skaet: no other Dells crashed, nor did any of the Lenovos, Toshibas and assorted others (some Sonys, a few Asus, the odd Sylvania or Samsung)
[19:24] <skaet> ogasawara, good news.   Thanks.   :)
[19:25] <bjf> ogasawara: done
[19:25] <ogasawara> bjf: thanks
[19:25] <bjf> ogasawara: did he get testing feedback?
[19:25] <ogasawara> bjf: he did from roadmr
[19:25] <bjf> cool
[19:26] <ogasawara> bjf: roadmr also was able to do a quick test against all systems he had access to
=== JustMe is now known as Guest68939
[19:50] <Guest11589> Evening
[19:50] <Guest11589> Is someone around for a module compiling question?
[19:52] <Guest11589> I C :-(
[19:53] <roadmr> Guest11589: feel free to ask, if someone knows / can help, someone will
[19:56] <Guest11589> Ok, first thing: 3.4 ppa kernels miss one module: DVB_USB_AZ6007 - who's the right person to speak to to enable it for the future?
[19:57] <Guest11589> Second thing: I tried to enable it myself but I fail compiling it - here's what I did:
[19:57] <Guest11589> * wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.4-rc3.tar.bz2
[19:57] <Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0001-base-packaging.patch
[19:57] <Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0002-debian-changelog.patch
[19:57] <Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0003-default-configs.patch
[19:57] <Guest11589> * tar xfvj linux-3.4-rc3.tar.bz2
[19:57] <Guest11589> * patch -p0 <0001-base-packaging.patch
[19:57] <Guest11589> * patch -p0 <0002-debian-changelog.patch
[19:57] <Guest11589> * patch -p0 <0003-default-configs.patch
[19:57] <Guest11589> * cp /usr/src/linux-headers-3.4.0-030400rc3-generic-pae/.config .
[19:57] <Guest11589> * make menuconfig
[19:57] <Guest11589> * make -C /usr/src/linux-headers-3.4.0-030400rc3-generic-pae M=/usr/src/linux/drivers/media/dvb/dvb-usb KBUILD_SRC=/usr/src/linux modules
[19:57] <Guest11589> It compiles all other modules in that directory fine but not AZ6007. Not even when I copy .config to that headers directory.
[20:01] <Guest11589> I guess I waited long  enough to know noone in here, who's online, knows something about that.
[20:04] <JanC> Guest11589: just be patient  ;)
[20:06] <JanC> Guest11589: most people aren't in here 24/7 (they have a job, social life, need to sleep, etc.), but they might answer if you stay around
[20:06] <Guest11589> As I've said "...who's online..."
[20:07] <JanC> well, "being online" doesn't equal "checks #ubuntu-kernel every 15 minutes"  :P
[20:07] <Guest11589> hehe :-)
[20:08] <roadmr> Guest11589: I assume you enabled the module in the "make menuconfig" step?
[20:08] <roadmr> Guest11589: I think the right procedure to get the module enabled in future kernels would be to file a bug in launchpad.net - but kernel changes are approached with a lot of caution, so it can be expected to take a while.
[20:09] <sforshee> Guest11589, I'd assume that it's using the .config file from /usr/src/...
[20:10] <Guest11589> working directory has been /usr/src/linux
[20:11] <Guest11589> yes, I enabled it then
[20:11] <sforshee> make -C /usr/src/linux-headers-3.4.0-030400rc3-generic-pae
[20:11] <sforshee> it will use .config from that directory
[20:12] <Guest11589> That's what I thought, but that .config had my module enabled
[20:12] <Guest11589> "Not even when I copy .config to that headers directory."
[20:12] <sforshee> so you copied the .config from your 'make menuconfig' invocation over to that directory?
[20:13] <Guest11589> yup
[20:14] <Guest11589> cp /usr/src/linux/.config /usr/src/linux-headers-3.4.0-030400rc3-generic-pae/
[20:15] <sforshee> oh, wait, that's not enough
[20:15] <sforshee> because the stuff generated from the .config probably isn't regenerated
[20:16] <sforshee> that really isn't the way I'd recommend you do it anyway, modifying stuff in the linux-headers package install directory
[20:17] <sforshee> the shortcut would be to modify the makefile in that directory to use obj-m instead of obj-$(CONFIG_DVB_USB_AZ6007)
[20:19] <Guest11589> that's the latest: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/dvb/dvb-usb/Makefile
[20:19] <Guest11589> line 91 needs to be changed to?
[20:20] <sforshee> obj-m += dvb-usb-az6007.o
[20:21] <Guest11589> I'll try that... thank you
[20:21] <sforshee> that will force it to be built as a module no mater what the config says
[21:03] <dlynes> Is this the correct channel to ask about a problem with a proposed backported kernel?
=== kamalmostafa is now known as kamal
[21:33] <cnd> bjf, ogasawara, jjohansen: do you know how to check if a module that is not loaded should be loaded because it handles hardware connected to the machine?
[21:33] <cnd> I want to load bcm5974 after resume, but only if the trackpad is present in the machine
[21:35] <cnd> actually, I can get around this a different way
[21:35] <cnd> hmm... maybe not
[21:36] <jjohansen> cnd: you mean like a file in /etc/pm/config.d ?
[21:36] <cnd> sorta
[21:36] <cnd> I want to rmmod bcm5974 at suspend
[21:37] <cnd> and modprobe it at resume
[21:37] <jjohansen> cnd: right, you remove and add by specifying stuff in /etc/pm/
[21:37] <cnd> what I want is basically SUSPEND_MODULES functionality, but I don't want to add to /etc/pm/config.d from a package
[21:38] <jjohansen> cnd: hrmm
[21:39] <cnd> maybe instead of adding a config through xserver-xorg-input-synaptics I should really add it to pm-utils directly
[21:39] <cnd> since it's not exactly specific to X
[21:41] <cnd> but I can't see any simple way of making it work without an ugly hack in /usr/lib/pm-utils/sleep.d/75modules
[21:41] <ohsix> is this related to trackpads going nuts when the display is almost closed?
[21:41] <cnd> yeah
[21:41] <ohsix> neat, i knew it wasn't the magnet! :D
[21:42] <cnd> oh, pm-utils is somewhat careful about things
[21:42] <cnd> you can add multiple files with their own SUSPEND_MODULES lines
[21:42] <cnd> and it will concatenate them together
[21:42] <ohsix> so the device has to be removed entirely? what networkmanager already does on suspend isn't sufficient?
[21:43] <cnd> ohsix, the easiest way is to remove the device
[21:43] <cnd> no matter what you do it will be a work around
[21:44] <ohsix> hm, maybe; has anyone tracked down what the device is actually doing when it's supposed to be inactive? since it's inactive it might be able to be told to stop doing that :]
[21:45] <cnd> ohsix, I don't know what you mean
[21:45] <cnd> the device is active
[21:45] <cnd> and that's part of the problem
[21:45] <ohsix> i thought networkmanager disassociated and disabled it on suspend
[21:46] <cnd> this has nothing to do with NM
[21:47] <ohsix> i'm not saying it does, i'm saying networkmanager already has a role during suspend, what it does with the device should already deactivate it, if the driver still does it when it's deactivated that could be fixed
[21:48] <cnd> ohsix, how does nm have anything to do with your trackpad?
[21:49] <ohsix> you proposed to remove the module on suspend, networkmanager disassociates a device and deactivates it on suspend, how much different is that from rmmod'ing the driver?
[21:49] <ohsix> or. is the broadcom the touchpad driver
[21:49] <cnd> bcm5974 is the touchpad driver
[21:49] <ohsix> hurrrrrrrr, ok
[21:50] <ohsix> i had thought someone had discovered that it's the wifi antenna proximity that messes with the touchpad
[21:51] <cnd> no
[21:51] <cnd> it's the screen
[21:51] <ohsix> ok, that's what i'd suspected
[21:51] <ohsix> everyone i was talking to insisted it was the magnet, they didnt' belieeeeeeeeve me
[21:53] <ohsix> is it spread spectrum on the link or something? i think you can still disable that with a module option
[21:53] <ohsix> the bandwidth and mode is adjustable so if someoen found out that it was, it could probably be massaged for those models