[07:22] <bullgard6> '~$ sudo modinfo snd; ...;  parm:  slots:Module names assigned to the slots. (array of charp)'. What does  »charp« stand for? '[array of] character parameters?
[07:22]  * smb guess char pointers
[07:22] <bullgard6> Ah!
[07:51] <ppisati> moin
[07:51] <apw> ppisati, moin, bad 
[07:51] <apw> head ?
[07:52] <ppisati> no, i'm ok
[07:54] <smb> ppisati, Surprising after having received so much beating... ;-P
[07:55] <ppisati> i didn't receive any beating, they did... :)
[07:55] <smb> Hehe, yeah, I know. Could not resist, though. :)
[08:10] <cooloney> morning, apw, smb and ppisati, EU folks
[08:10] <smb> Morning cooloney 
[08:11] <apw> cooloney, moin
[08:47] <ppisati> brb
[09:09] <cooloney> cking: morning
[09:09] <cking> cooloney, hiya
[09:10] <cooloney> cking: i'm just wandering are you still working on some benchmark for CFQ and deadline stuff?
[09:10] <cking> cooloney, not recently
[09:12] <cooloney> cking: ok, got it.
[09:36] <cooloney> cking: i'm just think how to reproduce the issue like this https://lkml.org/lkml/2011/6/9/167
[09:38] <cooloney> cking: apologize for the delay response.
[09:39]  * cking looks
[09:41] <cking> bah, need to kick my AP again
[09:42] <cooloney> cking: thx
[09:45]  * ppisati starts the airco
[10:43] <apw> henrix, you need a much bigger mic :)
[10:44] <henrix> apw: yeah, i'm using my internal mic atm :-/
[10:44] <apw> that'd be your problem, they suck
[10:55] <brendand> does anyone know why there might be a disparity between the amount of RAM you think you have installed, and the amount reported by /proc/meminfo (MemTotal). Let's assume it's a 64 bit install
[10:55] <apw> brendand, by how much ?
[10:56] <apw> brendand, i believe memtotal is how much memory was 'available' when the kernel freed unused ram into the pool.  ie the kernel itself is not included and nothing reserved is included
[10:56] <brendand> apw - what kind of things reserve memory?
[10:57] <apw> acpi tables, memory to hold information about the memory pages themselves, the kernel binary itself etc
[10:57] <apw> those things which you need to already have to be able to "visualise" the memory you have
[10:58] <brendand> is there anywhere that tells me how much each of those things uses?
[10:58] <apw> brendand, in a digestible form not that i know of, you get hints probabally in the dmesg output at boot about the sizes of various things
[10:58] <apw> how much are we missing that you'd care
[10:59] <brendand> so, let's say the memory installed is 1GB and MemTotal is 758076 kB
[10:59] <apw> that sounds unexpectedly low to me
[11:00] <apw> with 4GB or RAM i am missing 186100
[11:01] <brendand> i have another system which has 8Gb installed and is missing 2Gb
[11:01] <brendand> although that's i386 PAE
[11:01] <brendand> not sure if that explains it
[11:01] <apw> if its as much as 2GB thats more likely a h/w limitation and the e820 dump can help figure that out
[11:02] <apw> not all machines cna express all the RAM they will let you put in them
[11:02] <apw> for that 1GB machine a dmesg may be instructive
[11:02] <ohsix> you still need pci regions for devices that can't do DAC and bios' that won't let you tell it that you want that :]
[11:04] <apw> yep all depends how much ability to non-linearise the BIOS/hardware has in placing various ram components
[11:04] <apw> i suspect with 8GB you have two 4GB sticks, so it probabally cannot avoid dropping the ACPI and PCI spaces over the RAM and hiding some of it
[11:05] <brendand> http://paste.ubuntu.com/1071081/
[11:05] <apw> if it has 4 2GB sticks it might be able to do something more appropriate
[11:05] <brendand> for the 1GB system
[11:05] <brendand> oh i see the e820 stuff at the beginning
[11:06] <brendand> 759MB LOWMEM available.
[11:07] <brendand> right on the button. have no idea how it works that out though
[11:08] <apw> [    0.000000]  BIOS-e820: 0000000000100000 - 000000002f780000 (usable)
[11:08] <apw> and that is what the BIOS says it has
[11:09] <apw> 2f780000 is 759M
[11:11] <apw> brendand, and i can see nothing that even looks like the rest of any ram this machine is meant to have even marked as something else
[11:12] <apw> brendand, are we sure this has 1GB in it?  if i add this up its pretty much saying there is 768MB, which would be a 512MB+258MB 
[11:13] <ohsix> dmidecode to the rescue
[11:13] <apw> brendand, or is it being reserved for video ram, a low-end video sharing main memory for its vram, though 256MB seem excessive
[11:14] <apw> brendand, yeah as ohsix says can we have a full dmidecode output
[11:14] <brendand> apw - the video is onboard intel
[11:15] <apw> [    1.034945] agpgart-intel 0000:00:00.0: detected 131072K stolen memory
[11:15] <apw> so 128M is likely used by video
[11:16] <apw> i would also check in teh bios to see how much it thinks its allocating
[11:16] <brendand> apw - the figure is from dmidecode (i don't have physical access to these systems). so it's either 1GB stick or two 512MB
[11:16] <brendand> http://paste.ubuntu.com/1071094/
[11:17] <brendand> one gigabyte stick
[11:17] <brendand> right, i had heard/read that video cards can take ram for vram
[11:17] <brendand> and we just need to look in dmesg or is there somewhere in sys/proc where that can be looked up?
[11:18] <apw> brendand, yep so i would be suspicious to know if the bios has allocated 128 or 256 given the GART size is 256
[11:19] <apw> as for your 8gb machine again we'd need a dmesg
[11:20] <ohsix> what was the problem anyways, suspect that a more than neccessary amount of ram is being shadowed?
[11:20] <apw> symptom as reported was 1gb machine showing 759MB of ram
[11:20]  * ppisati -> lunch
[11:20] <apw> and yes suspecting that the shadowing in the BIOS is wrong
[11:22] <ohsix> hm, i forget if pci=nocrs is worth trying
[11:22] <ohsix> the bios can be dumb about placing devices and theres a way to get linux to try again for you
[11:23] <apw> i think in this case the machine has plenty of space to play with, as it only has 1G
[11:23] <brendand> 8GB DMI - http://paste.ubuntu.com/1071099/
[11:23] <ohsix> right, assuming the bios isn't super silly :p
[11:24] <brendand> 8GB dmesg - http://paste.ubuntu.com/1071103/
[11:24] <ohsix> it can't move all the devices anyways, so it could still leave the problem one in a bad place :\
[11:25] <brendand> apw - ok, scratch the 8GB one
[11:25] <brendand> apw - i was reading a system rom as a ram stick
[14:00] <Kalidarn> hi, i'm currently getting a kernel panic with the ATI fglrx driver, when i shut down what's the current doc for debugging kernel panics
[14:00] <Kalidarn> https://wiki.ubuntu.com/Kernel/CrashdumpRecipe i had a look at that, not sure if those 9.04 instructions are relevant
[14:00] <Kalidarn> or if there's a better way now
[14:25] <Kalidarn> hmm wel not really any need to debug it further the screen error is exactly the same as comment #4 of bug 750437
[14:25] <ubot2> Launchpad bug 750437 in fglrx-installer "fglrx hard lockup on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/750437
[15:18] <alexbligh1> Are there any plans to build a precise-backport kernel for Lucid, like there is oneric backport & natty-backport?
[15:47] <cking> apw, http://www.entropykey.co.uk/res/device.jpeg
[15:49] <apw> alexbligh1, i believe not currently
[15:49] <apw> thats what precise is for
[15:50] <Insyte> I have a Lucid -virtual VM that is crashing every few days.  It crashes hard and fast enough that no crash info escapes via syslog or local log files.  Any recommendations on trying to capture some decent data to start tracking down the cause?
[15:52] <ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.8_armhf.deb
[15:52] <ppisati> ogra_: give it a test if you can
[15:56] <apw> Insyte, what virtualisation are you using to run it
[15:56] <Insyte> KVM
[15:56] <Insyte> Under ganeti.
[15:58] <apw> Insyte, a quick chat round here, noone seems to know of a way, but noone is willing to say there isn't one ... you might get a better answer on #ubuntu-server however
[15:58] <Insyte> I'll check there.  Thanks.
[16:00]  * ppisati -> gym
[16:01] <ogra_> ppisati, will do, thanks
[16:01] <Eimann> Insyte: I guess you already tried kdump?
[16:02] <Insyte> Eimann: I've been reading up on it.  Haven't tried it yet.  Is that generally the best approach?
[16:02] <Eimann> Insyte: if you can force it to hang without a reboot, you can also try virsh dump <vmname> crashdump
[16:03] <Eimann> I would try kdump first and see if this already give you a coredump you can analyze
[16:03] <Insyte> OK, thanks.  Unfortunately the second option isn't available to me as Ganeti doesn't use libvirt.
[16:04] <Eimann> hmm yes indeed
[16:05] <Insyte> If I'm not running a -debug kernel, am I going to get any useful information out of a kdump dump file?
[16:11] <apw> Insyte, you should, as most crashes the basic information is what one needs to have any clue as to caus
[16:11] <Insyte> apw, excellent.  Thanks.
[16:12] <argu_halfabrain> Hi
[16:13] <argu_halfabrain> any clues why only 2 cores would be enabled on a quad core system? running latest 12.04, was fine on 10.04
[16:20] <alexbligh1> apw, indeed, but we have binaries that won't run under precise due to library issues (libdbi1/libdbi0, openssl1.0.0 vs 0.98.x etc.) - and I'm trying to avoid having 2 different software versions just to run on different hardware. The long term answer is 'move everything to precise' which is what we are doing for a next major release but it's a PITA for a minor release.
[16:20] <apw> argu_halfabrain, pastebin the output of cat /proc/cpuinfo
[16:20] <argu_halfabrain> from lshw -class cpu "cores=4 enabledcores=2 threads=4"
[16:21] <apw> alexbligh1, i can see how yet another lts backport would be handy, but you'd be just asking for Q then R for it, and we have to stop somewhere
[16:21] <argu_halfabrain> http://pastebin.com/EgzucL66
[16:25] <apw> argu_halfabrain, nothing obvious in there, it appears to have brought up the hyper threads on the first cpu if i am reading it right, pastebin a dmesg perhaps
[16:25] <alexbligh1> apw, well, the place I'd suggest stopping is 'nothing beyond the next LTS'. Our launch date was within a week of Precise so was no chance of using that. If we don't move to the next LTS by the time LTS+1 is out, that's our issue.
[16:26] <alexbligh1> apw, I can't believe other people who are "LTS only" for userspace would not have similar issues.
[16:26] <apw> alexbligh1, and that has been argued, that there is utility in lts+1 to lts backports, but that was not planned for L
[16:26] <apw> alexbligh1, the plan with the lts backports was to give you h/w enablement for the previous lts until the next lts came out, which it has
[16:27] <apw> that goal doesn't need P on L, and so its not been in plan
[16:27] <argu_halfabrain> also lshw -class cpu http://pastebin.com/1js0aCcu
[16:28] <argu_halfabrain> rebooting that machine, will pastebin dmesg in a minute
[16:32] <alexbligh1> apw, grumble grumble :-)
[16:33] <apw> alexbligh1, i am not ruling it out as every happening, but right now its not the plan.  we review the plans often however for impact.  it might be appropriate to ask on the kernel-team list stating your use case
[16:34] <alexbligh1> apw, thx - I might just do that :-)
[16:35] <argu_halfabrain> dmesg output http://pastebin.com/1LLQC4gw
[16:43] <apw> argu_halfabrain, whats in /sys/devices/cpu, how many cpuN directories
[16:43] <apw> cat same directory online and offline
[16:46] <argu_halfabrain> apw: cpu0, cpu1
[16:46] <argu_halfabrain> online 0-1, offline 2-31
[16:55] <apw> argu_halfabrain, ok nothing there is any help at all, i think the next step is file a bug and we'll want a dmesg and /proc/cpuinfo for the work and non-working cases
[16:56] <argu_halfabrain> apw, ok thanks
[16:56] <argu_halfabrain> gonna try a custom kernel
[18:34] <bryceh> jsalisbury, bug #918769 looks ripe.  Patch is now in 3.5-rc4.
[18:34] <ubot2> Launchpad bug 918769 in xserver-xorg-video-intel "X blink with Vostro 360 and Ubuntu Oneiric and Precise" [Medium,Fix released] https://launchpad.net/bugs/918769
[18:43] <jsalisbury> bryceh, thanks!
[18:51]  * ogasawara lunch
[19:02] <bobo37773> Anyone know which kernel patches are included in the ubuntu kernel related to copying to and from a usb device?
[19:09] <bobo37773> Yeah alright. Guess I'll just have to hack it apart until I can figure it out. Thanks anyways
[20:58]  * bjf -> giving blood
[22:41]  * bjf[blood] is back