[00:57] <smp4488> im trying to get openbox to run on my beagleboard xm. When i start x the screen flickers but the logs are showing no protocol specified
[01:01] <smp4488> got it! needed to delete all the .Xauthority files in /~
[03:16] <jeramee> hi guys
[03:22] <persia> hey jeramee
[13:25] <mahmoh> ppisati: testing the latest 3.0.0-1~dd and seeing kjournald timeouts with IO tests, unsure if they're new or not
[13:49] <ppisati> mahmoh: how did you get it?
[13:50] <cmagina> ppisati: he said he was running io stress tests
[13:51] <cmagina> one thing i noticed were the usb resets found before the hung task warnings
[13:51] <ppisati> usb hardisk?
[13:51] <cmagina> i believe so
[13:56] <cmagina> ppisati: yeah, it has a usb disk enclosure plugged into an externally powered hub
[13:59] <ppisati> unfortuntaley it seems usb support is flaky
[13:59] <ppisati> and it has been like this for a while
[14:00] <ppisati> e.g. lp 709245
[14:00] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
[14:00] <ppisati> if you ping the board while doing I/O tests, performance improve
[14:01] <mahmoh> it's getting pinged now and still seeing the resets
[14:05] <ppisati> can you try with a natty kernel?
[14:07] <mahmoh> natty?  I guess, can you point me to a package?  I think GrueMaster confirmed yesterday that he saw it with natty and maverick, the usb ping problem
[14:07] <GrueMaster> ppisati: I have tested this with a natty image as well as a maverick image.
[14:08] <mahmoh> I think it makes more sense to crash or dump when the problem occurs so we can see what's actually happening, no?  cmagina?
[14:08] <GrueMaster> And apparently it has also been reproduced on a beagleXM.
[14:09] <GrueMaster> It is a problem with either the usb chip or the driver for it.  prpplague has more insight.
[14:10] <cmagina> mahmoh: doubt it, as the crash would occur ~2 minutes after the usb reset occurred and that is the probable culprit for the hang
[14:10] <mahmoh> could we lower the timeout and attempt the crash that way?
[14:11] <ppisati> imo the best thing we can do is a fill a new bug for it (how to reproduce it, logs, etcetc) so we can forward it to more people
[14:11] <ppisati> TI, usb ml, arm, more people can see it, etcetc
[14:11] <mahmoh> or throw USB into debug?  what's the best approach here?
[14:11] <ppisati> but yes, the usb support for all the omap chips so far always had problems
[14:13] <mahmoh> http://pastebin.ubuntu.com/649155/
[14:14] <ppisati> uhmmm
[14:14] <ppisati> updatedb.mlocat? at the same time with an IO test? i bet it's stuck! :)
[14:16] <mahmoh> what's updatedb.mlocat from?
[14:18] <ppisati> mahmoh: from your pastebin -> Started Run 1 @ 05:29:28[27121.715026] INFO: task updatedb.mlocat:7519 blocked for more than 120 seconds.
[14:22] <cmagina> heh, missed that
[14:25] <GrueMaster> Next time you guys run io tests, you should run "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" first.  That will disable the timeout errors (what you are seeing).
[14:25] <mahmoh> yep, but what is "updatedb.mlocat", part of the fs?
[14:27] <GrueMaster> It may have nothing to do with the test suite.  Notice you also have an error in that pastebin from java.
[14:27] <cmagina> no, updatedb.mlocate generates the index that the locate commands uses
[14:28] <cmagina> its a cron job
[14:28] <cmagina> you should disable it
[14:28] <GrueMaster> No, leave the background tasks alone.  Just run the echo command above.
[14:29] <mahmoh> it's part of the default system plus we're on a dual core board, it should be fine
[14:29] <cmagina> its not cpu bound, its io bound
[14:29] <GrueMaster> we're hitting generic kernel timeouts on panda.  We either disable them (as above) or we change the kernel config.  I suggest manually disabling them first.
[14:29] <mahmoh> as for the timeouts, those should not occur either, I want to see when they happen
[14:30] <cmagina> the hung task timeout is just notifying you of the problem
[14:30] <cmagina> of a problem
[14:30] <mahmoh> exactly
[14:30] <cmagina> this could be that the system is thrashing as well
[14:30] <GrueMaster> Find out what the default timeout is and try increasing it.
[14:30] <mahmoh> 120s
[14:30] <GrueMaster> So try doubling it and rerunning.
[14:32] <cmagina> i would leave it, its not the problem, what we need to know is if we are getting completely hung or if the system is just thrashing under the load and as a result some processes are not getting the time they need
[14:32] <mahmoh> I'm not tweaking the system at this point except to debug this problem
[14:32] <mahmoh> so how do we find that out?
[14:32] <cmagina> we could enable sar data gathering and see if we are seeing high io wait times
[14:32] <cmagina> not sure if there is an easier way
[14:33] <mahmoh> hm, it is running the threaded io tests after all, hm, and elevator=deadline
[14:33] <GrueMaster> Look at your logs and see exactly what test reproduces this, then rerun just that test with different timeout settings.
[14:38] <mahmoh> ppisati: so this is with the 300-1~dd kernel, but I'm pretty sure it'll happen with stock, should I switch back or push forward?  I'm going to try the same thing on two other boards
[14:39] <mahmoh> the problem is there's no schedule as to when this occurs but I may be able to force it running background IO tasks (like updatedb.mlocat)
[14:39] <GrueMaster> mahmoh: I think you are beating a dead horse.  We need to keep moving forward.
[14:39] <mahmoh> you may be right but if there's a fundamental problem that needs to be fixed then it should be looked at; I can dedicate one board for this and push on on the other ones
[14:40] <cmagina> mahmoh: 252 is currently hovering around 70% io_wait
[14:40] <GrueMaster> There is a fundamental problem, but we do not have the resources or time to dedicate everything to it.  Others outside ubuntu are also looking at it.
[14:41] <GrueMaster> One board is good.  3 is a bit much.
[14:41] <cmagina> and by adding updatedb, it hit ~90%
[15:05] <siji> persia, you there?
[15:30] <GrueMaster> mahmoh: In reply to server kernel question in #u-meeting, there probably won't be a server specific kernel.
[15:30] <mahmoh>  then install should add a scheduler line to boot, Daviey?
[15:31] <GrueMaster> I don't know what the differences are on x86, or if they have any affect on armel.  May be worth looking into after Alpha 3.
[15:31] <mahmoh> sounds like just a bug to me, where should it go if it's against the installer vs. kernel image?
[15:32] <GrueMaster> It can be added to the server preinstalled images fairly easily I would think.  Not sure about netinstall.
[15:33] <mahmoh> should be both
[15:33] <GrueMaster> We should run some benchmarks on it to see if it helps performance on armel.
[15:33] <Martyn> GrueMaster ; What are the major differences, if any, between the desktop and the server kernel for x86?
[15:33] <GrueMaster> I know it should be both, just not sure how to go about it with netinstall.
[15:34] <GrueMaster> Martyn: ENOIDEA.
[15:34] <Martyn> copy that
[15:34] <mahmoh> it should install server kernel when selecting Ubuntu Server
[15:34] <Martyn> I'll take a look at it right now
[15:34] <GrueMaster> Hence why I raised the question.
[15:34] <mahmoh> scheduler is diff.
[15:34] <ppisati> janimo: i couldn't fidn any marvin24 3.x kernel on gitorius
[15:34] <janimo> ppisati, I think he justs sends stuff to lkml or the tegra list, at least that was my impression
[15:34] <janimo> are you on #ac100 ?
[15:35] <janimo> I do not know of a 3.0 kernel of his, just saw him active upstream
[15:38] <ppisati> yep, i'm on ac100
[15:41] <mahmoh> GrueMaster: so where should an arm-server-kernel bug request go? and where should a net-install-server bug go?
[15:42] <GrueMaster> I have no idea.  This is the first server work i have done with Ubuntu.
[15:43] <mahmoh> it's not server related it's either kernel image related or installer related, where do those bugs live?
[15:43] <GrueMaster> In launchpad.  beyond that I don't know.
[15:44] <GrueMaster> File a bug on the kernel for tracking purposes.
[15:44] <GrueMaster> From there, a comparison should be made on x86, and the relevant bits tested on arm.
[17:05] <arcaico> Hello, I am using ubuntu linux on SDcard .. my root (/) filesystem is not the total size of the sdcard
[17:05] <arcaico> my (df -h) is http://pastebin.com/fw6zeG5D
[17:07] <GrueMaster> arcaico: What image is this ?
[17:11] <arcaico> Linux FriendlyARM 2.6.28.6-FriendlyARM #2 Sat Jun 26 13:24:08 CST 2010 armv6l GNU/Linux   --- by: http://www.friendlyarm.net/
[17:15] <GrueMaster> I have no idea what that is or where it comes from.  Not an Ubuntu linux for sure.
[17:16]  * GrueMaster doesn't even see any references to Ubuntu on their web page.
[17:17] <arcaico> GrueMaster, http://www.youtube.com/watch?v=mBN0BUWoxa0
[17:17] <arcaico> http://kanebebe.dip.jp/download/ARM11-6410-DVD/images/Ubuntu/
[17:18] <GrueMaster> Unfortunately, we dropped support for 9.10 at the beginning of this release cycle, and since 10.04 have only supported armv7.
[17:18] <GrueMaster> You might have better luck with debian arm.
[17:20] <arcaico> Ok GrueMaster, I will give a researched
[17:23] <GrueMaster> mahmoh: Have you been able to do preseeding with netinstall yet?
[17:23] <mahmoh> not yet, should work fine though
[17:24] <GrueMaster> Ok.  No worries, just curious.
[17:24]  * GrueMaster was getting ready to reinstall on one of the pandas in the pool.