[07:51] <AceLan> is there anyone runs lucid kernel can paste the below command result here to me thanks
[07:51] <AceLan> ls /sys/firmware/acpi/tables/
[07:52] <ikepanhc> ikepanhc@Natasha:~$ ls /sys/firmware/acpi/tables/
[07:52] <ikepanhc> APIC  DSDT     FACP  HPET  SLIC   SSDT2  TCPA
[07:52] <ikepanhc> BOOT  dynamic  FACS  MCFG  SSDT1  SSDT3
[07:52] <abogani> APIC  ASF!  DSDT  dynamic  FACP  FACS  WDDT
[07:52] <AceLan> ikepanhc: cool
[07:53] <AceLan> abogani: thx
[08:59] <lag> smb: let "var = 0xc041c0b4 + 0x14"; printf "%02X\n", $var
[08:59] <smb> lag, Yeah, guess that should do the trick
[09:03] <smb> mourning cking 
[09:03] <cking> morning!
[09:04] <abogani> morning all!
[09:05] <smb> abogani, Good moning
[09:05] <AceLan> morning~
[09:08] <cking> hrm, laptop overheated :-(
[09:08] <ikepanhc> the lenovo N3000?
[09:09] <ikepanhc> good morning .eu
[09:09] <smb> I wished we knew why this happens all of a sudden
[09:09] <smb> ikepanhc, hey
[09:10] <cking> ikepanhc, yep
[09:10] <ikepanhc> is there any document saying how linux-meta package doing?
[09:10]  * smb rolls the drum
[09:10] <cking> smb, I maxed the CPUs on spam filtering, and pop it went
[09:11] <ikepanhc> seems using 'depends on' to pull linux-image package
[09:11]  * apw looks blery
[09:11] <cking> blurry or bleary?
[09:11] <jk-> hey apw, welcome back
[09:11] <apw> a bit of both ....
[09:11] <smb> cking, Blurry would mean he is fast. Hard to believe at this time
[09:12] <apw> jk-, thanks .... not sure i wouldn't rather be supping some nice wine
[10:10] <lag> apw: Do you remember us talking about addr2line?
[10:10] <apw> some
[10:10] <lag> apw: http://paste.ubuntu.com/486657/
[10:11] <lag> I've written a shim
[10:11] <lag> Take -> hack -> keep
[10:12] <apw> looks interesting, it would need some commentry on whats in $ARM/$ARCH for instance
[10:12] <apw> as i assume we have to put something there
[10:13] <lag> That's the part you need to hack
[10:13] <lag> That's just where _my_ Arm code lives
[10:14] <lag> I could make it more general for distribution, this is just the one I'm going to use
[10:22] <lag> apw: For you: http://paste.ubuntu.com/486661/
[10:45] <smb> apw, Ok, eomp :)
[12:36]  * apw pops to lunch
[12:56]  * smb returns from there
[13:05] <pgraner> JFo, can you make sure that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399978 and all its dupes get dealt with? Somehow these have slipped thru the cracks and its a regression going all the way back to Karmic or so it would appear.
[13:05] <ubot2> Launchpad bug 399978 in linux (Ubuntu) "Excessive heat versus excessive parkings (affects: 18) (dups: 4) (heat: 84)" [Undecided,Confirmed]
[13:06] <smb> pgraner, I had been looking on that I believe
[13:06] <pgraner> smb, no comments from you on that bug, not sure about the dupes
[13:06] <smb> The problem I see is that setting APM from 254 to 253 already starts the head load cycles
[13:07] <smb> pgraner, Wanted to discuss this first on irc and forgot
[13:07] <pgraner> smb, talk to manjo he has contacts at WD they might be able to shed some light on it
[13:07] <smb> Ok
[13:08] <pgraner> smb, JFo will still need to do all process magic on the bugs, get apport-collects and all that fun stuff
[13:08] <smb> I did not see increased heat on my netbook with a wd drive, so I cannot tell whether changing AAM would help temprature
[13:09] <smb> cking, Have you ever experimented with those? Though I think you rather "burn" ssd's :)
[13:10] <smb> JFo, I guess bug 417570 is one of those
[13:10] <ubot2> Launchpad bug 417570 in linux (Ubuntu) "hard disk is really hot (affects: 3) (heat: 20)" [Medium,Confirmed] https://launchpad.net/bugs/417570
[13:12] <cking> smb, wd drive?
[13:12] <smb> cking, Yeah, maybe not only but I  only remember wd drives. I got two laptops with them and no heat problems
[13:13] <cking> smb, I've only seen overheating when I drove a micro SSD full tilt in a Dell Inspiron 6400 laptop 
[13:14] <smb> neither me. but from the reports its claimed that those run at over 50°C and changing APM reduces that, but cause the drive to load-cycle the heads every 15 or so seconds
[13:14] <smb> I can confirm the problem with load-cycling
[13:17] <smb> cking, Cannot even say whether this is more than a annoyance. One of my drives has nearly done 20,000 of them and still runs. But you hear the clicking everytime it does it
[13:17] <apw> many are only rated in the millions of loads, which if it does it every 15s can mount up pretty fast
[13:17]  * cking wonders how many times one can cycle a HDD before it fails
[13:17] <apw> cking, smartutils can tell you i think
[13:18] <smb> apw, right smartctl from smartmon-tools
[13:18] <smb> or the disk util from system->admin
[13:18] <pgraner> apw, so does hdparm -I /dev/sda
[13:19] <pgraner> apw, could this be causing some of the heat issues akgraner is seeing?
[13:20] <apw> pgraner, this is the same old machine, same as tim's yes?
[13:20] <smb> pgraner, She could check the temp of the drive
[13:20] <apw> pgraner, if so, unlikely, as it was ok on lucid and i think those settings were karmic and later
[13:21] <apw> pgraner, she is seeing a return to the old climes to 90c and switches off thing isn't she ?
[13:21] <pgraner> apw, yep, sometimes the box just locks up and won't shut off
[13:26]  * cking pops away for a late lunch
[13:28] <apw> bah none of these values really means anything to me, a normalised vale of 103, worst of 94 and actuall of 44 for temperature on my HDD, what the heck does that mean
[13:29] <smb> apw, It feels sometimes only the actual makes sense
[13:31] <smb> apw, I hope your driver never saw a 94 in temperature
[13:31] <smb> err, drive
[13:32] <apw> indeed lets hope not
[13:39] <tgardner> ogra, is there going to be any rush to re-upload the maverick ti-omap4 package after Beta? I'm out Friday-Mon for the US holiday weekend.
[13:39] <tgardner> I think apw will be around, so he could likely do it.
[13:40] <pgraner> apw, I notice that on my Thinkpad ibm-acpi is borked, it reports all temps as 32F or 0C except the CPU 
[13:41] <smb> pgraner, Was that ever different? What model?
[13:42] <pgraner> smb, T410, I've only ever had maverick on it and had been using acpi temp reporting, I thought I'd check out the ibm-acpi and found that strangeness
[13:43] <smb> pgraner, It usually does this for those sensors not present. It might also be that you just have only one. Or it is a bug
[13:43] <smb> Hm, actually mine does -128 for those not present
[13:43] <pgraner> smb, ok
[13:48] <lag> apw: include/sound/soc.h:731
[13:51] <pgraner> lag, looks like i didn't send you an email, one is in your box now.
[13:53] <lag> apw: http://paste.ubuntu.com/486626/
[13:53] <lag> pgraner: Thanks
[14:06] <JFo> pgraner, working on those HDD heat related bugs
[14:30] <ogra> tgardner, if apw can do it thats fine 
[14:32] <apw> JFo, be good to make sure we have some kind of long term monitor of the drive temp, like we do for CPU overheat bugs
[14:32] <JFo> yep
[14:32] <apw> that page we did for them has the basic 'watch' stanza to collect it over time
[14:33]  * JFo looks for it
[14:34] <JFo> apw, this one? https://wiki.ubuntu.com/Kernel/Debugging/HighTemperatures
[14:35] <apw> we should make up a scripty similar to monitor disks too
[14:36] <JFo> k
[14:40] <diwic> smb, or whoever was wondering about RT kernel for ham radio, have you tried the normal kernel, and how well does it work?
[14:40] <smb> sconklin, ^
[14:40] <JFo> using hdparm doesn't seem so show me temp on my machine
[14:40] <apw> sudo hddtemp -n /dev/sda
[14:40] <apw> JFo, ^^ 
[14:40] <sconklin> diwic: I haven't gotten all the bits installed to test yet, but I intend to
[14:41] <JFo> command not found apw
[14:41] <diwic> sconklin, I'm curious of how well things would work and also how well the preempt kernel would work
[14:41] <sconklin> diwic: This is a horrible set of things to install, mostly from source, all glued together with shell scripts and config files that have to have the paths to various source dirs
[14:41] <JFo> clearly I am missing something
[14:41] <sconklin> But it's definitely on my list to try various kernels
[14:42] <sconklin> It may be that they spec the rt kernel because it uses jack
[14:43] <sconklin> diwic: this will give you a feel for all the things you have to install: http://code.google.com/p/sdr-shell/wiki/HowToCompileandInstallDttSPfromCGRAN
[14:43] <diwic> sconklin, my general impression is that normal kernels will do fine, but it might be that some drivers blocks the kernel for a very long time 
[14:44] <diwic> sconklin, dpkg-configure jackd will do the section under "Kernel parameters" there
[14:44] <sconklin> well, if I have a setup that reliably reproduces blockage like that, that's useful. I did some rt and low-latency work many years ago, and half the problem was being able to excercise the paths that held the kernel locks
[14:44] <sconklin> diwic: oh, thanks for that
[14:45] <diwic> sconklin, for Natty I'd like to change the group name
[14:45] <diwic> sconklin, but that's a different story
[14:46] <sconklin> diwic: the amateur radio community fights a lot of sound problems, but they're not well plugged into the rest of the development community, so there are a lot of various pages with voodoo recommendations for dealing with problems
[14:47] <diwic> sconklin, and unfortunately, the ubuntu community pages are not really correct either
[14:47] <diwic> as in there is "voodoo" there as well
[14:48] <sconklin> yes. I hope that the stackexchange goodness can overtake that eventually
[14:57] <apw> sconklin, sounds like you are generally using hideously out of date kernels as well, cause of the RT requirement, one I cannot begin to understand
[14:57] <apw> i don't see ham radio occuring at a speed to engender such a requirement
[14:58] <sconklin> apw: these are primarily requirements for SDR orr software defined radio, which places very high computational demands on the system while still having to move multiple audio streams around at 48000 samples per second or higher, with zero dropouts
[14:59] <diwic> sconklin, that's unimportant compared to the latency demands you have
[15:00] <sconklin> diwic: kernel latency or audio stream latency? Because delays in the audio stream aren't that big a deal (in a pipelining sense)
[15:01]  * apw tries to see how you have any latency requierme
[15:01] <apw> requirement, if you have no pipelining latency requirements
[15:01] <apw> but then thats why i am a kernel engineer not an audio engineer
[15:02] <diwic> sconklin, what's the lowest latency you need for *anything*? 
[15:03] <diwic> sconklin, as in "when my ham radio station receives a packet, I want it to start playing within x msecs"
[15:03] <sconklin> apw: Processing (FFTs and other signal processing occurs over a time range of samples, which is continuously processed. If you lose samples or have to wait for them, it blows the processing, and it doesn't resolve until the entire set of linear samples gets filled again with good data
[15:04] <sconklin> diwic: disclaimer: I am only just delving into this (SDR) but in general for standard TX and RX, hundreds of mS are probably ok. It's very like mumble in that sense.
[15:06] <sconklin> for packet based things where theres a protocol on top, this might be slightly more restricted, but I've done some of this with packet radio, and standard kernels work fine
[15:06] <diwic> sconklin, how can waiting for samples blow the processing? You'll just continue the processing once the new samples has arrived, which leads to a higher latency.
[15:08] <sconklin> because it created a delay in the output, and the output is fed into further processing to decode various frequency-shift and multitone encodings, and accurate timing matters. Not so much with voice, our brains are pretty good at fixing voice
[15:09] <sconklin> it blows it because there are multiple stages of processing, and later ones depend on the timing
[15:09] <sconklin> Hmm, I sense a conference talk here.
[15:09] <diwic> sconklin, not over ham radio, I hope ;-)
[15:10] <sconklin> well, more like "Amateur radio audio processing, which metrics matter in audio and the kernel"
[15:11] <diwic> sconklin, "over" as in "transferred over"
[15:11] <diwic> sconklin, sample processing should not have the wall clock as input, only count samples. IMHO. 
[15:11] <sconklin> oh :)
[15:11] <azop> f
[15:12] <sconklin> diwic: that's not how the world works ;-)
[15:12] <diwic> sconklin, fix the world, then ;-)
[15:13] <sconklin> when all this stuff was done in special SP hardware, these were design constraints, but now that it's moving to generalized computing platforms, it's not so simple.
[15:15] <sconklin> diwic: by the way, these are the some of the same issues that the financial quant guys care about in the kernel. Not for Audio, but for analyzing market data. That's why RH pays a lot of attention to things like the statistical distribution of latency of packets from the wire to userspace
[15:17] <diwic> sconklin, yeah, I heard that talk by John Kauer (?) /RedHat at Linux Audio Conference. 
[15:17] <diwic> sconklin, he also tried to explain the difference between rt and preempt kernels
[15:17] <sconklin> oh, I didn't would like to have.
[15:18] <sconklin> it's interesting, there are different classes of users. Some want a guarantee that latency will never, ever exceed a certain amount, and others don't care about a few outliers as long as the mean is very low. Two different problem sets.
[15:19] <diwic> sconklin, but that was more from a design rather than user perspective, but I got the feeling that the preempt kernel would work for all practical purposes, so you won't have to try the rt one
[15:20] <sconklin> diwic: iirc that's correct. I used to work with Clark Williams at RH, and he did a lot of that work. I built the hardware test set that they probably still use to measure interrupt processing latency
[15:22] <pgraner> smb, it this what you have been working on?
[15:22] <pgraner> http://marc.info/?l=linux-kernel&m=128335075002360&w=2
[15:23] <diwic> sconklin, ah, that was nice to know, now I know who to bug the next time I try to understand latencytop
[15:23] <smb> pgraner, No looks like something different
[15:23] <sconklin> after my time lalalala can't hear you
[15:23] <sconklin> ;-)
[15:23] <pgraner> smb, ok, might want to keep it in mind
[15:24] <diwic> I need to call it a day for now.
[15:24] <sconklin> but seriously, Clark is a really nice guy and very approachable and knows this inside out
[15:24] <smb> pgraner, Yeah, thanks. I keep an eye on it for Lucid and probably need to consider for Hardy
[15:24]  * pgraner nods
[15:26] <tgardner> pgraner, have you checked on emerald recently? seems dead
[15:27] <pgraner> tgardner, no, I was out yesterday, lemme go down there now
[17:28]  * smb sees a pint in his near future
[17:30]  * amitk is seeing the same future
[17:31] <smb> Always good to get the nice fortune cookies. :)
[17:31] <amitk> heh
[17:48] <JFo> sconklin, got the first of the boxes today
[17:49] <sconklin> strange, they were together when they left. Maybe that's a feature of the cheap shipping rate
[17:50] <sconklin> JFo: I'm not sure how useful most of that will be.
[17:54] <JFo> eh, it will or it won't
[17:54] <JFo> either way...
[17:54] <JFo> I got the Litl with the curiously strong magnets?
[18:00]  * achiang perks up at mention of litl
[18:22] <apw> smb-afk, what a good idea
[18:26] <cking> JFo, don't put those magnets near a HDD
[18:26] <JFo> heh
[19:02]  * tgardner lunches
[19:31] <manjo> cking, you coming back :) 
[19:31] <manjo> cking, did I scare you ? 
[19:37] <cking> manjo, http://paste.ubuntu.com/486907/
[19:53] <tgardner> apw, http://marc.info/?l=linux-kernel&m=128335681711984&w=2
[20:11]  * jjohansen -> lunch
[20:44]  * ogasawara lunch
[23:53] <brot> i am trying to bisect a bug in the kernel, and need to compile my own kernel packages to do so. running "make-kpkg --initrd --append-to-version=bisect1 kernel-image kernel-headers" for the vanilla kernel sources fails with:http://paste.ubuntuusers.de/398863/  . can someone tell me what i am doing wrong?