=== n0u_ is now known as n0u
[02:48] <CarlFK> amitk: are you the kernelopps expert?
[02:50] <CarlFK> http://dpaste.com/93532/  dmesg shows 3 stackdumps 
[08:42] <amitk> CarlFK: IIRC, you are running kerneloops on a server with no GUI?
[11:56] <apw> smb_tp, so we have a bug about extending p4-clockmod to include a newer celeron
[11:56] <apw> although it doesn't generally seem to be expected to be that useful, there are good stats reported
[11:56] <apw> in the bug for power savings and the like, how do we feel about slurping up something like that
[11:57] <apw> i get the feeling p4-clockmod is not loaded automatically even if you have such a cpu
[11:59] <smb_tp> apw, IFAIK no, you have to add it manually. About the savings I know there are different opinions. Normally throttling is rather seen as temperature control as the overall energy savings are not positive
[12:00] <smb_tp> apw, On the other hand, i the cpu does nothing it can do it half speed without taking longer, I guess
[12:00] <apw> yeah i saw those arguments, but some of the users seem to report very good savings on overall power from an idle system, whcih could make some sense
[12:00] <apw> yeah it depends some on how the idling is performed
[12:01] <apw> if the module is an opt-in thing anyhow it doesn't seem like a bad thing to include support for additional cpus to my mind
[12:01] <smb_tp> apw, I think if that change is small, we could add it as a SAUCE patch as hw enablement
[12:01] <apw> its a single line, to add a new processor id to p4-clockmod,
[12:02] <apw> i am wondering why its not upstream as yet, not managed to find any discussion  on that side
[12:03] <smb_tp> apw, I have the feeling sometimes, that this is somewhat abandoned due to the savings arguments
[12:03] <apw> yeah, and yet we have the module at all ... so it clearly does something for someone
[12:04] <apw> even if it is only for heat, then we should have it for heat (we == linux kernel community more than ubuntu)
[12:05] <smb_tp> apw, It makes some sense I think. Maybe mjg59 knows a bit more about whether there is some upstream maintenance to that.
[12:06] <apw> yeah ... have just found the kerneltrap thread on it, so will go read that and see what the outcome was
[12:16] <apw> this thread is pretty compelling as to why you really don't want it, how it makes things worse only
[12:17] <smb_tp> apw, What is the reasoning there?
[12:19] <apw> that the normal state of things is that when the system is idle it enters C2 state, which consumes the same amount of power as being in a skipped cycle due to throttling
[12:19] <apw> so on average the the overall consumption would be the same
[12:20] <apw> assuming you don't need more than half the cycles
[12:20] <apw> which is normal
[12:20] <apw> if you do need all the cycles, then you are actually worse off, as you run as half+idle cost for 2x the time and that can lead you to consume more power not less
[12:22] <apw> i think the right thing to do is write a clear and concise summary of this thread and post it in the bug and see what happens
[12:26] <smb_tp> apw, The strange thing then is only that it seems to have a measurable effect. Do you know whether C states are implemented on centrinos?
[12:30] <apw> that is an interesting question, this thread inplies so, but perhaps there is a bug elsewhere that prevents their use or something
[12:38] <gregd> hi guys, just was having some problems with my intel wireless card (was dropping constantly connection). Many people seemed to have similar problems. Found that the newest kernel 2.6.28-rc6 has a fix for it (look for "iwlagn: fix RX skb alignment
[12:38] <gregd> " in http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.28-rc6). I'm really looking forward for the fix to be incorporated into ubuntu-kernel. But in the meantime, should I compile the 2.6.28-rc6 kernel by myself?
[12:39] <amitk> gregd: a 2.6.28-rc6 kernel should be available for jaunty this week. If you can wait, then you could simply install that kernel.
[12:40] <gregd> this week seems to more than enough, that would be perfect :)
[12:41] <amitk> gregd: then just check back here around Thursday. We are shooting for an upload today.
[12:41] <gregd> great! ok will be back later this week! Thanks guys!
[13:00] <tjaalton> does hardy have a package to clean up old kernel versions, keeping the current and latest kernel alone?
[13:03] <amitk> tjaalton: moi! Not that I know of. There was an attempt to get it in Intrepid. But it was removed at the last minute due to some bugs.
[13:05] <tjaalton> amitk: ah ok, thanks
[13:06] <tjaalton> I'm using pkgsync anyway, so adding old versions to the maynothave-list works quite well :)
=== asac_ is now known as asac
[14:03] <CarlFK> amitk: it's u-desktop, but kerneloops wasn't installed.  just installed it.
[14:04] <amitk> CarlFK: is the kerneloops-applet running?
[14:08] <CarlFK> i just didi sudo apt-get install kerneloops - I don't see anything on the bar - it would be over by the clock, right?
[14:09] <amitk> CarlFK: no. It doesn't show up in the tray.
[14:09] <amitk> CarlFK: "ps aux | grep kerneloops"
[14:13] <CarlFK> yup: /usr/sbin/kerneloops
[14:14] <amitk> CarlFK: run kerneloops-applet from cmdline
[14:14] <CarlFK> in case it isn't clear: I just now installed it, after the crash (thought it was installed - you asking made me check...)
[14:14] <CarlFK> running
[14:15] <CarlFK> got dialog
[14:15] <CarlFK> 'always'
[14:15] <CarlFK> is that it?
[14:15] <amitk> yup
[14:15] <CarlFK> neat 
[14:15] <CarlFK> brb
[14:15] <amitk> CarlFK: i think when you logout/reboot your computer, the applet should be automatically started.
[14:43] <apw> rtg if we were considering pulling a newish driver back into intrepid, which was not already there would it go into the main tree or lbm ?
[14:44] <rtg> apw: it could go main tree 'cause there is little chance of regression. what driver?
[14:44] <apw> i felt it might, this is a panasonic laptop keys support driver
[14:45] <rtg> just be sure to evaluate the regression potential.
[14:45] <apw> no idea yet if its is a trivial backport or not, and yep that needs looking into
[15:00] <amitk> BenC: rtg: why can't skipabi=true really skip an abi check? The third check in scripts/abi-check is really not necessary in case of a new arch or a quick compile test.
[15:00] <rtg> amitk: I never use it, so it's never really annoyed me.
[15:01] <rtg> amitk: besides, for a subsystem quick compile test I use a completely different method.
[15:01] <amitk> rtg: you never have to do test builds when ABI is not yet updated?
[15:02] <rtg> rarely.
[15:02] <BenC> amitk: touch and empty file
[15:02] <rtg> Try something like this: 'make -C debian/build/build-generic M=`pwd`/drivers/net/wireless'
[15:03] <amitk> rtg: it isn't a subsystem compile check, I want to compile the whole shebang but not bother about abi.
[15:03] <BenC> amitk: basically you will need to just create empty ABI files for each flavour...the check fails because we never want to upload without the previous abi files
[15:03] <amitk> BenC: dpkg-buildpackage doesn't like empty files
[15:03] <BenC> amitk: then create one fake symbol entry :)
[15:04] <BenC> amitk: in your case an out-of-tree build usually works well for a compile test
[15:05] <amitk> BenC: out-of-tree would be ok for compile test. But if I wanted to check for packaging issues, I would need to use a binary-<flavour> target
[15:05] <BenC> amitk: abi files with one fake symbol is what you will need
[15:06] <BenC> amitk: either that or just grab the abi files from the initial build(s) as stub's
[15:06] <BenC> I just nailed down the final changes for the headers packages (the move from include/asm-* to arch/*/include/asm needed to be handled)
[15:07] <BenC> fglrx dkms build fine with the new header packages, so I think I'm done and ready for an upload
[15:07] <BenC> amitk: let me know when you have everything in place for armel
[15:07] <amitk> BenC: armel is all set since last night.
[15:07] <BenC> amitk: including the abi files?
[15:08] <amitk> BenC: yes. I already used the stub from a local build as the inital abi
[15:08] <BenC> I see they exist, so cool
[15:08] <amitk> BenC: who needs to be informed about EXTRAVERSION change? Have you checked the change?
[15:09] <BenC> amitk: let me commit the stuff I have and then I'll pull
[15:10] <BenC> amitk: best bet is ubuntu-devel@
[15:25] <amitk> BenC: build will fail. http://paste.ubuntu.com/76801/ Need to change some hardcoded paths for new EXTRAVERSION
[15:38] <BenC> amitk: instead of changing just extraversion, how about we add -ub- to the entire thing, even package name?
[15:39] <BenC> amitk: linux-meta will take care of upgrades (where we'll keep it flavour package names with no -ub-)
[15:41] <amitk> BenC: but would that reflect in /proc/version?
[15:43] <BenC> amitk: well the flavour name gets added to extraversion
[15:44] <BenC> right now it's $(abi)-$(flavour)...we just need to change it to $(abi)-ub-$(flavour)
[15:45] <BenC> amitk: I have to prep the audio patches for smagoun...if you could get this -ub- thing squared away, it will help make sure we still get an upload today
[15:46] <amitk> BenC: ohh right. I think that is a better proposal.
=== shay is now known as shayx
[18:51] <evand> Looking over bug 92014, I started to wonder if it's feasible to add some hint in /sys/block to discern between SCSI and SATA devices.  Does anyone know if this is possible and whether upstream would accept it?
[20:11] <amitk> BenC: -ub added to EXTRAVERSION and package names. Compile tested on amd64.
[20:11] <amitk> BenC: can you take over from here?
[20:19]  * amitk calls it a day...