| === ericm_ is now known as ericm|ubuntu | ||
| === rsalveti` is now known as rsalveti | ||
| ppisati | morning * | 08:22 |
|---|---|---|
| smb | morning | 08:23 |
| abogani | morning | 08:25 |
| * jk- tips hat | 08:27 | |
| smb | jk- is wearing hat in summer? ;) | 08:28 |
| iceroot | we have a working patch for this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502 | 08:28 |
| jk- | there are hats for all seasons! | 08:28 |
| ubot2 | Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed] | 08:28 |
| iceroot | what is the common way? wating until it is upstream? or directly patching ubuntu-kernel? | 08:28 |
| smb | iceroot, Usually the preferred way is to at least wait until it appears upstream, yes. On critical issues that may be accelerated, if it looks like the maintainer is ok with it. | 08:30 |
| iceroot | smb: ok | 08:31 |
| smb | If you send an email that points to the patch, gives some background where it comes from and what the upstream status is to kernel-team mailing list (and for what release it is) it is possible to look at it | 08:32 |
| iceroot | smb: so kernel-team is normally "only" reacting on mails not on launchpad-bugs? | 08:32 |
| iceroot | ubuntu-kernel-team | 08:32 |
| smb | iceroot, It is simpler because bug email just floods in. Easy to miss things there | 08:33 |
| smb | If there is a single developer already assigned, then its a bit different | 08:33 |
| iceroot | smb: thank you for the info, i will send a mail to last list | 08:34 |
| smb | iceroot, Thanks | 08:34 |
| apw | alexbligh, ahh yes it is possible we moved to linux, following linus | 08:49 |
| apw | alexbligh, i must admit my personal linux-linus tree i use for close bases is taken from kernel.org | 08:49 |
| * apw yawns | 08:51 | |
| jk- | ey apw | 08:54 |
| apw | jk-, dude | 08:54 |
| ppisati | who decides which pkg go into a release? i mean | 09:16 |
| ppisati | the preinstalled image for omap4 from friday is stil using the onerici kerne (3.0.0.12) | 09:16 |
| ppisati | while P/master has moved to... | 09:17 |
| ppisati | 3.2.x | 09:17 |
| ppisati | to whom shall i talk? | 09:17 |
| ppisati | BTW 3.0.0.x has bug for the beagle xm rev c (and the same bug doesn't show up on latest kernel that's why i would like to use an updated kernel) | 09:18 |
| ppisati | and there's no ogra around when you need one... | 09:18 |
| ppisati | :) | 09:18 |
| apw | smb, yeah we don't have lbm yet, and won't for some time i suspect | 09:31 |
| apw | will confirm it is turned off in meta, which it should be, and probabally let leann make it | 09:32 |
| smb | apw, Ah ok. Makes sense. | 09:32 |
| jibel | we get bug 894768 during automated iso testing of Precise images. Could one have a look ? | 09:41 |
| ubot2 | Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [Undecided,Incomplete] https://launchpad.net/bugs/894768 | 09:41 |
| smb | jibel, I try to look into it. There are not too many kernel errors on a quick first glance, though. Btw, do you know what xvda2 should be? extended partition? | 09:49 |
| jibel | smb, correct, extended partition. | 09:53 |
| smb | jibel, ok thanks. Was one message I did see. But that being unknown type for the os prober sounds ok | 09:54 |
| brendand | apw - hi | 10:04 |
| apw | brendand, HI | 10:05 |
| brendand | apw - have you been following : https://lists.ubuntu.com/archives/kernel-team/2011-November/017938.html ? | 10:06 |
| apw | brendand, i have seen some of the discussion yes | 10:12 |
| brendand | apw - any thoughts on what could be left out of the list? | 10:13 |
| === smb` is now known as smb | ||
| apw | brendand, i think the dimensions shown make sense, video, audio, webcam, etc | 10:16 |
| apw | brendand, those seem to be the ones we'd have an issue against, perhaps video(ati) video(intel) might be useful | 10:17 |
| apw | brendand, beyond that i think you are talking specific devices, and only a full list is of use | 10:17 |
| apw | (not sure if that answers what you are asking) | 10:17 |
| apw | brendand, the things which seem to be 'x' seem uninteresting in the main, perhaps some of the touchpads are interesting, but again most likely i care about one specific one | 10:19 |
| brendand | apw - but is it worth testing all of the different touchpads in general? | 10:21 |
| apw | brendand, i read teh email as asking about categories one might with to test against, so "i have a patch which does this can you test it on as many relevant machines" | 10:25 |
| brendand | apw - so, the scope of this is that we come up with a list of device categories for which we want at least one system with each device of that category in our testing pool | 10:26 |
| apw | is this a pool of machine to automatically test against? | 10:27 |
| apw | if so then no input device is relevant i guess | 10:27 |
| brendand | apw - best to assume they could also be manually tested | 10:28 |
| apw | the problem with both touchpads and wifi, is there are 100s of each, you're not going to cover the whole spectrum | 10:29 |
| brendand | apw - no, but we can test all the ones we have in house | 10:29 |
| brendand | apw - take a 'Memory controller' for example. would we ever want to be testing each different memory controller? | 10:30 |
| apw | brendand, memory controllers are so tied to the CPU type (being built in these days) that you'd more want a range of "platforms", ivybridge, sandybridge, whatever amd calls things | 10:31 |
| apw | (and those are all X on the list already) | 10:31 |
| Q-FUNK | Could the fix provided in bug #892615 please be merged? | 11:06 |
| ubot2 | Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615 | 11:06 |
| apw | BAH I hate it when people ask things and then go away | 12:29 |
| apw | q-funk, we are waiting for someone in the know to ack that the patch is safe for non-geode h/w | 12:29 |
| apw | (not that you will see my reply) | 12:29 |
| _ruben | can't really blame him for pinging out.. ;-) | 12:30 |
| _ruben | well, you can, but might not be fair | 12:31 |
| === yofel_ is now known as yofel | ||
| * cking needs to reboot | 13:54 | |
| ogasawara | apw: thanks for uploading -rc3 and linux-meta | 14:10 |
| tgardner | ogasawara, speaking of uploads, whats going on with armhf? | 14:11 |
| ogra_ | tgardner, we would like to have the entries in debian/control soon :) | 14:12 |
| ogasawara | tgardner: I believe apw was fixing up the control file | 14:12 |
| * ogra_ doesnt think any additional stuff is required atm ... we dont have the builders running yet | 14:12 | |
| tgardner | ogra_, are there functional chroots for armhf yet ? | 14:13 |
| ogra_ | not sure, last update from infinity i had was friday, saying the chroots should be ready and are pending launchpad enablement | 14:13 |
| ogra_ | (which still might take some days) | 14:14 |
| tgardner | ogra_, ok, I was just noticing uploads from him referencing armhf | 14:14 |
| ogra_ | right, we need to make the packages that dont have hf as target arch in debian/control aware of that arch | 14:14 |
| ogra_ | theye uploads are mainly doing that one line change i guess | 14:15 |
| tgardner | ogra_, right, I don't think its too complicated. | 14:15 |
| ogra_ | well, for kernels this is generated, isnt it ? | 14:16 |
| ogra_ | i.e. you need to duplicate the config etc | 14:16 |
| tgardner | ogra_, yes, but its mostly scripted. | 14:16 |
| ogra_ | yeah | 14:16 |
| * herton -> lunch | 14:17 | |
| ogra_ | but still a bit more than doing s/armel/armel armhf/ | 14:17 |
| tgardner | indeed | 14:17 |
| tgardner | cjwatson, if we switch the kernel to 'Depends: crda (>= 1.1.1-1ubuntu2)', can you deal with the main inclusion carnage ? | 14:34 |
| tgardner | p.s. - thanks for fixing the file collision between crda and wireless-regdb | 14:35 |
| apw | ogasawara, no problem, best to get it done early | 14:41 |
| apw | ogra_, i worked with infinity this am to add the armhf stuff; and to tell him about DEB_STAGE1 which he wasn't using | 14:41 |
| apw | tgardner, ^^ | 14:41 |
| tgardner | apw, ack. | 14:42 |
| apw | ogra_, all the config bits were already in it was just the control file change which was missing | 14:42 |
| ogra_ | ah, cool | 14:43 |
| apw | ogra_, in theory we are there, infinity is also going to play with the staged stuff for future | 14:44 |
| ogra_ | yeah, i'm personally more concerned to get the buildds up, armhf *can* run with armel kernels ... its just for getting a properly named deb in the archive | 14:44 |
| Q-FUNK | ogasawara: could the fix to bug #892615 please be merged? | 14:46 |
| ubot2 | Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615 | 14:46 |
| ogasawara | Q-FUNK: I'd like to get more testing on non-geode hw first and I would prefer to see it getting applied upstream as well. | 14:46 |
| brendand | sconklin - hi | 14:59 |
| sconklin | brendand: good day | 15:00 |
| brendand | sconklin - we're looking at an issue with the Lucid -proposed kernel at the moment. afraid we don't have an awful lot of detail right now though | 15:04 |
| brendand | sconklin - we have a server system which was certified with 10.04.3 and now it's halting shortly into testing | 15:05 |
| jsalisbury | op jsalisbury | 15:06 |
| tgardner | brendand, its bjf and herton problem now. have you been able to get a dmesg trace ? | 15:06 |
| sconklin | brendand: While I care (really!), bradf is the stable kernel manager as of UDS - I am doing a rotation in QA. herton is also doing a lot of the stable work | 15:06 |
| jsalisbury | ogasawara, do you know how I get the permissions to become operator, so I can change the channel topic? | 15:06 |
| ogasawara | jsalisbury: hrm, I can't remember the exact process bjf, apw, and I went through to get ops. let me try and dig for more info. | 15:08 |
| jsalisbury | ogasawara, thanks | 15:08 |
| apw | hrmmm i think we started out asking is | 15:08 |
| brendand | sconklin - ah, i didn't know that | 15:09 |
| apw | somehow our channel isn't one of the officially owned ones (an oversight) so it was less straight forward | 15:09 |
| === ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0.0 || Ubuntu Kernel Team Meeting - Tues Nov 29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| ogasawara | jsalisbury: I've gone ahead and updated the topic for you in the mean time | 15:10 |
| jsalisbury | ogasawara, cool, thanks | 15:10 |
| === ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Nov 29 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| herton | brendand, is it a new issue (are you able to freeze the machine with previous kernel, or only on the new kernel?) | 15:29 |
| brendand | herton - as far as we can tell, only with the new kernel. we don't know yet does it happen randomly or whether a test is triggering it | 15:30 |
| brendand | herton - unfortunately the system is in taipei and i don't have access so can't do any investigation right now | 15:31 |
| * ogasawara back in 20 | 15:32 | |
| herton | brendand, ok, would be good if someone is able to check which test freezes, and if there is some oops or other reason for the freeze. May be a bisect will be needed to check what introduced the problem. | 15:33 |
| cjwatson | tgardner: I already dealt with the main inclusion carnage :-) | 15:33 |
| tgardner | cjwatson, cools. thanks. | 15:34 |
| cjwatson | tgardner: mainly by taking the Gordian-knot approach; it's clearly a one-for-one replacement for wireless-crda, so I just promoted it, in trust that wireless-crda will fall out soon enough | 15:34 |
| tgardner | I'll make the change in the ekrnel. | 15:34 |
| cjwatson | that should be fine - the Provides should ensure that old and new kernel packages are still coinstallable | 15:34 |
| cjwatson | it'll have the effect of forcing everyone over to crda, which is what we want anyway | 15:35 |
| tgardner | cjwatson, hmm. this will essentially prohibit running a precise kernel in older user spaces if I make it absolutely dependent on crda. | 15:38 |
| tgardner | maybe I'll leave it 'Depends: wireless-crda | crda' for now. | 15:40 |
| brendand | herton - ok. we'll do more investigation when our lab engineer returns tomorrow morning and keep things up-to-date. when i have a bug number i'll add it to the tracking bug. | 15:46 |
| herton | brendand, ack | 15:48 |
| cjwatson | tgardner: you could flip the dependencies round to indicate the current preference | 15:49 |
| cjwatson | tgardner: although that probably won't cause apt to replace with the newer code | 15:49 |
| tgardner | cjwatson, I was just gonna ask if ordering had an impact. | 15:50 |
| tgardner | if we drop wireless-crda from precise, then dpkg should always select crda, correct ? | 15:50 |
| cjwatson | tgardner: for new installations, yes; that won't cause apt to remove wireless-crda on upgrades, though | 15:59 |
| cjwatson | (it might persuade update-manager to do so) | 15:59 |
| ppisati | if i bump the abi, does it fix the missing module case too? i guess it won't... | 16:01 |
| tgardner | cjwatson, ok, I'll start a bug against update-manager so we don't forget this. since wireless-crda will no longer be maintained, I'd like for it to get removed on upgreade. | 16:01 |
| tgardner | ppisati, nope. | 16:01 |
| tgardner | ppisati, add an ignore.modules to the ABI directory | 16:02 |
| ppisati | and i bump the abi too, right? | 16:02 |
| cjwatson | tgardner: update-manager is the wrong place to fix this - if you want to get rid of it, there needs to be a Conflicts: somewhere | 16:02 |
| tgardner | ppisati, thats not necessarily related. you can drop modules without changing the ABI | 16:02 |
| ppisati | ok | 16:03 |
| cjwatson | it's unfortunate that crda was uninstallable in oneiric | 16:03 |
| tgardner | cjwatson, but that affects the ability to run precise kernels in older user spaces. | 16:03 |
| cjwatson | I know, but still, fixing it in update-manager is an absolute last resort | 16:03 |
| cjwatson | let's not start there | 16:03 |
| tgardner | cjwatson, ok, I'll just leave it be for now. if I see a big crda update I'll consider updating wireless-crda | 16:04 |
| tgardner | I did swap the order so that crda is preferred | 16:04 |
| cjwatson | nothing springs to mind right now, but there may be some tricky way to conflict such that it goes away on precise upgrades but doesn't break older userspaces | 16:04 |
| cjwatson | most things are possible somehow :) | 16:05 |
| tgardner | yeah, yuo'd think this situation has been encountered before | 16:05 |
| cjwatson | we could even SRU wireless-crda to add a crda transitional package or something | 16:05 |
| cjwatson | kind of the reverse of the usual transitional package situation | 16:05 |
| cjwatson | hm, except that doesn't quite work | 16:06 |
| tgardner | cjwatson, perhaps turn the preicse version of wireless-crda into a meta package that depends on crda ? | 16:06 |
| cjwatson | oh, yes, of course, that's the simplest answer isn't it | 16:06 |
| tgardner | ok, I can do that | 16:06 |
| cjwatson | yeah, I recommend that | 16:07 |
| tgardner | ogasawara, can you get that on our list of things to do ? | 16:07 |
| ogasawara | tgardner: yep | 16:07 |
| cjwatson | maybe crda (>= 1.1.1-1ubuntu2) to make sure we don't get bitten by the uninstallability in oneiric | 16:07 |
| tgardner | cjwatson, already done for the kernel. I'll do the same for wireless-crda | 16:08 |
| cjwatson | (crda depended on wireless-regdb but they shipped a common file) | 16:08 |
| cjwatson | great | 16:08 |
| Q-FUNK | ogasawara: there won't be much testing taking place for as long as it's not applied to something that it pushed into the repository... | 16:10 |
| ogasawara | Q-FUNK: I'll be testing locally | 16:11 |
| Razec | Hi guys... | 16:35 |
| Razec | I want to get involved in the Ubuntu Kernel Development. What steps do I take to get involved? | 16:35 |
| Q-FUNK | ogasawara: I assume that we're talking about that one-line fix, mentioned in the bug, that applies the feature only to recent AMD hardware? | 16:38 |
| apw | ppisati, hey, whats the gen on this omap issue, display driver, we know what needs changing | 16:57 |
| apw | ppisati, and is this ti-omap4 ? | 16:58 |
| ogasawara | apw: ah, I see he's sent a patch to the ml | 16:58 |
| ogasawara | ppisati, ogra_: I assume this need uploading asap | 16:59 |
| apw | ogasawara, assuming the release team say yes of course :) | 16:59 |
| ogra_ | ogasawara, agreed ... its just a one option config change in the arm config though | 16:59 |
| apw | ppisati, and we have tested this yes? we know the kernel with just htat option is GOOD | 17:00 |
| apw | ogra_, has anyone tested with the option on, to make sure thats the only change | 17:00 |
| ogra_ | apw, its not working at all without it | 17:00 |
| apw | ogra_, and if changging it doesn't make it work there is no point in uploading and disrupting all the other architectures | 17:00 |
| ogasawara | from ppisati -> "Tested on my Beagle XM." | 17:00 |
| apw | so ... has anyone tested it does work | 17:00 |
| ogra_ | there is a new display driver thats being used by linaro already, we just didnt enable it in our config | 17:00 |
| ogra_ | well, we enabled it as module which apparently doesnt work at all ... so it needs =m to become =y | 17:01 |
| ogra_ | and given the old display driver is gone in favor of the new one .... | 17:01 |
| apw | yep new things become =m by default, if they can be, one assumes they work if they say they can do =m, sigh | 17:01 |
| ogra_ | well, its TI .... | 17:02 |
| l3on | Hi all... does someone know why we don't have a linux image 3.2-rc3 in http://kernel.ubuntu.com/~kernel-ppa/mainline/ ? | 17:05 |
| apw | ogra_, if this patch is accurate, the issue has existed in all the 3.2-rc kernels, ie been in the archive for weeks how have we missed this till today | 17:05 |
| ogra_ | apw, not much testing yet i guess | 17:06 |
| apw | ogra_, if we don't care enough to test it, why are we spinning for it | 17:06 |
| ogra_ | apw, we do, but the last weeks were filled with paperwork and vacations | 17:07 |
| ogra_ | and we are not used to have images before A1 at all | 17:07 |
| ppisati | apw: i just noticed this morning, because i was installing the new preinstalled image from 28th | 17:07 |
| ogra_ | thats a total novum | 17:07 |
| ppisati | apw: the omap images till 25th had a 3.0.x kernel still | 17:07 |
| ppisati | friday i tried a nioghtly build, and it still had the 3.0 kernel | 17:08 |
| ppisati | the funny thing is that i was looking to fix another bug... :) | 17:08 |
| apw | ppisati, hmm, how can that be i wonder, we've had 3.2-rc2 in there for ages | 17:08 |
| ppisati | apw: dunno | 17:09 |
| ppisati | apw: this morning, in this channel, i asked how the images are built | 17:09 |
| ogra_ | meta having been stuck somewhere without anyone noticing ? | 17:09 |
| ppisati | apw: who decides which pkgs go in evbery image | 17:09 |
| ogra_ | ppisati, the meta package | 17:09 |
| ogra_ | live-build pulls in linux-omap by default for the omap image | 17:10 |
| * apw is baffled | 17:10 | |
| ogra_ | so it might be that linux-omap sat in binary new and nobody noticed or that it accidentially went to universe once again and nobody noticed | 17:11 |
| ogra_ | though i had someone last week on IRC who actually complained about the orange screen you were seeing too, but i was swamped in sorting team specs | 17:11 |
| ogra_ | so i didnt dig into it | 17:12 |
| apw | ogra_, maybe universe, thats been a common problem recently | 17:12 |
| ogra_ | yeah, one of the two isuues are the usual ones | 17:13 |
| apw | ogra_, yeah so i think the kernel was out, so installs should have gotten it | 17:13 |
| apw | i suspect we have another issue in image build | 17:13 |
| apw | oh well | 17:13 |
| ogra_ | well, we'll do better next time | 17:13 |
| === bigbash is now known as zz_bigbash | ||
| GrueMaster | apw: As to testing, it comes down to man power. AFAIK, I am the only one really doing any image testing on daily armel images. I am also the only one testing SRU kernels on armel. I am also the only one doing major armel server test automation. I need more of me. | 18:15 |
| apw | yeah we need more testing power | 18:15 |
| GrueMaster | afaik, the testing that linaro does on the kernels is limited to mainly headless automation (I could be wrong, but given the hardware, I doubt it). | 18:17 |
| apw | ogasawara, i've added a annotation for the arm DVI thingy | 18:24 |
| ogasawara | apw: ack | 18:24 |
| * apw wanders to make some food ... | 18:27 | |
| * tgardner follows suit -> food | 18:48 | |
| cking | hrm food | 19:01 |
| apw | cking, yeah food | 19:21 |
| cking | yum | 19:21 |
| herton | apt | 19:27 |
| apw | tsk | 19:34 |
| cking | sigh | 19:40 |
| === zz_bigbash is now known as bigbash | ||
| rik_ | sforshee: can I ask you a question regarding bug 606238? | 20:00 |
| ubot2 | Launchpad bug 606238 in linux "synaptic touchpad not recognized on dell latitude e6510 and others" [Undecided,Confirmed] https://launchpad.net/bugs/606238 | 20:00 |
| sforshee | rik_, sure, go ahead and ask | 20:01 |
| rik_ | sforshee: you ask for the output from input-events for further debugging. When I run that command it returns | 20:01 |
| rik_ | protocol version mismatch (expected 65536, got 65537) | 20:01 |
| rik_ | any idea on how to handle this? | 20:01 |
| rik_ | Note that I'm running on debian testing with the 3.1 kernel | 20:02 |
| rik_ | I've patched the psmouse module | 20:02 |
| sforshee | rik_, you need a newer version of input-events, or else modify the source yourself to remove that protocol version check | 20:02 |
| sforshee | iirc the check was simply removed when this problem surfaced | 20:02 |
| sforshee | rik_, http://www.kraxel.org/cgit/input/commit/?id=d99f056745e53cd2518ca169af474f8c45c1436d | 20:04 |
| sforshee | that's the patch to remove the check | 20:04 |
| rik_ | sforshee: thanks, I've patched the code from trunk | 20:06 |
| rik_ | when I look at xinput list it shows my touchpad as 12 (ps2 mouse) and 13 | 20:06 |
| rik_ | but when I run input-events, it shows for 12 HDA Intel PCH HP Out at Ext Righ | 20:06 |
| rik_ | ? | 20:06 |
| rik_ | and something similar for 12 | 20:07 |
| rik_ | 13 | 20:07 |
| sforshee | rik_, the indexes from xinput aren't the same as input-events uses, use lsinput to get the argument you should pass to input-events | 20:07 |
| sforshee | rik_, also note that you need to run input-events from a virtual terminal to get the results. X will prevent you from seeing the events | 20:08 |
| rik_ | sforshee: thanks for the hint. I ran it in X and it showed input for the ps2 device but not for the alps glidepoint | 20:08 |
| rik_ | will try from a console | 20:08 |
| rik_ | doesn't make a difference. only input from the ps2 device :-( | 20:10 |
| rik_ | sforshee: would it make sense to play with the ALPS_PROTO version field in the driver? | 20:11 |
| sforshee | rik_, do you see REL_X and REL_Y events or ABS_X and ABS_Y? | 20:11 |
| rik_ | REL_X | 20:12 |
| sforshee | rik_, then I think it's likely that you're still just getting PS/2 data | 20:13 |
| rik_ | sforshee: I only get input on the PS2 mouse input device and nothing on the other device | 20:13 |
| rik_ | what do the fourth and fifth field in the alps_model_info struct mean? for example 0xcf, 0xcf | 20:15 |
| sforshee | rik_, you could try changing the ALPS_PROTO field for v3 and v4 and see if it works | 20:15 |
| sforshee | rik_, the fourth and fifth fields are used for identifying proprietary-formatted data packets, if you're trying v3 or v4 they should both be 0x8f | 20:16 |
| rik_ | V3 results in: unknown response while entering command mode: 73 01 0d | 20:17 |
| rik_ | what does the second field in the struct mean, for example 0x9b | 20:18 |
| rik_ | V4 results in the same error message | 20:19 |
| sforshee | rik_, the second field is used to differentiate between different v3 and v4 models | 20:20 |
| rik_ | sforshee: what are valid numbers to try there? | 20:21 |
| sforshee | rik_, based on those results I suspect yours isn't a v3 or v4 device. the response looks more like the response for an E7 report | 20:21 |
| sforshee | if you want to keep trying, you would need to change the second for your new model to 0x0d | 20:22 |
| sforshee | you also need to make alps_enter_command_mode recognize 0x73 and 0x01 as valid for the first two bytes of the response | 20:22 |
| sforshee | you can give it a try, but I don't expect it to work | 20:23 |
| rik_ | sforshee: ok, will focus on V2 then. could PS2_INTERLEAVED make a difference in the events output? | 20:24 |
| sforshee | rik_, you might as well try v3 and v4 since it's fairly easy. but you may well be looking at another protocol that no one has deciphered yet. | 20:25 |
| rik_ | sforshee: nice :-) | 20:25 |
| rik_ | :-/ | 20:25 |
| sforshee | rik_, do you or don't you have PS2_INTERLEAVED set currently? | 20:26 |
| rik_ | currently set | 20:26 |
| rik_ | but my v3 and v4 attempts did not have this set | 20:26 |
| rik_ | they had ALPS_PASS set | 20:26 |
| sforshee | rik_, my guess is that if you remove it your results will get worse. But there's no harm in trying. | 20:27 |
| sforshee | it will be informative at any rate | 20:27 |
| rik_ | so it should be set (ps2_interleaved) for all attempts (v2, v3...) | 20:27 |
| rik_ | ? | 20:27 |
| sforshee | if your results get worse then it confirms my guess that the driver is just handling PS/2 data when you have it "working" | 20:27 |
| sforshee | no, don't set it for v3 and v4 | 20:28 |
| sforshee | well, really it won't make any difference, the v3 and v4 support don't check that flag | 20:28 |
| rik_ | if I change the alps_dump_packets int in the alps.c code to 1, will this give me more debug output | 20:28 |
| sforshee | possibly, but it will be a flood of data that probably isn't very useful at this point. | 20:29 |
| rik_ | ok, will skip that then | 20:30 |
| rik_ | the only way to really debug this is to follow your instructions on building a custom qemu? | 20:30 |
| sforshee | hrm, actually removing PS2_INTERLEAVED probably won't prove anything, there's another path for PS/2 data that's probably the one you're actually hitting | 20:30 |
| sforshee | and my statement about v3 and v4 ignoring the flag are incorrect now that I look at the driver again, it's in a code path common to all protocol versions | 20:31 |
| rik_ | with V2 and ps2_interleaved enabled, the driver reports the following when loaded | 20:31 |
| rik_ | E6 report: 00 00 64 | 20:31 |
| rik_ | E7 report: 73 03 50 | 20:32 |
| sforshee | if you get to the point where the interleaved flag matters with v3 or v4 you're doing pretty good though :) | 20:32 |
| rik_ | Status: 10 00 0a | 20:32 |
| rik_ | sforshee: so it would make sense to try that? will do | 20:32 |
| rik_ | no difference for v3 | 20:33 |
| rik_ | v4: nodifference | 20:34 |
| rik_ | the DUALPOINT flag means that there's a touchpad and a stick between the keyboard keys? | 20:35 |
| rik_ | or does it mean multitouch? | 20:35 |
| rik_ | and what is a 4 direction button? | 20:35 |
| sforshee | rik_, it means a touchpad and a trackstick | 20:35 |
| rik_ | my system is a dell inspiron 15R, and doesn't have a trackstick | 20:36 |
| sforshee | rik_, I don't have experience with the 4 direction button thing, but looks like it's for some hardware that has some extra buttons | 20:36 |
| rik_ | I guess playing with those won't make a difference anyway? | 20:37 |
| sforshee | nope, i don't think you're getting far enough for them to matter | 20:37 |
| rik_ | so the qemu method is the only way to get any further? | 20:38 |
| sforshee | rik_, I'd suggest adding a printout to alps_report_bare_ps2_packet to verify that you're still just seeing plain PS/2 data, if your message is printed it means that you are (which is my suspicion). If that's the case trying to sniff the Windows driver using qemu would be the next step. | 20:39 |
| rik_ | your patch is for qemu or qemu-kvm? | 20:40 |
| sforshee | qemu-kvm | 20:40 |
| rik_ | correct about the report_bare thing. it's spewing my log out :-) | 20:41 |
| rik_ | will your patch work with 0.15.1? | 20:42 |
| sforshee | rik_, not sure, haven't tried it with 0.15.1 | 20:43 |
| sforshee | if it applies cleanly there's a good chance it might work :) | 20:44 |
| rik_ | seems to apply with some fuzzing | 20:46 |
| rik_ | sforshee: it's building. I'll try the qemu thing when i find the time. Have to install windows inside the vm first. Thanks for your time | 20:50 |
| sforshee | rik_, np, let me know if you have more questions. Good luck! | 20:50 |
| rik_ | sforshee: what timezone are you in? | 20:52 |
| sforshee | rik_, US central (UTC-6) | 20:57 |
| rik_ | sforshee: so it's like 1pm for you? | 20:59 |
| sforshee | no, 3pm | 21:00 |
| rik_ | ah yes | 21:00 |
| rik_ | ok | 21:00 |
| jsalisbury | bjf, herton, possible regression between 3.0.0-12 and 3.0.0-13: bug 894292 | 21:23 |
| ubot2 | Launchpad bug 894292 in linux "Sandybridge suspend/resume regression on 3.0.0-12-generic/3.0.0-13-generic" [Medium,Triaged] https://launchpad.net/bugs/894292 | 21:23 |
| herton | jsalisbury, we will check that | 21:26 |
| jsalisbury | herton, cool, thanks! | 21:27 |
| jsalisbury | ogasawara, Do you think this one should be on the hot list? Installation failures for Precise VMs: bug 894768 | 21:48 |
| ubot2 | Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Triaged] https://launchpad.net/bugs/894768 | 21:48 |
| ogasawara | jsalisbury: sure. probably needs more investigation though. | 21:49 |
| jsalisbury | ogasawara, thanks. I'll request additional investigation to try and find a root cause. | 21:50 |
| * tgardner -> EOD | 21:56 | |
| jibel | jsalisbury, is there any additional information I can provide? It's very easy to reproduce in our testing env and I can try to instrument the iso if it helps. | 22:09 |
| jsalisbury | jibel, Do you know if this only happens when installing Precise as a VM? Have you see this in any of the physical machine installs? | 22:10 |
| jibel | jsalisbury, I've never seen it on a physical installation, only Precise VM. I'll try tomorrow on a physical machine. | 22:12 |
| jsalisbury | jibel, from the error, it looks like the install.py script is loosing access to a file handle and throwing I/O errors. | 22:13 |
| jsalisbury | jibel, are there any logs on the host that can be added to the bug? | 22:14 |
| jibel | jsalisbury, on my report it happens in write() but in duplicates it happens in close(), I've seen the same error with dpkg on an alternate amd64 install. | 22:15 |
| jibel | jsalisbury, I haven't found any useful information on the host, no disk or media error but I can attach logs from the host when that happens. Which one do you need ? | 22:16 |
| jsalisbury | jibel, hmm. Maybe just the syslog and any logs specific to KVM. | 22:17 |
| jsalisbury | jibel, its interesting the error happens on a write() and close(). It's like it's loosing access to a file it had open. | 22:17 |
| jsalisbury | jibel, it would be good to see if it also happens with any other I/O operations in dup reports. | 22:18 |
| jibel | jsalisbury, this was the error with dpkg | 22:18 |
| jibel | Nov 24 10:01:11 in-target: dpkg: error processing /media/cdrom//pool/main/p/perl/perl-modules_5.14.2-5_all.deb (--unpack): | 22:18 |
| jibel | Nov 24 10:01:11 in-target: failed in write on buffer copy for backend dpkg-deb during `./usr/share/perl/5.14.2/IO/Uncompress/Base.pm': Invalid argument | 22:18 |
| jibel | jsalisbury, I'll run the test again and will attach the host logs | 22:19 |
| jsalisbury | jibel, cool thanks. I wonder if you could identify the file being written to when the error happens, and then see if you can get details on it. Maybe it's getting corrupt? | 22:20 |
| jibel | jsalisbury, ubiquity doesn't report the file being copied. I'll see what I can do. | 22:25 |
| jsalisbury | jibel, hmm. I haven't looked at the code yet, but do you think the file should have been copied somewhere, and it was not? | 22:26 |
| jibel | jsalisbury, I don't know | 22:27 |
| jsalisbury | jibel, ok, I'll take a closer look at the script tomorrow as well. | 22:28 |
| jibel | jsalisbury, great. thanks for your help | 22:29 |
| jsalisbury | jibel, np | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!