[00:00] LLStarks: not sure on that, do you have some logs you can point to? [00:00] one sec. [00:00] LLStarks: just post them to a bug report for the time being, easier to track and share that way [00:01] btw, i'd use the mailing lists, but i'm terrible about being bureaucratic. [00:02] LLStarks: as long as you have evidence to support your opinion and not just ranting most people are understanding [00:11] * ogasawara bails for a few hours, back on later === bjf[afk] is now known as bjf === bjf is now known as bjf[afk] [02:05] hey guys, I'm triyng to get my evtouch touchscreen on my asus t91mt working; it looks like the hid-mosart module isn't "finding" the touchscreen. [02:06] I'm using the xorg-edgers/multitouch PPA, and I see the device in lsusb, but the kernel doesn't want to attach a driver to it. [02:09] warewolf: what's the usb vendor:device id in lsusb? [02:10] what they're supposed to be 0185 and 0486 (I may have those flipped, they're from memory) [02:10] lemme grab the eeepc, 1 sec [02:11] agh, it didn't resume correctly from suspend to ram [02:13] Bus 004 Device 002: ID 0486:0185 ASUS Computers, Inc. === jjohansen is now known as jjohanse-afk [02:14] looks good [02:15] this is under lucid btw [02:26] warewolf: what do you mean by 'doesn't want to attach a driver'? you're looking for the driver link in sysfs? [02:27] jk- there's no device in /dev/input, and xorg doesn't recognize it as an available input device. [02:27] jk- oh, and the mosart driver doesn't seem to get loaded, and when I do load it, I don't see any messages in the kernel saying that it loaded and found a device. [02:28] it doesn't look like it should print anything on module init / probe [02:29] hrm ok [02:29] could you remove the module, `ls /sys/class/input`, modprobe the module, and do the ls again? [02:29] how do I tell udev to reload the rules and reevaluate them to kick off actions? [02:29] j- same number of entries in there before and after loading the module. [03:55] could use a bit of help here, I found a bug with a few of the kernels from the mainline ppa... I asked where I should file the bug report and was directed to https://bugzilla.kernel.org... so, I filed my report: https://bugzilla.kernel.org/show_bug.cgi?id=16316... however the response says to file it with Ubuntu's bug tracker... [03:55] bugzilla.kernel.org bug 16316 in kvm "VM's started through libvirt can't write to disk image files unless the file is owned by root" [Normal,New] === bjf[afk] is now known as bjf === bjf is now known as bjf[afk] [07:47] cooloney: ping [08:45] morning ... [08:46] apw, Argh a ghost :) [08:46] -.- [08:46] huhu [08:46] apw, It is not Friday, therefor you cannot be here [08:47] it's apw re-incarnated [08:47] smb: its nearly friday. [08:47] smb, really? if you're sure [08:47] * smb panics mildly [08:47] 3h23 to go IIRC the eastmost tz correctly. [08:48] lifeless, Looking at it that way, the weekend is near [08:48] smb: absolutely! [08:49] smb: 27h23m [08:49] \o/ [08:50] * amitk sets the count-down timer [08:53] * apw whines about the disk io performance on his laptop [08:53] completely kills interactivity [08:53] apw has not yet found out about his sound problems [08:53] aren't you like a kernel guru? physician, heal thyself ? [08:53] wow 3 minutes from typing that to getting it in the window [08:54] _wow_ [08:54] i am sure its the new fsync orieiented dpkg extract [08:54] basically eats your machine [08:59] apw: Yup. Btrfs seems particularly ill-suited to fsync heavy workloads. [09:01] RAOF, Oh while you're around and I remember. Did you have a chance to ask some people to try the oversampling i2c patch for i915 [09:03] smb: I haven't yet, no. I just managed to rescue that mail from my spam filter today! [09:03] RAOF, Don't tell me you consider my lovely mails as spam. :-P [09:03] No, but bogofilter seemed to. [09:04] I've been rifling through the badly-encoded text and random phrase generator that is my spambox to rescue the ham. And hit bogofilter with it. [09:07] * smb wonders his mails are sometimes sounding like random phrases. Especially those written late or before the first coffee [09:08] :) [09:09] It also ate some perfectly well-behaved launchpad bugmail. I don't think it's got a trigger on EDID or anything like that :) [09:16] RAOF: horrible! [09:16] smb: there was once a new maintainer wikipage telling people like me how to effectively create a new kernel from git. Do you happen to know where this is? [09:17] Oh, I've got it. I just need to build away like a madman. [09:17] TeTeT, I think [09:21] TeTeT, Does this help https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter [09:23] smb: yes, that's it, fakeroot debian/rules binary-generic === Daviey_ is now known as Daviey [10:15] smb, where can I find your 32.x.y tree ? [10:16] http://git.kernel.org/?p=linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git;a=summary [10:16] apw, git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git [10:19] Daviey, Was it you that wanted to send a SRU patch to the kernel-team mailing list? [10:19] smb, yep! [10:20] Did that happen? Cannot remember but maybe missed it... [10:20] smb, I've been checking linus' tree to see if it was committed there [10:20] Ah ok, so still waiting on that [10:54] oh is today alpha-2 ? [10:55] maybe [10:55] or it was yesterday if its Friday today [10:55] its thursday luckily [10:59] FYI, regarding the pad block issue - the fixed kernel is on our i386 image and the amd64 should be apt-get dist-upgrade away. === smb is now known as smb-afk [11:35] Hi [11:36] I'm trying to recompile (without any customizations) linux-image-2.6.31-10-rt from lucid [11:37] In the past I could just run skipabi=true skipmodule=true fakeroot debian/rules binary-rt [11:37] Now it's asking me some configuration questions [11:37] sounds about right, what fails with that [11:37] I want to reproduce the exact configuration that ships with Lucid [11:38] so it shouldn't ask me any oldconfig-style questions [11:38] indeed if the source had any it would not build [11:39] sorry, "if the source had any" what? [11:39] if the source needed configuration option answered it would not build in the build system [11:39] Right, that's what I thought, it would not be batch-compilable [11:40] Is there another step I forgot, e.g. copying a config file somewhere? [11:40] shouldn't be no, normally a binary- does everything needed [11:40] where did you get the source [11:41] dget http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-rt/linux-rt_2.6.31-10.153.dsc [11:41] Then dpkg-source -x, cd to the directory and skipabi=true skipmodule=true fakeroot debian/rules binary-rt [11:42] As a regular user, not as root [11:42] That dsc link is from http://packages.ubuntu.com/lucid/linux-image-2.6.31-10-rt [11:43] yep [11:47] lpd79, ok try doing an 'fakeroot binary/rules applypatchset' then do the build [11:47] Thanks, lemme try that [11:48] * apw tries build without that [11:48] (with it a binary-rt worked for me without erroring) [11:48] yeah without it, errors on the config [11:48] not sure _how_ that gets done automatcially though [11:48] You mean debian/rules applypatchset... [11:49] i meant debian/rules apply-patchset [11:49] _ahh_ [11:49] fakeroot debian/rules clean [11:50] that applies the patches, which the build ssytem does first [11:50] so [11:50] fakeroot debian/rules clean [11:50] fakeroot debian/rules binary-rt [11:50] should do the trick [11:50] no actually its more subtle than that [11:50] so you would need to do [11:50] fakeroot debian/rules clean [11:51] fakeroot debian/rules apply-patchset binary-rt [11:51] You're looking at the rules code I presume [11:53] yep [11:54] OK, that seems to get rid of the oldconfig questions. [11:54] Thanks [11:55] It's surprising that something as straightforward as re-building the kernel package isn't really documented anywhere [11:56] I mean, without creating a new kernel flavour etc [11:57] lpd79, it is for the normal kernels, but this is the RT kernel which is community supported [11:58] smb would i expect to see ddebs for your -proposed kernels in lucid ? [12:00] Thanks a lot apw. Bye! [12:10] Hi, Was the Intel NIC issue fixed in Maverick? [12:11] the e1000 issue [12:11] i suspect 'the' issue is not specific enough, i know of a number in the past which have been fixed, whether the one you mean is fixed i am unsure without knowing more [12:15] apw, intel e1000 didn't work in Maverick.. I was only aware this was a single issue. I didn't realise there were multple ones. I assumed you would be familar with it, so didn't state a bug number as i don't have it to hand. [12:15] the only one i remeber there was pending a firmware update on the machine in question [12:17] Ah, bug 591707 [12:17] Launchpad bug 591707 in linux (Ubuntu Maverick) (and 1 other project) "After upgrade lucid -> maverick eth0 interface is gone (affects: 1) (dups: 1) (heat: 175)" [High,In progress] https://launchpad.net/bugs/591707 [12:17] Daviey, yeah thats the one ... still waiting on the reporter to test a bios upgrade as far as i can see [12:18] This issue broke just before A2.. Is the best solution really to ask end users to bios upgrade? [12:18] Seems like a lotta users will have no net access post upgrade. [12:19] Daviey, i don't believe we know what the underlying issue is, Intel themselves suggest the update so one assumes its a firmware issue being glossed over by the kernel somehow [12:19] but without the reporter doing the work we're a bit hosed, cirtainly i do no have the H/W affected [12:20] apw, I have canonical owned hardware with the issue infront of me. [12:20] i also believe that people who do have this h/w do no see the issue, so its not clear how far this issue penetrates [12:20] then you are in a position to try the update, do you have more than one ? [12:20] I can do the firmware upgrade to try and follow through.. but i'm wondering if it's "better" to leave it on this for future fix [12:20] depends if you have more than one [12:21] apw, Sorry, i only have the one box with this [12:21] i'd need to confirm with rtg, but i believe he has more than one which are not showing the issue [12:21] could you attach the lspci output for your machine showing the issue, and indicate it also shows the issue [12:22] apw, well for further info.. this ISN'T the e1000 - it's the 82566DC.. But it's my understading that it uses the e1000 kernel foo. [12:22] apw, i'll attach that now [12:23] well if you attach the output, we can confirm if its even supported by the same driver or not [12:23] on it [12:36] apw, bug updated.. If your team wants me to try upgrading the bios - can you let me know please :) [12:37] annoyingly, this bug is blocking me :( [12:37] tim has the point on that bug, so i'll try and remmber to tell him you have the h/w [12:38] Daviey, what does lsmod | grep 1000 say [12:38] one mo [12:38] * Daviey needs a KVM switch [12:38] e1000e 149486 0 [12:39] apw, ^ [12:39] Daviey, ta [12:40] Daviey, and thats in some other kernel yes? as i believe the failure mode is to not see the card at all [12:40] apw, no.. that is A2 amd64 server iso, clean install - no updates [12:42] if you have eth0 mentioned in your dmesg then i don't hink you have the same issue [12:42] when your network is not working [12:42] apw, Ok.. it seems it's a different issue then [12:43] I have tried two cables, PXE boot works, but i die as soon as linux comes into play. [12:43] apw, should i raise another bug? [12:43] whats in your dmesg related to ethX ? [12:43] apw, dmesg is attached === smb-afk is now known as smb [12:44] * smb is back [12:44] [ 2.642747] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:19:d1:5d:e3:0f [12:44] [ 2.642751] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection [12:44] [ 2.642770] e1000e 0000:00:19.0: eth0: MAC: 6, PHY: 6, PBA No: 1021ff-0ff [12:44] Daviey, does it appear in ifconfig ? [12:44] * Daviey does the monitor cable dance [12:45] apw, no, lo and a bridge [12:45] hrm, so perhaps it is the same, i'll have to get tim to look and confirm as i don't have enough context to know [12:46] apw, Okay, thanks for your help.. I'm sure tim will know he can hilight me when he comes about. [12:46] but i don't see ethX in the reporters .35 boots, so i think its different at least [12:48] apw, scrub that about ifconig - that's because i couldn't configure at DHCP time during d-i.. so it's not in /etc/network/interfaces... However, eth0 does show in /proc/net/dev [12:51] Daviey, ok thanks, does ifup eth0 do anything [12:51] * Daviey checks [12:52] Ignoring unknown interface eth0=eth0 [12:52] though i think its not seen the link [12:53] [ 18.731191] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [12:53] i don't see that in yours [12:53] worth looking to see what the lights are saying on the card and the other end of the cable if you have them [12:54] FWIW, the amber led is flashing 1 sec on, 1 sec off. I don't know if that means anything :) [12:54] switch lights = off [12:55] hrm, so perhaps a PHY recognision issue [12:55] i suspect getting your own bug filed is a good plan, get all we have discussed here in there [12:55] apw, ok.. will do that today [12:56] thanks apw [13:27] * apw lunches === fddfoo is now known as fdd [14:19] lag, git log HEAD..FETCH_HEAD === sconklin-gone is now known as sconklin [15:54] * apw bounces to take a kernel [16:02] * abogani waves [16:04] sconklin: kernel is installed and running, I should know shortly if the problem gets resolved [16:04] cool [16:05] sconklin: looks like part of the Canonical infastructre is down, can't get to mumble or iso.qa.ubuntu.com [16:06] pgraner: mumble appears to still be working for me [16:06] pgraner, you ought to quit logging some of the inbound IP traffic. its pretty noisy [16:06] pgraner, chinstrap seems to be ok [16:06] but a lot of other things not [16:06] tgardner: yea I'll fix that up once I get this other issue worked out [16:07] apw: around? or drowning in emails from vaca [16:07] smb: yea something is up [16:07] pgraner, well, its like obscuring oops in dmesg [16:07] ogasawara, both ... wassup ? [16:07] tgardner: yea, I know [16:08] apw: I'm actually away starting tomorrow, wanted to double check if you could stand in for me at the release meeting tomorrow (and next fri as well) [16:08] apw: I can email the bits to cut and paste tomorrow [16:08] ogasawara, sure no worries [16:08] is the agenda up yet? [16:08] apw: thanks. no agenda yet. [16:08] apw: I'll wait for them to send it and then get you the bits [16:09] ogasawara, As long as it involves just talking apw can stand in anytime. :-P [16:09] ogasawara, whatever works for you :) [16:09] * apw adds that to the 'why i bashed smb' list [16:09] heh [16:09] * smb knows it must be long :) [16:10] apw, And I could not resist to reply to that text message either. :) [16:10] smb, heh yeah, i deserved that :) [16:10] luckily for me you meet argentina next, whome we hate even more, so i can now support .de :) [16:11] though i suspect a fiver on spain is the sensible plan [16:11] Sounds reasonable. Its gonna get hard for sure === kamal-away is now known as kamal === bjf[afk] is now known as bjf [16:22] ogasawara, commit aabef8b240880439b91574c9a9e33dcc44bfd8c7 looks to fix the bnx2 compilation issues ... should be in -rc4 [16:23] apw: sweet [16:23] * ogasawara makes a note [16:24] apw: should -rc4 land next week, don't feel the need to rebase. I'll do it when I get back. [16:25] ogasawara, ok :) [16:25] ogasawara, will there be an upload post freeze before you go ? [16:25] apw: I did one last night, with the blessing of the release team. [16:26] ahh good stuff, so we'll not be so behind then [16:26] apw: so my plan today is to the start the next release and pull in Kees' yama patches [16:27] and let that bake in pre-proposed ? [16:27] apw: indeed, wanted to get it in and available for testing [16:27] sounds like a sound plan to me [16:28] ogasawara: I just canceled tomorrows release meeting FYI [16:28] pgraner: oh cool [16:28] apw: ^^ [16:28] pgraner, heh you were doing the meeting ? [16:28] haha [16:29] apw: no, I got a message from rick last last night asking me to do so since he and robbiew are on holiday [16:29] cking, about ??? commit b681f7d9ab4d697a214fa4428795790c3a937a89 (acpi change in linus tree) looks interesting for your sort of problems [16:29] apw: and its the day after A2 [16:29] I figured it'd be uneventful anyways following A2 [16:29] pgraner, most excellent [16:30] apw, sorry, I'm multitasking in a conf at the mo, lemme have a look [16:32] apw, more "windows compatability" getting into the code ;-) [16:33] cking, VILE isn't it, but sounds like something you might test when seeing 'oddness' with new biosen [16:33] apw, I think it's possible to do some semantic analysis on the AML to do things. mmm.. [16:35] cking, this one limits Sleep() in aml to 2s: 9cbfa18e8a7b34a32eddbd914a07f085962f50a8 [16:35] apw, yeah, I was just reading that one [16:37] 2a6b69765ad794389f2fc3e14a0afa1a995221c2 cking more windoze compatibility [16:38] love it, windows is saving the ACPI non-volatile state in suspend to ram :/ [16:39] apw, shoot, I thought it was only used for S4. Dammit [16:39] cking, thats what the spec says, not what windows assumes, you can imagine what bioses therefore do [16:40] Mad [16:41] that will slow down S3 marginally [16:41] as the symptoms are 'second suspend/resume failes' that sounded of interest to you [16:41] apw it's very interesting. Explains a lot [16:42] * cking adds it to the growing list of S3 weirdnesses [16:43] apw, thanks for alerting me to these changes [16:44] sadly that means my jerky mouse is not fixed :( [16:46] haven't you fixed that yet? [16:46] i hoped someone would while i was on holiday ... sadly no joy [16:50] apw: Jerky approximately once every 5 seconds? [16:51] mjg59, nope the whole time, well thats unfair for periods of minutes while my kslowd's slog it out eating my cpu [16:52] they are 'happy' at the moment so things are ok, soon enough they will change their mind and bash each other a bit more [16:53] apw: Intel graphics? [16:53] mjg59, yeah, looking to be a bug in the output polling support [16:53] Yeah, hotplug interrupt breakage [16:53] Dave Airlie found a couple of issues [16:53] someone recons they solved it by reverting fbf81762e385d3d45acad057b654d56972acf58c [16:54] though i cannot yet confirm that this was enough to fix it [16:54] mjg59, got any pointer to the discussion, its not on my kslowd thread [16:54] intel-gfx, I think [16:54] He only dug it up yesterday though, so it may not be posted yet [16:54] ahh ok thanks [16:55] normally when i just find i have time to find a bug, and get it nailed is when the patch comes down from upstream, so about on target [16:57] * apw wonders where dave hangs out [16:59] mjg59, if you are talking to him i have a solid reproduce on my system [16:59] He's on Brisbane time, so his working day starts literally as mine ends [17:05] mjg59, heh lovely location at least [17:26] hi, what git tree is ~kernel-ppa/mainline/daily built on? is it linux/kernel/git/torvalds/linux-2.6.git ? [17:26] also, is that what they call 'mainline'? [17:29] appelflap: yes and yes. [17:31] ogasawara: thanks. there's a bug with "Please don't close it until the problem is fixed in the mainline." and it's closed, while the patch isn't in mainline yet. so i guess it's reasonable to ask them to reopen the bug [17:32] appelflap: what's the bug#? sometimes it's reasonable to close the bug in ubuntu even if it exists in mainline still, for ex if it's against Intrepid which is EOL. [17:33] ogasawara: https://bugzilla.kernel.org/show_bug.cgi?id=16235 is the upstream bug, which has a wrong conclusion (for now) [17:33] bugzilla.kernel.org bug 16235 in network-wireless "[REGRESSION] [IWL3945] Broadcast is broken?" [Normal,Closed: code_fix] [17:33] https://bugs.launchpad.net/linux/+bug/591016 is the corresponding launchpad bug [17:33] Launchpad bug 591016 in linux (Ubuntu) (and 1 other project) "DHCP does not work with iwl3945 (affects: 2) (heat: 12)" [Undecided,Triaged] [17:36] appelflap: the ubuntu bug still looks to appear open. the upstream bug does look a bit confusing based on the last comment but I'm wondering if that was just a mistake/typo? [17:37] appelflap: http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40 seems like the fix? [17:37] ogasawara: indeed [17:38] appelflap: I'd say leave the upstream bug as is, since the commit is in the iwlwifi-2.6.git tree [17:39] ogasawara: ok, that will likely just be merged? [17:39] appelflap: yep, we can leave the ubuntu bug open until the patch makes it's way into Linus' tree and we rebase [17:40] ogasawara: ok, cool, thanks! [17:40] appelflap: I'll post a comment to the bug to explain it's not in Linus' tree which is why it's not in the daily mainline builds [17:48] sconklin, hey ... i think you worked out you could turn on drm debug ... how does one do that [17:48] one sec while I look it up :) [17:49] apw: echo 4 > /sys/module/drm/parameters/debug [17:50] 4 is for mode setting debug, other bits are different [17:50] sconklin, where is that documented ? [17:52] apw: I documented it on the blueprint page, I think it's in kernel docs or maybe a header file, looking now [17:53] it's in include/drm/drmP.h [17:54] apw ^^ [17:54] sconklin, thanks ... just found it too [17:55] [ 7127.610872] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800 [17:55] [ 7131.004211] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08000b00 [17:55] [ 7131.010882] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800 [17:55] [ 7134.404340] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08000b00 [17:55] [ 7134.411197] [drm:i915_driver_irq_handler], hotplug event received, stat 0x00000800 [17:55] sconklin, getting constant hotplug events it seems === amitk is now known as amitk-afk [17:56] apw: Hmmm. Seems like there was a patch for that a while back, is this in Maverick? [17:56] yep maverick [17:56] that's not good [17:57] sconklin, any idea how to decode the numbers, i am suspicious its powersaving [17:57] apw: sorry, I don't know [17:57] cking, in UEFI banter [17:58] [ 7300.770314] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000 [17:58] [ 7300.790073] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000 [17:58] [ 7300.810302] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000 [17:58] [ 7300.830308] [drm:i915_driver_irq_handler], hotplug event received, stat 0x08400000 [17:58] sconklin, and when it goes mad, its those ones which differ i see [18:08] sconklin, so thats saying 'digital port D' and a bit which is not defined ... 'has triggered hotplug' [18:08] presumably as we do not handle it ... bad shit happens [18:09] apw: back in the late Karmic/early Lucid time frame there were problems with phantom events from inputs which were not physically connected on the board, and some patches to fix that. I have not heard of it since, but this sounds similar [18:10] sconklin, this could easily be a connector not connected, as it claimed i have to display port connectors that have no external ports [18:10] let me take a glance at the upstream mailing list [18:11] sconklin, can you send me that list address so i can sub my gmail to it [18:12] apw: sure, there are two you are probably interested in. dri-devel and intel-gfx [18:12] mjg59, your suggestion it might be bad hotplug seems to be born out ... i am getting what appear to be undocumented bits set in my HOTPLUG status [18:12] Hurrah Intel [18:12] no comment [18:13] mjg59, any idea where the intel guys hang out ... [18:13] #intel-gfx [18:15] mjg59, thanks again [18:16] apw: http://lists.freedesktop.org/mailman/listinfo/intel-gfx and http://lists.freedesktop.org/mailman/listinfo/dri-devel [18:16] apw: is it a GM45? [18:16] sconklin, how do i tell, its something like that [18:16] lspci [18:17] its a 2a42 [18:17] there is a mail on the list about a hotplug regression [18:17] got a pointer to it ? [18:17] working on it [18:17] ta [18:18] INTEL_VGA_DEVICE(0x2a42, &intel_gm45_info), [18:18] sconklin, so yes it is a GM45 [18:18] ogasawara: thanks for the reply in lp bug 591016! i'm not really in a hurry, so (if you haven't done it already) you don't need to build a test kernel for me. [18:18] Launchpad bug 591016 in linux (Ubuntu) (and 1 other project) "DHCP does not work with iwl3945 (affects: 2) (heat: 12)" [Medium,In progress] https://launchpad.net/bugs/591016 [18:18] for now I'll forward the email, still looking [18:18] sconklin, ack [18:18] appelflap: too late :) it's no problem. [18:19] appelflap: I just kick it off on one of our build boxes [18:19] dang it it is hard to hit the right box when its doing it [18:19] ogasawara: cool, thanks :-) [18:19] apw: mail on the way, and here's the archive link: [18:20] http://lists.freedesktop.org/archives/intel-gfx/ [18:20] pgraner: you said you cancelled the release meeting? is that kernel-team specific or did you mean the whole friday release meeting? (I ask since the security team is figuring out who will cover for jdstrand at the meeting while he's on vacation) [18:20] apw - http://lists.freedesktop.org/archives/intel-gfx/2010-June/007077.html [18:20] "hotplug storms still here" [18:21] (pgraner: oh, nm, just saw the ubuntu-devel email.) [18:22] apw: I don't see a clear resolution in the threads [18:23] kees: just fyi, I'm gonna tweak your yama commit msgs (to drop the sha1 id's per tim's comments in the thread) [18:23] kees: hope that's ok, since I'm the one who told you to put them there :) [18:24] sconklin, yeah the fix they suggest trying is already in [18:38] pgraner: tomorrow there should be a kernel in Lucid preproposed which has all the ext4 patches plus the various stable ones which are queued. lbm and meta should be there too unless I screwed it up [18:39] ogasawara: heh, I don't mind at all -- I just wanted it in whatever state you were most happy with. [19:01] smb, which is the upstream stable tree then ? [19:02] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git [19:03] manjo, Thats one of them [19:21] apw, Here we go 23/149/164/200 [19:22] smb ? [19:22] apw, That are the number of patches in the reviews for 2.6.27,32,33 and 34 o_O [19:23] * apw closes his eyes, logs off, and opens a beer ... madness [19:24] * ogasawara lunch [19:28] pgraner, just looked at your comment to bug 588069 [19:28] Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 4) (heat: 26)" [High,In progress] https://launchpad.net/bugs/588069 [19:29] * apw wanders out to the balcony ... smb ? [19:29] pgraner, not sure it is relevant to that bug, can you open a new bug on that issue :-) [19:53] ogasawara, hey ... why has u-m got branches for fsl-imx51 etc ? [19:55] apw, i just looked it doesn't [19:55] apw, not on zinc anyway [19:56] bjf, hrm, somehow it _has_ in the past but not now and i'd not pruned them ... very odd indeed [20:36] apw: that is quite odd as I don't ever recall creating any topic branches for maverick [20:42] bjf: that kernel fixed the issue [20:42] which kernel? [20:43] pgraner, i thought you said my test kernel didn't fix the problem you were seeing [20:44] bjf: it did, the issue I had was user error on my part, I've been running now for over 4+ hours, where before I couldn't run more than 30 mins [20:44] bjf: earlier issue that is, I knocked the power supply out of the drive on my desk and didn't realize [20:44] pgraner, that's very good to know [20:45] bjf: woould have told you sooner but had to run to an eye appt. [20:53] pgraner, can you update the bug with that info, thanks [20:53] bjf: yep right after this call I'm on :) [21:01] bjf: done === cnd is now known as cnd` === andreas_ is now known as anoteng [21:20] ogasawara, sconklin: I've sent a patch, based on some limited discussions and debugging with upstream, to deal with my i915 hangs. can I convince you to take it at least as a temporary work-around so I don't have to keep building my own custom maverick kernels? :) [21:22] kees: maverick or lucid? [21:22] sconklin: maverick. lucid has the old logic [21:22] ok, then ogasawara will have to make the call [21:22] sconklin: i.e. lucid is prone to https://bugzilla.kernel.org/show_bug.cgi?id=15733 but not https://bugzilla.kernel.org/show_bug.cgi?id=16294 [21:22] bugzilla.kernel.org bug 15733 in Video(DRI - Intel) "Crash when accessing nonexistent GTT entries in i915" [Normal,New] [21:23] originally, I had asked that f1befe71fa7a79ab733011b045639d8d809924ad be reverted, but that would have re-introduced https://bugzilla.kernel.org/show_bug.cgi?id=15733. The new patch fixes the G33 behavior, so the result leaves both bugs fixed. [21:23] kees: I think we've reached bug equilibrium in the 915 driver. You can't remove one without adding another [21:24] sconklin: heh [21:24] kees: I'm out for the week starting this evening and am not planning another upload before then. Not sure if apw or rtg will do an upload while I'm gone. [21:24] kees: so I probably won't apply it before I take off to give them a chance to review as well [21:25] kees: but they have the proper permissions to commit it in my absence [21:25] ogasawara: okay cool; I'm just hoping to get it in before the next upload so I don't rebreak my machine. ;) [21:25] kees: ack [22:09] hughhalf, available for a short chat ? [22:09] hi all [22:09] quick q [22:09] hi jono [22:10] what is the best way of checking if my machine is 64-bit? cat /proc/cpuinfo? [22:10] hey manjo [22:11] jono, whether you are running 64bit install or if the cpu is 64bit ? [22:11] manjo, if the CPU is 64-bit [22:12] proc cpu info [22:13] riht [22:13]