=== kamalmostafa is now known as kamal | ||
=== nickde is now known as Guest69444 | ||
RAOF | Oh, bah. Stupid broken mainline builds. | 06:01 |
---|---|---|
* smb crawls in | 06:55 | |
* RAOF waits to ambush apw. | 07:15 | |
smb | RAOF, He probably saw that. :) | 07:15 |
RAOF | smb: I know. You need to properly prime the target for a psychological ambush. | 07:16 |
smb | Giving time to don all armor does not seem like a good move before attacking... :-P | 07:17 |
RAOF | No. Now, apw will dread the moment he needs to say something in #ubuntu-kernel, premtively flinching for the pile of work that will be dropped upon him! | 07:18 |
smb | Reminds me of the rumors about a 24hrs notice before committing a crime to the victim (unverified to be thought of or done in TX) | 07:18 |
smb | RAOF, On the "good" side, we should have a whole bunch of QA analysts in London this week. :-P | 07:20 |
RAOF | Ah, really? What sprint's happening there? | 07:20 |
smb | Something with QA | 07:20 |
smb | CoP and DA | 07:21 |
smb | wth | 07:21 |
ppisati | morning | 07:59 |
abogani | ppisati: morning | 08:08 |
* smb wonders into which hole apw fell... | 09:21 | |
RAOF | apw: Could you give the drm-intel kernel builds a kick? I'm mainly interested in 1519b9956eb, ed10fca9c351c83, and de842eff410. | 09:25 |
apw | RAOF, will have a look | 09:29 |
apw | smb, in the office is all | 09:29 |
smb | apw, Ah, that explains mumble (and the general silence as there is probably a queue of broken laptops as usual) | 09:31 |
apw | heh :) | 09:31 |
=== Guest15357 is now known as lag | ||
=== lag is now known as Guest98318 | ||
=== yofel_ is now known as yofel | ||
=== nickde is now known as Guest47227 | ||
Guest47227 | does anyone know how to include some custom files in the linux-headers package after building a kernel with ubuntu-package ? I have some extra .so files build under tools/gcc (gcc plugins) but they don't get included in the headers .deb so I have to move them from the build dir manually after installing it. How can I include them in the package? | 11:44 |
* ppisati -> out to get some foood | 11:46 | |
siji | apw, hi | 12:50 |
siji | hi all | 13:16 |
siji | am trying to build 2.6.38-omap kernel (ubuntu natty) | 13:16 |
siji | for Touchscreen support (ads7846) | 13:16 |
siji | And downloaded the source code from ubuntu | 13:16 |
siji | but while doing menuconfig , this driver is not visible | 13:17 |
siji | then I have added this driver manually in .config | 13:17 |
siji | but its not building the module | 13:17 |
siji | any one can tell me where am wrong ? | 13:18 |
siji | http://paste.debian.net/126389/ | 13:20 |
siji | my .config file is there | 13:20 |
smb | siji, When you use the ubuntu source you should do a "debian/rules editconfigs" That modifies the config in debian.ti-omap4 which is used for the builds | 13:22 |
siji | smb, if am building only specific module then ? | 13:26 |
siji | same method have to follow ? | 13:26 |
smb | siji, Not exactly. But on the other hand it might be better to do complete builds because that gives you a package to install which can have a unique version number, too. Also it makes sure the module version matches up with the rest of the kernel. But I know that at least building on arm is not that quick | 13:32 |
tgardner | sconklin, herton: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813026/comments/2 | 13:33 |
ubot2 | Ubuntu bug 813026 in linux "CVE-2011-1020" [Undecided,Fix committed] | 13:33 |
siji | ya i got your point , cose of the time am trying to build only the module | 13:34 |
herton | tgardner: hmm ok, may be we have to revert the fix on lucid and everyone else. I'll mark the tracking bug with the regression found | 13:36 |
tgardner | herton, I pushed the revert for Lucid. I don't know that its required on newer kernels. | 13:36 |
herton | ok | 13:37 |
jwi | tgardner: maverick-proposed needs the revert as well, bug 827198 | 14:17 |
ubot2 | Launchpad bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,Confirmed] https://launchpad.net/bugs/827198 | 14:17 |
tgardner | jwi, noted.\ | 14:17 |
jwi | I guess 827208 & 825207 are dups | 14:19 |
tgardner | jwi, hmm, dunno about 825207. its possible. | 14:23 |
apw | tgardner, did i break it | 14:33 |
apw | tgardner, and if you are reverting, be nice if they are Reverts: | 14:33 |
tgardner | apw, it certainly did on Lucid. still working on Maverick | 14:34 |
apw | tgardner, bah ... | 14:41 |
tgardner | apw, I had a clean bisect on Lucid, so I'm reasonably sure its the right commit. | 14:42 |
apw | tgardner, fair enough indeed. i'll have to test that the reverts do the right thing | 14:43 |
tgardner | apw, lucid master-next has the revert. I built that kernel as well as the bisect kernel with that reverted. both fixed the lockup. | 14:44 |
apw | tgardner, sheet ... will have a look | 14:46 |
ogasawara | ## | 14:59 |
ogasawara | ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting | 14:59 |
ogasawara | ## | 14:59 |
herton | tgardner, apw: hardy update has the same cve fix, because of the regression we put it on hold now (bug 823912) | 15:00 |
ubot2 | Launchpad bug 823912 in linux "linux: 2.6.24-29.93 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/823912 | 15:00 |
tgardner | herton, does chromium even run on Hardy ? | 15:01 |
herton | tgardner: no idea. is this specific to chromium, or more a general issue? | 15:02 |
tgardner | herton, its likely generic, but chromium appears to be the most commonly used reproducer. | 15:03 |
* ogasawara back in 20 | 15:15 | |
Sarvatt | ogasawara: is it normal makedumpfile fails on the ubuntu-p kernel? i had to set no_dumpfile=1 to build it | 15:35 |
ogasawara | Sarvatt: I had to do the same. it appears makedumpfile doesn't like the newer kernel version, but I haven | 15:36 |
ogasawara | 't dug much deeper into it | 15:36 |
ppisati | maint-startnewrelease is failing for me | 15:53 |
ppisati | http://pastebin.ubuntu.com/667427/ | 15:53 |
ppisati | i think it cannot find linux-image-3.0.0-1201-omap4_3.0.0-1201.5_armel.deb | 15:54 |
ppisati | any way to force it? | 15:54 |
ppisati | (got a new BSP update from agreen so so i was rebasing...) | 15:54 |
tgardner | ppisati, can you just run 'fdr startnewrelease' ? | 15:54 |
ppisati | tgardner: good idea :) | 15:55 |
cnd | sforshee, awesome work on alps! | 16:10 |
sforshee | cnd, thanks! | 16:10 |
cnd | I want to ask you about your possibilities for reporting | 16:11 |
sforshee | still got a lot of work to do to get everything in shape | 16:11 |
cnd | I think I understand what alps is reporting | 16:11 |
cnd | and I understand option 1 | 16:11 |
cnd | but I can't figure out what option 2 is | 16:11 |
cnd | could you restate it? | 16:11 |
sforshee | so you understand that the projection of a touch point could set multiple bits in each of the bitfields? | 16:12 |
cnd | yeah | 16:12 |
sforshee | I could estimate the width by counting the number of bits that are set | 16:12 |
sforshee | and estimate the touch point to be in the middle of the range of set bits | 16:13 |
sforshee | does that make more sense? | 16:13 |
cnd | you could do that if there's only one touch | 16:13 |
cnd | but what if there are multiple? | 16:13 |
sforshee | then there are multiple groupings of set bits, as long as the fingers aren't too close together | 16:14 |
cnd | yeah | 16:14 |
sforshee | if they are too close together, I have to do a little guessing, like assuming the contacts are of equal size | 16:14 |
cnd | oh, I think I see what you are saying | 16:15 |
sforshee | I know how many contact points are represented in the bitmaps | 16:15 |
cnd | you'll try to figure out the center positions | 16:15 |
cnd | and the widths | 16:15 |
sforshee | yep | 16:15 |
cnd | and that's how it's different than option 1? | 16:15 |
sforshee | yes, for option 1 I'd only take the extremities and use that to create points for a bounding box | 16:15 |
cnd | ok | 16:15 |
cnd | sforshee, what do you get with three touches? | 16:16 |
cnd | do you get three sets of X and Y bits set? | 16:16 |
cnd | potentially up to three, that is | 16:16 |
sforshee | I still need to experiment with that, but that's my assumption | 16:16 |
cnd | ok | 16:17 |
sforshee | I think any bits that are "covered", so to speak, will be set | 16:17 |
cnd | yeah | 16:17 |
cnd | that makes sense | 16:17 |
cnd | so how to report that best... | 16:17 |
cnd | sforshee, I think you should use SEMI_MT | 16:18 |
cnd | and report only the min and max X and Y values | 16:18 |
cnd | but try to get the "center" of the extreme bits | 16:18 |
sforshee | so option 1 then? | 16:18 |
sforshee | ah, halfway between 1 and 2 | 16:18 |
cnd | yeah | 16:18 |
cnd | so if you have an X axis like: 00110000111000 | 16:19 |
sforshee | if I'm doing that work I might as well report width though, as I'll already have it | 16:19 |
cnd | then report half way between the first two '1's and in the middle of the second group of '1's | 16:19 |
cnd | sure | 16:19 |
cnd | well... | 16:19 |
cnd | actually, I wouldn't | 16:19 |
cnd | because of the tricky aspect of SEM_MT | 16:19 |
cnd | you don't know which bits correspond to which touches | 16:19 |
cnd | if you have two groups in both the X and Y directions | 16:20 |
cnd | you don't know if the touches are in corners 1 and 3 or 2 and 4 | 16:20 |
sforshee | yes, that's true, unless I'm able to figure it out from the absolute position data in the first packet, but I'm still unsure about that | 16:20 |
cnd | and evdev reports widths in a circular sense, so unless you can match up the X and Y directions the widths may not be correct | 16:21 |
cnd | yeah, I wouldn't try to figure it out | 16:21 |
sforshee | okay, makes sense | 16:21 |
cnd | that's too much to be doing in the driver | 16:21 |
cnd | at least at first :) | 16:21 |
cnd | and userspace could potentially do it | 16:21 |
cnd | though width values couldn't be calculated after the fact in userspace | 16:21 |
cnd | but as soon as you go from two to three touches, then you're screwed | 16:22 |
sforshee | all right, that's what I'll do then | 16:22 |
sforshee | thanks! | 16:22 |
cnd | you could match up one position | 16:22 |
cnd | but you don't have enough info for the other two | 16:22 |
cnd | sforshee, I'm so glad we're getting alps going! | 16:22 |
sforshee | yeah, it would only work for 2 fingers anyway | 16:22 |
sforshee | cnd, I'm not sure what's going to happen when we start trying this on more hardware though | 16:23 |
sforshee | the initialization is still pretty opaque | 16:23 |
cnd | sforshee, when you report values, I would linearly multiply the low-res stuff up to the high-res range | 16:23 |
sforshee | it may not be right for all hardware of this type | 16:23 |
sforshee | yeah, that was my plan | 16:23 |
cnd | so it's the same range between ABS_X and ABS_MT_POSITION_X | 16:23 |
cnd | yeah | 16:23 |
cnd | sforshee, I would suggest making a dkms and trolling for testers in one of the ALPS bugs on LP | 16:24 |
sforshee | will do | 16:24 |
cnd | they're like a honeypot, and you'll be treated like a king :) | 16:24 |
sforshee | you'd think, but I've only had a few testers for the elantech stuff | 16:24 |
cnd | really... | 16:24 |
cnd | that surprises me | 16:25 |
sforshee | me too | 16:25 |
sforshee | people are happy to complain, not so happy to test it seems | 16:25 |
cnd | did elantech have anything better than PS/2 emulation? | 16:25 |
cnd | before you worked on it? | 16:25 |
sforshee | not for the third-generation of their hardware | 16:25 |
cnd | k | 16:26 |
sforshee | I'm going to send those patches to linux-input in the next couple of days | 16:26 |
cnd | awesome! | 16:27 |
cnd | sforshee, please CC me when you do | 16:27 |
cnd | not a big deal if you forget though | 16:27 |
sforshee | I'll try to remember :) | 16:27 |
cnd | I'm subscribed and I'll see them one way or another | 16:27 |
ogasawara | ## | 16:50 |
ogasawara | ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting | 16:50 |
ogasawara | ## | 16:50 |
ogasawara | meeting's about to start ... | 16:59 |
Daviey | ppisati: There were a few server arm issues raised last week.. are you the contact for that? | 17:02 |
ppisati | Daviey: ah, the lxc stuff? sorry, i just came back from vacation | 17:02 |
ppisati | Daviey: i'll queue it up for the next arm report | 17:03 |
ppisati | btw, my usb stopped working... cool... | 17:03 |
Daviey | ppisati: There was iscsi support being missing aswell, which was a concern | 17:03 |
jjohansen | Daviey: stefan had lxc running on an arm kernel at the sprint | 17:03 |
Daviey | jjohansen: Oh great! via libvirt? | 17:03 |
ppisati | jjohansen: yep, he told me but i forgot to say it in the report :P | 17:04 |
jjohansen | he said the kernel was good but there where some user space issues | 17:04 |
Daviey | eek, i should have kept quiet | 17:04 |
jjohansen | Daviey: I don't think it was via libvirt | 17:04 |
smb | Not sure what lxc-tools using | 17:08 |
smb | Stephane was the one doing the user-space side | 17:08 |
jjohansen | smb: yep | 17:08 |
smb | And as far as I know the issues there are resolved | 17:08 |
jjohansen | hrmm, well hopefully, though I that he was using lxc-exec instead of lxc-start | 17:09 |
jjohansen | but I could be wrong | 17:09 |
smb | Hm, thought both | 17:10 |
ogasawara | sconklin: going forward for the meetings, would you prefer to just combine the "Status: Stable Kernel Team" and "Security & bugfix kernels" topics? | 17:10 |
ppisati | last time i check, lxc-config (??? don't remember the name of the user land tool that checks lxc kernel compatibility) complained about a deprecated option | 17:10 |
smb | Cause he pulled in a whole chroot env | 17:10 |
jjohansen | smb: oh maybe, I remember catching the bit about lxc-exec and then finding some of the problems so by the end maybe | 17:10 |
ppisati | s/check/checked/ | 17:10 |
jjohansen | smb: ah I missed that | 17:11 |
smb | ppisati, When we tried (with some other options enabled) there was only config_cgroup_freeze missing | 17:12 |
smb | and the userland tool crashed | 17:12 |
smb | because of a personality check | 17:12 |
sconklin | ogasawara: yeah, there's no sense in breaking out a one-line link as a separate agenda item | 17:12 |
ogasawara | sconklin: agreed. | 17:12 |
ppisati | smb: uhm ok | 17:13 |
ogasawara | bjf: ^^ might want to update your runes file for the meetings... | 17:13 |
smb | ppisati, Well anyway, next kernel should be ok and lxc tools saw several uploads last week :) | 17:13 |
smb | Beside of running with one cpu was faster than with two, things looked promising so far... | 17:14 |
ppisati | smb: the smp looks really nasty | 17:15 |
ppisati | smp bug | 17:15 |
* ppisati is really tired... | 17:15 | |
* smb nods | 17:15 | |
smb | ppisati, And all the useful tools seem to be missing on arm | 17:15 |
smb | Like perf or latencytop... | 17:15 |
cking | that's not fun | 17:16 |
smb | ppisati, Someone (jjohansen you remember his name? rob something?) noted that cache invalidation may be a problem... | 17:18 |
ppisati | smb: imo it could be everything | 17:19 |
ppisati | smb: from affinity, to timers, to $whatever... | 17:19 |
* smb thinks we need someone with a jtag and not being afraid to use it | 17:20 | |
jjohansen | smb: no I don't remember but he was the Calxeda guy | 17:20 |
ppisati | i've jtag and i know how to use it | 17:20 |
jjohansen | he said that the smp cache snoop/invalidate on A8 and A9 where extremely slow | 17:21 |
tgardner | jjohansen, Rob Herring ? | 17:21 |
smb | Could be. At least I think I remember the Rob part | 17:21 |
jjohansen | yeah I think that was it | 17:22 |
jjohansen | yep, it was | 17:22 |
jjohansen | ppisati: one way you could test that theory is do some parallel compute, and for one test make sure its hitting different areas of mem/cache alignment and for another shared data | 17:24 |
* jjohansen doubts that the slow cache is the responsible for the problem | 17:25 | |
cking | it's one of those bugs that you need to figure out a way to exercise it and then use JTAG to see what's really going on | 17:26 |
ppisati | jjohansen: sounds like a time-attack | 17:26 |
jjohansen | ppisati: yeah | 17:27 |
ppisati | imo it's something simpler but yes, trimming it down to the simplest case is the first step | 17:27 |
ppisati | so i can follow the code/call path and see what's different in the single vs dual cpu case | 17:28 |
smb | Though the hdparm run is quite simple, I guess there is still multiple things involved | 17:29 |
ppisati | yep | 17:30 |
ppisati | uhm | 17:38 |
ppisati | but if the bug is still there even when a cpu is hotplugged, how can it be an smp scheduling bug? | 17:39 |
smb | ppisati, I was suspecting the way or what timers are used | 17:39 |
ppisati | a good trace could be to see what's the difference between single cpu and smp-with-one-cpu only | 17:40 |
smb | Even when hut-unplugging one cpu, it is different from what is used when starting only with one | 17:40 |
ppisati | yep, but nothing is scheduled on the second cpu | 17:40 |
smb | right | 17:40 |
ppisati | because it's not there anymore (modulus bug) | 17:40 |
smb | well /proc/interrupts does look different (in the ipi section) | 17:41 |
smb | which still shows two entries... | 17:41 |
ppisati | ah | 17:42 |
sconklin | Is it possible to use virtualbox or any other vm tools to boot entire SATA drives in a VM? I have a machine with a swappable SATA drive bay, and I'd like to be able to boot entire test disks | 17:48 |
sconklin | anyone know? | 17:48 |
jjohansen | sconklin: look for pci device passthrough for kvm | 17:54 |
sconklin | jjohansen: thanks | 17:54 |
jjohansen | sconklin: I know its possible just haven't done it myself | 17:54 |
sconklin | That's just the kind of pointer I was looking for | 17:55 |
jjohansen | sconklin: I did do it years ago with vmware so I know its possible there too | 17:55 |
sconklin | Yeah, I'm done it with VMWare in the past | 17:55 |
CarlFK | have you tried: qemu -hda /dev/hdb | 17:57 |
CarlFK | er.. | 17:57 |
sbeattie | sconklin: http://www.virtualbox.org/manual/ch09.html#rawdisk indicates its possible with virtualbox, too. | 17:57 |
CarlFK | have you tried: qemu -hda /dev/sdb | 17:57 |
sconklin | haha typical Linux "there are three ways to do it" response. Thanks! | 17:58 |
sbeattie | sconklin: hehe, you get to pick your poison. :-) | 17:59 |
sconklin | sbeattie: Oh, I like any option that warns me about total loss of data in a Big Red Box! | 17:59 |
tgardner | herton, the mystery deepens: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/827198/comments/4 | 18:00 |
ubot2 | Ubuntu bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,In progress] | 18:00 |
* tgardner is back in an hour or so | 18:01 | |
=== tgardner is now known as tgardner-afk | ||
herton | tgardner-afk: strange indeed | 18:02 |
CarlFK | sconklin: from #qemu: balrog-k1n: i've done something like this many times, but usually added -snapshot to avoid the VM writing to the physical disk | 18:05 |
sconklin | CarlFK: ok, I'll check that also | 18:06 |
sconklin | thanks | 18:06 |
CarlFK | welcome | 18:07 |
herton | tgardner-afk: checking here commits, I suspect we need also "76597cd proc: fix oops on invalid /proc/<pid>/maps access" backported to maverick and others | 18:25 |
stickyboy | I'm starting to sense something fishy with kernel-package's `make-kpkg` in 11.04. The headers package it generates is behaving inconsistently. | 18:39 |
* ogasawara lunch | 18:55 | |
=== Guest98318 is now known as lag | ||
=== lag is now known as Guest67514 | ||
=== tgardner-afk is now known as tgardner | ||
tgardner | herton, while we may need 76597cd, I'm not sure its related to the chromium hangs. | 19:36 |
mfilipe | sforshee, fuuuuuuuuuuuuuuuuuu | 19:40 |
mfilipe | more 1 year to solve the bug :( | 19:40 |
mfilipe | +1 year* | 19:40 |
cr3 | anyone happen to know how to parse the MODALIAS strings in the output of udevadm info --export-db? | 19:41 |
herton | tgardner: indeed. but other guy came in the bug reporting a oops that I think 76597cd will fix. I think would be worth giving them a test build with it, and we should have that backported anyway | 19:41 |
tgardner | herton, ack. | 19:41 |
sforshee | mfilipe, every time there's a patch that fixes it something else gets broken, and that's a big part of why it's taken so long | 19:42 |
tgardner | herton, ok, I'll have a look at backporting that commit and getting some test kernels advertised. | 19:43 |
herton | ok, cool | 19:44 |
mfilipe | sforshee, thanks again for you effort to fix the problem but I think that it will get some months again :( | 19:47 |
tgardner | ogasawara, you might as well clone P into the ubuntu directory on zinc. that way we won't have to change | 20:01 |
tgardner | sources later | 20:01 |
ogasawara | tgardner: ack | 20:25 |
jjohansen | rebooting | 21:01 |
=== yofel_ is now known as yofel | ||
=== Quintasan_ is now known as Quintasan | ||
txomon | hello is there anyone that can explain me this? | 23:33 |
txomon | man 3 va_end in /va_dcl | 23:34 |
txomon | apw, can you help me? | 23:35 |
txomon | is there anyone there? | 23:45 |
bryceh | txomon, past EOD for most kernel folk I think | 23:45 |
txomon | Its about a strange C syntax, that I can't understand.. | 23:46 |
txomon | do you know what it means? | 23:46 |
txomon | !EOD | 23:47 |
ubot2 | Factoid 'EOD' not found | 23:47 |
txomon | bryceh, do you know what it means? | 23:48 |
bryceh | txomon, "End of Day" i.e. they're not in work hours | 23:50 |
txomon | ah xD ok ty | 23:51 |
bryceh | most kernel guys are in US or European time zones | 23:54 |
jjohansen | txomon: va_end is weird | 23:55 |
jjohansen | txomon: what are you looking for? | 23:56 |
txomon | im looking for the meaning of that va_dcl there in the middle | 23:57 |
txomon | C syntax | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!