[01:11] <smoser> for anyone who cares... (jjohansen, sconklin-gone, kees )... a short history of hardy on ec2 (as I understand it.. I wasn't really around for it)
[01:12] <smoser>  * ubuntu started getting onto EC2 after hardy was released, or at least late in its cycle, and things were thrown together
[01:13] <smoser>  * the ppa as utilized for a couple reasons, probably, some I'm not aware of, but the primary reason was so that you could include "ec2-modules", a virtual package that that ppa kernel build provided.
[01:13] <smoser>   That package did not contain a /boot/vmlinuz , as ec2 didn't use one anyway (kernel and ramdisk loaded outside the image)
[01:13] <smoser>   It was an optimization, that really turned out to be a pain
[01:14] <smoser>  * image builds pulled from that ppa with 'ec2-modules', and publishing the kernels (aki/ari) was a manual process... its a pain
[01:15] <jjohansen> smoser: yeah, that lines up with what I know, caveat /me wasn't around for it either
[01:15] <smoser>  * we're now moving to using the linux-xen from the archive proper.  This makes the process identical to what we have for karmic, and very similar to what we have for lucid and onward, and its really much easier to maintain.  We're moving here, but we want to be careful and not regress anything.
[01:16] <jjohansen> yep, and thanks again for doing the work on building the image
[01:16] <smoser>  our daily builds are now pulling from the archive proper. we'll hopefully be able to refresh images with this new process.
[06:08] <stoja> kernel 2.6.38 is compatible with Maverick ? I've got problems with fgrlx drivers :)
[07:50] <htorque_> hello everyone! bug 721389 - there's a patch applied upstream, should i remove any tags from the bug report?
[07:50] <ubot2> Launchpad bug 721389 in linux "Boot time regression 2.6.38" [Undecided,Fix committed] https://launchpad.net/bugs/721389
[08:58] <apw> htorque, god work finding the fix ...looking at bug
[08:59] <htorque> apw, heh, no credit to me - i only compiled and tested like mad
[09:03] <apw> its more than most do, it is more common to get repeated "why have you not fixed this bug yet" calls
[09:04] <apw> and you get your name in the kernel history for your trouble :)
[09:18] <apw> bug 634487
[09:18] <ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
[09:21] <apw> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[09:45] <lamont> so... how come when I rebooted this morning, I lost wireless to my broadcom 4727?
[09:46]  * smb looks for signs of solar winds
[09:46] <lamont> wireless is kinda important to my sprinting
[09:46] <smb> It would help us poor souls to narrow this to a certain release
[09:47] <apw> lamont, on what release of what
[09:47] <lamont> well... I tend to stay up-to-date on packages.  was clean on friday, and had working wireless
[09:47] <apw> and don't tell me you updated when on the sprint
[09:47] <apw> that is very very very stupid :)
[09:48] <smb> n/me stays up to date on lucid
[09:48] <lamont> y'all have done such a good job of not breaking me, that I forgot to not trust you
[09:48] <apw> heh ... so what updated last night?
[09:48] <lamont> well... I don't know that I rebooted at all this week
[09:48] <lamont> reboots I'm not so good at doing that often when living on my laptop
[09:48]  * apw is assuming this is dapper you are running
[09:48] <lamont> maverikc
[09:49] <apw> hmmm, not expecting issues with maverick
[09:49] <lamont> neither was I
[09:49] <smb> IS that broadcom usually using wl driver?
[09:49] <smb> (so maybe dkms package compilation broke)
[09:50] <lamont> I believe it is
[09:50] <lamont> yeah - we get wl.ko
[09:50] <smb> Is that loadable or complaining about symbols?
[09:50] <apw> so do you have a wireless interface ?
[09:50] <apw> yeah is it loaded, what does modprobe wl.ko say
[09:51] <apw> the last kernel update in -updates was 3 weeks ago .. there is a -proposed from 14 hours ago thought
[09:51] <apw> do you have -proposed enabled ?
[09:52] <apw> or ... what does cat /proc/version_signature say
[09:52] <lamont> http://paste.ubuntu.com/571617/ <-- grep -e ' installed' -e purge /var/log/dpkg.log
[09:52] <lamont> no proposed
[09:53] <lamont> cat /proc/version_signature 
[09:53] <lamont> Ubuntu 2.6.35-25.44-generic 2.6.35.10
[09:54] <apw> so you have not had a new kenel over the period
[09:54] <lamont> http://paste.ubuntu.com/571620/ <-- iwconfig eth1
[09:54] <smb> apw, but it seems a new wl dkms package
[09:54] <apw> so its there as far as the kernel is there
[09:55] <lamont> installing the backports-modules thing was an attempt that simply removed the interface completely
[09:55] <lamont> smb: I reinstalled bcmwl-* in a first attempt
[09:55] <apw> it has not changes since release
[09:55] <lamont> it didn't help that I was wired in the room last night
[09:55] <apw> so ... i'd say that nothing has changed
[09:55] <smb> Ah ok
[09:56] <smb> And the interface is actually there
[09:56] <apw> so whats the symptoms
[09:56]  * lamont ponders where the kill switch could be
[09:56] <smb> just not associated
[09:56] <apw> whats the machine
[09:56] <lamont> inspiron 15R (N5010)
[09:56] <apw> they sometimes have them near the hinge on the side
[09:57] <apw> a little slidey bit of unmarked plastic
[09:57] <apw> i didn't know my dell had one for a year till i knocked it :)
[09:58] <lamont> old-dell had one, this one seems to not have the slidy bit
[09:58] <lamont> though the f2 key does have a antenna transmitting thing going on there
[09:58] <apw> does rfill list list it
[09:58] <lamont> rfill?
[09:58] <apw> worth hitting it, it may be bios controlled
[09:59] <apw> rfkill list
[09:59] <lamont> 0: dell-wifi: Wireless LAN
[09:59] <lamont> 	Soft blocked: yes
[09:59] <lamont> 	Hard blocked: yes
[09:59] <apw> ok so thats blocked in HW as far as kernel is concerned
[09:59] <apw> hit the key and re-run
[09:59] <apw> apw@agent57:~$ rfkill list
[09:59] <apw> 0: brcmwl-0: Wireless LAN
[09:59] <apw> 	Soft blocked: no
[09:59] <apw> 	Hard blocked: no
[09:59] <lamont> 0: dell-wifi: Wireless LAN
[09:59] <lamont> 	Soft blocked: no
[09:59] <lamont> 	Hard blocked: no
[10:00] <apw> smb, interesting, natty level we get info from the wl driver direct
[10:00] <apw> now wait a bit and see if it assoc's
[10:00] <apw> i fine wl takes up to minute to notice you have turned it back on
[10:00] <lamont> bah
[10:00] <lamont> thanks muchly
[10:00] <lamont> brb
[10:00] <apw> it is possilbe its persistant too
[10:00] <apw> recorded in nvram by bios
[10:01] <smb> apw, Yes, interesting. At least its not our fault this time. :)
[10:01] <apw> handy for next time
[11:21] <cooloney> apw: one quick question, if i wanna get the abi file of current kernel version, I can just build the kernel to get it
[11:21] <cooloney> apw: instead of run script getabis
[11:21] <apw> a build does generate the _new_ one yes
[11:22] <apw> so you would need to build the previous versio
[11:22] <apw> to get the abis for that version
[11:22] <cooloney> apw: great, man. thanks
[11:22] <cooloney> yeah, i think so
[12:29] <Kano> hi, why is natty not yet rebased to rc6?
[12:36] <apw> Kano, why do you think it is not
[12:37] <Kano> no tag
[12:37] <Kano> last is rc5
[12:38] <apw> what is the last tag you have
[12:38] <Kano> UBUNTU: v2.6.38-rc5 rebased fixes Bug #716811
[12:38] <ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,Fix released] https://launchpad.net/bugs/716811
[12:38] <Kano> seems to be the last rebased tag or not?
[12:38] <apw> Ubuntu-2.6.38-5.32
[12:38] <apw> is the last rebase tag
[12:39] <apw> the commit you refer to there is simply a changelog update to an old commit
[12:39] <apw> old release
[12:39] <Kano> ok
[12:39] <apw> you can simply tell from the Makefile though
[12:40] <Kano> could you tell me how to disable everything execpt generic+generic-pae builds for use with pbuilder?
[12:40] <apw> just change the flavours= list in the arch.mk
[12:40] <Kano> and the udebs i dont need?
[12:41] <Kano> also no libc-dev
[12:41] <apw> remove the entries in kernel-versions.in
[12:42] <apw> there is a do_ thingy for libc-dev to disable it
[12:42] <Kano> ah
[12:42] <Kano> because the interesting thing is,when i use prebuild kernels
[12:43] <Kano> then nvidia drivers usually work against it but fglrx always fails - on a squeeze system
[12:43] <apw> yes the binary drivers have not been updated, i don't expect either of them to work with natty kernels at the moment
[12:43] <Kano> no thats not the problem
[12:44] <Kano> they work with the pure rc6 kernels from mainline with ease
[12:44] <apw> well it is a problem, and one we don't care about
[12:44] <Kano> thats why i ask to build only the things which i need...
[12:45] <Kano> i did that some time ago but forgot it already
[12:45] <Kano> on hd install mainline kernels are fine
[12:45] <Kano> just missing aufs is bad for live mode
[12:46] <Kano> i first thought i do not need to rebuild em anymore because the hpa disable patch was removed but well, it did not work out that way...
[12:49] <Kano> did you ever try r8192e_pci?
[12:50] <apw> seems that the binary driver issues are the xorg changes and not kernel related
[12:50] <apw> at least for ubuntu
[12:50] <apw> nope
[12:50] <Kano> most likely
[12:51] <Kano> i hate that driver
[12:51] <Kano> it is not working at all, also the 2nd driver as addon does not work
[12:52] <apw> luckily its not one i own it seems
[12:52] <Kano> the only way to use wlan with my samsung n510 is to use ndiswrapper
[12:52] <Kano> also it seems that .38 needs a newer nouveau driver
[12:55] <TeTeT> on a thinkpad t-61 I see an acpi video event generated when the lid is opened. I guess this comes from the BIOS and I wonder if I can somehow disable it by consuming it in a kernel module before it gets sent to user space, especially gnome-settings-daemon. Any hints if that's possible at all?
[12:56] <Kano> the first thing you mentioned is in the debian.master/rules.d right?
[13:00] <apw> yes
[13:01] <apw> TeTeT, why would you want to suppress it ?
[13:01] <TeTeT> apw: a customer is not happy with the video toggling when opening the laptop lid with an external display attached. They want to remove that
[13:01] <apw> TeTeT, i am sure it is possible, though it would likely be easier to fix g-s-d to allow you to tell it to not do whatever it does when you get it
[13:02] <TeTeT> apw: problem is that g-s-d does not differentiate between the fn-f7 hotkey and the video event upon lid open
[13:02] <apw> they don't want it to enable the display
[13:02] <apw> how do they both appear in input-events ?
[13:03] <TeTeT> apw: they want to enable the display, but not the toggling between modes
[13:03] <apw> are they different there?  if they are on different input event channels you may be able to make them separate X keys
[13:03] <TeTeT> apw: don't know, I checked with acpi_listen, how to see it with input-events?
[13:04] <apw> ls-input will show you all the differnet channels
[13:04] <apw> often lid is a separate one, and you can see the event there
[13:05] <apw> /dev/input/event2
[13:05] <apw>    bustype : BUS_HOST
[13:05] <apw>    vendor  : 0x0
[13:05] <apw>    product : 0x5
[13:05] <apw>    version : 0
[13:05] <apw>    name    : "Lid Switch"
[13:05] <apw>    phys    : "PNP0C0D/button/input0"
[13:05] <apw>    bits ev : EV_SYN EV_SW
[13:05] <apw> on this machine here i have an entire chanell just for the lid
[13:05] <TeTeT> need to install input-utils via 3g first, one second
[13:08] <TeTeT> argh, protocol mismatch, as I'm testing the natty kernel on lucid right now, need to reboot
[13:13] <apw> TeTeT, heh yeah, i know, it is compatible so a rebuild is sufficient
[13:15] <TeTeT> apw: finally rebooted, I see /dev/input/event0 for Lid Switch, EV_SYN, EV_SW and /dev/input/event5 for Video Bus, EV_SYN, EV_KEY
[13:16] <Kano> apw: is that full_build var true for pbuilder?
[13:18] <apw> Kano, yes
[13:19] <Kano> then i should patch that too
[13:19] <apw> TeTeT, so you need to  input-events 0 etc which will show you what comes out of there for each
[13:19] <apw> hit the lid switch see what it does, then hit the other key and see whic channel that comes out of and what it looks like
[13:19] <apw> you may be able to map the lid one to something else
[13:21] <TeTeT> apw: the lid is fine, it's just the video toggle that needs to go. It reports EV_KEY KEY_SWITCHVIDEOMODE (0xe3) pressed and released
[13:21] <TeTeT> let's see what fn-f7 does report
[13:21] <TeTeT> nothing there
[13:22] <apw> it'll be on one of the other channels, likely the keyboard
[13:22] <TeTeT> apw: yes, it's on channel 7, ThinkPad Extra Buttons
[13:23] <apw> what do you get for that
[13:23] <TeTeT> the same, EV_KEY KEY_SWITCHVIDEOMODE (0xe3) pressed and released
[13:24] <Kano> what was the position to disable d-i?
[13:25] <Kano> kernel-versions.in`
[13:25] <apw> yes
[13:25] <apw> TeTeT, was there more than one line per button in either case ?
[13:26] <TeTeT> apw: yes, first a pressed event, then EV_SYN code=0 value=0, then the released event, then another EV_SYN code=0 value=0
[13:27] <TeTeT> apw: do you want me to pastebin the output?
[13:27] <apw> for both yes please TeTeT 
[13:27] <TeTeT> apw: ok, need to transfer it via USB
[13:32] <Kano> hmm when i do a debian/rules clean with kernel-wedge 2.73 u 1, then i get unintialized value builddep
[13:32] <TeTeT> apw: thinkpad key is http://pastebin.ubuntu.com/571717/ and video is http://pastebin.ubuntu.com/571719/
[13:44] <mjg59> TeTeT: You could hack the ACPI video module not to send that event
[13:44] <mjg59> On the grounds that you get the key event via the Thinkpad driver
[13:44] <mjg59> But that's about the limit of it
[13:46] <apw> it does seem that the lid should really produce a 'SW_LID' open close event and not that one
[13:46] <TeTeT> mjg59: I unloaded thinkpad_acpi and the event is still generated - you think that's evidence that it comes straight from the bios?
[13:47] <TeTeT> apw: the lid _also_ produces a EV_SW code=0 value=1 on /dev/input/event0 when closing
[13:48] <TeTeT> and code=0 value=0 when opening, followed by a EV_SYN each time
[13:48] <TeTeT> I wonder if that event is also generated on newer generation thinkpads
[13:48] <mjg59> TeTeT: Yes
[13:48] <mjg59> If it's coming via the video device it's a notification on the VGA device from te firmware
[13:49] <mjg59> apw: It's common to send a display siwtch notification on lid state change to force the OS to reprobe outputs
[13:49] <mjg59> Unnecessary in Linux, but common
[13:50] <TeTeT> how could g-s-d differentiate between the user wanted fn-f7 and this implicit toggle?
[13:50] <mjg59> It can't
[13:50] <TeTeT> it seems that for the lid close / open it would be best to just apply it's configuration for that setting
[13:50] <mjg59> Like I said, you can hack the ACPI video driver
[13:50] <TeTeT> probably not me ;)
[13:50] <mjg59> But no, there's no generic way to fix this
[13:52] <TeTeT> apw + mjg59 : thanks for your time, guess I'll have to tell the customer that there's no way out of this short of hiring a kernel developer to get it done
[13:52] <mjg59> TeTeT: Also, such a hack wouldn't go upstream
[13:52] <mjg59> It'd be a one line diff, though
[13:54] <TeTeT> mjg59: hmm, but where would I find that ACPI video driver when not in thinkpad_acpi?
[13:55] <TeTeT> gpu/drm/i915?
[13:56] <mjg59> drivers/acpi/video.c
[13:57] <mjg59> Just comment out every line that says keycode = KEY_SWITCHVIDEOMODE
[13:58] <mdz> apw, around?
[13:58] <apw> mdz, hi
[13:58] <mdz> apw, good day to you
[13:58] <mdz> I'm wondering if there is a straightforward way to tell, from userspace, if a given pid is actually a kernel thread
[13:58] <mdz> e.g. via something in /proc
[13:58] <apw> hmm
[13:59] <mdz> the only info I found so far was in top.c, which says:    /* if a process doesn't have a cmdline, we'll consider it a kernel thread
[13:59] <mdz>       -- since displayed tasks are given special treatment, we must too */
[14:00] <mdz> which seems less than rigorous
[14:00] <mdz> but maybe it's correct?
[14:01] <apw> not very satisfactory
[14:02] <mdz> FWIW I'm wondering in order to fix https://bugs.launchpad.net/ubuntu/+source/apport/+bug/504340
[14:02] <ubot2> Launchpad bug 504340 in apport "ubuntu-bug can't report bugs on kernel threads" [Wishlist,Triaged]
[14:02] <mdz> it would be pretty straightforward to fix given such a test
[14:07] <Kano> apw: i used this: http://kanotix.com/files/hellfire/ubuntu/ubuntu-kernel-build-only-generic.txt
[14:07] <Kano> apw: and i still got:  linux-source/doc/tools/tools-common packages
[14:07] <Kano> how to get rid of those
[14:08] <PhoenixSTF> apw, hey m8
[14:08] <apw> mdz its possible you could use the 'size' component of the /proc/$$/stat output, which seems to be 0 for such a thing
[14:08] <mjg59> mdz: exe won't point anywhere
[14:08] <Kano> i set source/doc to false, still there...
[14:09] <apw> mdz, sorry /statm
[14:10] <mdz> mjg59, since it's a root-owned process, I don't think I can even readlink(exe)
[14:10] <mdz> apw, hmm, that sounds fairly unlikely to generate a false positive
[14:11] <apw> mdz a quick sanity check here on a random latop on maverick seems to show size 0 only on things which i believe are kernel threads
[14:12] <mdz> apw, statm looks the same for a zombie process :-/
[14:16] <mjg59> mdz: Does a zombie have any vm entries in status?
[14:16] <apw> mdz how did you generate a Z so i can poke one
[14:16] <apw> yeah the whole of stat and statm on one would be good
[14:16] <mjg59> And status
[14:17] <mdz> http://paste.ubuntu.com/571741/ = stat, statm, status
[14:17] <apw> mdz i assume $3 of /proc/<zombie>/stat is a Z
[14:17] <mdz> apw, I happened to have one around
[14:18] <mjg59> What does ps use for putting [] around them?
[14:18] <apw> so you could elide those
[14:18] <mdz> forking something which exits and not wait()ing for it should create one
[14:18] <mdz> mjg59, that was the first place I looked but it makes my eyes bleed
[14:18] <mjg59> Pragmatically, check size in stat and check that it's not a zombie
[14:18] <mdz> and of course it puts [] around zombies too
[14:18] <mdz> but it also says <defunct> so it's checking for state=Z probably
[14:19] <mdz> mjg59, it appears there are no vm entries in status for a zombie
[14:20] <apw> mdz, but a safer test might be statm $1 == 0 and statm $3 != 'Z'
[14:20] <mdz> mjg59, but there aren't for kernel threads either
[14:21] <mdz> yeah, I think it's probably most practical to do statm == zeros && state!=Z
[14:22] <apw> mdz do you have stat and statm output for your Z, save me writing something to gen one
[14:22] <mdz> apw, the pastebin link I pasted earlier is that
[14:22]  * apw <-- blind
[14:22] <apw> got it now
[14:33] <apw> mdz, mjg59, ok in theory the $8 of stat is the process flags and converted to hex 200000 bit is PK_KTHREAD
[14:33] <apw> PF_KTHREAD even
[14:34] <mdz> apw, $8 == the eighth field counting from 1?
[14:34] <mdz> if so, that's -1 for the iwlagn thread
[14:34] <apw> yeah, the big big number
[14:35] <apw> ahh $9 sorry
[14:35] <apw> 9 (events/0) S 2 0 0 0 -1 2216722752 0 0 0 0 0 4894 0 0 20 0 1 0 32 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 18446744073709551615 0 0 17 0 0 0 0 0 0
[14:35] <apw> 2216722752
[14:35] <apw> 84208140
[14:35] <apw> 00200000
[14:35] <apw> so thats a kthread ... of course you are relying then on that number never changing, which is tricky
[14:36] <apw> but i guess for apport we might be ok there
[14:40] <mdz> apw, that seems to work reliably
[14:42] <mdz> apw, I don't suppose there's any way to find out which module owns that thread?
[14:42] <mdz> then I could put that hint into the bug report
[14:45] <apw> mdz not that i know of at the moment
[14:46] <apw> and now that damnable unity is crashing on login again ... ARRRG
[14:49]  * apw lunches
[14:55] <PhoenixSTF> apw, when you come back i got some questions about that thing yesterday :)
[15:01] <JFo> mdz, I updated that apport bug and fix released it.
[15:02] <mdz> JFo, cool, thanks
[15:05] <JFo> my pleasure :)
[15:19] <PhoenixSTF> hey guys i was here yesterday with issues on a vt6421 pci controler
[15:21] <PhoenixSTF> i got some new info, its givving issues no matter what hdd is on, and only outpust badCRC and Esmask error when using hi tranfers rates off the HDD
[15:21] <PhoenixSTF> *high transfers rates
[15:23] <PhoenixSTF> any fix for this specific issue for this pci board?
[15:38] <hallyn> apw: what is the kernel team stance on taking patches from -mm?  (user namespace patches are there now, would be sort of nice to have them in natty)
[15:43] <PhoenixSTF> back
[15:56] <PhoenixSTF> apw you there m8?
[15:57] <apw> s'up
[15:58] <PhoenixSTF> hey
[15:58] <PhoenixSTF> remenber yesterday i aked about a posssible fix for that card
[15:59] <PhoenixSTF> well i narrow it down, it bugs with whatever hard driver is pluged on it, but only when massive amounts of data is requested
[16:00] <PhoenixSTF> if it's like 2 to 10 Mb per sec its ok
[16:00] <PhoenixSTF> when it goes over 30 it start with Badcrc and Esmask error
[16:01] <PhoenixSTF> apw, any advice for me m8?
[16:03]  * smb thinks of a blender but that is not helpful
[16:05] <PhoenixSTF> smb, LOL yes well i got 2 choices, either put away 2 controler cards, and buy a new one, or beg for someone to please make fix
[16:05] <PhoenixSTF> smb, i am on the begging part now
[16:05] <PhoenixSTF> smb, altouth i will consider yours has a 3rd one!
[16:06] <PhoenixSTF> xD
[16:06] <smb> PhoenixSTF, To be honest the way you describe it. It sounds a bit like it actually could be really phisicallly broken. And there is not much any driver could do there.
[16:07] <joaopinto> PhoenixSTF, SATA2 or SATA3 ?
[16:08] <PhoenixSTF> os discos sao sata2, mas placa aceita 1,5
[16:08] <joaopinto> keep english please ;)
[16:08] <PhoenixSTF> sorry
[16:08] <PhoenixSTF> ;
[16:08] <joaopinto> PhoenixSTF, do you get something like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/285892 ?
[16:08] <ubot2> Launchpad bug 285892 in linux "ata1.00: exception Emask 0x0 SAct 0x807f SErr 0x0 action 0x6 frozen" [Unknown,Fix released]
[16:08] <PhoenixSTF> yes well its a VT6421 controler so its accepst only 1,5 tops
[16:09] <PhoenixSTF> the HDD are sata 2, samsung 1,5 tb and a Seagate 1tb
[16:09] <DBO> chase told me I could come here and ask if there is anything I can do to help my system stay responsive during IO (non IO bound apps, actually pretty much everything, stop responding during hard drive read/writes)
[16:09] <PhoenixSTF> ubot2, yes i have checked taht but still a lot of people complain about it only works for some
[16:09] <ubot2> PhoenixSTF: Error: I am only a bot, please don't think I'm intelligent :)
[16:10] <PhoenixSTF> oh crap ;)
[16:11] <joaopinto> PhoenixSTF, with my newer system I have replace the HD 3 consecutive times, the motherboard was replaced, in the end I had to use a different HD brand
[16:12] <PhoenixSTF> joaopinto, that was unlucky :S
[16:13] <PhoenixSTF> joaopinto, that was unlucky well i just got these  boards i got a 3rd one and its working fine, with the same COntroler vt6421
[16:13] <joaopinto> whatever was the issue somehow it was more severe with Linux, Windows was usable
[16:14] <joaopinto> and also more severe between an older Fedora kernel and a recent Ubuntu version
[16:14] <PhoenixSTF> so problem was the kernel,
[16:15] <PhoenixSTF> i recon it takes a lot of work on a kernel
[16:15] <PhoenixSTF> speacialy when new hardware comes out
[16:16] <joaopinto> I don't know, from the comments on both bug 285892, bug 285892, and bug 569680 I was unable to figure the cause
[16:16] <ubot2> Launchpad bug 285892 in linux "ata1.00: exception Emask 0x0 SAct 0x807f SErr 0x0 action 0x6 frozen" [Unknown,Fix released] https://launchpad.net/bugs/285892
[16:16] <ubot2> Launchpad bug 569680 in linux "Hard disk write/read freezes for 10 seconds several times in session" [Undecided,New] https://launchpad.net/bugs/569680
[16:17] <PhoenixSTF> yes the last one hapens to me
[16:17] <PhoenixSTF> same error output and some more stuff
[16:17] <PhoenixSTF> but thats about it
[16:20] <PhoenixSTF> but only hapens when to mutch data is requested
[16:23] <joaopinto> PhoenixSTF, does it happen at every boot ? Or do you have instances of long periods running without issues ?
[16:24] <PhoenixSTF> joaopinto, its a home server, so boath hdd are not the system, and the problem only hapens when i start to use the hdd at full transfer speed.
[16:25] <PhoenixSTF> joaopinto, if i am whatching a movie its ok, if i copy it it starts with the errors and freezing
[16:26] <PhoenixSTF> joaopinto, and sometimes i guess i have periods of no issue with one hdd, its hard to figure out... sorry
[16:27] <joaopinto> ok was just comparing with my case, which seemed to be initialization related, I could reboot and use the disk for several hours without errors, and perform the same activity after a power recycle and just getting freezes a few minutes after booting or during boot
[16:28] <joaopinto> it was disk activity related, but not persistent between recycles
[16:28] <PhoenixSTF> not the same thing.... it hapens whenever u use the hdd full speed
[16:28] <joaopinto> ok
[16:28] <PhoenixSTF> http://pastebin.com/c7AzfhQ1
[16:29] <PhoenixSTF> here is my log
[16:32] <hggdh> jj-afk: any news on the hardy ec2 kernel having a signature of -generic?
[16:53] <sforshee> apw, have you seen this thread on lkml: http://thread.gmane.org/gmane.linux.kernel/1103561/focus=1104637
[16:53] <sforshee> wondering if we have something we need to push upstream...
[16:54] <herton> sforshee, indeed, we carry a patch which fixes this issue
[16:56] <sforshee> hmm, wonder why we've been sitting on it then
[16:56] <herton> while I was working with Mandriva, I submitted a different patch here: https://bugzilla.kernel.org/show_bug.cgi?id=26232
[16:56] <ubot2> bugzilla.kernel.org bug 26232 in Console/Framebuffers "Multiple framebuffer oops and sysfs attribute deadlock" [Normal,New]
[16:57] <herton> didn't knew Ubuntu fixed it 6 months ago, these days I was looking and found apw already had fixed 6 months ago the issue
[16:57] <herton> I posted on lkml the same patch on bug report, but didn't got answers from what I remember
[16:58] <apw> herton, yeah its one of those patches which is hanging about and i really really need to push up
[16:58] <herton> Comparing the both solutions are ok, just I don't cared in my patch about mm_lock issue in do_mmap
[17:00] <hallyn> apw: how do ya'll usually feel about taking patches (into natty kernel) from -mm ?
[17:00] <apw> hallyn, depends what they are, i like things fixed
[17:01] <hallyn> apw: alas these are not bugfixes, but user namespace patches
[17:01] <hallyn> apw: there's probably no hurry on it.  It just came out of UDS that I would see about getting them into natty kernel, so I"m following up :)
[17:01] <apw> hallyn, and why would i want them
[17:01] <apw> well feature freeze was today 
[17:01] <hallyn> bc they allow root in a container to not be able to kill or ptrace tasks in other namespaces
[17:02] <apw> hallyn, it is pretty late to be changing semantics, so if you want them you will need to convince me they are worthy
[17:03] <hallyn> apw: thanks, i think i'll be more interested in getting them into o release.  (though hopefully they'll go into linus' tree pretty quickliy anyway)
[17:03] <JFo> bjf, still no joy getting those nominations approved.
[17:03] <hallyn> apw: given ff, i have no desire to seek exception...
[17:04] <hallyn> apw: thanks
[17:04] <apw> hallyn, well if they are security related it may make sense to persue them
[17:04] <apw> i normaly prefer them to be in mainline, even if its for .39
[17:06] <hallyn> apw: yup, we'll see how they fare.  thanks
[17:07] <apw> get them out for review, copy kees on them, i assume he is the protagonist
[17:07] <kees> hm?
[17:08] <kees> I am interested in hallyn's patches, but not in much position to drive them.
[17:09] <apw> kees i think the key is if you deem them a security consolidation then we can be more flexible taking them
[17:10] <apw> sforshee, would you email me the link to that thread so i don't forget to push out my patch pile pls
[17:10] <sforshee> apw, will do
[17:12] <PhoenixSTF> ok what is Ultradma mode?
[17:14] <herton> apw, do you mind if I reply to that thread, saying that you will push the patch? I want to point Linus to the bug report with the testcase too
[17:14] <apw> herton, sure, cc: me on the reply pls ... i am assuming you know my fix fixes this
[17:18] <kees> apw: I guess I'm trying to say that I don't have a strong opinion about those patches, but if hallyn wants to see them in, go for it. hallyn will you be able to support those patches if something needs additional tweaking going forward?
[17:21] <hallyn> yup, i'll be supporting (and continuing development) upstream anyway
[17:21] <JFo> <- lunch
[17:21] <hallyn> kees: apw: ^  however I'm happy waiting until I get a few more patches and getting the result into o
[17:24] <jjohansen> apw: I have a small one line fix for aufs, its just a bug fix so its no rush but if your holding off it might be nice to get it in
[17:24] <jjohansen> hggdh: I don't know why you are getting -generic need to look at it more
[17:25] <hggdh> jjohansen: thank you.
[17:27] <apw> jjohansen, nice ... get it to me, and i'll get it committed
[17:28] <jjohansen> apw: just opening the bug
[17:28] <jjohansen> but I already have the patch
[17:40] <PhoenixSTF> apw, how can i force the reading on hdd to be slower?
[17:40] <jjohansen> apw: sent
[18:16] <jjohansen> rebooting
[18:29] <bdmurray> bjf: I tried approving your nominations in bug 723945 but lp is timing out
[18:29] <ubot2> Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945
[18:29] <bjf> bdmurray, thanks, jfo has been having the same problem
[18:29] <JFo> yup, making me rabid
[18:30] <JFo> there is an LP bug open
[18:30] <bdmurray> I think if there were only 1 task it'd work out better
[18:30]  * JFo digs the # up
[18:30] <bdmurray> so create 1 task, approve nominations, open other tasks
[18:30] <JFo> bug 723999
[18:30] <ubot2> Launchpad bug 723999 in launchpad "structural subscriptions taking 4.8 seconds during nomination editing POST" [Critical,Triaged] https://launchpad.net/bugs/723999
[18:47] <bjf> bdmurray, it's being done via a script which is adding all the tasks
[18:49] <bdmurray> okay, I was just thinking that doing it in the other order might avoid the timeout
[18:50] <bjf> bdmurray, it could be that it is making the problem much worse
[18:54] <bdmurray> the email interface might be a way to workaround it
[20:37] <charlie-tca> vanhoof: hear you? as on my speakers? 
[20:37] <vanhoof> charlie-tca: on irc :)
[20:37] <vanhoof> having some timeouts connecting to another server
[20:37] <vanhoof> although things seem to be fine here
[20:37] <bjf> vanhoof, you quit again
[20:37] <charlie-tca> well then, I guess so
[20:42] <vanhoof> bjf: i give up
[20:43] <vanhoof> bjf: its anything across the pond for me
[20:43] <bjf> vanhoof, yes, i see you just got dropped again
[20:44] <blag> I have a patch that adds some functionality to the kernel.  Linus' (newest) branch of the 2.6.38 kernel already has a better way to do the same thing.  Should I upstream my patch to the Ubuntu kernel devs?
[20:45] <bjf> blag, we'll get it from the next .38 rc
[21:20] <jjohansen> bjf, sconklin: looks like we have some regressions in the lucid and maverick ec2 kernels, I am looking into it
[21:21] <bjf> jjohansen, thanks for the heads up
[21:21] <sconklin> thanks
[21:47]  * blag reads the channel topic (specifically that the Natty kernel is going to be a 2.6.38)
[21:47] <blag> bjf: cool.
[21:47] <blag> we should totally call the Natty kernel a ".38 special" just for grins  :-)
[22:06] <rsajdok> Are there other wiki page like this https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
[22:06] <rsajdok> that describe other kernel problems?
[22:08] <rsajdok> All right. I found https://wiki.ubuntu.com/Kernel/Debugging
[22:09] <Krunch> what kind of problem are you having?
[22:24] <rsajdok> Krunch: Personally I have not. I want to learn to write patches for various problems.
[22:27] <Krunch> to write patch you first need to figure out what is the problem, this is probably a good start: http://www.dedoimedo.com/computers/crash-book.html
[22:30] <rsajdok> Krunch: thank you:)