=== jjohansen is now known as jj-afk
[06:29] <eugenesan> Hi all, I am experiencing data loss on USB storage devices while entering S3, can qemu/kgdb help here?
[06:37] <jj-afk> eugenesan: what kid of data loss?,  What fs is on the usb storage, did you sync and unmount before suspend, ...
[06:39] <eugenesan> jj-afk: Looks like data not committed to filesyste, ext4 loose journal, for example
[06:40] <eugenesan> jj-afk: I am talking about root filesystem on USB
[06:41] <jj-afk> Ah Bug #706795
[06:41] <ubot2> Launchpad bug 706795 in linux "[All releases] Suspending with rootfs on USB, causes silent corruptions, kernel panic on mount attempt, data loss and leaving system unbootable." [Undecided,Confirmed] https://launchpad.net/bugs/706795
[06:41] <eugenesan> Indeed, this is the bug
[06:42] <jj-afk> so it is possible that using a vm to test on will help
[06:43] <jj-afk> it will depend some what on where the bug is and how good the vm's usb emulation/pass through is
[06:43] <jj-afk> it certainly can't hurt to try replicating it on a vm
[06:44] <eugenesan> jj-afk: yes, I'll just wanted to check if someone already have tried.
[06:44] <jj-afk> however, I will note that suspend/resume with an external dev mounted generally causes the fs to be unmounted
[06:45] <jj-afk> and treated as if they are ejected and then reinserted
[06:45] <jj-afk> unplugged/plugged ..
[06:46] <jj-afk> it might help if you set USB persist
[06:46] <eugenesan> Well with rootfs this different. No mount/umount events. I suspect USB-host get's reset/sleep too soon, before data got actually written
[06:47] <jj-afk> yes, and this can be device specific
[06:47] <jj-afk> it will depend on the devices driver and the device firmware, ...
[06:48] <eugenesan> do you mean USB dongle specific or specific for USB-MassStorage in general?
[06:48] <jj-afk> both really, or the interplay between them
[06:50] <eugenesan> actually bug is persistent on variety of USB hosts and USB dongle, and correct for all Linux versions and flavors.
[06:50] <jj-afk> basically a bug in the device, the device firmware, the computers firmware, the usb mass storage layer, or even the fs could do it
[06:50] <jj-afk> correct for all Linux versions and flavors?
[06:50] <eugenesan> yes
[06:51] <jj-afk> so the variety of devices would point to the machine or the OS
[06:51] <eugenesan> I think this case is just not treated in code, since with SATA it's almost same data path but working.
[06:51] <jj-afk> by all linux versions do you mean all other versions?
[06:52] <eugenesan> I mean, issue reconstruct easily on every HW and any Linux version, and I tried many...
[06:53] <jj-afk> eugenesan: ah okay thanks for clarifying
[06:54] <jj-afk> so yeah that would point to something in the usb code not handling this correctly
[06:54] <jj-afk> have you tried with other filesystems
[06:55] <eugenesan> I even suspect, in past, there were similar reports regarding SD and SATA...
[06:55] <eugenesan> Yes, they all affected
[06:56] <jj-afk> eugenesan: okay, well I know I have run some linux devices with the root OS on an sd card that could successfully suspend resume.
[06:56] <jj-afk> I will take a shot at replicating
[06:56] <jj-afk> but yes I have heard of root on SD cards being corrupted by suspend/resume before
[06:57]  * jj-afk is going to finish reading your bug now
=== smb` is now known as smb
[10:10] <TeTeT> following up on yesterdays query on the video switch key upon lid open on a Thinkpad, I know built a kernel where I've commented out all KEY_SWITCHVIDEOMODE in acpi/video.c, but the event is still generated. The customer tells me that there is no such event generated when a RHEL4 desktop is installed on the T61
[10:11] <TeTeT> I grepped for KEY_SWITCHVIDEOMODE in the source tree,  but didn't find anything that looks like it would be used
[10:18] <TeTeT> strangely with sudo input-events 5 I know get a KEY_UNKNOWN (0xf0) pressed and released, instead of 0xe3 as yesterday
=== yofel_ is now known as yofel
[11:43] <amitk> cking: something for your bedtime hacking: https://lwn.net/Articles/429812/ :)
[11:44] <cking> amitk, sounds all too familiar
[11:44] <cking> I downloaded the image yesterday, but got sidetracked
[11:45] <amitk> * Run Intel's power management reference code to override your BIOS's configuration.  This includes writing the ACPI tables for P-states and C-states, replacing those normally provided by your BIOS.
[11:45] <amitk> wow ^^
[11:45] <cking> funny how that seems to admit that ACPI has failed to deliver
[11:59] <TeTeT> found it, I commented the acpi_bus_generate_proc_event(...) call as well, then there is no longer a keypress event generated, even not an unknown one
=== amitk is now known as amitk-afk
[13:22] <herton> apw, just a heads up, the guy which reported that race with framebuffer tested the patch, https://lkml.org/lkml/2011/2/24/442
[13:22] <herton> should be good to go to repost it
[14:33] <smb> herton, apw is not around today (only by luck)
[14:38] <herton> smb, thanks for informing, I'll check with him again later then
[14:39] <smb> herton, He took the day off today. Later would need to be Monday
[14:41] <herton> hmm, then perhaps I should CC him again on lkml, he wasn't kept on all messages on the thread, as its his patch he will need to repost
[14:41] <smb> herton, Keeping him on cc definitely is good
[14:42] <herton> I added him on CC on my replies to the thread, but some of the replies were not on the messages he was on CC I think
[14:44] <smb> Yeah, I am not sure he will keep track of the thread when not on cc. He gets enough mail to loose track even for the ones written directly to him
=== amitk-afk is now known as amitk
=== herton is now known as herton_lunch
[16:16] <JFo> <-lunch and errands bbiab
=== amitk is now known as amitk-afk
[16:41] <hggdh> JFo: bug 725089 <- SRU testing
[16:41] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[16:44] <smb> hm, trying to do something with tsc...
=== _LibertyZero is now known as LibertyZero
[16:45] <smb> hggdh, Is that the first try with ec2 from regression testing or was there a previous run that was ok?
[16:47] <hggdh> smb: to my knowledge -- which is quite fragmented -- the first. i386 passes, BTW
[16:49] <smb> hggdh, Ok, thanks
[17:07] <bjf> smb, what's the right way to bump the abi in dapper, it doesn't seem to be the same rules as later kernels (just changing the abi in the changelog)
[17:07] <smb> bjf, There is a bumpabi target that you run
[17:08] <bjf> smb, AH!
[17:09] <smb> bjf, And also be careful that Dapper (as Hardy) needs the control files and stuff stored in git with the update
=== herton_lunch is now known as herton
[17:29] <kees> bjf: if you're bumping dapper's abi, can you try to get it and the -meta package using the same ABI number? right now they're off by one.
[17:29] <bjf> kees, will try
[17:30] <kees> bjf: cool; thanks
[17:30] <kees> I'm not sure if the linux-source-2.6.15 package or the meta needs to be bumped twice.
[17:30] <kees> let me look
[17:30] <smb> kees, They use the same abi number. I guess what you want is the same upload number
[17:31] <kees> smb: no, they're not the same abi in the package name (yes, all the deps are correct, but it's goofy)
[17:31] <kees> linux-source-2.6.15 | 2.6.15-55.93
[17:31] <kees> linux-meta | 2.6.15.56
[17:31] <kees> note 55 vs 56
[17:31] <kees> bjf: so, linux-source-2.6.15 needs to go to -57 instead of -56, and then the meta can go to .57
[17:32] <kees> and then I can drop these special-cases for dapper I've got in the archive kernel ABI checker :)
[17:32] <smb> Oh, right. Well actually there is no abi number in the meta package
[17:32] <bjf> kees, ok, i just went to 56
[17:32] <smb> Just that abi number and upload number are close 
[17:33] <kees> smb: I don't know what you mean by "upload number"
[17:33] <kees> bjf: can you move linux-source-2.6.15 to 57?
[17:33] <bjf> kees, will attempt to do so
[17:33] <smb> kees, For the meta package 2.6.15.56  the 56 is the uplload number
[17:33] <bjf> kees, :-)
[17:33] <kees> smb: heh, okay, well, for every other kernel package, upload number == ABI number.
[17:34] <smb> kees, For the linux kernel package 2.6.15-56.93 the 56 is the abi number and the 93 is the upload number
[17:34] <kees> bjf: cool; thanks
[17:34] <kees> smb: uhmm...
[17:34] <smb> kees, It probably serves just the mental sanity
[17:34] <kees> linux | 2.6.35-25.44
[17:34] <kees> linux-meta | 2.6.35.25.32
[17:34] <kees> that's maverick
[17:34] <smb> Usually we only need a new meta package when the abi bumps
[17:34] <kees> the meta's upload number is .32 not .25. .25 is the Abi
[17:35] <smb> but it could also be for a different reason
[17:35] <kees> smb: the problem, I guess, was that dapper lacked an ABI number
[17:35] <kees> smb: so I guess I'm hoping to align dapper's upload number with the ABI, since for all the other releases, there is both ABI and upload number in the meta version
[17:36] <smb> kees, I am rather hoping to be in June soon and not to have to care about Dapper any longer. :)
[17:36] <smb> Otherwise, yes we probably added a meta number to avoid further confusion later
[17:37] <kees> smb: yes! I'm going to throw a party for dapper eol
[17:37]  * smb wished he could be there to join. :)
=== herton is now known as herton_away
=== sforshee is now known as sforshee-lunch
=== Quintasan_ is now known as Quintasan
=== sforshee-lunch is now known as sforshee
[18:59] <bjf> smb, are you looking at bug #725089 ?
[18:59] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[19:00] <bjf> ogasawara, hi :-)
[19:02] <jjohansen> ogasawara: hey
[19:02] <jjohansen> bjf: I started looking at that yesterday
[19:03] <bjf> jjohansen, ah
[19:04] <jjohansen> bjf: there is also a lucid issue that is different, hrmm not sure what its bug number is
[19:04] <bjf> jjohansen, it's still unassigned and no additional comments so wasn't sure
[19:04] <jjohansen> bjf: ah, yeah I actually got the info before the bug was opened
[19:04] <jjohansen> I'll assign it to my self
[19:05]  * ogasawara waves
[19:05] <bjf> ogasawara, o/
[19:06] <bjf> jjohansen, the lucid issue is with lucid-ec2 ?
[19:06] <ogasawara> wtf, the kid starts crying right when I start typing
[19:06] <sconklin> ogasawara: o/
[19:06] <vanhoof> ogasawara: hi :D
[19:06] <sconklin> hahaha
[19:06] <vanhoof> ogasawara: its a sign 
[19:06] <jjohansen> bjf: yep, its a failure in the qrt mem mapping checks
[19:06] <bjf> ogasawara, are you traveling to uds ?
[19:07] <ogasawara> bjf: I think so, wayne and I were discussing it yesterday
[19:07] <jjohansen> bjf: hrmm just a sec, or was that on hardy
[19:07] <bjf> ogasawara, wayne was saying "no NO! pleeeeese don't go"
[19:07] <ogasawara> bjf: heh, a little :)
[19:09] <ogasawara> bjf: we figured kai will be about 5mo at the time and a little more settled and better able to survive a week without me
[19:09] <jjohansen> ogasawara: you could always bring him :)
[19:09] <ogasawara> jjohansen: you guys would probably kill me on the flight over
[19:09] <bjf> ogasawara, ah you new parents and your little fantasies 
[19:10] <jjohansen> ogasawara: hehe not me, and think of the excellent excuse you would have to miss the config review
[19:10] <ogasawara> jjohansen: heh having a kid was all part of my giant scheme just to get out of the config review :)
[19:11] <ogasawara> bjf: I think I'm more worried about wayne surviving the week
[19:11] <jjohansen> bjf: so the memory thing is lucid not the hardy issue
[19:11] <jjohansen> ogasawara: hah, I knew it
[19:11] <bjf> ogasawara, hehe i can imagine
[19:12] <jjohansen> ogasawara: and well worth it :)
[19:14]  * ogasawara will drop back in later ..
=== herton_away is now known as herton
[20:17] <kees> smb: so "upload" number should be used instead "revision"? should https://wiki.ubuntu.com/Kernel/Dev/KernelPackageVersioning be updated?
[20:36] <bjf> jjohansen, just to be perfectly clear, there is a lucid issue that you know about ?
[20:37] <jjohansen> bjf: yes, though I am not sure whether it is a regression
[20:37] <bjf> jjohansen, do you have a bug # ?
[20:37] <jjohansen> let me check if hggdh opened a bug for it
[20:41] <jjohansen> bjf: I don't see one, I'll coordinate with hggdh and make sure there is one, and get the information attached and then let you know what it is
[20:41] <bjf> jjohansen, thanks
[20:44] <hggdh> I did open a bug, jjohansen 
[20:44] <hggdh> jjohansen: bug 725089
[20:44] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[20:44] <jjohansen> hggdh: I figured you probably did but my lp foo is weak
[20:44] <jjohansen> bjf: ^
[20:44] <jjohansen> hggdh: thanks
[20:45] <jjohansen> err wait
[20:45] <hggdh> oops
[20:45] <jjohansen> hggdh: not that one
[20:45] <jjohansen> hggdh: the failed qrt memory test on lucid
[20:45] <hggdh> jjohansen: yeah, sorry. No, no bug yet, I will open one
[21:16] <lamont> is umask visible under proc/$pid??
[21:34] <sforshee> lamont, not that I can find
[21:35] <lamont> yeah - I resorted to gdb
[21:55] <hggdh> jjohansen: you are talking about http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/lucid-2.6.32-313.25-ec2/m1.small-i386/qrt-kernel-security.txt
[21:55] <hggdh> right?
[21:56] <jjohansen> hggdh: yep, thanks
[21:56] <jjohansen> bjf ^
[21:56] <hggdh> jjohansen: so you want a bug on that?
[21:57] <jjohansen> hggdh: yeah, that is doesn't pass the mem test is disturbing and I'll look into it
[21:57] <hggdh> jjohansen: opening one now. It will be manually opened (no apport collection)
[21:58] <jjohansen> hggdh: thats okay, and thanks
=== herton_ is now known as herton
[22:21] <cnd> kamal, thanks for the endorsement :)
[22:22] <kamal> cnd: my pleasure :)
[22:41] <JFo> k, I'm starving. See you guys Monday :)
=== sconklin is now known as sconklin-gone