=== bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net]  has joined #ubuntu-kernel
[01:23] <bluefoxicy> Hi
[01:23] <bluefoxicy> this may be a stupid question
[01:24] <bluefoxicy> but should running mplayer on a half-corrupted wmv file cause it to stop, complain it died
[01:24] <bluefoxicy> and then if you hit "OK" so it exits OR kill -9 it
[01:24] <bluefoxicy> the kernel decides it's time to have a fit and hard-lock?
[01:24] <bluefoxicy> (i.e. apparently mplayer caused kernel memory corruption)
[01:33] <crimsun> that shouldn't be possible
[01:36] <bluefoxicy> crimsun:  ok, I think the ubuntu amd64 kernels in dapper need some nice looking at then.  Are you guys using any weird patches?
[01:37] <crimsun> heh, what do you call "weird?"
[01:37] <bluefoxicy> or anything aside from drivers that's experimental?
[01:37] <bluefoxicy> crimsun:  well, if it does something to the kernel's source tree, it's weird.
[01:38] <crimsun> well by that classification, everything that's patched is done by something weird, which is some non-negligible amount of source
[01:38] <bluefoxicy> there's a specific reason why the linux mainline kernel is what it is.  Additional drivers are pop in and out; but modifications to the VM system, initialization routines, VFS subsystem, CPU schedulers, or the like that aren't backported bugfixes are DISTINCTLY odd
[01:39] <bluefoxicy> crimsun:  if it's a bug in something you added, I can't go to the LKML and report it; otherwise I can just bounce it at them
[01:40] <crimsun> the kernel isn't precisely the first place I'd look for an oops caused by mplayer
[01:40] <bluefoxicy> If I bring them something and say "Oh there's some odd patches in ubuntu's kernel like the hard-deadline-scheduler and the memory-split-merge-mapper and ingo molnar's realtime patches" they'll go "THEN DON'T ASK US!"  :(
[01:40] <crimsun> do you have ksymoops output?
[01:40] <bluefoxicy> crimsun:  it's not an oops.
[01:41] <crimsun> how are you ascertaining it's not an oops if you get a hard lock?
[01:41] <bluefoxicy> mplayer sits there fine; then when I send kill -9 at it, the box drops straight off network, the mouse stops working, sound stops playing, hard disk stops, the screen stays as is, keyboard won't work. . .
[01:41] <bluefoxicy> crimsun:  because an oops is a condition where the kernel says, "Oops," and keeps on going.
[01:41] <bluefoxicy> The most kernel-aware activity this could be is a panic
[01:42] <bluefoxicy> which is where the kernel says "HOLY SHIT" and stops
[01:42] <crimsun> that doesn't mean you don't have an oops and then a panic
[01:42] <crimsun> in any case, can you reliably reproduce it?
[01:42] <bluefoxicy> well, I guess I could cause one and see
[01:42] <bluefoxicy> but I'm a little shakey
[01:42] <bluefoxicy> every 2 or 3 hard-locks, gnome's settings reset.
[01:43] <bluefoxicy> applet configurations go, background goes, xchat-gnome settings reset, gnome-terminal settings reset, startup programs reset, rhythmbox settings reset. .
[01:43] <crimsun> the first thing I'd do is try with an ia32 kernel
[01:43] <bluefoxicy> anything stored in the ~/.* directories for the apps stays there
=== bluefoxicy doesn't have IA32 ubuntu installed
[01:44] <bluefoxicy> I had IA32 dapper installed, it was stable
[01:44] <crimsun> which kernel with ia32?
[01:44] <bluefoxicy> the x86-64 kernels are being a real pain
[01:44] <bluefoxicy> I had i686 up to 2.6.15-14
[01:44] <bluefoxicy> then i installed a 64-bit base.
[01:45] <crimsun> so do flight 2 amd64 or flight 3 amd64 have this issue?
[01:45] <bluefoxicy> no idea.
[01:45] <bluefoxicy> oh
=== bluefoxicy facepalm
[01:46] <bluefoxicy> I most likely know where the problem is anyway
[01:47] <bluefoxicy> I keep forgetting, I'm using the via driver in xorg
[01:47] <bluefoxicy> and it seems to be really bitchy
[01:47] <bluefoxicy> but I don't see how that could be linked to killing mplayer. . .
[01:47] <bluefoxicy> Feb 23 14:30:05 localhost kernel: [ 8564.581410]  RIP: 0010:[_end+134114922/2132357120]  <ffffffff88453e6a>{:via:via_mmFreeMem+10}
[01:48] <bluefoxicy> This is where every single oops I've had has happened.
[01:48] <bluefoxicy> like ever
[01:48] <bluefoxicy> so I'm assuming there's a bigger bug around there that's causing a panic or hard-lock
[01:49] <bluefoxicy> crimsun:  I can't make the logical link between "killall -9 gmplayer" and "Hard lock," but that's a starting point.  There's no logs of kernel panics (for a specific reason-- the kernel halts immediately)
[01:50] <bluefoxicy> for now I'm getting off the via driver.
=== bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net]  has joined #ubuntu-kernel
[01:53] <bluefoxicy> ok my test data to reproduce it is gone now damn.
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== j_ack [n=nico@p508D938E.dip0.t-ipconnect.de]  has joined #ubuntu-kernel
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== crimsun [n=crimsun@pdpc/supporter/silver/crimsun]  has joined #ubuntu-kernel
[10:54] <mjg59> infinity: It's supposed to - we should probably work out what's up (swsusp)
=== CataEnry [n=cataenry@host92-11.pool8261.interbusiness.it]  has joined #ubuntu-kernel
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== jane_ [n=JaneW@dsl-146-161-84.telkomadsl.co.za]  has joined #ubuntu-kernel
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
[12:26] <infinity> mjg59: Well, check recent threads on ubuntu-users.  Several users claim that adding RAM to their machine breaks swsusp (and removing it again to drop below 1GB fixes it)
=== smurf [n=smurf@run.smurf.noris.de]  has joined #ubuntu-kernel
=== doko [n=doko@dslb-084-059-116-248.pools.arcor-ip.net]  has joined #ubuntu-kernel
[03:49] <makx> there swap might be to small
[04:46] <bluefoxicy> swsusp could be better designed though
[04:47] <bluefoxicy> halt programs, flush disk buffers (so file system is consistent), check how much swap is free vs how much memory is used
[04:48] <bluefoxicy> if there's not enough swap, see if there's enough space on / for the rest, if yes then create a swsusp file there and make note of it in the swap partition
[04:48] <bluefoxicy> flush to swap, flush remaining to the new inode on /, flush disk buffers, and halt
[04:48] <bluefoxicy> when coming back up, look for something that claims there's an inode holding a swsusp file.  If there's one there, load that entirely into RAM and unlink the inode
[04:49] <bluefoxicy> a little less lazy, but it would be possible.
[04:49] <bluefoxicy> but that's out of scope.
[04:49] <bluefoxicy> makx is probably right, they probably get like a gig and a half of application memory used and have a gig of swap.
[04:53] <bluefoxicy> SHIT.  I can't run apt.
[04:53] <bluefoxicy> gotta reboot I guess.
[05:16] <mjg59> infinity: Hnngh.
=== desrt [n=desrt@dhcp-0-20-af-d2-7c-3.cpe.mountaincable.net]  has joined #ubuntu-kernel
=== bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net]  has joined #ubuntu-kernel
[09:48] <bluefoxicy> I can say with 95% certainty at this point that the bug was in the via dri code in the kernel.
[09:48] <bluefoxicy> if I stay up for another day, I'll promote that to 99%
[09:49] <bluefoxicy> I've had no oopses since boot and no crashes
=== ispiked [n=ispiked@unaffiliated/ispiked]  has joined #ubuntu-kernel
[10:19] <desrt> oh where oh where is benc
=== netzmeister [n=netzmeis@p549FA3B8.dip0.t-ipconnect.de]  has joined #ubuntu-kernel
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== desrt tackles BenC 
=== BenC doges and runs for the touchdown
=== crimsun [n=crimsun@pdpc/supporter/silver/crimsun]  has joined #ubuntu-kernel