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 <m...@online.fr> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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-bugsm=142168911530356w=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 ((fMODE_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-bugsm=142168911530356w=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: HTC426060G9AT00 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: MATSHITA, DVD/CDRW UJDA775, CB03 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 usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4
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.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
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 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)
acpiprt4 at acpi0: bus 4 (RP03
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. /snipped 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 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. /snipped 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 at intagp0: aperture at 0xb000, size 0x1000 inteldrm0 at vga1 drm0
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
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
