| === tsimpson_ is now known as tsimpson | ||
| === michael is now known as Guest44233 | ||
| === smb` is now known as smb | ||
| fairuz | Hi, morning. I have a question about interrupt handler. In my current interrupt handler, I disable the interrupt, do the treatment and reenable the interrupt. Is that the correct way to do it? Because it didn't work. It just recall the handler function again and again. | 08:46 |
|---|---|---|
| diwic | fairuz, afaik interrupts are already disabled in an interrupt handler, so don't reenable them. | 08:52 |
| fairuz | diwic: so I dont need to disable and reenable them? how about clearing interrupt flag? | 08:52 |
| diwic | fairuz, no you don't. I'm not an expert but I'd say that if there is some driver magic you need to do to tell the device that the interrupt has been handled, that should be done in your handler. | 08:55 |
| jjohansen | not needed | 08:55 |
| jjohansen | the kernel handles the disabling/reenabling of interrupts | 08:56 |
| jjohansen | when you register your handler you specify the type | 08:56 |
| jjohansen | whether all interrupts are disabled on the current processor, or just the one irq while your interrupt is being handled | 08:57 |
| jjohansen | your handler will need to set any bits on the hardware that may need to be twiddled because of the interrupt | 08:57 |
| jjohansen | and when done you return IRQ_HANDLED if you handled the interrupt | 08:58 |
| jjohansen | the LDD3 has a pretty good description of all this in chapter10 | 08:58 |
| diwic | jjohansen, just as I thought then. Thanks. | 09:00 |
| jjohansen | diwic: yep your right, the kernel responds to the apic but the driver has to do any extra device specific twiddling | 09:00 |
| fairuz | jjohansen: diwic: ok i will try it and tell you guys the outcome | 09:02 |
| fairuz | request_irq(OMAP44XX_IRQ_PL310, pl310_irq_handler, IRQF_DISABLED, "pl310", NULL) as for my interrupt install, looks ok to you guys? | 09:04 |
| bullgard | After Maverick coldstarts it writes to the virtual console 1 : "System information as of Sat Mar 12 15:51:57 CET 2011. System load, Temperature, Usage of /home, Processes, Memory Usage, Users logged in, Swap usage, IP address for eth0. -- What program prints this information? | 09:09 |
| jjohansen | fairuz: for what little I know of what your doing it looks reasonable | 09:12 |
| fairuz | jjohansen: I still need to clear the interrupt flag? | 09:12 |
| jjohansen | fairuz: if the hardware has an specific bits to twiddle you will need to handle that, the kernel with ACK the apic and handle enabling/disabling of interrupts | 09:13 |
| jjohansen | so no you do not handle the interrupt flag | 09:14 |
| fairuz | jjohansen: so basically i just do what i want the handler to do and thats all? no extra code..that what we call magic | 09:15 |
| jjohansen | fairuz: pretty much | 09:16 |
| fairuz | jjohansen: no luck for me..i got this [ 612.033447] BUG: soft lockup - CPU#0 stuck for 61s! [migration/0:4] | 09:22 |
| fairuz | [ 612.040313] BUG: soft lockup - CPU#1 stuck for 61s! [irqbalance:827] | 09:22 |
| fairuz | and the kernel basically freezes | 09:22 |
| jjohansen | fairuz: are you taking any locks in your handler? | 09:23 |
| fairuz | nope, i just put a line of code (printk) | 09:23 |
| fairuz | jjohansen: irqreturn_t pl310_irq_handler(int irq, void *dev_id, struct pt_regs *regs){ | 09:24 |
| fairuz | printk(KERN_INFO "pl310 : interrupt 0x%x!\n", readl(pl310_base + L2X0_EVENT_CNT1_VAL)); | 09:24 |
| fairuz | return IRQ_HANDLED; | 09:24 |
| fairuz | } | 09:24 |
| fairuz | jjohansen: so maybe the magic can't be applied here or something like that? | 09:26 |
| jjohansen | fairuz: hrmm, start by disabling the printk see if you get the lockup with just an empty handler | 09:34 |
| fairuz | jjohansen: just tried with an empty handler and still no luck | 09:34 |
| fairuz | jjohansen: got the same lockup message | 09:34 |
| fairuz | jjohansen: what's the soft lockup anyway? | 09:36 |
| apw | fairuz, that is telling you that the thread in question is not completing in a timly manner | 09:37 |
| apw | normally cause something is in the way | 09:37 |
| jjohansen | fairuz: you are likely going to need some extra flags in requesting your irq | 09:39 |
| jjohansen | there are two other possibilities, wrong interrupt number messing things up for some reason, or you need to twiddle something on the device because not doing so is messing something up | 09:42 |
| jjohansen | arm socs are a little different than x86, so I am not sure there | 09:42 |
| jjohansen | but the kernel should be reenabling interrupts for you when your handler exits | 09:43 |
| fairuz | jjohansen: ok i will check first on the interrupt number. Just to confirm it | 09:44 |
| jjohansen | fairuz: I am thinking the second case is more likely, maybe the device will reraise the interrupt until some bit is twiddled so the kernel never gets to leave the interrupt handling code | 09:46 |
| fairuz | jjohansen: i will look on it too, i will start by modifying one bit of the interrupt registers | 09:51 |
| fairuz | jjohansen: apw: I think I found the culprit. Apparently, the counter (the hardware that I'm using) does not reset itself if it overflowed. So the value if always 0xFFFFFFFF and maybe it's that who always regenerate the interruption. | 10:00 |
| jjohansen | fairuz: sounds likely | 10:01 |
| jjohansen | rebooting | 10:02 |
| fairuz | jjohansen: it works now. thanks | 10:13 |
| jjohansen | fairuz: glad to hear its working for you | 10:13 |
| === Nafallo_ is now known as Nafallo | ||
| === zul_ is now known as zul | ||
| jjohansen | rebooting | 12:55 |
| ogasawara | morning | 12:56 |
| bullgard | After Maverick coldstarts, it writes to the virtual console 1 : "System information as of Sat Mar 12 15:51:57 CET 2011. System load, Temperature, Usage of /home, Processes, Memory Usage, Users logged in, Swap usage, IP address for eth0. -- What program prints this information? | 12:58 |
| soren | landscpape-sysinfo | 12:59 |
| soren | err... | 12:59 |
| soren | landscape-sysinf | 12:59 |
| soren | landscape-sysinfo, even. | 12:59 |
| soren | Wow. That was difficult. | 12:59 |
| bullgard | soren: Thank you very much for your help. | 13:15 |
| sladen | Hello all, I'm trying to answer this question, which has been outstanding for a little while: | 13:48 |
| sladen | http://askubuntu.com/questions/28047/where-can-i-get-the-natty-kernel-config-file/30486#30486 | 13:48 |
| sladen | so far I've pointed them towards /boot/config-`uname -r` | 13:48 |
| sladen | but now re-reading they're asking for an online location of the Kconfigs | 13:49 |
| sladen | should I post something like http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=arch/x86/configs/i386_defconfig;h=6f9872658dd2d66e80d8025eb7f8c40ee86b958f;hb=HEAD | 13:49 |
| jjohansen | sladen: that will work, or they can download the source and reconstruct it | 13:49 |
| sladen | jjohansen: yeah, they're specifically (from re-reading) asking for something that doesn't need downloading the whole lot | 13:49 |
| smb | I would say the git is not that good. It is not the config used | 13:50 |
| smb | but the parts that get assembled | 13:50 |
| jjohansen | right, you have to reconstruct | 13:50 |
| sladen | smb: presumably "the config" is only constructed dynamically at the point of build | 13:50 |
| smb | sladen, correct | 13:50 |
| roadmr | Hey all! I used to be able to get X memory usage info from /proc/dri/0/gem_objects, but as of kernel 2.6.38-6 (Natty recent dailies) it's gone - where can I get that information now? | 14:17 |
| bjf | ## | 14:20 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 14:20 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 14:20 |
| bjf | ## | 14:20 |
| === herton is now known as herton_lunch | ||
| * ogasawara back in 20min | 14:46 | |
| === ogra is now known as Guest56191 | ||
| === Guest56191 is now known as ogra_ | ||
| === diwic is now known as diwic_afk | ||
| === jjohansen is now known as jj-afk | ||
| fairuz | what is the difference between ioctl call and a normal fwrite/write for communication between user space and kernel space | 15:19 |
| JFo | bjf, we have an hour, yes? | 15:54 |
| bjf | JFo, yes | 15:54 |
| JFo | think I want to address my need for lunch :) | 15:54 |
| JFo | thank you sir | 15:54 |
| JFo | bbiab | 15:54 |
| Kano | hi, why is there no .38 final kernel in the mainline dir only .37.4? | 15:57 |
| === herton_ is now known as herton | ||
| Kano | hmm now it is there | 16:03 |
| apw | fairuz, they both serve to carry data across the kernel boundary, but write is intended to be used for payload data, and ioctl for control data. overall though we sometimes use additional files to use write to carry control information etc. its about which is most natural for the use case | 16:27 |
| roadmr | Sorry for asking again - I used to be able to get X memory usage info from /proc/dri/0/gem_objects, but as of kernel 2.6.38-6 (Natty recent dailies) it's gone - where can I get that information now? | 16:29 |
| bjf | ## | 16:41 |
| bjf | ## Kernel team meeting in 20 minutes | 16:41 |
| bjf | ## | 16:41 |
| * JFo preps his notes | 16:41 | |
| JayFo | well that is good to know | 16:58 |
| JayFo | if I pull the USB dongle for my headset out, my machine poops itself | 16:58 |
| === JayFo is now known as JFo | ||
| vanhoof | JFo: does it panic? | 17:01 |
| JFo | dunno | 17:01 |
| vanhoof | JFo: I want to say I saw Cody having the same problem | 17:02 |
| vanhoof | JFo: theres a bug somewhere :) | 17:02 |
| JFo | Logitech dongle | 17:02 |
| * JFo will grab dmesg after the meeting | 17:02 | |
| apw | JFo, which kernel, latest one / | 17:03 |
| JFo | this is a MAverick machine | 17:03 |
| apw | oh :) | 17:03 |
| JFo | the one I am working from | 17:03 |
| JFo | :) | 17:03 |
| * JFo eats the dog food on his nettop | 17:03 | |
| roadmr | Actually, where did /proc/dri go?? | 17:03 |
| === jj-afk is now known as jjohansen | ||
| JFo | but I haven't seen that on there | 17:03 |
| vanhoof | JFo: https://launchpad.net/bugs/715318 | 17:04 |
| ubot2 | Launchpad bug 715318 in linux "Disconnecting USB headset while audio playing results in kernel panic" [Undecided,Fix released] | 17:04 |
| apw | roadmr, on which release? seems tob be there on my natty box | 17:04 |
| JFo | this is without audio playing | 17:04 |
| JFo | but may be the same | 17:05 |
| JFo | thx vanhoof :) | 17:05 |
| apw | JFo, if mumble is runinng then 'audio input is recording' all the time | 17:05 |
| vanhoof | JFo: np | 17:05 |
| JFo | ah hah | 17:05 |
| JFo | so that may be exactly it | 17:05 |
| roadmr | apw: 2.6.38-5.32 has no /proc/dri, on 2.6.38-6.34 it's there, but /proc/dri/0/gem_objects is not <- this is what I ultimately need | 17:06 |
| JFo | I didn't think of that | 17:06 |
| roadmr | apw: so I apologize, you're right that /proc/dri is there in latest kernels | 17:06 |
| apw | roadmr, they appeat to be in the debugfs inforamtions | 17:08 |
| apw | roadmr, possibly the information you are looking for is now in /sys/kernel/debug/dri/*/i915_gem_objects | 17:10 |
| roadmr | apw: oh yes, /sys/kernel/debug/dri/0/i915_gem_objects, thanks - is that likely to work on non-intel chipsets? like with nvidia or ati gpus? | 17:10 |
| apw | roadmr, no idea, not with an i915_ prefix ... you'd need to see if its even the same info or not | 17:11 |
| * smb would highly doubt that | 17:11 | |
| apw | roadmr, according to the commit that moved the file to i915 specific the stats were wrong and missleading for others anyhow | 17:12 |
| apw | commit 73aa808f10effc280e6eb70267314542a7c29426 | 17:12 |
| apw | Author: Chris Wilson <chris@chris-wilson.co.uk> | 17:12 |
| apw | Date: Thu Sep 30 11:46:12 2010 +0100 | 17:12 |
| apw | drm: Move the GTT accounting to i915 | 17:12 |
| apw | 17:12 | |
| apw | Only drm/i915 does the bookkeeping that makes the information useful, | 17:12 |
| roadmr | apw: that commit info is really useful, thanks !! it'll let me redefine the test that relied on gem_objects | 17:14 |
| roadmr | I really appreciate it, thanks :) | 17:15 |
| wendar | Bug #735601 (requested by apw) | 17:18 |
| ubot2 | Launchpad bug 735601 in linux "[STAGING] Eee PC 1015PEM unstable on 2.6.38-6-generic" [Undecided,New] https://launchpad.net/bugs/735601 | 17:18 |
| apw | wendar, any idea what 'crap' you have loadded ? | 17:19 |
| wendar | apw: it's a pretty bare install | 17:20 |
| wendar | started as a fresh Maverick 10.10 in Dec | 17:20 |
| apw | wendar, sorry your panic is taineded 'crap' which means you have staging drivers loaded | 17:20 |
| wendar | what would fall under 'crap'? Broadcom wireless drivers? | 17:21 |
| apw | wendar, the proprietry drivers taint you 'P' which you are also so tainted | 17:21 |
| wendar | where would I look for 'crap'? | 17:21 |
| apw | wendar, i think you have something odd going on | 17:22 |
| apw | as you have wl(P) and brcm80211(C) both listed in your modules | 17:22 |
| wendar | that would be nice | 17:22 |
| wendar | (if it's unique to this install) | 17:23 |
| apw | hmmm mine is the same and no issues. | 17:23 |
| apw | wendar, ok ... so is it always in intel_idle when it tanks ? see the RIP: line in your dump | 17:23 |
| wendar | I'm not sure (haven't been taking screenshots each time), but I suspect so | 17:24 |
| apw | wendar, if that is a common one you could try booting with intel_idle.max_cstate=0 a | 17:24 |
| apw | and see if that helps | 17:24 |
| === sforshee is now known as sforshee-lunch | ||
| wendar | do you recommend adding that to /etc/default/grub? | 17:27 |
| apw | wendar, well if it works you will only be booting once more forever :) but likely so | 17:28 |
| wendar | okay, will try, thanks | 17:28 |
| === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - March-22 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| ogasawara | apw, bjf: intel patsburg device id patch pushed to natty master-next | 18:12 |
| bjf | ogasawara, thanks | 18:12 |
| apw | ogasawara, AceLan_ | 18:13 |
| apw | ogasawara, ack even | 18:13 |
| apw | ogasawara, drop after .38 :) fixed it up | 18:14 |
| ogasawara | apw: bah, thanks | 18:14 |
| * apw is about to upload a .38 final kernel, anyone got anything else they think is pending for natty | 18:17 | |
| smb | apw, There should be a fix for the fix (polarity for irq0) but that seems still underway and not in upstream | 18:33 |
| apw | smb, got any pointers to that? | 18:37 |
| smb | apw, There was a mail submitted which I could fw to you | 18:38 |
| smb | apw, sent | 18:39 |
| apw | smb thanks | 18:39 |
| cking | smb, that was a quick turnaround, - was that a fix from AMD | 18:46 |
| smb | cking, Yep, someone on linux-acpi posted his regression and Andreas fixed it up | 18:47 |
| smb | cking, So yes, AMD | 18:47 |
| cking | yay | 18:49 |
| apw | smb, is there any discussion that that is not final? it sounds pretty ready | 18:52 |
| smb | apw, Well, it was only tested to solve the regression | 18:53 |
| apw | smb, whats your recommendation, in or out for the next upload ... | 18:55 |
| smb | apw, I would rather tend to in. There was some more xplanation on the linux-acpi thread and is seemed good. Without it you got a regression of fans being always on | 18:57 |
| apw | smb, OUCH yep i'll suck that up me thinks | 19:01 |
| mjg59 | Turns out HP still can't write firmware | 19:01 |
| mjg59 | This bug's been there since *2005* | 19:01 |
| smb | Some cannot set the irq override correctly the other mess up with the polarity. Writing firmware that complies to the acpi spec seems really hard | 19:03 |
| apw | mjg59, why does that not supprise me | 19:03 |
| mjg59 | apw: They have code that explicitly reads the pin 2 config from the apic and then changes the thermal trippoints | 19:04 |
| apw | nnng | 19:05 |
| * apw decides the right to bear arms may have its uses | 19:05 | |
| cking | heh | 19:06 |
| mjg59 | apw: Amazingly, they're considerate enough to set the trip temperature to the minimum temperature that Windows 98 will accept without red screening | 19:07 |
| cking | mjg59, so you refer to "they have code that explicitly reads the pin 2 config" - you disassembled the firmware to find this out? | 19:07 |
| mjg59 | In the ACPI table, yeah | 19:08 |
| mjg59 | So less heroic | 19:08 |
| cking | oh - that's not so bad ;-) | 19:08 |
| apw | mearly enough to make you need a shower | 19:09 |
| cking | if I got a dollar for each DSDT I read... | 19:10 |
| apw | cking, you might be able to afford half your extension ? | 19:10 |
| kamal | cking: ... the DSDT would be buggy and you'd only end up getting $0.10. | 19:10 |
| cking | heh | 19:11 |
| JFo | .10 more than he had :) | 19:23 |
| bjf | apw, your push to talk appears to be stuck | 19:37 |
| cking | it's very enlightening | 19:37 |
| * jjohansen -> lunch | 19:42 | |
| apw | bjf, yeah its not so much stuck as i forget that skype doesn't need it :/ | 19:56 |
| bjf | apw, hehe | 19:56 |
| apw | not a conversation i wanted to be having at all, let alone in public :) | 19:56 |
| kamal | apw: approximately when will the natty 2.6.38 final kernel be pushed to master? (today or not today?) | 20:12 |
| apw | kamal, oh whats there (master-next) is at most one commit short i think, once my builds complete i'll be pushing it to master | 20:14 |
| kamal | apw: oh I'll just wait for the "official" master push then ... thanks. | 20:14 |
| TeTeT | apw: will the new version also make it to the lucid backports ppa? | 20:19 |
| === smb` is now known as smb | ||
| apw | TeTeT, yep, it should, the last one didn't make it cause of compiler issues | 20:19 |
| TeTeT | apw: great :) Eager to test it. Even though on desktop machines ... | 20:20 |
| jbicha | hi I was trying to troubleshoot my laptop's hotkeys, several of which don't work but I can't even get the scankey produced to show up | 20:44 |
| sforshee | jbicha, it depends on the specific driver whether or not scancodes are reported | 20:46 |
| sforshee | do you happen to know what driver is used for your machine's hotkeys ? | 20:46 |
| jbicha | sudo /lib/udev/findkeyboards reports AT keyboard: input/event3 | 20:47 |
| sforshee | does anything get reported for your working hotkeys on that device ? | 20:48 |
| jbicha | yes, I get codes when I do sudo /lib/udev/keymap -i input/event3 | 20:50 |
| sforshee | but nothing at all for the non-working keys? Or are the keycodes just wrong? | 20:51 |
| jbicha | I get nothing for the "media player" button and I get Alt and F7 for the brightness-up button for instance | 20:52 |
| jbicha | *I mean Fn and F7 | 20:53 |
| jbicha | oops, I get nothing for the non-working Fn combinations either | 20:55 |
| sforshee | I'm a little confused -- do the media player and brightness up buttons work or not ? | 20:56 |
| sforshee | sometimes there's a secondary device for hotkeys, and sometimes the hotkeys even show up on two different devices | 20:56 |
| jbicha | no, they don't work and I haven't been able to figure out the scankey they produce | 20:57 |
| sforshee | jbicha, what machine is this ? | 21:01 |
| jbicha | Toshiba Satellite L305 | 21:02 |
| sforshee | jbicha, does 'lsmod | grep toshiba_acpi' give anything ? | 21:10 |
| jbicha | sforshee: no | 21:13 |
| sforshee | hrm, that's funny, because the AT keyboard driver seems to normally emit scancodes | 21:14 |
| jbicha | should I try to enable toshiba_acpi ? | 21:16 |
| sforshee | no, I just suspected that's where the key events were coming from | 21:16 |
| sforshee | this is probably a bit much to debug over irc, I'd suggest opening a bug in launchpad if you want to pursue further | 21:17 |
| sforshee | one other thing you could try is grepping dmesg for lines containing "Unknown key", which the AT keyboard driver will sometimes produce | 21:20 |
| sforshee | jbicha, iirc keymap ignores scancode without a keycode, so that might actually be why you don't see anything | 21:23 |
| sforshee | input-events (from the input-utils package) dumps all the events from the device, so it might be more informative | 21:24 |
| jbicha | dmesg hasn't produced any output for keypress and input-events doesn't show anything for the nonworking keys either | 21:27 |
| sforshee | okay, filing a bug is probably your best bet then | 21:29 |
| jbicha | thanks for your help, filed as bug 735756 | 21:32 |
| ubot2 | Launchpad bug 735756 in linux "Toshia Satellite L305 hotkeys not working" [Undecided,New] https://launchpad.net/bugs/735756 | 21:32 |
| lool | apw: Hey, I was wondering whether you plan to switch to the upstream linux tarball for future linux uploads now that .38 is released upstream? | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!