Re: Remove extra brackets from MINIMUM definition ber.c
On 05/30/17 20:15, Ted Unangst wrote: Fred wrote: I was greping the tree for MINIMUM and this one stood out as it was (((a) rather than ((a). not sure why this one stood out. the 16 definitions of MAXIMUM in bin and sbin are all the same. i don't think we really need churn changing either way. Okay Cheers Fred
Re: Remove extra brackets from MINIMUM definition ber.c
On 05/30/17 19:57, Theo de Raadt wrote: No. This is consistant with a couple hundred others in the tree, which were originally copied from sys/param.h before we cleaned userland from using the file. The brackets were good enough for CSRG, and they are good enough for me... This patch removes the redundant brackets form the MINIMUM macro in ber.c Cheers Fred Index: ber.c === RCS file: /cvs/src/usr.sbin/ldapd/ber.c,v retrieving revision 1.12 diff -u -p -u -p -r1.12 ber.c --- ber.c 11 Feb 2017 20:40:03 - 1.12 +++ ber.c 30 May 2017 17:34:14 - @@ -31,7 +31,7 @@ #include "ber.h" -#define MINIMUM(a, b) (((a) < (b)) ? (a) : (b)) +#define MINIMUM(a, b) ((a) < (b) ? (a) : (b)) #define BER_TYPE_CONSTRUCTED 0x20/* otherwise primitive */ #define BER_TYPE_SINGLE_MAX 30 I was greping the tree for MINIMUM and this one stood out as it was (((a) rather than ((a). I have also noticed that their are two minimum definitions in the tcpdump code one is MIN(a, b) the other is min(a, b) would you be interested in a diffs that converted them both to MINIMUM? Cheers Fred
Remove extra brackets from MINIMUM definition ber.c
This patch removes the redundant brackets form the MINIMUM macro in ber.c Cheers Fred Index: ber.c === RCS file: /cvs/src/usr.sbin/ldapd/ber.c,v retrieving revision 1.12 diff -u -p -u -p -r1.12 ber.c --- ber.c 11 Feb 2017 20:40:03 - 1.12 +++ ber.c 30 May 2017 17:34:14 - @@ -31,7 +31,7 @@ #include "ber.h" -#define MINIMUM(a, b) (((a) < (b)) ? (a) : (b)) +#define MINIMUM(a, b) ((a) < (b) ? (a) : (b)) #define BER_TYPE_CONSTRUCTED 0x20/* otherwise primitive */ #define BER_TYPE_SINGLE_MAX30
Re: remove IF_PREPEND in src/sys/dev/pci, was Re: IFQ_PREPEND
On 11/08/15 01:06, David Gwynne wrote: On 8 Nov 2015, at 8:23 AM, Miod Vallat wrote: noone has a vr? You can't expect people to use the crappiest Ethernet chip ever designed. theyre in the alix, surely someone has those still. i thought le(4) was the worst. Finally tested this patch on: vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 00:0d:b9:17:d8:90 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 graybox:fred ~> ifconfig vr0 vr0: flags=8843 mtu 1500 lladdr 00:0d:b9:17:d8:90 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.5.7 netmask 0xff00 broadcast 192.168.5.255 And so far there has been no obvious regressions. Thanks Fred
Re: ed(1): keep custom prompt string that was specified by -p
On 06/18/15 15:18, Jason McIntyre wrote: On Thu, Jun 18, 2015 at 03:56:15PM +0200, Theo Buehler wrote: >From looking at the source code, I'm quite sure that the other BSD's behavior is the same as the current behavior in OpenBSD. I agree that the formulations in the manpages and POSIX aren't explicit, let alone unambiguous, as to what exactly is supposed to happen when pressing "P". However, what POSIX claims about "P" being a synonym of "p" is bogus: * BSD does not support the P command; moreover, in BSD it is synonymous with the p command. Compare this with the following session: $ ed p ? P *p ? *P q $ The source code in FreeBSD and NetBSD shows that the "print command p" and the "prompt command P" are treated completely differently there as well. the posix stuff no doubt relates to traditional bsd behaviour. obviously "P" is now supported. if other systems behave this way and no one steps up to support the idea of changing behaviour, i'll add a note to the doc. but i'll wait and see first. jmc $ uname -a; ed -p "::> " FreeBSD s3 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 ::> P P ::> q $ FreeBSD ed follows the behaviour of Theo Buehler's patch. hth Fred
Re: telnet not sending return
Hi tech@, The following patch [1] resolves my issue with telnet - by allowing me to login into a Cisco CP-7940G IP Phone - and slightly improves the telnet issue with regards to 'send dont echo' [2]. There is still an issue that if you set 'dont echo' all characters appear twice on the terminal, this existed prior to Brabec's bug report and with the fix to [2], as shown: Cisco7960> telnet> send dont echo sshhooww Thanks Fred [2] http://marc.info/?l=openbsd-bugs&m=142168911530356&w=2 [2] Index: sys_bsd.c === RCS file: /cvs/src/usr.bin/telnet/sys_bsd.c,v retrieving revision 1.29 diff -u -p -u -r1.29 sys_bsd.c --- sys_bsd.c 12 Feb 2015 09:50:50 - 1.29 +++ sys_bsd.c 21 Mar 2015 23:28:23 - @@ -283,6 +283,7 @@ TerminalNewMode(int f) } else { tmp_tc.c_lflag &= ~ECHO; tmp_tc.c_oflag &= ~ONLCR; + tmp_tc.c_iflag &= ~ICRNL; } if ((f&MODE_FLOW) == 0) {
telnet not sending return
Hi, Revision 1.29 to usr.bin/telnet/sys_bsd.c breaks telnet for me. The issue is that return is not sent when entering a password, when connected by telnet to a device[1]. The patch below [3] reverts the change and telnet then works again. This change does not solve the problem [2] that brought this change about. I will see if I can work out a fix that solves both problems. Cheers Fred [1] Cisco CP7940G IP Phone [2] http://marc.info/?l=openbsd-bugs&m=142168911530356&w=2 [3] Index: sys_bsd.c === RCS file: /cvs/src/usr.bin/telnet/sys_bsd.c,v retrieving revision 1.29 diff -u -p -u -r1.29 sys_bsd.c --- sys_bsd.c 12 Feb 2015 09:50:50 - 1.29 +++ sys_bsd.c 21 Mar 2015 00:23:35 - @@ -310,6 +310,7 @@ TerminalNewMode(int f) tmp_tc.c_lflag |= ICANON; } else { tmp_tc.c_lflag &= ~ICANON; + tmp_tc.c_iflag &= ~ICRNL; tmp_tc.c_cc[VMIN] = 1; tmp_tc.c_cc[VTIME] = 0; }
Re: keyboard and mouse problems
On 03/14/15 21:48, Theo de Raadt wrote: yes, can you try the next snapshot? we are muddling our way through trying to find a series of fixes for a problem :) Laptop keyboard now working again, as expected with: OpenBSD 5.7-current (RAMDISK_CD) #723: Sat Mar 14 14:51:43 MDT 2015 bsd.rd dmesg below. Thanks Fred Script started on Sun Mar 15 10:53:03 2015 port:fred ~> cu -l /dev/cuaU0 -s115200 Connected to /dev/cuaU0 (speed 115200) bsd.rd /-\|/-\booting hd0a:bsd.rd: |/-\|6494084/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+423044 [72+243584-\|/-\|/-\|/-\|+233906/-\|/-\|/-\|/-]=0x70d720 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.7-current (RAMDISK_CD) #723: Sat Mar 14 14:51:43 MDT 2015 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,EST,TM2,PERF real mem = 1600516096 (1526MB) avail mem = 1566670848 (1494MB) mainbus0 at root bios0 at mainbus0: date 03/14/06, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (59 entries) bios0: vendor IBM version "74ET61WW (2.06 )" date 03/14/2006 bios0: IBM 2525FAG acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (EXP0) acpiprt2 at acpi0: bus -1 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 4 (PCI1) acpiprt6 at acpi0: bus -1 (DOCK) bios0: ROM list: 0xc/0xe800! 0xce800/0x1600 0xd/0x1000 0xdc000/0x4000! 0xe/0x1 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03 vga1 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: apic 1 int 20 pci1 at ppb0 bus 2 bge0 at pci1 dev 0 function 0 "Broadcom BCM5751M" rev 0x11, BCM5750 B1 (0x4101): apic 1 int 16, address 00:16:d3:2f:63:7c brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16 uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17 uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19 ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3 pci2 at ppb1 bus 4 cbb0 at pci2 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0x8d: apic 1 int 16 sdhc0 at pci2 dev 0 function 1 "Ricoh 5C822 SD/MMC" rev 0x13: apic 1 int 17 sdmmc0 at sdhc0 iwi0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2915ABG" rev 0x05: apic 1 int 21, address 00:16:6f:c1:16:40 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 5 device 0 cacheline 0x0, lattimer 0xb0 pcmcia0 at cardslot0 "Intel 82801FB AC97" rev 0x03 at pci0 dev 30 function 2 not configured "Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured pcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03 pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 "Intel 82801FB SMBus" rev 0x03 at pci0 dev 31 function 3 not configured usb1 at uhci0: USB revision 1.0 uhub1 at us
Re: keyboard and mouse problems
On 03/11/15 15:11, Theo de Raadt wrote: Two related problems regarding mice and keyboards came to my attention during s2k15 in Brisbane and I worked with jcs@ on solutions. The first problem is some newer machines (such as the thinkpad x1) have keyboard repeat or stuttering during install -- this issue only happes on the RAMDISK kernel. Eventually we figured out that this is due to the large touchpad! Even a light brush against it would mess up the pckbc driver subtly, causing 10 second pauses. This happens because the RAMDISK media lacks the pms driver. The solution is to forcibly reset the mouse port at attach. We initially thought this change would only be needed for RAMDISK, but it looks like this sequence was always missing in the past, and we need it. The second related issue is that boot -c on some machines has never worked. The keyboard would be unresponsive. It turns out this is also related to mouse ports which have not been reset. These changes did not make the cut for 5.7, because there are a plethora of keyboard contoller models, on PCs and non-PCs. We need lots of testing before it goes in. Hi Theo & tech@ I'm seeing an issue with bsd.rd on i386 snapshot from Fri Mar 13, the output from bsd.rd boot is shown at [1] on a ThinkPad X41. My issue is that the built in laptop keyboard does not respond at all - but plugging in an external usb keyboard allowed me to complete the upgrade with no problems. Is this fall out from this change, as I see a version of the above diff was commited on 12 Mar? I am currently bring my src tree up todate and will try and build a ramdisk kernel with the 1.45 changes to pckbc.c to see if that solves the issue. Thanks Fred [1] Script started on Sat Mar 14 20:40:54 2015 Connected to /dev/cuaU1 (speed 115200) bsd.rd /-\|/-\booting hd0a:bsd.rd: |/-\|6494084/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+423044 [72+243584-\|/-\|/-\|/-\|+233906/-\|/-\|/-\|/-]=0x70d720 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.7-current (RAMDISK_CD) #721: Fri Mar 13 18:01:01 MDT 2015 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,EST,TM2,PERF real mem = 1600516096 (1526MB) avail mem = 1566670848 (1494MB) mainbus0 at root bios0 at mainbus0: date 03/14/06, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (59 entries) bios0: vendor IBM version "74ET61WW (2.06 )" date 03/14/2006 bios0: IBM 2525FAG acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (EXP0) acpiprt2 at acpi0: bus -1 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 4 (PCI1) acpiprt6 at acpi0: bus -1 (DOCK) bios0: ROM list: 0xc/0xe800! 0xce800/0x1600 0xd/0x1000 0xdc000/0x4000! 0xe/0x1 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03 vga1 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: apic 1 int 20 pci1 at ppb0 bus 2 bge0 at pci1 dev 0 function 0 "Broadcom BCM5751M" rev 0x11, BCM5750 B1 (0x4101): apic 1 int 16, address 00:16:d3:2f:63:7c brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16 uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17 uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19 ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2
Re: pstat segfault
On 12/19/14 18:12, Ted Unangst wrote: On Fri, Dec 19, 2014 at 13:04, Stuart Cassoff wrote: On 12/19/14 07:18, Stuart Cassoff wrote: $ pstat -T 221/7030 open files Segmentation fault I suppose more info from me is desired. I think that was sufficient. It should be fixed now. Hi Ted, It's fixed, but if I run pstat as an ordinary user I get: port:fred /usr/src/usr.sbin/pstat> ./pstat -T pstat: kvm_openfiles: /dev/mem: Permission denied rather than: port:fred /usr/src/usr.sbin/pstat> sudo ./pstat -T Password: 1477/7030 open files 34681 vnodes 0M/8311M swap space But pstat -f works as expected as an ordinary user. Cheers Fred PS This with pstat.c patched to 1.96
Re: run(4) firmware update; please test
On 05/15/14 10:35, Stefan Sperling wrote: This firmware update to version 0.33 is a prequisite for newer run(4) devices which are not yet supported. Can active users of run(4) devices please test this update to make sure no regressions are introduced for already working devices? I don't have a supported run(4) device to test with. cd /usr/src/sys/dev/microcode/rum # yes, rum with m patch < this-patch make obj make depend sudo make install I've obtained permission from Mediatek/Ralink to distribute this firmware update under the terms in /etc/firmware/run-license. Hi, Tested with the at TP-Link TL-WN727N USB Wifi device: May 15 13:24:46 x41 /bsd: run0 at uhub0 port 4 "Ralink 802.11 n WLAN" rev 2.00/1.01 addr 3 May 15 13:24:46 x41 /bsd: run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 74:ea:3a:8a:b6:8f No regressions with this diff. Thanks Fred
Re: detach before suspend and attach after resume
On 03/25/14 23:07, Fred wrote: On 03/25/14 22:56, Fred wrote: On 03/25/14 20:42, Martin Pieuchot wrote: This diff should help to avoid some races occurring when resuming a machine with USB devices, please test! Since the Host Controllers are halted during suspend and reset on wakeup, all the connected USB devices are disconnected during a suspend/resume cycle. When a device is disconnected its pipes are aborted and closed, right now this is done *after* resuming. But since the HC have already been reset and some timeout might also fire, that generates a lot of problems. So the diff below detaches the root hub of every controller before suspending, so that no device stay "logically" attached when suspended. Make sure you have my last commit to all *hci.c before trying this, and report any regression/success story. I've just noticed that my ehci.c is at v 1.145 and not 1.146 - I'll bring my source up to date and try again. Sorry for the noise. Fred No regressions - once my source tree was up to date. Cheers Fred -- dmesg: OpenBSD 5.5-current (usbGEN.MP) #0: Tue Mar 25 21:17:49 GMT 2014 f...@port.crowsons.com:/usr/src/sys/arch/amd64/compile/usbGEN.MP real mem = 8447131648 (8055MB) avail mem = 8213540864 (7833MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xaafd (43 entries) bios0: vendor TOSHIBA version "Version 3.60" date 01/24/2012 bios0: TOSHIBA TOSHIBA acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! TCPA BOOT SLIC SSDT SSDT SSDT SSDT acpi0: wakeup devices LANC(S4) HDEF(S3) RP02(S4) PXSX(S4) RP04(S4) PXSX(S4) USBB(S4) USBC(S4) EHC1(S4) EHC2(S4) PWRB(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.21 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEGP) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 4 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus 5 (RP05) acpiprt7 at acpi0: bus 6 (RP06) acpiprt8 at acpi0: bus 7 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PCIB) acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpicpu2 at acpi0: C1, PSS acpicpu3 at acpi0: C1, PSS acpipwrres0 at acpi0: PDOC, resource for DOCK acpitz0 at acpi0: critical temperature is 102 degC acpitoshiba0 at acpi0 acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID_ acpibat0 at acpi0: BAT1 model "G71C000E4410" serial 001888 type Li-ION oem "0" acpidock0 at acpi0: DOCK not docked (0) cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 intagp0 at vga1 agp0
Re: detach before suspend and attach after resume
On 03/25/14 22:56, Fred wrote: On 03/25/14 20:42, Martin Pieuchot wrote: This diff should help to avoid some races occurring when resuming a machine with USB devices, please test! Since the Host Controllers are halted during suspend and reset on wakeup, all the connected USB devices are disconnected during a suspend/resume cycle. When a device is disconnected its pipes are aborted and closed, right now this is done *after* resuming. But since the HC have already been reset and some timeout might also fire, that generates a lot of problems. So the diff below detaches the root hub of every controller before suspending, so that no device stay "logically" attached when suspended. Make sure you have my last commit to all *hci.c before trying this, and report any regression/success story. I've just noticed that my ehci.c is at v 1.145 and not 1.146 - I'll bring my source up to date and try again. Sorry for the noise. Fred
Re: detach before suspend and attach after resume
On 03/25/14 20:42, Martin Pieuchot wrote: This diff should help to avoid some races occurring when resuming a machine with USB devices, please test! Since the Host Controllers are halted during suspend and reset on wakeup, all the connected USB devices are disconnected during a suspend/resume cycle. When a device is disconnected its pipes are aborted and closed, right now this is done *after* resuming. But since the HC have already been reset and some timeout might also fire, that generates a lot of problems. So the diff below detaches the root hub of every controller before suspending, so that no device stay "logically" attached when suspended. Make sure you have my last commit to all *hci.c before trying this, and report any regression/success story. Hi Martin, This caused a regression on my amd64 laptop - dmesg with patch is below in [1] and normal dmesg is also below at [2] - the following is transcribed from pictures of the crash: The fault was: uvm_fault(0xfff81dc6f00, 0x0, 0, 1) -> e kernel: page fault trap, code=0 Stopped at usbd_do_request_flags+0x33: movq 0(%rdi),%rax ddb{0}> trace usbd_do_request_flags() at usb_do_request_flags+0x33 usbd_reset_port() at usbd_reset_port+0x49 usbd_new_device() at usbd_new_device+0x1b0 usb_attach_roothub() at usb_attach_roothub+0x21 usb_activate() at usb_activate+0x56 config_suspend() at config_suspend+0x37 config_activate_children() at config_activate_children+0x4d config_suspend() at config_suspend+0x37 config_activate_children() at config_activate_children+0x4d config_suspend() at config_suspend+0x37 config_activate_children() at config_activate_children+0x4d config_suspend() at config_suspend+0x5c acpi_sleep_state() at acpi_sleep_state+0xde acpi_sleep_task() at acpi_sleept_task+0xf acpi_dotask() at acpi_dotask+0x55 acpi_thread() at acpi_thread+0x11d end trace frame: 0x0, count: -16 I will try and find away of capturing the panic as it will take me a month of sundays to transcribe all the output from ps. Cheers Fred [1] OpenBSD 5.5-current (usbGEN.MP) #0: Tue Mar 25 21:17:49 GMT 2014 f...@port.crowsons.com:/usr/src/sys/arch/amd64/compile/usbGEN.MP real mem = 8447131648 (8055MB) avail mem = 8213540864 (7833MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xaafd (43 entries) bios0: vendor TOSHIBA version "Version 3.60" date 01/24/2012 bios0: TOSHIBA TOSHIBA acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! TCPA BOOT SLIC SSDT SSDT SSDT SSDT acpi0: wakeup devices LANC(S4) HDEF(S3) RP02(S4) PXSX(S4) RP04(S4) PXSX(S4) USBB(S4) USBC(S4) EHC1(S4) EHC2(S4) PWRB(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.21 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEGP) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02
Re: [PATCH] frame length validation for USB ethernet adapters
On 03/19/11 18:01, Loganaden Velvindron wrote: Hi, I'm uploading the new diffs for this. It concerns axe(4), aue(4), cdce(4), cue(4), kue(4), mos(4) and url(4). Of these, axe(4) is the most tricky, and I'd appreciate testing on all vaariants of axe(4). Please test both small and large packets (NFS and SCP). As usual, feedback is most welcomed. Hi, Running the patch here for Linksys USB adapter: x41:fred ~> dmesg|grep url url0 at uhub2 port 2 "Linksys Linksys USB LAN Adapter" rev 1.10/1.00 addr 2 url0: address 00:10:60:e9:42:87 urlphy0 at url0 phy 0: RTL internal phy No regressions so far. Thanks Fred -- PS dmesg follows: OpenBSD 4.9-current (usbeth) #0: Sun Mar 20 11:08:54 GMT 2011 f...@x41.crowsons.com:/usr/src/sys/arch/i386/compile/usbeth cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 1600548864 (1526MB) avail mem = 1564225536 (1491MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/14/06, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (59 entries) bios0: vendor IBM version "74ET61WW (2.06 )" date 03/14/2006 bios0: IBM 2525FAG apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6e0/0x920 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdec0/240 (13 entries) pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc/0xe800! 0xce800/0x1600 0xd/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0 at mainbus0: (uniprocessor) cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) mem address conflict 0x5f70/0x8 io address conflict 0x5800/0x8 io address conflict 0x5808/0x4 io address conflict 0x5810/0x8 io address conflict 0x580c/0x4 pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03 vga1 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: no ifp : irq 11 drm0 at inteldrm0 "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: irq 11 pci1 at ppb0 bus 2 bge0 at pci1 dev 0 function 0 "Broadcom BCM5751M" rev 0x11, BCM5750 B1 (0x4101): irq 11, address 00:16:d3:2f:63:7c brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: irq 11 uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: irq 11 uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: irq 11 uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: irq 11 ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3 pci2 at ppb1 bus 4 cbb0 at pci2 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0x8d: irq 11 sdhc0 at pci2 dev 0 function 1 "Ricoh 5C822 SD/MMC" rev 0x13: irq 11 sdmmc0 at sdhc0 iwi0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2915ABG" rev 0x05: irq 11, address 00:16:6f:c1:16:40 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 5 device 0 cacheline 0x0, lattimer 0xb0 pcmcia0 at cardslot0 auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: irq 11, ICH6 AC97 ac97: codec id 0x41445374 (Analog Devices AD1981B) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 "Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 "Intel 82801FB SMBus" rev 0x03: irq 11 iic0 at ichiic0 spdmem0 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-4200CL3 SO-DIMM usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.0
Re: [patch] -H flag for grep.
On 02/21/11 15:54, Alexander Schrijver wrote: On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote: Implement a -H flag for grep, useful for combining e.g. find and grep. -o used to do this but has been removed. (See the commit logs for the reason, i forgot it) grep(1) only prints the filename when it receives more then 1 filename as arguments. Thus, when you do this: $ find . -name '*.c' -exec grep bla {} \; It doesn't print the filename. But when you use xargs(1), like Bret suggests it does. $ find . -name "*.php" -exec grep blah {} \; -print Will print the file name after the line that grep matches. hth Fred
missing function definition uvm_pmemrange.c
Hi tech@ While trying to build a debug ramdisk kernel - I came across a build error in uvm_pmemrange.c where the function uvm_pmr_isfree was not defined, I've added it to #ifdef not sure if this is the correct process or whether it needs its own #ifdef. diff -ui follows. Thanks Fred x41:fred /usr/src/sys/uvm> diff -ui uvm_pmemrange.c my_uvm_pmerange.c --- uvm_pmemrange.c Fri Jul 16 20:34:42 2010 +++ my_uvm_pmerange.c Fri Jul 16 12:36:59 2010 @@ -75,8 +75,10 @@ intuvm_pmr_size_cmp(struct vm_page *, struct vm_page *); intuvm_pmr_pg_to_memtype(struct vm_page *); -#ifdef DDB + +#if defined(DDB) || defined(DEBUG) void uvm_pmr_print(void); +intuvm_pmr_isfree(struct vm_page *pg); #endif /*
typos in #ifdef DEBUG
Hi tech@ While building a kernel with option DEBUG to try to hunt down my issue with the Libretto 70CT (PR 6052) I came across the following typos which prevented the build: sys/arch/i386/i386/trap.c --- trap.c Wed Jul 14 00:55:31 2010 +++ mytrap.cWed Jul 14 00:44:26 2010 @@ -173,7 +173,7 @@ #ifdef DEBUG if (trapdebug) { printf("trap %d code %x eip %x cs %x eflags %x cr2 %x cpl %x\n", - frame->tf_trapno, frame->tf_err, frame.->f_eip, + frame->tf_trapno, frame->tf_err, frame->tf_eip, frame->tf_cs, frame->tf_eflags, rcr2(), lapic_tpr); printf("curproc %p\n", curproc); } and in sys/kern/dma_alloc.c --- dma_alloc.c Wed Jul 14 01:05:14 2010 +++ my_dma_alloc.c Wed Jul 14 00:26:56 2010 @@ -49,7 +49,7 @@ if (sz <= (1 << (b + DMA_BUCKET_OFFSET))) return (b); #ifdef DEBUG - printf("dma_alloc/free: object %d too large\n", sz) + printf("dma_alloc/free: object %d too large\n", sz); #endif return (-1); } Thanks Fred