Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
On 23 Oct 2023 09:32:19 -0600 "Andy Bradford" wrote: > Thus said Roger Marsh on Thu, 19 Oct 2023 17:23:47 -: > > > fixes the delay problem, but was the delay a predictable consequence > > of some change? Or perhaps the entry should never have been expressed > > in the way that led to the delay? > > Most likely the cause is an unexpected side effect of some other change. > There have been some interesting changes to SSH with this release, > perhaps try disabling: > > http://man.openbsd.org/OpenBSD-7.4/ssh_config#ObscureKeystrokeTiming > > I would be surprised if this is actually the cause, but it is a change > that was introduced and something that is easily tested. > > You could also look through: > > http://www.openbsd.org/plus74.html > > See if any of the changes stand out as relevant and try to test them. > > Andy > Thanks. ObscureKeystokeTiming turned out to be the cause, or so it seemed after reading the ssh_config reference. Setting this option to 'no' whereever ssh is used in the .fvwmrc configuration file got rid of the response time problem. I remember looking at plus74.html some time before formal release. If ObscureKeystrokeTiming had caught my eye I think I would not have associated it with the possibility of a large increase in response time. The line in plus74.html immediately before the one about ObscureKeystokeTiming states 'Limit artificial login delay ...'. That change looks a more likely cause than 'ObscureKeystokeTiming' measures. Roger
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Thus said Roger Marsh on Thu, 19 Oct 2023 17:23:47 -: > fixes the delay problem, but was the delay a predictable consequence > of some change? Or perhaps the entry should never have been expressed > in the way that led to the delay? Most likely the cause is an unexpected side effect of some other change. There have been some interesting changes to SSH with this release, perhaps try disabling: http://man.openbsd.org/OpenBSD-7.4/ssh_config#ObscureKeystrokeTiming I would be surprised if this is actually the cause, but it is a change that was introduced and something that is easily tested. You could also look through: http://www.openbsd.org/plus74.html See if any of the changes stand out as relevant and try to test them. Andy
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Philip, Thanks for reply, On Sun, 22 Oct 2023 14:39:37 -0700 Philip Guenther wrote: > If this had been observed _during_ 7.4 development then it would have been > simpler to isolate what set of changes caused it. Since that didn't happen > you'll have to debug this yourself on the affected systems. For starters, > I would suggest turning up ssh logging with the -v option and capturing > that to a file and comparing the output on working and not working > systems. Or ktrace the stuttering processes and see when kdump -T output > shows as the operations where the delays occurred. > I am planning to binary chop my way through the 7.4 development part of the CVS repository, assuming there is a revision before which the problem never occurs and after which the problem always occurs, but as yet do not know how long each build and test step will take. Plenty of time, starting now, to see where your suggestions lead. > > As for your "should I have never been doing these this way?" question, > that's unanswerable without knowing _why_ you had written them that way. > Using -Y instead of -X to disable XSecurity enforcement? Why tunnel X > instead of have the remote client connect directly to the X server? You > wrote those to solve some problem, changing that means going back and > reopening that question, which is probably a distraction from the "why did > the latency change" question. > Distraction: yes. But at least you did not say writing the things that way is wrong because ..., which I thought was a possibility. I did get to connecting directly to the X server a couple years ago, I think, following private message suggestions on another problem. However it turned out that moving the Xclient role disks to the older hardware on which they now sit proved simpler and effective but not perfect. > > Roger > On Sun, Oct 22, 2023 at 7:22 AM Roger Marsh wrote: > > > On Thu, 19 Oct 2023 17:23:47 + > > Roger Marsh wrote: > > > > > Hi, > > > > > > After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this > > entry in .fvwmrc (on monitor): > > > > > > 'Exec exec ssh -Y opendev xterm -title roger@opendev' > > > > > > takes several seconds to deliver the xterm window, while I did not > > notice any delay before upgrade. > > > > > > For other usernames on opendev the .fvwmrc entry is like (without the > > '-X' for most usernames other than grading): > > > > > > 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' > > > > > > and I do not notice any delay after upgrade compared with before upgrade. > > > > > > Expressing the 'roger@opendev' entry as: > > > > > > 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' > > > > > > fixes the delay problem, but was the delay a predictable consequence of > > some change? Or perhaps the entry should never have been expressed in the > > way that led to the delay? > > > > > > Below are dmsesg and pkg_info for both boxes involved. > > > > > > Roger > > > > ... > > dmesg and pkg_info for monitor and opendev snipped. > > ... > > > > Hi, > > > > Later I saw opening files with Python's Idle editor suffers the same > > pattern of slow response, in terms of serving up the file edit window, as > > seen with xterm. Scrolling through an editor window is slower too, and > > stutters, compared with what was seen when both boxes were at 7.3 (PgUp and > > PgDn buttons are what I used). > > > > One box (gash) had not been upgraded to 7.4 (because I thought it did not > > have OpenBSD disks). It was modified, in particular adding Python Idle and > > Chromium, to see what happens when 7.3 has the Xserver role and 7.4 the > > Xclient role; and the other way round. > > > > Idle > > XserverXclient Display file window Scrolling > > 7.47.3 slow stutter > > 7.37.4 quicksmooth > > 7.47.4 slow stutter > > 7.37.3 quicksmooth (from > > memory: confirmed on reverting) > >Same 7.4 boxquicksmooth > > > > Idle is started by 'Exec exec ssh -Y idle3.10' in .fvwmrc file. > > Chromium is started by 'Exec exec ssh -X @ chrome' in > > .fvwmrc file. > > > > This behaviour with Python persuades me to revert the OpenBSD 7.4 box > > (monitor) in the Xserver role to 7.3 until 7.4 or later provides more > > acceptable response times. > > > > Chromium seemed unaffected except for slow response when typing in the URL > > bar on the separate 7.4 Xserver box. I thought I could mostly avoid this > > by starting to use bookmarks, but the effect on Python matters more. > > > > Apologies for going off-topic by discussing Python and Chromium rather > > than xterm: but the Python stuff changes my attitude to the problem from > > minor annoyance to something which needs an immediate workaround. > > > > Below are
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
If this had been observed _during_ 7.4 development then it would have been simpler to isolate what set of changes caused it. Since that didn't happen you'll have to debug this yourself on the affected systems. For starters, I would suggest turning up ssh logging with the -v option and capturing that to a file and comparing the output on working and not working systems. Or ktrace the stuttering processes and see when kdump -T output shows as the operations where the delays occurred. As for your "should I have never been doing these this way?" question, that's unanswerable without knowing _why_ you had written them that way. Using -Y instead of -X to disable XSecurity enforcement? Why tunnel X instead of have the remote client connect directly to the X server? You wrote those to solve some problem, changing that means going back and reopening that question, which is probably a distraction from the "why did the latency change" question. On Sun, Oct 22, 2023 at 7:22 AM Roger Marsh wrote: > On Thu, 19 Oct 2023 17:23:47 + > Roger Marsh wrote: > > > Hi, > > > > After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this > entry in .fvwmrc (on monitor): > > > > 'Exec exec ssh -Y opendev xterm -title roger@opendev' > > > > takes several seconds to deliver the xterm window, while I did not > notice any delay before upgrade. > > > > For other usernames on opendev the .fvwmrc entry is like (without the > '-X' for most usernames other than grading): > > > > 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' > > > > and I do not notice any delay after upgrade compared with before upgrade. > > > > Expressing the 'roger@opendev' entry as: > > > > 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' > > > > fixes the delay problem, but was the delay a predictable consequence of > some change? Or perhaps the entry should never have been expressed in the > way that led to the delay? > > > > Below are dmsesg and pkg_info for both boxes involved. > > > > Roger > > ... > dmesg and pkg_info for monitor and opendev snipped. > ... > > Hi, > > Later I saw opening files with Python's Idle editor suffers the same > pattern of slow response, in terms of serving up the file edit window, as > seen with xterm. Scrolling through an editor window is slower too, and > stutters, compared with what was seen when both boxes were at 7.3 (PgUp and > PgDn buttons are what I used). > > One box (gash) had not been upgraded to 7.4 (because I thought it did not > have OpenBSD disks). It was modified, in particular adding Python Idle and > Chromium, to see what happens when 7.3 has the Xserver role and 7.4 the > Xclient role; and the other way round. > > Idle > XserverXclient Display file window Scrolling > 7.47.3 slow stutter > 7.37.4 quicksmooth > 7.47.4 slow stutter > 7.37.3 quicksmooth (from > memory: confirmed on reverting) >Same 7.4 boxquicksmooth > > Idle is started by 'Exec exec ssh -Y idle3.10' in .fvwmrc file. > Chromium is started by 'Exec exec ssh -X @ chrome' in > .fvwmrc file. > > This behaviour with Python persuades me to revert the OpenBSD 7.4 box > (monitor) in the Xserver role to 7.3 until 7.4 or later provides more > acceptable response times. > > Chromium seemed unaffected except for slow response when typing in the URL > bar on the separate 7.4 Xserver box. I thought I could mostly avoid this > by starting to use bookmarks, but the effect on Python matters more. > > Apologies for going off-topic by discussing Python and Chromium rather > than xterm: but the Python stuff changes my attitude to the problem from > minor annoyance to something which needs an immediate workaround. > > Below are dmesg (most recent reboot only) and pkg_info for the OpenBSD 7.3 > box (gash). > > Roger > > Script started on Sat Oct 21 17:09:38 2023 > gash$ dmesg > syncing disks... done > rebooting... > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 3967422464 (3783MB) > avail mem = 3827781632 (3650MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) > bios0: vendor Hewlett-Packard version "786G1 v01.16" date 03/05/2009 > bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR > acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) > PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) > USB5(S3) USB6(S3) EUS1(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0:
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Let me joke that we clealry hope in 7.5 to slow down things further. -- Daniele Bonini
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
On Thu, 19 Oct 2023 17:23:47 + Roger Marsh wrote: > Hi, > > After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this > entry in .fvwmrc (on monitor): > > 'Exec exec ssh -Y opendev xterm -title roger@opendev' > > takes several seconds to deliver the xterm window, while I did not notice any > delay before upgrade. > > For other usernames on opendev the .fvwmrc entry is like (without the '-X' > for most usernames other than grading): > > 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' > > and I do not notice any delay after upgrade compared with before upgrade. > > Expressing the 'roger@opendev' entry as: > > 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' > > fixes the delay problem, but was the delay a predictable consequence of some > change? Or perhaps the entry should never have been expressed in the way > that led to the delay? > > Below are dmsesg and pkg_info for both boxes involved. > > Roger ... dmesg and pkg_info for monitor and opendev snipped. ... Hi, Later I saw opening files with Python's Idle editor suffers the same pattern of slow response, in terms of serving up the file edit window, as seen with xterm. Scrolling through an editor window is slower too, and stutters, compared with what was seen when both boxes were at 7.3 (PgUp and PgDn buttons are what I used). One box (gash) had not been upgraded to 7.4 (because I thought it did not have OpenBSD disks). It was modified, in particular adding Python Idle and Chromium, to see what happens when 7.3 has the Xserver role and 7.4 the Xclient role; and the other way round. Idle XserverXclient Display file window Scrolling 7.47.3 slow stutter 7.37.4 quicksmooth 7.47.4 slow stutter 7.37.3 quicksmooth (from memory: confirmed on reverting) Same 7.4 boxquicksmooth Idle is started by 'Exec exec ssh -Y idle3.10' in .fvwmrc file. Chromium is started by 'Exec exec ssh -X @ chrome' in .fvwmrc file. This behaviour with Python persuades me to revert the OpenBSD 7.4 box (monitor) in the Xserver role to 7.3 until 7.4 or later provides more acceptable response times. Chromium seemed unaffected except for slow response when typing in the URL bar on the separate 7.4 Xserver box. I thought I could mostly avoid this by starting to use bookmarks, but the effect on Python matters more. Apologies for going off-topic by discussing Python and Chromium rather than xterm: but the Python stuff changes my attitude to the problem from minor annoyance to something which needs an immediate workaround. Below are dmesg (most recent reboot only) and pkg_info for the OpenBSD 7.3 box (gash). Roger Script started on Sat Oct 21 17:09:38 2023 gash$ dmesg syncing disks... done rebooting... OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3967422464 (3783MB) avail mem = 3827781632 (3650MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) bios0: vendor Hewlett-Packard version "786G1 v01.16" date 03/05/2009 bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.55 MHz, 06-17-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.57 MHz, 06-17-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa
Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Hi, After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this entry in .fvwmrc (on monitor): 'Exec exec ssh -Y opendev xterm -title roger@opendev' takes several seconds to deliver the xterm window, while I did not notice any delay before upgrade. For other usernames on opendev the .fvwmrc entry is like (without the '-X' for most usernames other than grading): 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' and I do not notice any delay after upgrade compared with before upgrade. Expressing the 'roger@opendev' entry as: 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' fixes the delay problem, but was the delay a predictable consequence of some change? Or perhaps the entry should never have been expressed in the way that led to the delay? Below are dmsesg and pkg_info for both boxes involved. Roger dmseg and pkg_info for 'monitor' 7.4 appears after second 'rebooting...' line. Script started on Thu Oct 19 16:04:50 2023 monitor$ dmesg OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2056990720 (1961MB) avail mem = 1975300096 (1883MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) bios0: vendor Hewlett-Packard version "786G1 v01.08" date 08/25/2008 bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.53 MHz, 06-17-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.59 MHz, 06-17-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 32 (PCX1) acpiprt4 at acpi0: bus -1 (PCX2) acpiprt5 at acpi0: bus 48 (PCX5) acpiprt6 at acpi0: bus -1 (PCX6) acpiprt7 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, G45, gen 4 "Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 1 int 19, address 00:23:7d:20:19:d3 uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 1 int
