| alkisg | When my pc boots, my keyboard doesn't work, but if I unplug/replug it then it does work | 06:40 |
|---|---|---|
| alkisg | It's a ps/2 keyboard, can I somehow unload and reload the i8042 module instead? | 06:40 |
| alkisg | My problem is that there's no i8042 module anymore.... what replaced it? | 06:41 |
| alkisg | [ 331.529953] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 | 06:41 |
| alkisg | This is shown in dmesg when I unplug/replug the keyboard, which then works | 06:41 |
| alkisg | Before that, there's a /sys/devices/platform/i8042/serio0 directory, but no /sys/devices/platform/i8042/serio0/input directory | 06:42 |
| alkisg | Maybe I can `echo xx>yy` something there in order to force a rescan? | 06:42 |
| alkisg | xinput doesn't list the keyboard before I unplug/replug it | 06:45 |
| apw | alkisg, that is built in, so you cannot rmmod/modprobe it no | 07:42 |
| alkisg | apw: any way to force a rescan? | 07:42 |
| apw | there are some options to that module to tell it to reset in a different way, rescan i am not sure | 07:42 |
| alkisg | Reset would be fine too | 07:42 |
| alkisg | The client reports that all of his 9 PCs have that, and it happens mostly on the first boot of the day | 07:42 |
| alkisg | In subsequent reboots it mostly loads, e.g. 90% of the times... | 07:43 |
| alkisg | So I'm trying to find a way for him to avoid buying new USB keyboards... | 07:43 |
| alkisg | I tried both 3.2 and 3.13 kernels, they did the same | 07:43 |
| smb | do the keyboards work for bios on first boot? | 07:44 |
| * alkisg asks... | 07:44 | |
| apw | a wide range of kernel versions affected then | 07:45 |
| smb | I once had an old IBM one which seemed to show the same symptoms and my feeling was that that just wanted too much power maybe too early. So it seemed not getting initialized correctly | 07:45 |
| alkisg | He had told me that it didn't happen until a few months ago | 07:45 |
| alkisg | He was on precise with the stock 3.2 kernel, doing regular upgrades | 07:46 |
| apw | alkisg, well if we can find the kernel it changed in there is a chance of finding the issue | 07:46 |
| smb | Not saying it cannot happen but getting a drastic change happening back in the 3.2 kernel seem rather slim | 07:47 |
| apw | right its unlikley the module status has changed for sure | 07:47 |
| alkisg | Ah, there's the stock kernel still available in the repositores (not in -updates), I can try with that one... | 07:47 |
| alkisg | smb: I think the client has a boot menu that waits e.g. 10 seconds before selecting "boot from network" (the one it normally uses), so I don't think it would be power related, | 07:48 |
| alkisg | but it could be related to timings inside the kernel | 07:48 |
| smb | Yeah would be good to make sure its not spontaneous hw degradation or so | 07:48 |
| smb | alkisg, The init I mean is not the one from the kernel but the bios | 07:49 |
| smb | IOW in my case the keyboard was useless already on the boot menu | 07:49 |
| alkisg | I just told him to try all of the clients in the boot menu | 07:50 |
| apw | smb, though 9 machines all the same seems unlikely to be h/w | 07:50 |
| smb | apw, there is that. yeah. not clear how that would happen | 07:50 |
| smb | But as there is a boot menu its easy to test whether one can wiggle the selection there (even when then going into the default option) | 07:52 |
| smb | at least that would prove the kernel itself to be doing things wrong | 07:52 |
| alkisg | To test previous versions, do I only need a previous linux-image, or some other package too? E.g. something related to udev, xinput, ...? | 07:56 |
| smb | alkisg, no only the related linux kernel packages... linux-headers (arch + all) + linux-image.... (now if I could remember whether we had linux-image-extra already back then) | 07:58 |
| smb | I think not... | 07:58 |
| alkisg | no -extra package installed | 07:58 |
| smb | ok, not that then, but give me a sec to boot a vm to check for sure | 07:59 |
| alkisg | He reported that he just had 2 cases where the keyboard was working in the boot menu, but not later on | 08:01 |
| smb | alkisg, ok thanks. so really more kernel or timing in there | 08:02 |
| alkisg | Is there a "waitfordevices=10secs" parameter or similar? | 08:02 |
| smb | alkisg, not that I know but then keyboard is not really seen boot critical... or its not completely not there but just does not send events | 08:05 |
| smb | alkisg, So its just the 3 packages needed linux-headers-<ver> linux-headers-<ver>-generic and linux-image-<ver>-generic (if you already got -generic) | 08:06 |
| smb | otherwise replace generic by whatever is there. it would be good when you could open a lp bug report by ssh in and running "ubuntu-bug linux" when the keyboard is not working | 08:07 |
| smb | (or the customer himself) | 08:08 |
| jk- | cking: would it be feasible to do a fwts-live image for ppc64el? | 08:15 |
| cking | jk-, i'm not sure, I don't know how the fwts-live image is created, I'll have to check out with the HWE fwts folk | 08:16 |
| jk- | cking: ah! I can follow up - that'd be ivan and/or alex? | 08:17 |
| cking | jk-, ivan and/or alex :-) | 08:17 |
| jk- | cking: super, thanks. | 08:17 |
| * alkisg installs 3.2.0-23, apt-get install --auto-remove --purge linux-image-generic-pae=3.2.0.23.25 linux-generic-pae=3.2.0.23.25 linux-headers-generic-pae=3.2.0.23.25 | 08:23 | |
| alkisg | [ 1.034415] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 | 08:32 |
| alkisg | [ 1.034475] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp | 08:32 |
| alkisg | [ 1.034807] serio: i8042 KBD port at 0x60,0x64 irq 1 | 08:32 |
| alkisg | [ 1.191588] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 | 08:32 |
| alkisg | The last line is missing whenever the problem occurs. | 08:32 |
| alkisg | I tried i8042.kbdreset, it didn't do anything (still waiting for the kernel to install) | 08:33 |
| * alkisg also checks i8042.nopnp... | 08:34 | |
| smb | not sure that helps much. hm, so the controller is detected but somehow the probe for the device behind that controller fails | 08:36 |
| smb | iirc aux was potentially mouse... | 08:36 |
| * apw idly wonders if this is one of those behind the mouse | 08:42 | |
| alkisg | Heh. The older kernel seems to work fine | 08:43 |
| apw | alkisg, so one needs to work forward to find the first one which fails | 08:43 |
| apw | alkisg, normally one does a "binary split search" for these, pick one in the middle try that stylee | 08:43 |
| alkisg | kernel bisect, got it... | 08:47 |
| * alkisg tries to get some more info, due to the diffuculty of doing that remotely... | 08:47 | |
| smb | alkisg, just not bisect within a kernel but taking the packages from launchpad | 08:48 |
| smb | In theory if you can get a better "when" this started you could narrow down which kernel to start with | 08:48 |
| alkisg | Gotcha, thanks, give me some time to check with that client (teacher) and what he's willing to do... :-/ | 08:49 |
| cking | alkisg, you may like to also try i8042.noloop | 08:53 |
| alkisg | Thank you guys. The result it: (1) the older kernel did not fix it, the first test was just a random time that it worked. (2) i8042.nopnp fixed it. | 09:26 |
| alkisg | So I'm guessing that it didn't work for him in the past as he reported, and I updated his kernel command line to always have i8042.nopnp, and ..."closed" the issue :) | 09:26 |
| caribou | apw: morning, got a minute to discuss the kdump-tools/initrd bug ? | 09:30 |
| smb | alkisg, Thanks for the update. Weird, somehow I would have thought that nopnp only would affect mice but I certainly will not complain if this fixes the issue. :) | 09:32 |
| apw | caribou, always | 09:50 |
| caribou | apw: what do you prefer ? mumble or here ? | 09:52 |
| apw | mumble is fine | 09:52 |
| apw | if mumble would start | 09:52 |
| apw | just making tea so too noisy | 09:53 |
| caribou | apw: hold on, PTT doesn't work | 09:54 |
| caribou | apw: I forgot to ask : do you see a /boot/kdump directory being an issue ? | 10:07 |
| apw | caribou, i don't think so, though i guess they don't actualy have to be in /boot at all do they | 10:11 |
| apw | caribou, as they are not loaded by the bootloader, so they are not special files in the same way, they could | 10:11 |
| apw | go in like /var/lib/kdump/kernel or something just as well | 10:11 |
| caribou | apw: kexec calls them so they need to be in the same FS as the original ones | 10:14 |
| apw | caribou, i thought it loaded them after we have mounted everything, so why do we care where they come from ? | 10:15 |
| apw | and i thought it literally just read the file and shoved it into kernel memory | 10:15 |
| apw | caribou, oh you mean on reboot? so we have unmounted everything by then ? | 10:16 |
| apw | we don't do that for kdupm though do we ? | 10:16 |
| caribou | apw: no they're used as parameter to the kexec call that boots the kernel | 10:16 |
| caribou | apw: sorry, I need to step out. I'll check a few thing upon my return to make sure I put them at the right place | 10:17 |
| apw | caribou, np | 10:30 |
| silidan | hi, i have a library here(no sourcecode) for accessing a USB 2.0 camera which uses libusb-1.0, when using usbmon and wireshark i see URBs for Bulk Transfer which are always 61504 Bytes long, on windows the native driver for the camera seems to use URBs of length 307227 bytes, how can i make sure the URBs on Linux are the same Size as on Windows? | 14:15 |
| apw | silidan, i'd expect the library caller to specify the buffer size | 14:16 |
| apw | which is the bit you don't have source for | 14:16 |
| silidan | apw: i dont have the source for the library that calls libusb | 14:17 |
| apw | i know | 14:17 |
| apw | silidan, an strace might tell you if the buffer being offered by userspace is bigger than the URB or not | 14:19 |
| apw | and tell you if the kernel or userspace is making the upper limit | 14:19 |
| silidan | apw: never used strace, can you point me to a tutorial so i can get up and running? | 14:19 |
| apw | normally "strace -o <tracefile> <command>" gives you everything that happens | 14:20 |
| silidan | apw: if the kernel makes the upper limit, are there any chances i can set the limit at runtime? | 14:20 |
| apw | silidan, maybe indeed, though i have no idea off the top of my head | 14:23 |
| apw | knowing which driver it is loading etc we migt be able to tell | 14:23 |
| apw | but first determine the size of the buffer offered from userspae | 14:23 |
| silidan | apw: here is the output from a short test http://pastebin.com/hmhvzkad | 14:26 |
| silidan | apw: this output is new to me.... dont know how to read it | 14:30 |
| apw | silidan, those are the raw systemcalls your app made | 14:30 |
| silidan | apw: ok so to understand it i have to know which sys calls to look for right? | 14:31 |
| apw | ioctl(13, USBDEVFS_SUBMITURB, 0x705560) = 0 | 14:34 |
| apw | silidan, so i think that is saying that URBs are coming from userspace in a raw sense, so size is likey coming from there | 14:34 |
| silidan | apw: and that tells me what? | 14:45 |
| apw | it implies to me that the libbray and your app are deciding on the URB sizes | 14:46 |
| apw | as it is just saying "SEND URB" not "write some data" | 14:47 |
| silidan | apw: ok so that size limit is either given by libusb or the lib that uses libusb? | 14:49 |
| apw | i gues it may be returned from the kernel inthe preceeding lookup phase | 14:50 |
| apw | now it is hard to tell | 14:50 |
| apw | ioctl(13, SNDRV_CTL_IOCTL_TLV_READ or USBDEVFS_GET_CAPABILITIES, 0x705550) = 0 | 14:50 |
| apw | it does do that shortly before, so it is possible that that containst upper limits | 14:50 |
| apw | silidan, ok no that doesn't appear to say how big it can be | 14:52 |
| apw | and then we set a configration on the device and claim it | 14:52 |
| apw | and then start sending urbs, so i'd say | 14:52 |
| apw | from the inforamtion we have here that its likley it is either your app or the libusb which determins max urb size | 14:53 |
| apw | but this cna only be conjecture at the moment | 14:53 |
| silidan | so in other words we cant be sure what is limiting? | 14:53 |
| apw | but whats there right now, i'd say the kernel isn't obviously telling you, and userspace is saying "send this" | 14:54 |
| apw | so i'd say the urb is being sized and made in userspace | 14:55 |
| silidan | apw: ok, but now lets assume the kernel would be telling me, where would i look further? | 15:04 |
| apw | silidan, well it is hard to say as i cannot see you doing anything which looks like asking | 15:05 |
| apw | silidan, why do you care that it is making smaller urbs anyhow, they are still pretty large | 15:08 |
| silidan | apw: well the problem is this camera reaches 30 fps on windows, and only 10 on linux, and the image transfers start to stall when the camera is supposed to transfer more than 10 fps. | 15:11 |
| apw | silidan, so what is hte closed source thing you are using to read from it, does anything open osurce work with it | 15:12 |
| apw | if its just a normal camera could you use cheese or something to see if that can read at a beter speed | 15:12 |
| silidan | apw: the closed source thing is the SDK from the manufacturer, im not aware of any open source thing to talk directly to the camera without the closed source SDK | 15:13 |
| apw | silidan, closed source things suck | 15:14 |
| silidan | apw: yep | 15:14 |
| silidan | apw: but at least this manufacturer made the effort of creating a linux sdk... better than nothing at all.. | 15:15 |
| silidan | apw: i can give you the download link for the sdk if you are interested... | 15:15 |
| apw | i guess, just about | 15:15 |
| apw | silidan, i don't really have the imte to investigate binaries | 15:16 |
| apw | likely your next step is to ask them, if they make the sdk they may respond | 15:16 |
| silidan | apw: i already asked them, so far their response: "we have dig into the source code of libusb and found it did not split the transfer to small URBs" and "the short URB problem is related to Linux kernel our USB3.0 camera has a larger hardware buffer than our USB2.0 cameras so USB3.0 cameras runs well through small URBs" | 15:18 |
| silidan | apw: and also: "we did some test and track this problem in libusb but seems there is no such limitation in libusb we do think this is because of linux Kernel" | 15:20 |
| silidan | apw: if you want i can hint them to this channel so you can communicate with them directly.. | 15:25 |
| apw | silidan, so they are claiming we are splitting hte urb they send into more than one? | 15:25 |
| apw | silidan, what does the URB say that we send to the other end | 15:30 |
| apw | silidan, you took traces me thinks | 15:31 |
| silidan | apw: ? | 15:48 |
| apw | silidan, they claim to be submitting bigger urbs than we submit to the device right ? | 15:48 |
| apw | silidan, so i am asking what the wireshark info for the URBs is, so i cna try and figure out what path they took to see if we do do that | 15:49 |
| apw | silidan, as they are claiming (i belive) that they submit large urbs and we submit multiple smaller ones onto the wire | 15:49 |
| apw | and we'd have to have code to do that, which i cannot easily find without knowing the route it takes | 15:49 |
| apw | and for that i need to know what kind of urb it is | 15:50 |
| silidan | apw: i can send you the wireshark info, but only in about 1-2 h, im afk now | 15:52 |
| silidan | apw: ok im back, getting hold of the data now | 18:41 |
| silidan | apw: Here is the usbmon capture of wireshark on Ubuntu 64bit http://wikisend.com/download/915008/ASI_120MM_USBMON_Capture_Linux_x64.pcapng | 18:59 |
| silidan | apw: it includes the whole communication from start to shutdown of the capture application, it doesnt contain the enumeration process during plugging in, if you want that ill make a new capture, just let me know | 19:00 |
| silidan | im off now, ill be back tomorror | 21:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!