[02:23] Hello good evening, I have just installed Ubuntu Studio Disco Dingo 19.04 on a Toshiba Satellite C55 [02:24] It did not recognize the built in laptop keyboard or trackpad, I am trying solutions to make them work, working with a usb at the moment, kybrd and mouse, one of the solutions I found was to update the kernel, I currently have 5.0.0-29-lowlatency, and the possible solution advised to update to kernel to 5.1.16 through PPA [02:25] Since I am new I do not know exactly how to update only the kernel, using ubuntu studios low latency, which is the point I installed Ubuntu Studio, could someone please advice me? [02:29] Having a rough install, does not detect internal keyboard, trackpad, external bluetooth keyboard, and has wifi intermittengly [02:30] I installed from scratch on laptop [02:35] I am really excited to try ubutustudio, used linux many years ago, trying to come back to it [03:23] jamesg27: hmm, that's unfortunate, it's actually quite rare that an internal laptop keyboard isnt detected. sure, you can try a different kernel version, though 19.04 only supports a single kernel version. you could also take a look at your logs and try to understand what's causing these issues, and how to handle them with the kernel version you already have. [03:25] "journalctl -b" shows your system and application logs since the latest reboot. to share it here, use journalctl -b | nc termbin.com 9999 (you can also try getting help in #ubuntu, since this should be an ubuntu 19.04-wide issue with your hardware). [03:29] Thank you let me try to print the log [03:35] thank you for your help, here is the link for the log

https://termbin.com/2kth

[03:37] I have npo problem with a single kernel, what I do not know is hopw to update it to the 5.1.16 throu8gh ppa like a person said it worked for them, without loosing the low latency kernel which is the reason I installed ubuntustudio for multimedia applications [03:40] jamesg27: i suspect you added those extra kernel parameters in an attempt to fix the issue? [03:42] no no I currently have the 5.0.0-29-lowlatency that came with the install, I learned that the updating to the 5.1.16 through ppa helped another user with this same problem, So I thought I should try it, but I dont know how [03:42] yes that is correct [03:42] about the newer kernel version: i believe i would do you a disfavor by suggesting ways to install different but unsupported kernel versions. what i can suggest is to install 18.04 LTS instead, which will offer at least two, maybe three, kernel versions to choose from. [03:43] qahhh I c... and how do you choose those kernel versions, do they come up as options in the menu while you are installing [03:44] I am also going to try and update the bios of the laptop, since it has the 1st version... [03:44] i think i will try that before installing 18.04 lts [03:45] did you happen to see something important in the logs? [03:45] i generally recommend bios updates, too [03:45] i'm still reading those logs [03:45] TOSHIBA Satellite C55-A/Portable PC, BIOS 1.10 12/03/2013 [03:45] ok ok ty [03:46] but i think you should remove those extra kernel parameters, do the bios upgrade and test that way first of all. [03:46] and share another log based on it, too. [03:47] ty what extra kernel parameters? how do i do that? [03:47] i8042.nomux=1 i8042.reset acpi=noirq [03:47] those three, did you not add those to /etc/default/grub ? [03:47] ahh that was somebody elses solution i tried that i found online, did not work [03:47] yes [03:47] i did [03:48] you can copy line that's in the file and comment it out (place a # in front), then remove those options off the non commented line. [03:48] so you keep it for later [03:48] ok i will remove those, and try the bios update , if it does not work, i will install 18.04 LTS [03:48] then run sudo update-grub [03:48] yes thank you [03:49] will do that right now, and will make a bootable usb with the bios update, [03:52] good luck. if you'll return here and want to address me later, be sure to mention my nickname, tomreyn (or i may not notice). but i may also no longer be at the computer then (just logged in). [03:54] thank you tom I appreciate your help, do i mention your nick with the @ infront? [03:58] Tom I found some instructions on how to update the bios on linux, they recommend a prog called 'unetbootin' but I do not find it on the software center, can you recommend something else I can use? [03:59] I have the updated bios, but it is an exe, and inside there is an iso image.. [03:59] that was the only update avaliable on the laptops page on the toshiba website [04:05] no need for the @ here on irc. if yu ever want a better chaqt client, you can install hexchat (on several operating systems including ubuntu linux). [04:06] jamesg27: << this should make your browser tab flash, and similarily it'd try to ge tmy attention here. [04:08] you can use usb-creator-gtk (probably already installed) to write the iso to a USB stick - but be aware that the entire stick gets overwritten that way - backup your data first. [12:37] I don't have experience with any version of linux. I'm running windows 7, and most likely will want to dual-boot. Where should I start? [12:41] Uhfgood I'd make a bootable USB of the latest version (19.04) and take it for a spin [12:44] ok, i'll probably have to burn an iso and use a dvd. I don't have any extra usb drives (I guess I'm still stuck in the last century ;-)) [12:49] jazzslag - thanks [12:56] dvd should work, too (but yes, i'd prefer usb) [14:12] OvenWerks: Well, the good news is jackd appears to be more stable now. Hasn't restarted at all over the weekend. The bad news is I do still get 4-5 xruns per minute, but we also haven't figured out the irq thing so there is hope. :) [15:27] wonko which version are you using? I just upgraded to 19.04 and is super stable [15:28] 19.04 [15:37] I've tried shortening the USB extension cable to the audio device and I got a proper mic so I'm no longer doing zita-a2j for the shitty webcam mic. One of those things may have solved the issue. :) [15:50] Or neither did and it's a coincidence. :) [16:02] jazzslag: wonko has some IRQ conflict problems, from what I understand. Fairly unique to his hardware. [16:05] Eickmeter ah ok sorry to trivialise [16:06] simply installing 19.04 and playing with the Carla settings fixed a very specific problem I had, so I assumed 19.04 was the magic cure-all :D [16:06] Well, the IRQ thing is still an issue. I'm not sure if that's related to the jackd stability or not. A lot of unknowns here. :) [16:07] wonko: It absolutely is. If the IRQ thing is conflicting, you bet jackd is going to have a problem. [16:07] oh, getting the audio device onto a different controller than the mouse/keyboard may also have played a part to stability. Hard to say. [16:07] I'm not sure it's conflicting though or not [16:07] those are just guesses Oven and I had. :) [16:08] Well, they're decent guesses. [16:09] still need to figure out a way to determine which is the correct irq handler for chrt though. [16:09] Yeah. That stuff is over my head, unfortunately. [16:14] Yeah, I don't quite understand things at this depth either [16:17] The thing I don't understand is if I follow the path all the way to the pci usb controller its IRQ is 24, but there is no process for that, only for 35 which is the root hub it's connected to [16:20] * Eickmeyer whoosh [16:25] EXACTLY [16:25] I'm asking some people smarter than me to see what they say. :) [16:52]

pcie interrupts are message signaled; the controller puts a message in a ring buffer and then (maybe) flags a physical interrupt line to say the queue needs processing [16:52]

so the thread in this case is the kthread that's processing that ring buffer [16:52] So that technically answers the question [16:52] I just don't know how that applies to what I'm doing. :) [16:53] wonko: it means that the computer doesn't bother with the physical IRQ... the one listed by lspci [16:53] it uses a virtual or messages irq. [16:53] is that the one we're getting from /sys? [16:53] *messaged [16:54] * OvenWerks has forgotten where we were with that [16:55] Lost in the woods I think [16:55] if the one from sys matches the one shown in /proc/interrupts then that is the correct one [16:55] /proc/interrupts shows what is actually being seen by the cpu [16:56] so looking at the irq for the PCIe USB card, they do not match [16:56] for the root hub I think they do [16:56] but there is no process for the USB card anyway so I'm not sure what magic that is [16:57] PCIe PME, aerdrv is what shows up on 35 from /proc/interrupts [16:57] wonko: when I was playing with it on my system... I was finding that the irq listed in lspci -v was the right one... not sure what changed... oh maybe I was looking at my ethernet card [16:58] https://paste.ubuntu.com/p/Nbh5H3WsHm/ [16:58] ugh, lspci -v on this system is painful. :) [16:58] wonko@deepthought:~/bin$ lspci -v | wc -l [16:58] 868 [17:02] so lspci output matches expectations [17:02] https://paste.ubuntu.com/p/2yR588xVhs/ [17:03] using /sys to fine the irq matches that anyway [17:03] s/fine/find/ [17:41] wonko: first thing is that /sys/devices/ does not show me everything [17:41] ... /sys/devices has a sub directory pci0000:00 [17:42] but lspci seems to show pci0000:02 - 05 [17:50] wonko: I think you are looking for /sys/bus/pci/devices//msi_irqs/ [17:50] the MSI is the key [18:04] wonko: this is for my ethernet because it has the same problem. [18:05] $ cat pci/devices/0000\:03\:00.0/irq -> 17 [18:05] ls pci/devices/0000\:03\:00.0/msi_irqs/ -> 26 27 28 29 30 [18:06] yeah, looking at the msi IRQs they match nothing else I've collected before. :) [18:06] Ya 5 of them this is an Intel i210 [18:06] wonko@deepthought:~/bin$ ls /sys/devices/pci0000:80/0000:80:02.0/0000:81:00.0/msi_irqs [18:06] 38 39 40 41 42 43 44 45 [18:06] 81:00.0 is the PCIe USB controller [18:08] except I bet you find the same list for your internal USB pci "card" [18:10] I did try blacklisting the xhci module with no success [18:10] there is supposed to be a bit that can be turned off in the usb controller that changes that too. [18:13] https://www.systutorials.com/241533/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux/ [18:14] wonko: I found a number of pages about turning off xhci and why that are not related to audio but usb device count: [18:14] https://acroname.com/blog/why-cant-i-connect-more-usb-30-devices-my-system [18:15] http://marc.merlins.org/perso/linux/post_2018-12-20_Getting-Around-USB3-xhci-32-Device-Limit-_Max-number-of-devices-this-xHCI-host-supports-is-32_.html [18:15] wonko: however it is obvious to me that because of the horrible way xhci does things, you may have little choice [18:17] ugh [18:18] smart guy can't figure out how we need to do this because he's pretty sure this interrupt is handled as a kthread so there is no way to alter the priority [18:18] you do need thge right irq one way or the other [18:18] that he's figured out so far anyway [18:20] what does your jack log look like when there is an xrun? [18:20] Is there one particular port that is listed every time? [18:21] I am guessing you have both pulse and usb bridging turned off? [18:22] https://paste.ubuntu.com/p/mNTy5NZsw6/ [18:22] no, those bridges are both on I believe [18:23] pulse in was not fiished seems to be pretty common. [18:23] a2j needs to be on, I meant usb bridging and pulse bridge size is greater than 0 [18:25] wonko: also pavucontrol in the Confiuration tab should say "No cards available for configuration" [18:27] It is almost like pulse is picking up another sync source [18:27] indeed it does say that, yes [18:31] Hmm, normally pulse doesn't give problems like that unless it can see another device. [18:32] but pulse is causing xruns in an almost clock like way. [18:38] not quite [18:38] two or three in a row then nothing for a bit [18:43] So I'm reading a bit and they mentioned rtirq [18:44] so I wanted to see what it was doing [18:44] https://paste.ubuntu.com/p/BdnGjJ3fmx/ [18:44] Looks like it just takes the IRQs handling USB devices and blindly assigns decending prioroty [18:45] priority [18:45] with HDA-Intel at the top [18:45] and wtf even is that? [18:45] I have no intel audio [18:47] and yes, it's not handling stuff like usb5 like you want it to it doesn't look like [18:47] Well [18:47] actually I think it would if it found it in the output of /etc/interrupts [18:48] but at least in my case usb5 doesn't show up there [18:49] the only ones that show up are usb1, usb2 and usb3 [18:55] yup... [18:56] That has been my experience too. [18:57] it has found something that looks like an HDA controller [18:58] it could very well be your display has an hdmi line and some MB handle that using hda [18:58] (or you graphics card) [19:02] ah, yes, that is the case [19:02] I don't use it, but the nvidia card has audio [19:03] I have seen hdmi two ways, as a part of hda or PCU or the may be a batch of [hdmi] [19:03] it seems the new way is to separate out hdmi which often requires a large latency to even work. [19:04] so if I put usb before snd in /etc/defaults/rtirq it at least puts the USB before that, but honestly it's not even used so I doubt that'll have much impact [19:05] if you know the irq you want you can use like 38-xhci in rtirq [19:05] that's the problem, I don't. :) [19:05] I still haven't worked that part out yet [19:06] I mean unless I prioritize the pci hub, but I don't think that's what we want? [19:06] so if cat /proc/interrupts has one of the with :usb5 that would be the one or if the same output shows one og the irqs with a lot of activity on only one cpu [19:07] there is no usb5 unfortunately [19:07] only usb1/2/3 [19:07] no 4/5/6 [19:08] well looking at cat /proc/interropts my usb audio device shows as: 20: 2774412 0 30 0 IO-APIC 20-fasteoi ehci_hcd:usb1 [19:09] note the first number after the irq is quite high while the next three nujmbers are low or none. [19:09] this is compared to: 23: 0 38027 331623 63 IO-APIC 23-fasteoi ehci_hcd:usb2 [19:09] which is my mouse [19:10] the numbers are lower eventhough I just plugged the audio in while the mouse has been there since boot [19:11] So you should be able to guess which of the eh/xhci are handling your USB audio by looking for such a pattern [19:13] 116: 0 359301 0 0 0 9035 0 202119 2862447 1995 0 0 0 12727 0 0 0 0 0 0 0 0 0 0 0 0 0 0 909 0 0 67105 0 0 0 0 0 32437585 0 0 [19:13] 5524745 5286763 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 512000-edge ahci[0000:00:1f.2] [19:13] oh wait [19:13] that's all the CPUs, isn't it? [19:13] so I'll need to look at every other one? [19:14] GRRR [19:14] so maybe show me what cat /proc/interrputs |grep hcd [19:14] http://paste.ubuntu.com/p/5y5t6VmVjB/ [19:14] 38 looks like a winner [19:15] ya that would be my guess [19:15] so how would I tell rtirq to set that one highest? [19:16] so for rtirq use 38-xhci [19:17] I would do "38-xhci snd usb" [19:17] but you should be able to not include usb or snd try it both ways :) [19:18] wonko@deepthought:~/.log/jack$ sudo /etc/init.d/rtirq restart [19:18] Setting IRQ priorities: start [HDA-Intel] irq=184 pid=1498 prio=85: OK. [19:18] Setting IRQ priorities: start [ehci_hcd] irq=18 pid=557 prio=80: OK. [19:18] Setting IRQ priorities: start [ehci_hcd] irq=19 pid=556 prio=79: OK. [19:18] Setting IRQ priorities: start [xhci_hcd] irq=38 pid=559 prio=80: OK. [19:18] 38 and 18 are conected then [19:19] also rtirq does not reset stuff it did last time very well may have to reboot to see the real effect [19:20] it's still putting hda ahead of it though [19:20] which is a tad confusing [19:20] yes, but it may be left from last boot [19:20] hmm, ok [19:20] rtirq does not lower old irq settings [19:20] ah, ok [19:21] I can try a reboot [19:21] at least that was what the docs used to say... thogh I haven't read them lately [19:21] but even still with what you had, your audio card should be a higher priority than yur mouse [19:23] wonko: are you running hyperthreading? [19:24] ie, is you cpu x cores/(x*2)threads? [19:30] yes, hyperthreading [19:30] after reboot: [19:30] wonko@deepthought:~$ /etc/init.d/rtirq status [19:30] PID CLS RTPRIO NI PRI %CPU STAT COMMAND [19:30] 1444 FF 85 - 125 0.0 S irq/184-snd_hda [19:30] 555 FF 80 - 120 0.0 S irq/18-ehci_hcd [19:30] 557 FF 80 - 120 0.7 S irq/38-xhci_hcd [19:30] 554 FF 79 - 119 0.0 S irq/19-ehci_hcd [19:30] 558 FF 79 - 119 0.0 S irq/39-xhci_hcd [19:30] so snd is still top, but 38/18 is at least second highest [19:33] in testing I did some time ago (think P4) I found that with hyperthreading enabled the lowest quite stable low xrun latency I could go on my PCI audio was about 62/2. with hyperthreading disabled I was able to have 16/2 with no xruns [19:34] Hmmm [19:34] I probably don't *need* hyperthreading [19:34] 28 cores should be more than enough. :) [19:35] with latencies above 64/2 there seemed to be little difference [19:35] well, i'm at 128/2 [19:35] I have also found that having "Boost" turned off helps [19:36] although shouldn't I have 3? Is that still the recommended number of periods for usb? [19:36] by the time you get to 128 it should not matter. [19:37] ok, well let's watch it and see what happens [19:37] so far no xruns [19:37] USB is 1 ms cycles (maybe 1.25ms I have heard other places) [19:37] starting qsynth caused an xrun [19:38] so 16/3 at 48k is 1ms [19:38] So long as you don't get them while using qsynth that is ok [19:38] yeah, played some stuff an no xruns while playing [19:39] so the minimum a USB device can run is 32/3 ish [19:43] The annoying part about debugging this is now there's nothing really to do except wait and see what happens [19:44] I purposely chose the i5 over the i7 (there was no i9 at the time and xeon was too pricey) because I felt that paying for hyperthreading I wasn't going to use anyway :) [19:44] I didn't pay for these CPUs/RAM so I wasn't complaining. :) [19:44] :) [19:44] best way. [19:45] I probably should have sold them and gotten something else with the money but at the time they made sense [19:45] to keep that is [19:46] I likely would have done the same [19:46] We were possibly moving out of the country and dragging a rack full of server gear wasn't feasable so this became my everything box. It is *really* good at that. :) [19:47] Also, it's very good at building UnrealEngine4 for linux. :) [19:47] Ya, I build enough stuff I would like it for that [19:48] 11 minutes. Last I tried building it was on an i7 laptop and it took like 2 hours and didn't even finish. :) [19:48] their build process scales nicely across CPUs [19:48] and ran the thing up to 4% idle [19:49] I build Ardour quite a bit. my laptop takes an hour at least, this is 14 min and someone with a server similar to your's reports less than 1 min [19:49] Ardour pins all of my cpus to 100 [19:50] I use that to monitor my temperature if it gets too high it is time to clean dust out [19:50] nice. :) [19:50] I haven't run into too many dust issues yet [19:51] although the radiator for the 1080 will clog up eventually [19:51] 😔 [19:55] @miftahulAlvinRizki [😔], Do you have a support issue? [19:56] OvenWerks: as things stand now my CPUs are running at 49C and 54C [19:56] while working hard or at idle? [19:56] mostly idle [19:56] it's hard to make this thing work hard [19:56] I should build UE4 again [19:57] so far still no xruns except for that one starting qsynth [19:57] mine idles at around 25C and gets to about 70C at 100% times 4 [19:57] Xeons run a lot hotter in my experience [19:58] No, i just confused about bot. Did you know something? [19:58] I think my do not excede is 90C [19:59] So 20 min with no x runs. that is not a bad place to start [19:59] @miftahulAlvinRizki [No, i just confused about bot. Did you know something?], The bot is a bridge to our IRC channel. [20:00] It remains to be seen if your IF will use the same IRQ every boot. But time will tell. If you boot some time and the xruns go up that would be something to check [20:02] boo, just got come [20:02] some [20:02] Did cron just run something in the background? (apt update for example) [20:02] I started doing a sizable apt install [20:03] That would do it, some network operations are more atomic than I like [20:03] ok, that's good to know [20:03] If you had to do an apt anything to get xruns you are doing well [20:04] wonko: next test: set sample buffer to 64/3 [20:04] or 64/2 or 32/3 [20:04] :) [20:04] That was my plan. :) [20:18] @Eickmeyer [The bot is a bridge to our IRC channel.], Okay, thank you [20:48] OvenWerks: building UE4 (takes idle to 0.2%) and the CPUs topped out at 59C and 68C