[00:34] <dandel_> hmm... i found a bug with the ext3 subsystem used for the virtual partition install of ubuntu 9.04 :/ (when using kernel 2.6.32-rc7)
[00:35] <dtchen_> reported upstream?
[00:35] <dandel> somewhat.
[00:35] <dandel> i'm trying to reopen a bug that got closed ><;
[00:35] <dandel> i haft to figure out how to over ethernet send the debug ><; (the crash happens upon resume)
[00:36] <dandel> 2.6.28 (which is used in 9.04 by default does not display this bug, but the system still crashes shortly afterwards)
[00:37]  * dandel checks 2.6.32-rc6 for bug.
[00:39] <dandel> that also displays the bug (go figure)
[00:42] <dtchen_> and rc8?
[00:42] <dtchen_> rc7*
[00:42] <dandel> i'm testing 2.6.31 ><;
[00:43] <dandel> 2.6.31 also does the crash on resume 0o
[00:45] <dandel> i know it's some sort of module change... the crash does not occur when i suspend with testing via s2ram on init=/bin/bash
[00:51] <dandel> it'd be excellent if i could get the kernel dmesg stuff to go to my tower (the laptop lacks serial ports tho)
[00:55] <maco> is one of your USB ports a debug port?
[00:55] <dandel> no clue.
[00:56] <dandel> however, the kernel did not panic, so the log is scrollable (although it is a little short)
[00:57] <dandel> how can i make the usb port a debug port?
[00:58] <maco> http://www.coreboot.org/EHCI_Debug_Port
[01:00] <dandel> Yes, the usb does support debug 0o'
[01:01] <maco> this time, im bookmarking that link. i had to search through last december's chatlogs to find it :P
[01:02] <dandel> so how do i run the device as a debug port then?
[01:02] <dandel> (Keep in mind that i have 2 EHCI controllers, and both of them support debug)
[01:08]  * dandel makes note that both the laptop and tower have debug port capability on the usb.
[01:09] <maco> ive never done it myself. the $83 pricetag on that hardware was a bit steep for me
[01:09] <dandel> ><;
[01:09] <dandel> any idea on how to get the debug to go over ethernet?
[01:11] <maco> spose you could ssh in before it breaks...
[01:11] <dandel> can't
[01:11] <maco> right....suspend/resume
[01:11] <maco> i wasnt thinking
[01:33] <dandel> hmm... my only option now is to start gutting module trees with the modprobe blacklisting.
[02:39] <dandel> ok... got the crash down to about 15 modules which i can't unload.
[03:41] <hagabaka> why doesn't the kernel ppa work as a repository now?
[12:08] <asabil> hi all
[14:28] <teabag> hello all, I am getting this error during the makefile process
[14:28] <teabag> http://paste.ubuntu.com/319311/
[14:28] <teabag> can anyone plz tell me what is wrong and how to fix it ?
[14:39] <teabag> ah nevermind
[14:39] <teabag> go it
[20:36] <_Narc_> Hello, Kernel Wizards. I got a little something to ask you. I had/I'm having/ a hard time figuring out if a bug is coming form the kernel or from something else. It's network related, especially to the r8169 module... Anyone I could explain to ? Thanks
[21:41] <dtchen_> _Narc_: please don't ask to ask.
[21:41] <dtchen_> _Narc_: and, it's better if you have a bug report reference.
[22:27] <_Narc_> dtchen_: Sorry. The problem is I don't have a bug report yet because I waited to have an advise here to submit it under the right package.
[22:28] <BenC> _Narc_: you can file a bug report against just ubuntu and specify the package later
[22:29] <BenC> _Narc_: since you know it is in ubuntu, you know you will have to file a bug report anyway, so best to do it from the start and narrow down the exact package after it's been triaged a bit
[22:30] <_Narc_> BenC: Good idea, I didn't think about that. I came here to ask because someone on ubuntu-bugs told me it was weird and to ask to someone who knows the kernel better. But I'll do that, thanks.
[22:30] <BenC> _Narc_: you can still explain here if you can provide enough detail
[22:35] <_Narc_> BenC: Yes, I even have too much of them. Too make a long story short, it's been months that I experience network hangs/ deconnexions when the network was under heavy load, using bittorrent (Miro) for example. I tested with a different router, changed nothing. Then I looked in syslog and found this : http://paste.ubuntu.com/318620/ . 
[22:37] <BenC> _Narc_: not so sure that's a bug at all...
[22:38] <BenC> _Narc_: if anything, it is kernel, but just saying that the driver may be acting as expected
[22:38] <_Narc_> With different people on ubuntu-bugs, we thought it was a r8169 issue. But now I discovered that changing the default port in Miro stops it. So, I need your help determining if it's Miro who's talking nonsense to the kernel or the kernel who can't handle it.
[22:38] <_Narc_> Oh really
[22:38] <_Narc_> Two people on ubuntu-bugs told me it was an Oops
[22:38] <BenC> it's not an oops at all
[22:38] <_Narc_> Oh
[22:38] <BenC> it's a WARN_ON() in the driver
[22:39] <BenC> oops == crash, WARN_ON() == driver got something unexpected from the hardware and tried to handle it
[22:39] <BenC> likely in this case, that means resetting the device
[22:39] <_Narc_> Ok, it means it's just telling that something is wrong, but acting as expected ?
[22:39] <_Narc_> Ok
[22:40] <BenC> that's an initial guess
[22:40] <_Narc_> It's really something already :)
[22:40] <_Narc_> Do you know if the SYN flood messages just at the beginning could trigger this ?
[22:40] <_Narc_> Or is it unrelated 
[22:41] <_Narc_> Because I had a lot of them. 
[22:41] <BenC> I believe it is directly related
[22:42] <BenC> need to find out why the kernel thinks it is getting syn-flooded
[22:43] <_Narc_> Oh. That's interesting, because that's what I thought, and I unabled the syn flood cookies, and it still hanged. But changing Miro's default port from 8500 to 51413 solves it. So, I wondered why one and not the other...
[22:46] <_Narc_> I say Miro specifically because it's the only app who's doing this. On this port. And the syslog message I showed you does not appear at each network hang. 
[22:47] <_Narc_> So, hardware, kernel, miro... I'm not good enough to figure out. Ask me if you need any other info.
[22:48] <BenC> _Narc_: do not disable syn cookies, that causes more problems
[22:48] <BenC> _Narc_: quite possible you need to lower some limits in Miro so that it doesn't cause flooding on your connecting
[22:52] <_Narc_> Yes, that's what I did. But the strange thing is that I only get the syn warnings when miro's port range are 8500-8600. So, it's not a kernel issue you say, because it's acting brave and try to handle miro's/my hardware crappy packets, right ? 
[23:00] <BenC> _Narc_: I believe so
[23:02] <_Narc_> Ok, thank you very much then. I'm starting to understand this more. It's probably a Miro bug then. Because my hardware is not exotic.