[07:16] <smb> morning
[07:21] <apw> moin
[09:16] <apw> ogasawara, there is something slightly odd going on on precise master-next.  we seem to have both the disable of ite-cir and what appears to be the fix for it.  noticed cause the config one causes a module loss abi failure (which i've fixed and pushed over), but it likely needs review
[09:18] <ogasawara> apw: oops, indeed the config disablement shouldn't be in there
[09:19] <apw> ogasawara, ok well rather than making the push part true when this build finishes i'll let you drop it :)
[09:19] <apw> ogasawara, and what the heck are you doing awake
[09:20] <ogasawara> apw: ack, I'll push over the top and get it fixed up
[09:22] <smb> apw, ogasawara really should be in that padded cell called bed... not only in the mumble channel of that name... ;)
[09:22] <apw> smb, indeed ...
[09:23] <ogasawara> apw, smb: I was tending to kai and while sitting in the rocking chair I realized I forgot to mute mumble...
[09:23] <apw> ogasawara, luckily we tend to dump lurkers in the cell for their own protection
[09:23] <ogasawara> apw, smb: and so here I am :)
[09:24] <smb> Indeed we do or put protective gear over the virtual heads
[09:24] <ogasawara> apw: ok, fixed up master-next and pushed
[09:25]  * ogasawara checks her day-0 branch
[09:25] <apw> ogasawara, thanks ... saves me messing it up ...
[09:25] <apw> ogasawara, oh is that in the repo ?
[09:25] <orated> ppisati: There?
[09:26] <ogasawara> apw: only local, although I should push it now that you mention it
[09:26] <apw> yeah i'd say publish it indeed
[09:33] <ogasawara> apw: day-0 branch pushed.  basically everything on master-next sans v3.2.15 patches
[09:35] <apw> ogasawara, presumably we can just rebase the master-next on that and it'll reorder things
[09:35]  * apw gives it a go
[09:36] <ogasawara> apw: yep, that's what I'd assume
[09:37] <ogasawara> apw: we technically don't need the ABI bump, but I threw it on the day-0 just for fall back purposes
[09:37] <apw> ogasawara, right there _always_ should be an abi bump in the first upload, thats the law
[09:37] <ogasawara> apw: yep
[09:37] <ppisati> orated: yep
[09:38] <apw> ogasawara, ok that rebase just worked
[09:38] <apw> -linux (3.2.0-24.37) UNRELEASED; urgency=low
[09:38] <apw> +linux (3.2.0-23.37) UNRELEASED; urgency=low
[09:38] <apw> leaving that as diff between my new master-next and the origin, so that sounds about right
[09:39] <ogasawara> apw: cool
[09:39] <apw> ogasawara, i may as well push it up?
[09:39] <ogasawara> apw: yah, go ahead
[09:39] <ogasawara> apw: if we end up throwing anything else on day-0, we can just rebase master-next again and push over the top
[09:40] <apw> ogasawara, indeed and this is more accurate to the consumer ... pushed
[09:41]  * apw throws a build test on gomeisa for completeness
[09:42] <orated> ppisati: Hi, last time you suggested to try zcat $imgfile | sudo dd of=/dev/$sdX bs=64k if ubuntu/cacnonical images for beagleboard is not working. Why bs=64k?
[09:42] <ppisati> orated: because that's the usual sector size on sd card IIRC
[09:43] <orated> ppisati: I've seen some wiki suggesting bs=4m like - https://wiki.ubuntu.com/ARM/OmapNetbook 
[09:43] <ohsix> or a multiple of it, which is way faster than the default bs, 512
[09:43] <orated> ah-ok
[09:49] <orated> I still get blank screen on terminal. I have set the gtkterm port configuration BAUD RATE - 115200, DATA - 8 bit, PARITY- none, STOP - 1bit, FLOW CONTROL - none. I'm not sure what I'm missing.. 
[09:54] <ppisati> orated: do you see the bootloader?
[09:55] <orated> ppisati: Even for erasing the nand on the BB, I should be able to get something on gtkterm like uboot... It gives nothing
[09:55] <orated> uboot countdown*
[10:02] <ppisati> orated: if you erase the flash, then you need to reflash the bootloader before you get something
[10:02] <ppisati> orated: did you do that?
[10:03] <ppisati> orated: without a bootloader, the board is not initialized and thus ubuntu won't boot
[10:08] <orated> ppisati: Yes, I tried that. I followed http://code.google.com/p/beagleboard/wiki/BootingBeagleBoard and the hardware setup to perform Booting u-boot on NAND Flash  but there was nothing on gtkterm/screen like shown in the link for me to able to even start the process
[10:21] <ppisati> orated: uhm
[10:21] <ppisati> orated: let me see if i can dig up my beagle
[10:22] <orated> ppisati: Sorry, pinged out
[10:25] <ppisati> orated: i've a beagle c4 here, let me see if i can guide you
[10:26] <orated> Sure ...
[10:29] <orated> I noticed something different on new attempt now. Apart from having D5 PWR LED, D6,7,12 also glowed for a moment
[10:33] <ppisati> orated: so, did you fat32 format the sd card and put u-boot on it? 
[10:34] <orated> yep
[10:34] <ah-> wc
[10:37] <ppisati> orated: do you have the sd card mounted now?
[10:38] <orated> ppisati: I got D6,7 and 12 blinking continuously. Do you want me to remove it from BB now?
[10:39] <ppisati> orated: yes please, i want to see it's content
[10:40] <orated> sure
[10:41] <orated> ppisati: initrd.img  MLO  tools  u-boot.img  uEnv.txt  uImage  uInitrd  zImage -- contents of boot FAT
[10:41] <ppisati> orated: and it's the result of a cat $img blablabla, right?
[10:41] <ppisati> orated: which image did you try?
[10:43] <orated> ppisati: Sorry, that was another card. The output of ls in boot is - boot.scr  MLO  u-boot.bin  uImage  uInitrd and the image tried was - zcat ubuntu-11.10-preinstalled-desktop-armel+omap.img.gz | sudo dd of=/dev/mmcblk0 bs=64k
[10:43] <orated> command* 
[10:43] <ppisati> orated: ok, let me get that image so i can try it
[10:44] <orated> ppisati: Is there a way to test beagleboard to eliminate hardware issues?
[10:44] <ppisati> orated: there's a validation image somewhere
[10:45] <ppisati> orated: http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext
[10:45] <orated> ah, I tried http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnostics and http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
[10:56]  * apw wanders to get hiself shawn
[10:57]  * ppisati -> goes to pick a package, brb
[12:57] <pgraner> http://pastebin.ubuntu.com/938244/
[13:14] <pgraner> apw, http://paste.ubuntu.com/938259/
[13:27] <smb> apw, I guess it is somewhat clear that udisk triggered a blkid and that got stuck waiting on the bd_mutex. Just not so clear why it happened while a dd was running and whether it was the dd holding the mutex while writing...
[13:35] <apw> smb, indeed, clear that blkid is looking at the partition in lock step with the dd doing someting ... not sure why it would get stuck tho
[13:46] <smb> apw, Interestingly it were two blkid tasks getting into that problem and then got killed... And yes, bd_mutex should not be claimed by anything so long... Wonder whether something left it in a claimed state by accident...
[13:47] <apw> smb, or perhaps there is a mutex orering issue.  can we tell if they are on the same partitions?
[13:47] <smb> apw, Both seem to be for /dev/sdc
[13:48] <apw> hmmm.  odd indeed.  i wonder if it bounced
[13:48] <apw> like inserted, came out, reinserted perhaps triggered a scenario like your suspend one
[13:48] <apw> i wish udev kept a log always
[13:49] <smb> Yeah, well one other thing may be: dd starts and creates a new partition table, <something> looks at the disks and decides "oh lets run rereadpt on that"
[13:49] <apw> BAH this damn update has eaten my keyboard config and now i can't find the backslash key
[13:50] <smb> apw, ctrl-alt-ß won't help you there...
[13:50] <apw> smb, i though partition re-read was an ioctl, something you had to initate, i'd be supprised if we detected that
[13:50]  * apw doesn't have a 'shhhh' key...
[13:50] <smb> apw, its a ss key... ;)
[13:51] <smb> apw, yes, rereadpt it an ioctl... but then as we learned there is a lot of things running and looking at our devices behind our backs... :/
[13:52] <smb> usually it would be the other way round... rereatpt causes events which cause blkid to be called
[13:53] <apw> ahhh ... /me finds it .. on a US keyboard in UK mode with no actual |\ key .. there are backup | and \ keys on altgr-backtit and altgr--
[13:53]  * apw likely has to logout to fix this ... grrr
[13:54] <apw> smb, i even have a ß key it seems
[13:54] <apw> wild
[13:54] <smb> apw, Maybe you got a de keyboard now
[13:54] <smb> is your z at the right place?
[13:55] <apw> heh ... no its a UK layout .... just it has some extra altgr's for .eu things it seems
[13:55] <apw> ~~~~~
[13:55] <apw> ã
[13:55] <apw> ã
[13:55] <smb> apw, Aynway hm, dpending how quick pgraner was maybe the blkid's running are remainders of the initial detection which udev still was processing ...
[13:55] <apw> i even have a compose thingy ... how useless for me
[13:56] <apw> smb, two on the same device sounds wrong
[13:56] <smb> apw, They came after each other
[13:56] <smb> blkid (blocked) .... killed , next out (blocked) ... killed
[13:57] <smb> apw, Something else, now that we both got our acks, who is gonna commit first? :)
[13:57] <apw> smb, you can commit both if you like
[13:58] <smb> apw, all three you mean :)
[13:58] <apw> or i can commit both, thats the logical one
[13:58] <apw> ... you are clearly the one in the know ... i nominate you
[13:58]  * smb profoundly thanks apw
[14:40]  * ogasawara back in 20
[14:49] <apw> ppisati, when we make arm branches for Q we need to garbge collect the numbers back to -100
[14:49] <apw> ppisati, else we'll hit like 10000000 
[14:53] <ppisati> apw: version number overflow? :)
[14:54] <apw> ppisati, in a year or two :)
[14:56] <ppisati> -EVERSIONNUMTOOBIG
[14:59] <bjf> Quasimodo
[15:04] <cking> bjf, your Q namespace will run out soon
[15:33] <gema> ppisati: are you around, I have a pandaboard making lights at me that I am not sure how to interpret
[15:33] <gema> ppisati: what does it mean when led D1 does two quick flashes and then repeats ad infinitum the same thing
[15:35] <GrueMaster> gema: It means the system is running.  It is just the led_heartbeat driver.
[15:35] <gema> GrueMaster: but the system is not running, it is stuck on uncompressing the kernel
[15:36] <GrueMaster> Which image?
[15:36] <gema> desktop
[15:36] <GrueMaster> Do you have a monitor plugged in to the HDMI port?
[15:36] <gema> I have a monitor and the serial
[15:36] <gema> both working fine
[15:37] <GrueMaster> Has it worked with the panda on previous images?
[15:37] <gema> GrueMaster: last thing the serial said before dying was: Uncompressing Linux... done, booting the kernel.
[15:37] <gema> which is why I was asking ppisati :D
[15:37] <gema> GrueMaster: I have installed it yes
[15:38] <gema> it went through the install fine, it is on reboot that's stuck
[15:38] <GrueMaster> That is a very generic kernel message that all platforms spit out.  You could enable the serial console to see if there are kernel issues.
[15:39] <gema> well, that is (I thought) the serial console
[15:39] <GrueMaster> The process is on the wiki.
[15:39] <gema> the wiki doesn't document error situations
[15:39] <GrueMaster> The serial console is not enabled by default on the desktop images.  Never has been.
[15:39] <gema> and I believe I am on an error situation
[15:39] <gema> so what comes through by default on the desktop images through the serial?
[15:41] <GrueMaster> U-boot messages.
[15:41] <gema> that makes sense
[15:41] <gema> how do I enable the serial console then?
[15:41] <gema> whenever I manage, to boot, I guess
[15:41] <GrueMaster> You can strip the u-boot header from the boot.scr and edit it.  Then use mkimage to put it back.
[15:42] <GrueMaster> I am looking through the wiki.  The instructions seem to have been buried.
[15:42] <gema> I am only looking at instructions linked from the iso tracker
[15:43] <GrueMaster> They were on wiki.ubuntu.com/ARM/<somewhere>
[15:43] <gema> now I 've got a disco, both lights are jumping up and down
[15:43] <GrueMaster> But I haven't updated them in months.
[15:43] <gema> GrueMaster: ack
[15:46] <GrueMaster> Well, since I can't seem to find the wiki, I'll just start typing.
[15:46] <GrueMaster> First, on your desktop with SD inserted and first partition mounted, type "dd bs=72 skip=1 <SD>/boot.scr boot.script".
[15:46] <GrueMaster> Then add "console=ttyO2,115200,n8 console=tty0" to the boot cmdline.
[15:46] <gema> GrueMaster: found it somewhere else: They are just programmable LEDs, named STATUS1 and STATUS2. By default, the kernel assigns trigger 'heartbeat' to the STATUS1 LED and trigger 'mmc0' to the STATUS2. This means that STATUS1 will blink twice per second, and STATUS2 will indicate activity on the SD card
[15:47] <GrueMaster> Yes.  That is correct.
[15:47] <GrueMaster> I thought you were having boot issues though?
[15:47] <gema> I am
[15:47] <gema> but the lights are not really helpful
[15:47] <gema> :D
[15:48] <GrueMaster> Do you want the rest of my instructions on adding serial console output?
[15:48] <gema> GrueMaster: I'd like them better on a wiki
[15:48] <gema> cos here I will lose them
[15:49] <gema> GrueMaster: sorry I am multitasking a bit
[15:50] <GrueMaster> Well, I had them on a wiki for a long time.  Someone else either deleted them or moved them.  I don't currently have the time or motivation to re-edit the wiki.
[15:51] <gema> GrueMaster: no worries, I will find them if they've been there, thanks
[16:33] <GrueMaster> gema: https://wiki.ubuntu.com/ARM/EditBootscr
[16:34] <gema> GrueMaster: thanks
[16:35] <GrueMaster> btw:  Desktop is running fine here.  Now booting today's image.
[17:32]  * cking runs a bunch of updates and then puts his server into deep soak test for the weekend..
[17:37] <jsalisbury> Anyone else having an issue getting into tangerine?
[17:38] <ogasawara> apw: just fyi, I'm beginning to add stub blueprints and wiki page specs -> https://wiki.ubuntu.com/KernelTeam/Specs
[17:38] <ogasawara> apw: I figure we can fill in the actual content next week-ish
[17:39] <ogasawara> jsalisbury: same here (for both tangerine and gomeisa)
[17:39] <apw> ogasawara, sounds good to me
[17:39] <jsalisbury> ogasawara, thanks for confirming.  I'll open a RT ticket
[17:40] <apw> ogasawara, fyi all gomeisa and tangerine are mia right now
[17:40] <apw> jsalisbury, ahh yes, i am talking to them now on #is
[17:40] <apw> jsalisbury, there is some cabling going on or something and we should not be affected but are
[17:40] <jsalisbury> apw, ahh, ok.
[17:51]  * cking --> EOD
[17:55] <ogasawara> jsalisbury: for the scripts which were running on cranberry, did you guys just temporarily disable your cron jobs?
[18:03] <aboSamoor> Hi, can someone help me with this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986321?
[18:03] <ubot2> Launchpad bug 986321 in linux "READ/Write FPDMA QUEUED failures" [Undecided,Incomplete]
[18:05] <herton> jjohansen, hi, there is some lucid tracking bugs awaiting for security-signoff, I think they are on the way to be checked?
[18:05] <apw> aboSamoor, i think we'd need at least a dmesg from teh system to have any idea what we are looking at
[18:08] <aboSamoor> apw: does the logs have the dmesg. I generated the logs using ubuntu-bug
[18:08] <aantoon> hi, will 12.04 alternate support ssd+trim+luks out of the box or do I have to do some tweaking
[18:13] <jjohansen> herton: okay, give me a bit I have been revising the scripts so, I am behind on the security-signoff
[18:13] <aantoon> knock knock
[18:33] <aantoon> I would love an answer 
[18:42]  * ogasawara lunch
[18:47] <aantoon> hi, will 12.04 alternate support ssd+trim+luks out of the box or do I have to do some tweaking
[18:51] <bjf> aantoon, have you tried a daily-live image ?
[18:52] <bjf> aantoon: i believe that it should have that support but if you want to know for sure you need to test
[18:54] <aantoon> last test (ubuntu 11.10) i lost my partition table and could not recover using testdisk so i lost all my data
[18:56] <jsalisbury> ogasawara, no, the scripts are still running, the reports just are not accurate.
[19:07] <aboSamoor> jsalisbury: I updated bug 986321 with apport-collect
[19:07] <ubot2> Launchpad bug 986321 in linux "READ/Write FPDMA QUEUED failures" [Medium,Confirmed] https://launchpad.net/bugs/986321
[19:07] <jsalisbury> aboSamoor, thanks.  I'll take a look.
[19:35] <aantoon> I have a new computer that has an Intel SSD. I have some questions about using Ubuntu with an SSD that I hope ubuntu developers can answer for me. I've researched online but do not know how best to proceed as there seems to be differing advice. I see it mentioned online that I should mount with DISCARD. But an article from OpenSUSE says DISCARD is not good to use. 
[19:35] <aantoon> http://opensuse.14.n6.nabble.com/SSD-detection-when-creating-first-time-fstab-td3313048.html
[19:35] <aantoon> Here are my questions
[19:35] <aantoon> 1.) are there any issues I should be aware of if using ubuntu on an SSD? Is ubuntu primarily intended to be used on HDD and not recommended for SSD?
[19:36] <aantoon> 2.) do you recommend TRIM be used for SSD with ubuntu?
[19:36] <aantoon> 3.) If you do recommend TRIM be used, how should TRIM be setup? Automatic wiping, or manual wiping? FITRIM, FSTRIM, or DISCARD?
[19:36] <aantoon> I really don't understand any of this in depth, so I'm very thankful for any direction/guidance you can provide
[19:37] <aantoon> i copyed this from archives/ubuntu-devel-discuss and it is the same questions i have
[19:38] <aantoon> the mail was not answered so i thought i'll ask it here
[20:33] <aboSamoor> jsalisbury: do you have an idea what does the flags NCQ and pcie_aspm mean?
[20:34] <jsalisbury> aboSamoor, pcie_aspm has is replated to power management.  Here's a good blog about it:
[20:35] <jsalisbury> aboSamoor, http://smackerelofopinion.blogspot.com/2011/03/making-sense-of-pcie-aspm.html
[20:35] <jsalisbury> aboSamoor, NCQ is "Native Command Queuing"
[20:36] <jsalisbury> aboSamoor, your running a server correct?  If so, changing pcie_aspm may not help.
[20:37] <aboSamoor> jsalisbury: I am running ubuntu server 12.04
[20:37] <aboSamoor> jsalisbury: this bug report, mentions two solutions https://bugzilla.kernel.org/show_bug.cgi?id=32682
[20:38] <ubot2> bugzilla.kernel.org bug 32682 in Serial ATA "libata freeze randomly hangs disk I/O" [High,New]
[20:38] <aboSamoor> jsalisbury: it seems that NCQ has something to do with the problem. testing more to confirm that
[20:38] <jsalisbury> aboSamoor, thanks for the info and update.
[20:39] <jsalisbury> aboSamoor, I saw a discussion on LKML on an issue similar to this.  I'll post a link in the bug.
[20:42] <aboSamoor> jsalisbury: echo 1 > /sys/block/sdX/device/queue_depth helps with small loads as copying hundreds of MiBs but not with large copying
[20:45] <jsalisbury> aboSamoor, Does changing the queue_depth reduce the number of errors or help improve performance?
[20:45] <aboSamoor> jsalisbury: it reduces the number of errors I see in syslog
[20:46] <jsalisbury> aboSamoor, Hmm, that may be due to less I/O actually being performed
[20:46] <aboSamoor> looking at the queue depts in my ~30 hard disks, I find half of them with the value 31 and others with the value 1!
[20:50] <jsalisbury> aboSamoor, Would it be possible for you to test some earlier kernels to see if this bug is a regression, or if it always existed?
[20:58] <aboSamoor> jsalisbury: point me to the kernels that you want me to test
[20:59] <jsalisbury> aboSamoor, sure thing.  I'll post links in the bug 
[21:03] <aboSamoor> jsalisbury: do I have to do anything other than adding that line to the file http://ubuntuforums.org/showpost.php?p=9684933&postcount=12 ? how can I test that it took effect?
[21:04] <jsalisbury> aboSamoor, You need to run sudo update-grub and reboot as well
[21:04] <jsalisbury> aboSamoor, You can then look at /proc/cmdline after rebooting to see if it took effect