=== fabbione-vac is now known as fabbione
[08:00] <cwillu> okay, so it looks like some recent xorg changes have fixed up the intel immediate crashing on resume from suspend, so now I can actually sensibly bug people about my delayed slow-crash after resume-from-suspend that I've had from early 2.6.30rc's through to present 2.6.31rc4
[08:01] <cwillu> now if only I could remember who I was talking to about that :p
[08:01] <cwillu> apw, I think that might have been you
[08:07] <cwillu> apw, yep, that was you:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380807
[08:07] <ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] 
[08:07] <cwillu> apw, the other bug that was confounding things is fixed and closed, so it might be a little easier to get something done now :p
[08:20] <jjohansen> cwillu: with this bug does your filesystem still require the fsck after reboot using reisub?
[08:21] <cwillu> jjohansen, you know, I can't remember.  The last couple times I just rebooted and came back a minute or two later
[08:21] <jjohansen> cwiilu: if so, is it possible to test with an alternate fs, say ext3
[08:21] <cwillu> was thinking about that
[08:22] <cwillu> s/was thinking/was just thinking/
[08:23] <cwillu> looks like I've got enough room on my backup disk to take an image and reinstall fresh
[08:24] <jjohansen> cwillu: that would be really helpful
[08:24] <cwillu> okay, so I'm going to just do an rsync, recreate an ext3 filesystem and rsync back (so, not actually a fresh install)
[08:24] <cwillu> is that still useful?
[08:25] <cwillu> I could do a complete reinstall and just restore /home, but that'll be more... annoying, than I'd like
[08:26] <jjohansen> yeah the rsync to ext3 is useful
[08:26] <cwillu> k, waiting for the backup to finish... will probably take a little while as it hasn't been home for the nightly backup in a couple weeks
[08:27]  * cwillu looks around
[08:27] <cwillu> what, doesn't everyone do an automatic nightly backup? :p
[08:27] <jjohansen> basically with reisub not working (ie. having fsck) the first place I would look is the fs layer
[08:28] <jjohansen> cwillu: I think most people around here use rsync, though I have played with simple backup config and it is easy and not too bad
[08:51] <cwillu> dtchen, also, I remember poking you about some pulseaudio instability and drop-outs, which was blamed on a bad driver.  Indeed, 2.6.31 on this machine (different from the laptop I'm talking about to jjohansen) hasn't had any audio issues that I've noticed.
[09:04] <apw> cwillu, heh sounds good
[10:06] <lesshaste> the touchpad on my toshiba tecra a9 fails intermittently and I see this in dmesg psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
[10:23] <lesshaste> http://bugzilla.kernel.org/show_bug.cgi?id=12577 appears to fix my problem
[10:23] <ubot3> bugzilla.kernel.org bug 12577 in Input Devices "DualPoint TouchPad at isa0060/serio1/input0 lost sync" [Normal,New] 
[11:27] <apw> lesshaste, is there an ubuntu bug for that one?
[11:27] <lesshaste> apw, yes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/365968
[11:27] <ubot3> Malone bug 365968 in xserver-xorg-input-synaptics "touchpad randomly failing" [Undecided,New] 
[11:27] <lesshaste> actually there seem to be a few
[11:27] <lesshaste> lots of people are reporting something similar
[11:27] <lesshaste> I emailed the kernel mailing list too
[11:28] <apw> no wonder we have not seen it, its not got a linux task, nor does it have a link to the upstream bug
[11:38] <lesshaste> apw, that's bad... in general the triaging of kernel related bugs on launchpad is really weak
[11:38] <apw> we do our best given our team is small, we can only triage those bugs marked for the kernel after all
[11:39] <apw> normally the x group is pretty good at triaging those and pushing them to linux for us
[11:39] <apw> this one sounds like its fallen through the holes.
[11:39] <apw> i've done the admin on it so at least we can see it
[11:42] <lesshaste> thanks
[11:42] <lesshaste> and yes the problem is that they are not even marked for the kernel usually
[11:42] <lesshaste> so the problem happens before you :)
[11:42] <lesshaste> I should say that it's a pretty fatal bug
[11:42] <lesshaste> I have to reboot to recover
[11:43] <apw> lesshaste, so you can trigger this?
[11:44] <lesshaste> apw, actually I don't know how to trigger it but it happens after I use X for a bit
[11:44] <lesshaste> every day I would say
[11:46] <apw> ok
[11:48] <apw> lesshaste, what arch you using i386 or amd64
[11:49] <lesshaste> i385
[11:49] <lesshaste> err.. i386
[11:54] <lesshaste> apw, although this is slightly OT, some teams don't seem to exist at all.. I had a grub bug that I fixed myself but no one from the grub team ever contributed to it as far as I can see
[11:54] <lesshaste> is there anyone on that team?
[11:55] <apw> there is probabally no specific team for grub.  foundations tend to care as its a critical package, we care as it impacts us directly as in interfaces directly with us
[11:55] <apw> though i would say we are concentrating on grub2 this cycle
[11:56] <lesshaste> that was the fix in fact
[11:56] <apw> move to grub2?
[11:56] <lesshaste> https://bugs.launchpad.net/bugs/389930
[11:56] <ubot3> Malone bug 389930 in grub "grub menu does not display after cold boot on Toshiba laptops" [Low,Confirmed] 
[11:56] <lesshaste> apw, yep
[11:57] <lesshaste> scott howard was very friendly but I don't feel this was his expertise
[11:57] <apw> noone upon noone really wants to work on grub, upstream has moved on to grub2 and so should we
[12:08] <lesshaste> apw, ok.. does anyone want to work on grub2?
[12:10] <apw> we are taking an interest in it from a bug point of view, not planning any dev for it here
[12:11] <apw> as a distro we are blazing a trail being one of the first mainstream distros to jump
[12:23] <lesshaste> apw, :) yes
[12:58] <ibrar> Can Any body tell me how to set ALL_PATCH_DIR
[12:58] <ibrar> I am compiling kernel using "fakeroot make-kpkg --initrd --append-to-version=-my --added-patches equal.patch   kernel-image kernel-headers"
[12:58] <ibrar> and always getting error 
[12:58] <ibrar> debian/ruleset/misc/patches.mk:108: *** Could not find patch for equal.patch.  Stop.
[13:00] <ibrar> ?
[13:08] <apw> ibrar, can't say i've ever used it sorry
[13:08] <apw> lesshaste, ok am pushing some packages with that 9-byte format patch applied, will update the bug when they are up
[13:11] <ibrar> apw: I have made changes to kernel! I only want to incremental build that 
[13:12] <ibrar> apw: Can you guide me how 
[13:12] <apw> i generally build using either in a ppa, or using the direct build interfaces myself
[13:12] <ibrar> apw: this fakeroot make-kpkg --initrd --append-to-version=-my --added-patches equal.patch   kernel-image kernel-headers command does not pick my changes so I have to clean and rebuild the whole kernel which waste a lot of time 
[13:13] <apw> generally you have to remove the build stamps from debian/stamps to get a partial rebuild, iirc.
[13:15] <ibrar> apw: These are really higher level timestamp and removing this cause almost compiling whole kernel again
[13:16] <apw> generally if the build one is still there it cleans the whole thing when using the debian/rules targets
[13:17] <apw> generally i am building using fakeroot debian/rules binary-generic
[13:17] <apw> and removing the build specific stamp lets me redo that without a full rebuidl
[13:18] <rtg_> ibrar, apw: how about a command of this form 'make -C debian/build/build-generic M=/my-module-directory-here' ?
[13:22] <apw> one doesn't end up with a whole kernel but if all you need is the .ko that can work
[13:28] <apw> rtg_, you prolly noticed i pushed a startnewrelease
[13:28] <rtg_> apw, yep
[13:28] <apw> i am also testing an aufs update, seems to be a few small bug fixes upstream so pulling them into karmic
[13:29] <rtg_> cool. Have our Live CD users noticed anything? Was A3 even built using aufs?
[13:30] <apw> yep the live cds are pretty magic, they use aufs if it exists so they switch automatically when we uploaded.  just before A3 the images were using it, and direct reports of goodness in testing
[13:31] <apw> lesshaste, pushed ... all yours
[13:32] <rtg_> apw, I might get back on LTS backports this week.
[13:33] <apw> that sounds cool.  its one of the laggers though we should separate it out as its not a release goal persee
[13:33] <lesshaste> apw, thanks!  how would I find them?
[13:33] <apw> details in the bug
[13:34] <lesshaste> apw, ah yes.. thanks
[13:34] <rtg_> apw, I'm pretty close to having the first batch of uploads. Just need to review the -meta details.
[13:34] <apw> so we should be able to get -server to test on it and let us know if it might work for them
[13:34] <rtg_> apw, yep, they are the only audience I'm interested in.
[13:53]  * cwillu proposes renaming livecd's to magiccd's
[14:07] <cwillu> oh, incidently, is it expected that wireless devices default to off in 2.6.31?
[14:07] <cwillu> I always have to hit the killswitch to turn it back on now
[14:08] <rtg_> cwillu, what laptop do you have?
[14:09] <cwillu> acer aspire 3690
[14:09] <cwillu> wireless has worked fine since edgy
[14:10] <rtg_> cwillu, its likely the acer WMI or RFKILL driver that is causing the problem. the rfkill subsystem was completely rewritten
[14:11] <gnarl> There has been an rfkill rework in 2.6.30/1 which still could have some problems
[14:11] <gnarl> rtg_, Yeah, apw was looking on some cases iirc
[14:11]  * cwillu pokes apw with the laptop-from-hell :p
[14:11] <cwillu> but it should or shouldn't be defaulting to off?
[14:12] <rtg_> cwillu, no, it should default to off
[14:12] <gnarl> It should be defaulting to the state it had last imo
[14:12] <cwillu> I can file a bug once I know if its actually a bug and not just something finally working as expected ;p
[14:12] <cwillu> k
[14:12] <rtg_> should not*
[14:12] <cwillu> (k, in the 'misread that to mean what you intended' sense :p)
=== You're now known as ubuntulog
[14:13] <apw> cwillu, do you find hitting the h/w switchy thing twice sorts it out?  generally where the default is inverted we see that occuring
[14:13] <cwillu> apw, I'll have to try that
[14:13] <cwillu> just heading off to work, but I'll let you know
[14:14] <cwillu> but... after startup, hitting it once brings it back.  after resume from suspend, I have to hit it once, and then restart networkmanager before it'll kick in
[14:14] <cwillu> the latter may just be my usual delayed and gradual crashing of everything
[14:14] <cwillu> (on resume)
=== fdd is now known as taoup
=== taoup is now known as fdd
[15:45] <Q-FUNK> howdy!  is there any 2.6.31 without DRM support that I could test?  I'm starting to believe that bug #396286 might be caused by the kernel and/or udev insisting on loading DRM to get KMS, even on hardware where it's not ported.
[15:45] <ubot3> Malone bug 396286 in linux "kernel 2.6.31-generic oops after loading initramfs" [Undecided,New] https://launchpad.net/bugs/396286
[15:47] <mjg59> udev will load the drm module even without KMS, yes
[15:48] <mjg59> But there's no drm for the Geode
[15:49] <mjg59> So that's not what's happening
[15:50] <Q-FUNK> mjg59: indeed, there isn't any ported yet AFAIK
[15:50] <mjg59> So it's not a drm issue
[15:52] <Q-FUNK> the drm-related modules are the only difference I can spot between what 2.6.30 and 2.6.31 loads whenever dpkg-reconfiguring the kernel
[15:52] <mjg59> If there's no driver with a PCI ID that'll bind to the Geode then nothing will end up running
[15:54] <Q-FUNK> aye
[15:55] <Q-FUNK> I'm just running out of options as to what could cause this kernel crash during bootup.  I've checked every possible issue I could, short of learning how to read kernel core dumps
[16:33] <Ng> how's 802.11n support in karmic? (I was in a room that had a/b/g/n yesterday and I only seemed to connect to g)
[16:36] <rtg_> Ng, 4965? I'm using an xps1330 to an 802.11n AP
[16:37] <Ng> 5300
[16:38] <rtg_> Ng, I have one of those somewhere....
[16:38] <Ng> rtg_: it could just be that NetworkManager wasn't trying to use the 11n in preference, I was just idly curious if we'd generally expect it to work
[16:39] <rtg_> Ng, yes, in general 802.11n _should_ work.
[16:40] <Ng> groovy
[17:57] <rtg_> apw, push it
[17:58] <apw> doh, will push the aufs update ...
[17:58] <Q-FUNK> heh
[17:59] <apw> rtg pushed
[18:01] <apw> rtg that dell rfkill switch thing i guess thats testable on anything with a h/w kill switch 
[18:05] <apw> Keybuk, just fyi the next kernel update will include a few aufs bug fixes
[18:05] <Keybuk> ok
[18:10] <apw> Keybuk, its applied in the kernels here: https://edge.launchpad.net/~apw/+archive/green if you want to play, passed basic testing here
[18:11] <apw> Keybuk, bah will take  a few mins to sort, PPA copy jut did something mad
[18:28] <apw> Keybuk, now they are there
[18:39] <rtg_> apw, do you have anything in the pipe for Karmic? I'm thinking about getting the aufs and dell-laptop changes uploaded.
[18:40] <apw> no nothing ...
[18:40] <rtg_> apw, ok, I'll wrap a bow on it in a bit
[18:40] <apw> rtg_, ack
[18:42] <apw> rtg the nice thing is that would also test sparc build fixes
[19:21] <lesshaste> apw, is shm.c: mmap() failed: Cannot allocate memory an  application bug?
[19:22] <apw> will generally be something that side though nothing is guarenteed in this world
[19:22] <lesshaste> ok :)
[19:23] <lesshaste> except death and taxes of course
[19:24] <lesshaste> people seem to see it all over the place so I doubt its actually a specific app issue
[20:01] <ivoks> rtg_: you said that you've removed drbd from karmic kernel, but it's still here?
[20:03] <sbeh> hi, 1. is there an option for debian/rules that does not clean the kernel-build? 2. how do i get linux-headers-2.6.28-14.deb because the file linux-headers-2.6.28-14-generic.deb depends on it?
[20:04] <rtg_> ivoks, I'm not sure where or when I said that. the git log shows a couple of maintenance touches since your January update.
[20:05] <ivoks> rtg_: mail sent to ivoks@grad.hr, 24/06/2009
[20:05] <ivoks> rtg_: anyway, could you remove it or should i report a bug about it?
[20:07] <rtg_> ivoks, start by reporting the bug. That'll give me time to remember what in hell drbd does.
[20:07] <ivoks> :)
[20:07] <ivoks> rtg_: it's network mirror, we moved kernel part to drbd8-source package which uses dkms
[20:08] <rtg_> sbeh,  there are several meta packages tha you can use to kkep your headers packages up to date; linux-headers-generic, linux-headers-server, etc.
[20:08] <sbeh> why is building kernels on debian that terrible complicated
[20:08] <sbeh> on gentoo i unpack the source and make menuconfig && make && cp .. /boot, thats it
[20:08] <sbeh> rtg_: I build git to boot from nfs
[20:08] <ivoks> you can do that on debian/ubuntu too
[20:09] <rtg_> sbeh, install devscripts, then type 'debuild -b'. 
[20:09] <sbeh> ivoks: but then i loose the ability to use apt for kernel-modules
[20:11] <ivoks> sbeh: which you had on gentoo? :D
[20:11] <sbeh> portage
[20:12] <sbeh> rtg_: this does create deb-packages, i don't know which files linux-headers-2.6.28-14-generic is awaiting in linux-headers-2.6.28-14.deb
[20:13] <rtg_> sbeh, 'debuild -b' creates everything, including the headers debs
[20:14] <sbeh> oh reset, i read the KernelCompile-Wikipage and I already got linux-image*.deb and linux-header*.deb, but the linux-header*.deb depends on a deb that did not get build while following the instructions on the wikipage
[20:14] <sbeh> what do you mean by 'everything'?
[20:15] <rtg_> sbeh, the linux-headers packages depend on linux-headers-*_all.deb. 'debuild -b' will build that package as well.
[20:16] <sbeh> does it take hours too?
[20:16] <sbeh> like debian/rules binary-generic?
[20:16] <rtg_> sbeh, that depends on your build machine.
[20:18] <sbeh> like ...
[20:18] <sbeh> argh, i will just try it
[20:19] <rtg_> sbeh,  read the man page on debuild first. by default it cleans first
[20:22] <sbeh> dpkg-checkbuilddeps: Unmet build dependencies: xmlto docbook-utils transfig sharutils
[20:22] <sbeh> wtf?!
[20:22] <sbeh> the hole texlive-distribution, wonderful!
[20:23] <rtg_> sbeh, have you tried satisfying the build dependencies by installing those packages?
[20:23] <sbeh> i dont want to
[20:23] <sbeh> linux can be build without texlive *g
[20:23] <rtg_> sbeh, this ain't linux, this is debian.
[20:25] <sbeh> hm, ok, I will build 2.6.28-13 than, so I can use the already build packages, thanks
[21:14] <lerot> hi
[21:15] <lerot> do most distros such as ubuntu  use the same system calls which UNIX has as mentioned by POSIX?
[21:38] <praveen> lerot: I think they do
[21:42] <sbeh> even gentoo with freebsd-kernel does ;)
[21:43] <Kernel_n00b> Hi
[21:43] <Kernel_n00b> Anyone here ?
[21:43] <sbeh> don't ask to ask, just ask!
[21:56] <Kernel_n00b> Hi,
[21:56] <Kernel_n00b> I need to measure the time consume by the Page-Fault process.
[21:56] <Kernel_n00b> I'm trying to measure the software's overhead (no including the HDD overhead).
[21:56] <Kernel_n00b> I'm using Ubuntu 9.04 running Linux Kernel 2.6.28
[21:56] <Kernel_n00b> I have a small application which generates Page-Fault and then calculate the time (user mode) it is handled.
[21:56] <Kernel_n00b> In order to deduce the IO (HDD) Time, I try to wrap the following section:
[21:56] <Kernel_n00b> file : linux/mm/page_io.c
[21:56] <Kernel_n00b> function: int swap_readpage()
[21:56] <Kernel_n00b> bio = get_swap_bio(GFP_KERNEL, page_private(page), page,
[21:56] <Kernel_n00b> end_swap_bio_read);
[21:56] <Kernel_n00b> Is this the correct location ?
[21:56] <Kernel_n00b> In addition, in order to time the process correctly, I couldn't decide whether I should use "gettimeoftheday()" , RDTSC (on Intel's CPU) or maybe the new Intel's HPET.
[21:56] <Kernel_n00b> Any Suggestion ?
[21:56] <Kernel_n00b> Thank you for your help.
[22:00] <Kernel_n00b> No one ?
[22:02] <Kernel_n00b> sbeh ?
[22:07] <manjo> Kernel_n00b, have you seen this http://ww2.cs.fsu.edu/~hines/present/timing_linux.pdf
[22:09] <Kernel_n00b> Nope.. I'll check it out.
[22:09] <Kernel_n00b> Thanks!
[22:09] <manjo> Kernel_n00b, looks like that is what you need to do instead of adding kernel code 
[22:11] <Kernel_n00b> How did you find it ?
[22:14] <Kernel_n00b> Hmmm....
[22:15] <Kernel_n00b> I think I'm back to the same question :-(
[22:16] <Kernel_n00b> getinfo() is using RDTSC
[22:16] <Kernel_n00b> as in my question....
[22:16] <Kernel_n00b> the problem is that I still neeed to measure the HDD Access time, and deduce it from the PageFault time.
[22:27] <Kernel_n00b> Anyone ?
[22:40] <Kernel_n00b> Someone ?
=== Kernel_n00b is now known as Kernel_n00b__
[22:41] <Kernel_n00b__> ?
[22:42] <jjohansen> Kernel_n00b__: all of the timing sources have problems, so its a pick your poison type of thing.
[22:44] <Kernel_n00b__> I was hopping someone could tell me which function should I measure (in order to deduce the HDD overhead)
[22:44] <Kernel_n00b__> I know that timing is a tricky issue. it is always tricky if you're running an multitask OS
[22:44] <jjohansen> Kernel_n00b__: I haven't played in the vm code lately so it would require digging
[22:45] <jjohansen> Kernel_n00b__: how do plan on accounting for everything else that can happen while your process is waiting for its page fault
[22:47] <jjohansen> Kernel_n00b__: just because you start a page fault doesn't mean its the only io going on, and there could be other interrupts, cpu use etc
[22:48] <Kernel_n00b__> I plan to kill all process that I don't need (including network).
=== MT- is now known as probuntu
[22:49] <Kernel_n00b__> I though of installing a RAM-drive and swap to it. this is how I can measure the HDD access VS memory access (which is much faster)
[22:49] <jjohansen> Kernel_n00b__: measuring at swap_readpage (I haven't looked) will probably work for a rough value as long as you get a good sampling get rid of the outliers 
[22:50] <Kernel_n00b__> I think I'll used RDTSC to measure timing. I need uSec accuracy
[22:50] <jjohansen> Kernel_n00b__: I would go ask on kernelnewbies and see if anyone more familure with current vm is hanging out
[22:51] <jjohansen> Kernel_n00b__: make sure to set it so the processor doesn't do any speed changes, or C state changes then, as those will affect your RDTSC
[22:53] <Kernel_n00b__> I'll also use CPUID in order to ensure no "Out-Of_Order" execution on the measuring section :-)
=== probuntu is now known as MT-