[01:31] <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:48] <JesperHansen> ratpoison: I am thinking "underpowered" 
[08:17] <tjaalton> huh, it takes a minute for qla2xxx to initialize on jaunty.. per path
[08:27] <tjaalton> it seems to be trying to run modprobe using the pci id or such
[08:29] <tjaalton> ok, so qla2xxx is still a module..
[10:05] <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:06] <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:07] <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:08]  * smb_tp_ thinks it is at least 3y old
[10:08] <apw> yeah true
[10:10] <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:11] <smb_tp_> yes maybe. 
[10:11]  * cking looks at the documentation..
[10:12] <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:13] <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:14] <cking> ..so I suspect the answer is "should do"
[10:14] <smb_tp_> Yeah, this far it sound just reasonable
[10:16] <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:17]  * cking looks at the spec a little more
[10:18] <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:19] <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:20] <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:21] <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:22] <smb_tp_> They are slightly different. I patched it to return not 0 or 1 but a bitfield
[10:22] <apw> ahh
[10:23] <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:25] <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:26] <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:27] <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:28] <apw> it tells us things it finds and explicitly tells us it turns this on
[10:30] <apw> where do i fine iasl
[10:30] <apw> find
[10:31] <smb_tp_> apt-get install iasl ?
[10:32] <apw> odd its not recommended
[10:33] <Kano> hi apw , it seems the blacklight hack is still in -5 kernel?
[10:34] <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:35] <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:38] <Kano> anybody responsible for linux-firmware package here?
[10:38] <apw> whats the question
[10:38] <Kano> well you need more firmware files
[10:39] <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:40] <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:41] <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:42] <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:43] <Kano> but found out that the firmware was missing
[10:43] <apw> one mail with all the firmware issues would be good
[10:44] <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:45] <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:46] <Kano> http://www.ralinktech.com.tw/data/drivers/RT2870_Firmware_V8.zip
[10:46] <Kano> licence included
[10:50] <Kano> ok, found these 2 + 3 others, will mail it
[10:57] <Kano> mail sent
[10:57] <apw> cool
[10:58] <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
[11:01] <Kano> well the hauppauge dvb-t i own myself
[11:33] <Kano> http://www.phoronix.com/scan.php?page=article&item=phoenix_hyperspace&num=1
[11:33] <Kano> ups wrong channel ;)
[11:34] <Kano> when can i expect a linux-firmware update?
[11:51] <apw> not sure, others will need to review the changes and decide
[12:03] <Kano> upload it somewhere an i will test it for you
[13:36] <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:37] <tjaalton> it's an ntfs file system, so using fuseblk
[13:37] <tjaalton> oh, the __ratelimit is irrelevant
[13:38] <smb_tp> right, just even more i/o errors
[13:38] <tjaalton> yep
[13:44] <tjaalton> might be just ntfs-3g failing..
[13:54] <rtg> smb_tp: wireless normally works with the -rt kernel, right?
[13:55] <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:56] <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:58] <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
[14:00] <smb_tp> I fear as much. Do they user an -rt kernel in the bug?
[14:02] <rtg> smb_tp: no (Ubuntu 2.6.24-4.6-generic), and I also just found an oops in his dmesg.
[14:04] <smb_tp> rtg, -4.6 sounds pretty old. same problem with anything newer?
[14:05] <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:07] <rtg> smb_tp: doh! thats the version of the kernel on the buildd, his kernel was 2.6.24-23-rt
[14:08] <smb_tp> rtg, Ah, so latest but -rt
[14:09] <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:10] <smb_tp> When I updated to -stable upstream alessio took the chance to get a new -rt patch into hardy
[14:11] <rtg> hmm, maybe we should start looking there.
[15:21] <amitk> useful link comparing various wear-levelling flash fs: http://free-electrons.com/pub/conferences/2008/jm2l/flash-filesystems.pdf
[16:11] <cking> amitk: that's handy
[17:07] <Kano> apw: i saw the patch is reverted now, what about the firmware update?
[17:09] <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:12] <rtg> Kano: what patch? the rt2860/2870 stuff?
[18:21] <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:30] <rtg> mous16: make -C /lib/modules/`uname -r`/build M=`pwd`
[18:34] <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:37] <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:53] <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:54] <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:56] <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
[19:01] <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:15] <mnemo> mous16: ah yes, that directory does not have a "makefile" at all in it
[19:26] <infinity> So, who's handling armel kernel flavors, and how do I talk them into doing a distro kernel for our buildds?
[19:27] <rtg> infinity: me or amitk
[19:28] <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:29] <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:30] <infinity> And now, the challenge of finding my original build tree with the config in it...
[19:30] <infinity> *cough*
[19:32] <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:33] <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:34] <rtg> infinity: is the qemu faster then native? these babbage boards with USB disk are sloooow
[19:35] <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:36] <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:37] <rtg> infinity: ok, the first thing I'll do with the porter machine is to test build your config.
[19:38] <rtg> and rev it from 2.6.27 to 2.6.28
[19:39] <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:40] <rtg> amitk: aren't buildd's and porters all running stock Hardy?
[19:40] <rtg> complete with module bloat
[19:41] <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:42] <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:43] <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:44] <amitk> hmm.. yet another flavour
[19:46] <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:48] <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:49] <infinity> s/my/me/
[19:49] <rtg> it'll make it faster.
[19:49] <rtg> rather, it'll happen sooner with a porter
[19:51] <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:52] <rtg> debian/rules updatconfigs
[19:53] <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:54] <amitk> rtg: let me rephrase. Did you just merge the configs, copy over ogra's versatile config and then split config again?
[19:55] <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:56] <rtg> amitk: where you is now? back in Europe?
[19:57] <amitk> rtg: yeah...
[19:57] <kirkland> rtg: \o/
[19:58] <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:59] <rtg> kirkland: that'll mystify homeland security :)
[19:59] <kirkland> rtg: my goal, of course
[23:30] <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:43] <radii> rtg: you around?