[01:06] Hello. can yo think of any thing bad about adding splassert(IPL_NONE) to pmap_enter() ? [02:59] Hello, I found a bug in the gma500_gfx module. How can I obtain the sources? [03:16] Never mind, sorry for the stupid question. [09:19] ppisati, i have updated the summary-matrix with your latest upload: http://kernel.ubuntu.com/~kernel-ppa/configs/quantal/reviews/Portland.html [09:21] apw: still a lot of sh*t to be synced, thanks [09:22] ppisati, now you know my highbank pain [09:22] if i update kernel 3.4.2+ my wireless card does not work anymore. uses ath9k driver. anyone knows what i can do? [09:23] guest1337, does it report anything in dmesg when you use that level of kerenl, it may be needing newer firmware for instance [09:23] wlan controller is not shown at all [09:24] thats odd indeed, whats the pci ids for it, as ath9k still exists in later kernels [09:26] 02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01) [09:27] if you use lspci -nnvv it will include some numbers for it (xxxx:yyyy) sort of thing [09:28] 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9485 Wireless Network Adapter [168c:0032] (rev 01) [09:28] Subsystem: AzureWave Device [1a3b:2086] [09:28] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- [09:28] Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes [09:28] Interrupt: pin A routed to IRQ 17 [09:28] Region 0: Memory at dea00000 (64-bit, non-prefetchable) [size=512K] [09:28] Expansion ROM at dea80000 [disabled] [size=64K] [09:28] Capabilities: [09:28] Kernel driver in use: ath9k [09:28] Kernel modules: ath9k [09:29] guest1337, presumably thats from an [09:29] guest1337, presumably thats from an older kernel [09:29] yes thats a working kernel [09:29] and where did you get your 3.4.x kernel [09:30] you need the output of an non working kernel? [09:30] not sure about that yet [09:30] you only need that output? have to reboot [09:31] i am wondering where the 3.4 kernel came from first [09:31] so i can check the config [09:31] http://kernel.ubuntu.com/~kernel-ppa/mainline/ [09:31] which one specifiically [09:31] 3.4.1 works [09:31] 3.4.3 tested does not work [09:31] and 3.4.4 also not working [09:31] all 3.5.x also not working [09:31] i did not test 3.4.2 [09:32] well that would be worth testing indeed to work out which jump is the issue [09:32] why are you using 3.4 kernels? any reason, or just for fun [09:32] part fun [09:32] other [09:32] tochpad is correctly recorganized in 3.4.1 [09:33] if i use the stock one touchpad is show as mouse etc [09:33] which touchpad out of interest [09:34] Sentelic Touchpad [09:34] sforshee, ^^ may be an interesting data point for you [09:35] also scrolling is working with 3.4.1 [09:36] there is exactly one ath9k patch between those two versions, which is also present in v3.4.2, so if you could test that version that would help work out if it is that commit [09:37] it sound somewhat unlikely [09:37] ok brb 5min [09:41] BLKSSZGET should return new disk size when I resized a disk, and did a rescan ? [09:41] Did: echo 1 > /sys/bus/scsi/devices/0\:0\:1\:0/rescan [09:41] dmesg shows new size, but for example fdisk not (which uses BLKSSZGET) [09:43] if dmesg shows the new size then the disk ought to have changed, is the overall size in the partition table too? [09:44] [57013390.810115] sd 0:0:1:0: [sdb] 2147483648 512-byte hardware sectors (1099512 MB) [09:44] and fdisk: Disk /dev/sdb: 536.8 GB, 536870912000 bytes [09:49] hmmm you might strace fdisk and see what was returned there [09:49] if i am reading the current code right it should be returnign the samem number [09:54] here i am again [09:54] srry took bit longer [09:55] apw: 3.4.2 also not working [09:56] guest1337, there does only seem to be one commit .1->.2 which could possibly affect ath9k [09:56] another problem which i forgot [09:56] whole usb ports do not work anymore [09:56] on top of that [09:56] apw: ioctl(3, BLKSSZGET, 0x7fffffffd31c) = 0 [09:57] fdisk does a BLKSSZEGET, which seems to return wrong size [09:57] that does seem broken, i assume this is a VM of some sort given you can change the size of the disk ? [09:57] blockdev --getsz /dev/sdb also returns old value [09:57] yep [09:58] virtual machine, extended disk, rescanned disk [09:58] but now I can't extend partition because of this [10:00] apw: found a difference in lspci -nnvv : Interrupt: pin A routed to IRQ 17 (with working kernel) and Interrupt: pin A routed to IRQ 5 with non working. from network controller [10:01] dupondje, presumably a reboot of the vm will resolve it [10:01] apw: indeed, but thats what we want to avoid ofc :) [10:01] ath9k driver and module is not loaded at all in non working [10:03] dupondje, Sorry I just saw and still read this, I am not sure the scsi rescan attribute works the way ... have you tried to use 'blockdev --rereadpt'? [10:03] BLKRRPART: Device or resource busy, its mounted ofc :( [10:06] guest1337, ok not sure how any change in .1->.2 could cause that, but there is an ath init change so that seems suspicious as a first cut [10:07] guest1337, will see about getting a build with that on top of .1 to see if that it, will take me a few [10:07] ok [10:08] dupondje, Yes, none of the device old partitions or the device itself should be opened by anything at that point. And sometimes its near impossible to find out what keeps it busy. :/ [10:09] fuser? [10:12] More often not that it does in that case [10:13] dupondje, Hm, what kind of virtual machine and how did you resize the disk? Just to get a bit more context [10:32] smb: ESXi host [10:32] resized in the vmwware interface [10:35] its just annoying imo :) resize2fs can do live resizes [10:35] vmware can do live resize of disk [10:35] and then your stuck just with extending the partition :) [10:38] dupondje, Well don't know much about the internals of vmware. But I guess they just change the disk itself. To some degree this has been noticed by the kernel, but whatever makes the rereadpt fail prevents the gendisk info to get updated. And as long as that doesn't get done the rest fails too [10:38] I assume rebooting is not an option otherwise you'd probably done it long ago... [10:39] well its an option [10:39] None of the partitions on that disk are currently mounted? [10:39] as last resort :) [10:40] Well they are mounted ... [10:41] alot of services running on the disk, so reboot/unmount is last option [10:41] But I guess its just not possible to resize without a reboot/umount [10:43] At least not without unmounting. You would certainly not be happy if someone stole the chair you are sitting on, even if it gets replace by a bigger one... [10:43] feature request ? :p [10:43] guess it should be possible? [10:45] disk can be live resized, new size is mostly seen by the kernel after a device rescan and filesystem can be live resized. [10:45] so just missing the fdisk/partition part :) [10:46] guest1337, http://people.canonical.com/~apw/mainline-3.4.2-debug-quantal/ [10:47] Well "just" the partition part has a potential to move around any mapping the kernel is using (while mounted). To allow that is not sane feature in my world... [10:47] apw whats that? [10:49] guest1337, a .2 with teh ath change reverted [10:50] smb: you mean if you have like 2 partitions, and second partition gets deleted it would fuckup ? :) [10:50] ok ill give it a tyr [10:50] try [10:54] dupondje, Certainly, I would. :-P [10:54] apw: restarting and testing [10:56] smb: but still, there could be a check that it for example only resizes partitions, and never add/delete ? :) [10:56] dupondje, Feel free to add that and get it accepted upstream. 3:) [10:57] challenge ... oh wait :) [11:04] re [11:04] apw: not working. [11:10] smb: hey, is http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=4b727361f0bc7ee7378298941066d8aa15023ffb;hp=e1ac50f64691de9a095ac5d73cb8ac73d3d17dba not applied to precise? [11:13] Daviey, That points to a net staging tree. Should it? Certainly this normally would need to be upstream _and_ marked cc stable... [11:14] smb: I'm just vaguely looking into.. bug 997978 .. which is a set of https://bugzilla.kernel.org/show_bug.cgi?id=42829 [11:14] Launchpad bug 997978 in qemu-kvm "KVM images lose connectivity with bridged network" [High,Confirmed] https://launchpad.net/bugs/997978 [11:14] bugzilla.kernel.org bug 42829 in kvm "KVM Guest with virtio network driver loses network connectivity" [Blocking,Resolved: code_fix] [11:14] Daviey, But checking upstream, this was in Linus tree at 3.2 time... [11:15] And it is in Precise [11:16] smb: I thought it would have been applied, which is why i am confused [11:16] smb: I guess that commit is unrelated to the Ubuntu bug? [11:16] Daviey, Well it was in from the beginning [11:16] That patch went upstream v3.2-rc1 [11:17] smb: So why no worky? [11:18] Daviey, Some other problem? Why should I know? ;) [11:19] smb: you smart guy. [11:19] Daviey, Maybe, but not almighty. ;-P [11:19] nor omnipresent [11:20] smb: Oh, i see. I looked at you as an oracle for all things. [11:20] Daviey, Where did you find the reference to that upstream commit? In that bug of ours of rh bugzilla? [11:21] smb: community member correlated them on IRC. [11:23] Daviey, Omm. I think I found it. Its in the upstream bug before the comment saying 11.10 (Oneiric) looks good... [11:24] smb: Oh sorry, i thought you meant.. what linked the kernel.org bug to LP [11:26] Daviey, No more in the sense how or why do we assume this would be the fix. It is a bit confusing in the upstream bug report. It say "I assume it got fixed" but nothing really definitve and the next comment probably only means with a certain argument... [11:29] Daviey, I wonder. In our bug report, is there anything said about the host? I only see guest versions but may miss something [11:31] apw: just tried quantal live build wit 3.5.0.2 and it works.. Oo [11:31] smb: I only started looking at this briefly before i pinged out.. hallyn has been closer to it. [11:33] wow, ogasawara made it into the german IT news [11:33] http://www.golem.de/news/ubuntu-zweite-alpha-von-quantal-quetzal-erschienen-1206-92862.html [11:35] Daviey, So guess it needs more reading. The change you asked for definitely is in. So whatever the issue is in PRecise it would be different. Or maybe something that has to be changed in a driver running in the host space... [11:36] can someone watch up xserver-xorg-video-intel current version in 12.04 pls? [11:37] is there a particular package i need to install to get the quantal xorg packages on precise? [11:37] looking at dpkg -l i don't have them, despite that the ppa is enabled [11:41] smb: okay, thanks muchly [12:08] <[yates]> hi, where can i find a changelog of precise's linux-image-3.2.0-25-generic and linux-image-3.2.0-26-generic? [12:18] [yates]: in the package itself. take a look at /usr/share/doc/linux-image-3.2.0-25-generic/ [12:19] <[yates]> ahh yeh, nice, thanks :) [13:29] * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal [13:36] * apw tries to remember where the udev persistant naming db is [13:36] and finds them in the first place he looks, yay [13:36] apw, network devices? [13:36] yeah, adding a 3rd nic to my firewall [13:37] Now you can do a network packet 3-way merge... [13:37] heh... 4 way as i have a tunnel too === ayan-afk is now known as ayan [13:38] cking, hello [13:39] arges, hiya [13:39] cking, finally getting around to the jack_delay testing (its been a fun week) [13:39] cking, where did you get jack/jack.h headers from? [13:39] arges, something like libjack*-dev - I can't recall of the top of my head [13:40] ah there we are [13:40] cking, thanks [13:40] libjackdev2-dev I think [13:40] nope, libjack-jackd2-dev [13:41] libjack-jackd2-dev [13:41] yea [13:41] wrong version causes issue [13:42] yep, it causes all kinds of woes [13:48] cking, ahhhh. i have it playing back via headphones and monitors... whoops [13:48] arges, its not the most helpful of test tools [13:49] cking, i see no variance at all ... i can't even tell my terminal is scrolling anymore [13:50] arges, yep, I only got variance when the buffer settings were very small [13:50] ..and on a slow machine [13:50] but if you load it with tools like "stress" you may see some jitter [13:52] cking, ok i may run a stress/unstressed test [13:52] as another variable [13:52] arges, if you see my data, I had lots of variables :-/ [13:56] cking, do you have particular stress settings you used? [13:56] arges, I ensured all the CPUs were loaded, and followed the defaults otherwise [13:57] arges, for my 2 CPU laptop, I used: stress --cpu 2 --io 4 --vm 2 --vm-bytes 128M [13:58] stress --cpu `grep -c processor /proc/cpuinfo` --io 4 --vm 2 --vm-bytes 128M --timeout 60s [14:00] * cking nods [14:00] cking, also are you testing on quantal or precise? [14:01] i know the ll is quantal [14:01] Q [14:01] hmm [14:01] and I compared the low-latency kernel Q against P, and they behaved the same [14:06] cking, the maximum schedule delay... where di dyou find htis? [14:08] arges, its on the qjacktql messages window - just near the XRUN count [14:08] but only shows up if you get XRUNs [14:08] cking, ah [14:11] cking, lowest latency settings just crashed jackd [14:11] : ) [14:11] arges, yep, I get that too, it may work after a reboot, but it was really flakey [14:12] cking, yea i wrote a 'kickSoundcard.sh' script that just removes all the firewire modules, kills jackd, kills pulse, and reinserts and loads everything up again [14:12] because this stuff happens fairly frequently [14:13] basically it's fragile like eggshells [14:13] arges, it took me forever to collect multiple sets of reliably looking data for different kernels, different loads, different buffer size configs [14:15] cking, i still don't see max sched delay in the qjackctl window... is it somewhere else? [14:16] arges, urm, I need to fire up the box that I tested this on just to re-remind myself, lemme dig it out of the pile [14:17] cking, i see it [14:17] cking, messages->status [14:17] arges, that's the one [14:19] cking, did you notice if the -ll kernel was anymore stable? [14:20] w.r.t. to audio latency / jack not crashing [14:20] arges, nope, both were flakey [14:20] well its time to reboot my machine [14:59] * ogasawara back in 20 [15:05] after rebooting a preinstall-server image on my panda, /proc/cmdline contains only 'ro quiet splash' [15:16] brb [15:18] josepht, quantal ? [15:18] ogra_: yes [15:18] thats normal [15:18] ogra_: okay, thanks [15:19] in the new world order the boot config lives now in /usr/share/flash-kernel/bootscript/ in case you want to change it ... the root= stanza isnt necessary anymore, flash-kernel installs an initramfs hook that reads it from fstab now === cnd` is now known as cnd [15:31] arges_, so what was your conclusion? anything of substance? [15:31] cking, getting data now, but had a call so getting back on task [15:31] arges_, ah, no sweat :-) [15:37] cking, hmm i think this test is invalid because something called 'unity-music-daemon' started slamming my harddrive [15:37] arges_, :-/ [15:41] ogra_: I still need to run flash-kernel right? [15:41] yep [15:41] that hasnt changed === yofel_ is now known as yofel [16:05] * ppisati goes to buy some food === bjf[afk] is now known as bjf [16:10] cking, so really >= 32 frames I'm not getting XRUNs with jack_delay and one channel + stress test [16:11] anything else I should be adding to test perhaps 8 channels etC? [16:11] arges_, well, it may be your CPU is just fast enough [16:11] cking, yea perhaps test on my other machine [16:11] but i'll add that data to the study so we have it [16:12] we could set the max freq lower and re-test [16:12] cking, one thing is that the stress maxes the CPU [16:12] cking, but harddrive operations will cause xruns [16:12] yep, well run the bonnie test and see if that causes xruns too [17:18] * henrix -> EOD [17:30] * cking --> EOD [18:24] * bjf -> lunch [18:43] apw, I've just sent you the 32/32 32/64 64/64 combo results [18:43] no big surprises [18:43] cking, hey thanks, will look at the tommorrow when i am more with it [18:44] whenever reallty [18:44] cking, which side of 32/32 is 32/64 better or worse [18:44] it depends on what you're looking for :-) [18:45] that means its better for soemthing :) i shall look forward to reading [18:45] lets chew it over on monday when I've not got the kids pestering me [18:45] Performance-wise, I can't see how 32/64 would be any better than 32/32 (since the userspace is too stupid to know it has access to native atomics and other fun stuff), but the obvious benefit of having a 64-bit kernel on your 64-bit CPU seems worth it. [18:47] Assuming, of course, that your "32" is i386. If the 32 is x32, that's a different can of worms, since you just bought yourself more registers and instructions and such. [18:47] Or even if your 32 assumes the presence of sse [18:47] Which ours doesn't. [18:47] like always, it's a mixed bag [18:47] Though, it has runtime selection here and there. [18:49] * cking -> REALLY EOD [18:49] s/D/W/ [18:50] infinity, well bear in mind that your system calls we in 64bit so it could easily be faster for some operations, and hotter, and eat more battery [18:50] *will be in [18:51] * apw calls it a wrap too, i smell some lovely spagbol in my future [18:52] You people and your living in the future. [18:52] its better than the now in most cases ... [18:53] Is this why Australians always seem so unjustifiably happy? [22:09] Anyone still awake?