[01:31] Hello! anybody know what this http://pastebin.com/m69cc4e49 is? 8.10 amd64 user. Symptoms are: system doesn't shut down properly, nautilus crashes and won't launch and dvds won't mount [01:48] ratpoison: I am thinking "underpowered" === pgraner is now known as pgraner-afk [08:17] huh, it takes a minute for qla2xxx to initialize on jaunty.. per path [08:27] it seems to be trying to run modprobe using the pci id or such [08:29] ok, so qla2xxx is still a module.. === Lure_ is now known as Lure [10:05] I am extremely puzzled by the generic acpi support. The way I understand this is: if a bios supports it the LCD object would have a _BCL method that returns the supported levels. [10:06] i believe that to be true from my experience on this bug too [10:06] Now we had those reports that some Thinkpads did not work correctly because the thinkpad_acpi driver backs out since there is generic support. And yes, the brightness proc file contains various levels. [10:07] so it must be later thinkpads then, t30 must be too old [10:07] what is your thinkpad? [10:07] Now I asked for the dsdt of those but when I look into there, I don't find any _BCL method [10:07] hmmm [10:07] mine is a T42p, doesn't have support [10:07] so pretty new [10:07] not in laptop world I would say [10:07] we have a couple of T6x's around [10:08] * smb_tp_ thinks it is at least 3y old [10:08] yeah true [10:10] Hm, maybe mjg59, do you know whether I should find a _BCL method in the disassembly of a dsdt when a laptop supports the generic acpi brightness controls? [10:10] cking, might know such things too [10:11] yes maybe. [10:11] * cking looks at the documentation.. [10:12] Actually I just looked at the dsdt of a sony and there it is. [10:12] so you are looking for the right thing [10:13] This method allows the OS to query a list of brightness level supported by built-in display output devices. [10:13] (This method in not allowed for externally connected displays.) This method is required if an integrated [10:13] LCD is present and supports brightness levels. [10:13] Each brightness level is represented by a number between 0 and 100, and can be thought of as a percentage. [10:13] For example, 50 can be 50% power consumption or 50% brightness, as defined by the OEM. [10:13] The OEM may define the number 0 as "Zero brightness" that can mean to turn off the lighting (e.g. LCD [10:13] panel backlight) in the device. This may be useful in the case of an output device that can still be viewed [10:13] using only ambient light, for example, a transflective LCD. If Notify(Output Device, 0x85) for “Zero [10:13] brightness” is issued, OSPM may be able to turn off the lighting by calling _BCM(0). [10:14] ..so I suspect the answer is "should do" [10:14] Yeah, this far it sound just reasonable [10:16] Just that there are three reports from people with T61, X61s and r61 which can show you acpi brightness support indication but when I look at the disassemled dsdt there is nothing [10:17] * cking looks at the spec a little more [10:18] does it have BCM and/or BQC [10:18] nothing [10:18] _BCM --> The OS will only set levels that were reported via the _BCL method. This method is required if _BCL is [10:18] implemented. [10:19] apw, maybe you can cross check. see bug 311716 [10:19] Malone bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Fix committed] https://launchpad.net/bugs/311716 [10:20] smb_tp_, your fixes to allow switching both ways are not in jaunty are they? [10:20] take the dsdt from the last reporter, cking "iasl -d dsdt.bin" is correct,? [10:20] yep [10:21] apw, no, they are only in intrepid [10:21] /* First check for boot param -> highest prio */ [10:21] if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR) [10:21] return 0; [10:21] else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) [10:21] return 1; [10:21] /* Then check for DMI blacklist -> second highest prio */ [10:21] if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_DMI_VENDOR) [10:21] return 0; [10:21] else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_DMI_VIDEO) [10:21] return 1; [10:21] i see this in jaunty kernels, so there is something upstream in this area [10:22] They are slightly different. I patched it to return not 0 or 1 but a bitfield [10:22] ahh [10:23] /* First check for boot param -> highest prio */ [10:23] if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR) [10:23] return ACPI_VIDEO_BACKLIGHT_FORCE_VENDOR; [10:23] else if (acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) [10:23] return ACPI_VIDEO_BACKLIGHT; [10:23] this way it can have both set. but that is hackish [10:25] if (ACPI_SUCCESS(acpi_get_handle(handle, "_BCM", &h_dummy1)) && [10:25] ACPI_SUCCESS(acpi_get_handle(handle, "_BCL", &h_dummy2))) { [10:25] that seems to be the check for turning on ACPI_VIDEO_BACKLIGHT [10:25] so if you don't have those you shouldn't get it turned on [10:26] Exactly what I believed [10:26] smb_tp_, there is a shit load of debug in here for acpi [10:26] i wonder if we can get them to boot with that enabled [10:26] ..yeah.. boot eventually with all the debug turned on. [10:27] any idea how to turn it on? [10:27] Must check for intrepid. At some point you had to compile with ACPI_DEBUG set, which was not the default [10:27] Then you could use some bitmask setting. Should be in ./Documentation [10:28] it tells us things it finds and explicitly tells us it turns this on [10:30] where do i fine iasl [10:30] find [10:31] apt-get install iasl ? [10:32] odd its not recommended === asac_ is now known as asac [10:33] hi apw , it seems the blacklight hack is still in -5 kernel? [10:34] yeah we are still working on what to do about it over all [10:34] not good [10:34] i have some tests out in the field on some new combinations [10:34] will revert it for my build [10:34] it will be going, its just not clear what is going in in its place [10:35] smb_tp_, no i can't see either of those in that dsdt in the bug, so that should imply it is not found and enabled [10:38] anybody responsible for linux-firmware package here? [10:38] whats the question [10:38] well you need more firmware files [10:39] for drivers we have already? [10:39] different ones for some dvb-t devices like hauppauge dvb-t [10:39] additional ones for new rt28x0 drivers - like mentioned in my mail [10:39] i thought we got out hauppauge ones recommended by them [10:40] http://www.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-1.20.fw [10:40] you need that now [10:40] you have got 1.10 [10:40] but 2.6.28 needs 1.20 [10:41] you have emailed all this to the kernel list? [10:41] maybe you can add a symlink from 1.20 to 1.10 [10:41] nope, but i mentioned ti before [10:41] irc stuff tends to get forgotten in minutes [10:42] for some driver for that little xo there the firmware would be missing too [10:42] bought a similar wlan device but that did not work with my simple id hack ;) [10:43] but found out that the firmware was missing [10:43] one mail with all the firmware issues would be good [10:44] will seek my notes [10:44] but you saw the mail about rt2860+70 already? [10:44] no not seens that [10:45] i only see one from you about the brightness in my inbox [10:45] i sent the other 10min later or so [10:45] oddness [10:45] http://www.ralinktech.com.tw/data/drivers/RT2860_Firmware_V11.zip [10:46] http://www.ralinktech.com.tw/data/drivers/RT2870_Firmware_V8.zip [10:46] licence included [10:50] ok, found these 2 + 3 others, will mail it [10:57] mail sent [10:57] cool [10:58] at least i did not see more right now [10:58] it happens from time to time that i have to seek for firmware for others [11:01] well the hauppauge dvb-t i own myself [11:33] http://www.phoronix.com/scan.php?page=article&item=phoenix_hyperspace&num=1 [11:33] ups wrong channel ;) [11:34] when can i expect a linux-firmware update? [11:51] not sure, others will need to review the changes and decide [12:03] upload it somewhere an i will test it for you === smb_tp_ is now known as smb_tp [13:36] I'm getting strange disconnects when copied ~10GB from the usb drive to my local hd on jaunty. dmesg says something about "__ratelimit: 167 callbaks suppressed" and then a bunch of buffer i/o errors [13:37] it's an ntfs file system, so using fuseblk [13:37] oh, the __ratelimit is irrelevant [13:38] right, just even more i/o errors [13:38] yep [13:44] might be just ntfs-3g failing.. === pgraner-afk is now known as pgraner [13:54] smb_tp: wireless normally works with the -rt kernel, right? [13:55] Hardt -rt, that is. [13:55] rtg, how do you think I know? [13:55] I don't know of any reports, but that must not mean anything [13:56] smb_tp: well, I guess one of would have noticed if no one's wireless worked with the Hardy -rt flavour. [13:56] s/of/of us/ [13:56] If they tried to probably yes. Not sure whether wireless and -rt are compatible [13:58] smb_tp: bug #318219. Its loading the i3945, but doesn't appear to do anything after that. guess I'll have to load up one of my laptops. [13:58] Malone bug 318219 in ubuntu "Dell n-series won't wifi after reload of Ubuntu" [Undecided,New] https://launchpad.net/bugs/318219 [14:00] I fear as much. Do they user an -rt kernel in the bug? [14:02] smb_tp: no (Ubuntu 2.6.24-4.6-generic), and I also just found an oops in his dmesg. [14:04] rtg, -4.6 sounds pretty old. same problem with anything newer? [14:05] smb_tp: I was just gonna suggest that he subscribe to -proposed [14:05] -23.46 is in -updates [14:05] even the released (guess thats the .1) is -16.30 [14:07] smb_tp: doh! thats the version of the kernel on the buildd, his kernel was 2.6.24-23-rt [14:08] rtg, Ah, so latest but -rt [14:09] rtg, Hm, the -rt code is pretty new [14:09] smb_tp: he's still got an oops, looks like a sysctl is failing [14:10] When I updated to -stable upstream alessio took the chance to get a new -rt patch into hardy [14:11] hmm, maybe we should start looking there. [15:21] useful link comparing various wear-levelling flash fs: http://free-electrons.com/pub/conferences/2008/jm2l/flash-filesystems.pdf [16:11] amitk: that's handy [17:07] apw: i saw the patch is reverted now, what about the firmware update? [17:09] not something i am working on at the moment, not looked to see if anyone has looked at the other [17:09] well a new kernel without firmware does not help that much [17:12] Kano: what patch? the rt2860/2870 stuff? [18:21] hi to all. I need the module aic7xxx_old. how can i compile only this module and than inserti it in the ubuntu precompiled kernel? [18:30] mous16: make -C /lib/modules/`uname -r`/build M=`pwd` [18:34] rtg: thanks! where I need to move with shell when i launch this make? and how I insert the module in the initrd? (this is the module of the scsi controller) [18:37] mous16: aic7xxx_old must have a compatible makefile. the command line assumes you are in the same directory as the makefile. once the modules is compiled you can load it using 'sudo insmod *.ko' === lamont` is now known as lamont [18:53] mous16: I have this other macro to permanently install a .ko once I built it [18:53] alias modmake='make -C /lib/modules/`uname -r`/build M=$PWD modules' [18:53] moduse() { [18:53] sudo cp $1.ko /lib/modules/`uname -r`/kernel/`pwd | awk "{print substr(\\$1, index(\\$1,\"drivers\"))}"`/$1.ko [18:53] } [18:53] so then to permanently use a .ko I just run "moduse drm" and drm.ko gets copied to the right location [18:54] mnemo: I'm having trubless in compiling the module. I'm using the kernel source in ubuntu repo, but it tell me that there isn't a make file... [18:56] mous16: so if you do like "mkdir my_kernel_code ; cd my_kernel_code ; apt-get source linux-image-2.6.28-4-generic ; cd linux-2.6.28/drivers/gpu/drm" [18:56] and then just do that comment rtg said [18:56] if you are in the drivers/gpu/drm part of the kernel tree it will build all the .ko's that are built from that dir etc [19:01] with drm it seams to compile correctly all the modules interessed. but if i move to drivers/scsi/aic7xxx_old and give the same command it return: http://paste.ubuntu.com/107901/ === makke_ is now known as makke [19:15] mous16: ah yes, that directory does not have a "makefile" at all in it [19:26] So, who's handling armel kernel flavors, and how do I talk them into doing a distro kernel for our buildds? [19:27] infinity: me or amitk [19:28] infinity: what are the buildd's and do you have a config? [19:28] rtg: Which source is armel built from? I see both linux and linux-ports failing on armel... [19:28] infinity: its building from the Jaunty git repo, I'm aware of the FTBS (I think its fixed) [19:29] rtg: The buildds are Marvell DB-78x00-BP Development Boards, and I have a monolithic config right now that works. I see no reason why it can't go modular with an initramfs, though. [19:29] infinity: the monolithic config is fine. I think all of the other flavours are like that. [19:30] And now, the challenge of finding my original build tree with the config in it... [19:30] *cough* [19:32] Do proc or sys export a config somewhere from the running kernel, perchance? :) [19:32] not in the distro kernel [19:32] Oh, it's an option? Almost certainly one I didn't enable, then. [19:33] dunno what you're running on the buildd [19:33] * infinity digs for his tree instead. [19:33] if its there, then it'll be /proc/config* [19:33] Nah, it's not, but I found my tree. [19:33] Sitting in a qemu image on my laptop. [19:34] infinity: is the qemu faster then native? these babbage boards with USB disk are sloooow [19:35] rtg: qemu on my laptop is speedy, the Marvell buildds are MUCH faster. [19:35] rtg: It's just that I had a chicken and egg problem where I couldn't build a kernel for the Marvell machines on the Marvell machines... [19:36] rumor has it that we may get one or two as porter machines soon [19:36] rtg: This is the kernel config I'm using: http://lucifer.0c3.net/~adconrad/armel-kernel-config [19:36] rtg: And I'm setting up the porter machine as we speak. :) [19:37] infinity: ok, the first thing I'll do with the porter machine is to test build your config. [19:38] and rev it from 2.6.27 to 2.6.28 [19:39] infinity: you won't mind if we homogenize the config, will you? ...add things like netfilter, ipv6 and other bloated modules that are common across all flavours? [19:40] amitk: aren't buildd's and porters all running stock Hardy? [19:40] complete with module bloat [19:41] All the other arches are stock hardy-server, yeah. [19:41] If you plan to make it a generic marvell DB-78x00-BP kernel for re-use by end users and testers, then yeah, bloat it up. I don't mind. [19:42] rtg: true. But most ARM-folks are used to hand-crafting their configs like in the good old days. I don't want to encourage those expectations. [19:42] If I'm going to end up being the only person who uses the kernel on my 6 machines, then no. :P [19:42] I know that Marvell handed out a fair number of these boards to the Free Software community, some Debian people have them, etc. So a generic kernel might actually get used. Maybe. [19:42] infinity: is this an orion5x-based machine? [19:43] amitk: I don't speak codenames. So. Maybe? I don't know? [19:43] infinity: grep for ARCH or MACH in the config [19:43] CONFIG_ARCH_MV78XX0=y [19:43] # CONFIG_ARCH_ORION5X is not set [19:43] That would answer that. [19:44] hmm.. yet another flavour [19:46] amitk: Oh, and it's uBoot based. I assume (hope?) that our build system can automagically staple the uBoot bits on the image? I had to do mine by hand. [19:48] infinity: make uImage ought to do that. I don't think our build system knows about it yet. [19:48] Anyhow, I'll get back to you guys when the porter machine's online, since I'm hearing that that's a prereq for getting my a distro kernel. :) [19:49] s/my/me/ [19:49] it'll make it faster. [19:49] rather, it'll happen sooner with a porter [19:51] rtg: how did you merge the versatile config? Just copy it over? [19:51] amitk: for i in config.* ; do cat config >> $i; done; rm config [19:52] debian/rules updatconfigs [19:53] rtg: aahh.. so the config failed on pulling from upstream? [19:53] amitk: I got it from ogra, so I have no idea [19:54] rtg: let me rephrase. Did you just merge the configs, copy over ogra's versatile config and then split config again? [19:55] yes [19:55] ok [19:55] which has caused me some gief, missing modules etc [19:55] s/gief/grief/ [19:56] amitk: where you is now? back in Europe? [19:57] rtg: yeah... [19:57] rtg: \o/ [19:58] filename encryption? [19:58] rtg: your filename encryption kernel is working :-) [19:58] rtg: yup [19:58] cool [19:58] rtg: $ ls [19:58] rtg: ECRYPTFS_FNEK_ENCRYPTED.FYZOEIsgDeUixETd-IcPajGrIikAQ4n6KRVe2BW2L0vIlNbyGJugWlyAkCgV9Mv1EBJ2Go2.z36IhdEoBEbxo2CxgC-1B4DMGD2J [19:58] rtg: $ ls Private/ [19:58] rtg: doc [19:58] :-) [19:58] rtg: okay, i gotta finish the userspace utilities for it now [19:59] kirkland: that'll mystify homeland security :) [19:59] rtg: my goal, of course [23:30] so I'm looking at the ubuntu/ubuntu-jaunty tree and it looks like c0399d55 "Enabled CONFIG_PID_NS=y for i386/amd64" reverts the previous 7 i915 commits -- fb8d31f8 428b85cb 29277168 30ee913c e7a95a8a c569e25c 4e5967f9. [23:30] should I mail kernel-team@ about it, or ping Tim directly, or ... ? [23:43] rtg: you around?