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