Cierre del Ejercicio Fiscal y Laboral 2011 (10 de Noviembre)
Politicas de Privacidad Si no puede ver esta informacisn haga click aqum [IMAGE] POLMTICAS DE CANCELACISN [IMAGE] Corporativo Fiscal Dicada, S.C. posee una rmgida polmtica contra el SPAMming, por lo que respetamos su privacidad. Por favor, si usted no desea recibir mas informacisn y comunicados sobre Corporativo Fiscal Dicada, S.C. o considera que recibis por error este e-mail, le suplicamos haga click aqum, escriba su nombre y lo daremos de baja inmediatamente de nuestra base de datos.
Re: libc/regcomp vulnerable?
Op 5 nov. 2011 om 00:46 heeft Ted Unangst t...@tedunangst.com het volgende geschreven: On Fri, Nov 04, 2011, Johan Ryberg wrote: Hi Just read this: http://securityreason.com/achievement_securityalert/102 Claiming that OpenBSD 5.0 is affected Is it? Red Hat does not consider crash of client application, using regcomp() or regexec() routines on untrusted input without preliminary checking the input for the sanity, to be a security issue. I am, to some extent, inclined to agree. glob() has similar problems which have been fixed because it's frequently used with naughty inputs. regcomp() is different, I think. libc is really not the right layer to be doing input validation. This is a bug in proftpd more than anything else IMO. Yes, although there definitely could be made some improvements to the way out of memory conditions are handled. The use of assert here is ugly. There are also some expressions that could overflow. I need to find some time to dig into these. -Otto
kernel panic on openbsd i386 snapshot 20111103
I am in the process of building a new OpenBSD i386 5.0-release Intel Atom
D510-based fw/router. I was editing some config files on the box in emacs
when the process threw a core dump. Thinking perhaps it was just emacs, I
went to do something else, 'sudo pkg_add -v mutt', and received a coredump
again.
I went looking for stress testing apps, thinking I might have a bad CPU or
RAM module and came upon 'stress'. After several iterations of stress
seeming to cause kernel panics, and then upgrading to a 5.0 snapshot from
November 13, 2011[1], I was still seeing panics. I provide the below detail
to help those more knowledgeable in debugging.
Thanks in advance,
Jeff
[1] http://openbsd.mirrors.tds.net/pub/OpenBSD/snapshots/i386/
Full stress command line:
# stress --cpu 8 --io 4 --vm 2 -m 5 --vm-bytes 128M --timeout 30s -v
panic: rw_enter: vmmaplk locking against myself
Stopped at Debugger+0x4: popl%ebp
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{2} trace
Debugger(d08d8366,dea05ba4,d08b5738,dea05ba4,d0521ecb) at Debugger+0x4
panic(d08b5738,d08cf0ac,0,dea05c3c,d0522be6) at panic+0x5d
rw_enter(d8d4eb48,1,d0d10c20,1,dea05c1c) at rw_enter+0x231
rw_enter_read(d8d4eb48,d0d10bdc,101,dea05c74,) at
rw_enter_read+0x2
1
uvmfault_lookup(dea05d44,0,5f4aa000,3,1) at uvmfault_lookup+0x98
uvm_fault(d8d4eb44,40,0,1,d2725e3c) at uvm_fault+0x59
trap() at trap+0x468
--- trap (number 0) ---
Bad frame pointer: 0xd8acf754
0:
ddb{2} ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
32600 22207 22207 0 2 0stress
9130 22207 22207 0 2 0stress
12362 22207 22207 0 2 0stress
14411 22207 22207 0 2 0stress
9246 22207 22207 0 2 0stress
* 8781 22207 22207 0 7 0stress
28867 22207 22207 0 7 0stress
22593 22207 22207 0 2 0stress
9847 22207 22207 0 7 0stress
17346 22207 22207 0 2 0stress
2098 22207 22207 0 2 0stress
27969 22207 22207 0 2 0stress
13618 22207 22207 0 2 0stress
13017 22207 22207 0 2 0stress
23837 22207 22207 0 2 0stress
24834 22207 22207 0 2 0stress
22390 22207 22207 0 7 0stress
22207 21299 22207 0 30x80 wait stress
21299 12082 21299 0 30x88 pause ksh
18262 28817 28817 95 30x80 kqreadsmtpd
11710 28817 28817 95 30x80 kqreadsmtpd
2941 28817 28817 95 30x80 kqreadsmtpd
3949 28817 28817 95 30x80 kqreadsmtpd
972 28817 28817 95 30x80 kqreadsmtpd
4951 28817 28817 95 30x80 kqreadsmtpd
19759 28817 28817 95 30x80 kqreadsmtpd
28438 28817 28817 95 30x80 kqreadsmtpd
28817 1 28817 0 30x80 kqreadsmtpd
12082 22273 12082 1000 30x88 pause ksh
22273 32054 32054 1000 30x80 selectsshd
32054 22661 32054 0 30x80 poll sshd
8577 1 8577 0 30x80 ttyin getty
31323 1 31323 0 30x80 ttyin getty
27262 1 27262 0 30x80 ttyin getty
870 1870 0 30x80 ttyin getty
24785 1 24785 0 30x80 ttyin getty
20842 1 20842 0 30x80 ttyin getty
23798 1 23798 0 30x80 selectcron
12148 1 12148 0 30x80 selectinetd
22661 1 22661 0 30x80 selectsshd
24417 27000 13320 83 30x80 poll ntpd
27000 13320 13320 83 30x80 poll ntpd
13320 1 13320 0 30x80 poll ntpd
14780 19383 19383 74 30x80 bpf pflogd
19383 1 19383 0 30x80 netio pflogd
14790 23994 23994 73 30x80 poll syslogd
23994 1 23994 0 30x80 netio syslogd
18 0 0 0 30x100200 aiodoned aiodoned
17 0 0 0 30x100200 syncerupdate
16 0 0 0 30x100200 cleaner cleaner
15 0 0 0 30x100200 reaperreaper
Re: kernel panic on openbsd i386 snapshot 20111103
Hi Jeffrey, On Sat Nov 5 2011 07:49, Forman, Jeffrey wrote: I am in the process of building a new OpenBSD i386 5.0-release Intel Atom D510-based fw/router. I was editing some config files on the box in emacs when the process threw a core dump. Thinking perhaps it was just emacs, I went to do something else, 'sudo pkg_add -v mutt', and received a coredump again. I went looking for stress testing apps, thinking I might have a bad CPU or RAM module and came upon 'stress'. After several iterations of stress seeming to cause kernel panics, and then upgrading to a 5.0 snapshot from November 13, 2011[1], I was still seeing panics. I provide the below detail to help those more knowledgeable in debugging. Thanks in advance, Jeff [1] http://openbsd.mirrors.tds.net/pub/OpenBSD/snapshots/i386/ Full stress command line: # stress --cpu 8 --io 4 --vm 2 -m 5 --vm-bytes 128M --timeout 30s -v I did this on my machine as well, it's a i386 single core processor running a single processor kernel. I ran this stress test several times, no panic. Your panic trace also indicates complications with uvm's page fault handler and an MP locking mechanism involved. Therefore, could you try bsd.sp and do the stress testing again? Is it running well now? Norman. OpenBSD 5.0-current (GENERIC) #85: Wed Nov 2 22:27:31 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1.70GHz (GenuineIntel 686-class) 1.70 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 2146299904 (2046MB) avail mem = 2101112832 (2003MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/18/07, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (61 entries) bios0: vendor IBM version 1RETDRWW (3.23 ) date 06/18/2007 bios0: IBM 2374VDL apm0 at bios0: Power Management spec V1.2 acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6e0/0x920 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdea0/272 (15 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #6 is the last bus bios0: ROM list: 0xc/0x1 0xdc000/0x4000! 0xe/0x1! cpu0 at mainbus0: (uniprocessor) cpu0: Enhanced SpeedStep 1695 MHz: speeds: 1700, 1400, 1200, 1000, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) 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 82855PM Host rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xd000, size 0x1000 ppb0 at pci0 dev 1 function 0 Intel 82855PM AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: irq 11 drm0 at radeondrm0 uhci0 at pci0 dev 29 function 0 Intel 82801DB USB rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801DB USB rev 0x01: irq 11 uhci2 at pci0 dev 29 function 2 Intel 82801DB USB rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 Intel 82801DB USB rev 0x01: 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 0x81 pci2 at ppb1 bus 2 mem address conflict 0xb000/0x1000 mem address conflict 0xb100/0x1000 cbb0 at pci2 dev 0 function 0 TI PCI4520 CardBus rev 0x01: irq 11 cbb1 at pci2 dev 0 function 1 TI PCI4520 CardBus rev 0x01: irq 11 em0 at pci2 dev 1 function 0 Intel PRO/1000MT (82540EP) rev 0x03: irq 11, address 00:11:25:32:45:72 iwi0 at pci2 dev 2 function 0 Intel PRO/Wireless 2200BG rev 0x05: irq 11, address 00:0e:35:bc:03:c1 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 cardslot1 at cbb1 slot 1 flags 0 cardbus1 at cardslot1: bus 6 device 0 cacheline 0x8, lattimer 0xb0 pcmcia1 at cardslot1 ichpcib0 at pci0 dev 31 function 0 Intel 82801DBM LPC rev 0x01: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801DBM IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG HM160HC wd0: 16-sector PIO, LBA48, 152627MB, 312581808 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, UJDA745 DVD/CDRW, 1.03 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801DB SMBus rev 0x01: irq 11 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM non-parity PC2700CL2.5 spdmem1 at iic0 addr 0x51: 1GB DDR SDRAM non-parity PC2700CL2.5 auich0 at pci0 dev 31 function 5 Intel 82801DB AC97 rev 0x01: irq 11, ICH4 AC97 ac97: codec id 0x41445374
Re: kernel panic on openbsd i386 snapshot 20111103
On Sat, Nov 5, 2011 at 8:29 AM, Norman Golisz li...@zcat.de wrote: Hi Jeffrey, On Sat Nov 5 2011 07:49, Forman, Jeffrey wrote: I am in the process of building a new OpenBSD i386 5.0-release Intel Atom D510-based fw/router. I was editing some config files on the box in emacs when the process threw a core dump. Thinking perhaps it was just emacs, I went to do something else, 'sudo pkg_add -v mutt', and received a coredump again. I went looking for stress testing apps, thinking I might have a bad CPU or RAM module and came upon 'stress'. After several iterations of stress seeming to cause kernel panics, and then upgrading to a 5.0 snapshot from November 13, 2011[1], I was still seeing panics. I provide the below detail to help those more knowledgeable in debugging. Thanks in advance, Jeff [1] http://openbsd.mirrors.tds.net/pub/OpenBSD/snapshots/i386/ Full stress command line: # stress --cpu 8 --io 4 --vm 2 -m 5 --vm-bytes 128M --timeout 30s -v I did this on my machine as well, it's a i386 single core processor running a single processor kernel. I ran this stress test several times, no panic. Your panic trace also indicates complications with uvm's page fault handler and an MP locking mechanism involved. Therefore, could you try bsd.sp and do the stress testing again? Is it running well now? Norman. OpenBSD 5.0-current (GENERIC) #85: Wed Nov 2 22:27:31 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1.70GHz (GenuineIntel 686-class) 1.70 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 2146299904 (2046MB) avail mem = 2101112832 (2003MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/18/07, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (61 entries) bios0: vendor IBM version 1RETDRWW (3.23 ) date 06/18/2007 bios0: IBM 2374VDL apm0 at bios0: Power Management spec V1.2 acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6e0/0x920 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdea0/272 (15 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #6 is the last bus bios0: ROM list: 0xc/0x1 0xdc000/0x4000! 0xe/0x1! cpu0 at mainbus0: (uniprocessor) cpu0: Enhanced SpeedStep 1695 MHz: speeds: 1700, 1400, 1200, 1000, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) 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 82855PM Host rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xd000, size 0x1000 ppb0 at pci0 dev 1 function 0 Intel 82855PM AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: irq 11 drm0 at radeondrm0 uhci0 at pci0 dev 29 function 0 Intel 82801DB USB rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801DB USB rev 0x01: irq 11 uhci2 at pci0 dev 29 function 2 Intel 82801DB USB rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 Intel 82801DB USB rev 0x01: 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 0x81 pci2 at ppb1 bus 2 mem address conflict 0xb000/0x1000 mem address conflict 0xb100/0x1000 cbb0 at pci2 dev 0 function 0 TI PCI4520 CardBus rev 0x01: irq 11 cbb1 at pci2 dev 0 function 1 TI PCI4520 CardBus rev 0x01: irq 11 em0 at pci2 dev 1 function 0 Intel PRO/1000MT (82540EP) rev 0x03: irq 11, address 00:11:25:32:45:72 iwi0 at pci2 dev 2 function 0 Intel PRO/Wireless 2200BG rev 0x05: irq 11, address 00:0e:35:bc:03:c1 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 cardslot1 at cbb1 slot 1 flags 0 cardbus1 at cardslot1: bus 6 device 0 cacheline 0x8, lattimer 0xb0 pcmcia1 at cardslot1 ichpcib0 at pci0 dev 31 function 0 Intel 82801DBM LPC rev 0x01: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801DBM IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG HM160HC wd0: 16-sector PIO, LBA48, 152627MB, 312581808 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, UJDA745 DVD/CDRW, 1.03 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801DB SMBus rev 0x01: irq 11 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM non-parity PC2700CL2.5 spdmem1 at
Re: kernel panic on openbsd i386 snapshot 20111103
On Sat Nov 5 2011 09:13, Forman, Jeffrey wrote: Am I barking up the wrong tree trying to deduce if I really do have a hardware problem? I am open to accepting diffs and compiling from source if other developers think there might be a bug to fix here. It seems to be a hardware fault. To trap memory issues, you could try memtest86+ [1]. Good luck, Norman [1] http://www.memtest.org/
Re: kernel panic on openbsd i386 snapshot 20111103
On Sat, 5 Nov 2011, Norman Golisz wrote: On Sat Nov 5 2011 09:13, Forman, Jeffrey wrote: Am I barking up the wrong tree trying to deduce if I really do have a hardware problem? I am open to accepting diffs and compiling from source if other developers think there might be a bug to fix here. It seems to be a hardware fault. To trap memory issues, you could try memtest86+ [1]. [1] http://www.memtest.org/ Or ports/sysutils/memtest86+, which is the same and as a package it is easier to deal with - it can be loaded by boot(8) directly from /stand on your root filesystem. No CDs, floppies etc. are needed. As a sidenote, memtest (www.memtest.org) an memtest86+ (www.memtest86.com) are not exactly the same. Regards, David
Re: kernel panic on openbsd i386 snapshot 20111103
On Sat Nov 5 2011 15:07, David Vasek wrote: On Sat, 5 Nov 2011, Norman Golisz wrote: On Sat Nov 5 2011 09:13, Forman, Jeffrey wrote: Am I barking up the wrong tree trying to deduce if I really do have a hardware problem? I am open to accepting diffs and compiling from source if other developers think there might be a bug to fix here. It seems to be a hardware fault. To trap memory issues, you could try memtest86+ [1]. [1] http://www.memtest.org/ Or ports/sysutils/memtest86+, which is the same and as a package it is easier to deal with - it can be loaded by boot(8) directly from /stand on your root filesystem. No CDs, floppies etc. are needed. Thanks for the pointer. I was thinking of burning the ISO, but that's indeed better.
The keyboard doesn't work in X after the most recent update
Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. My dmesg is: OpenBSD 5.0-current (GENERIC) #16: Sat Nov 5 13:14:54 CST 2011 c...@chen-laptop.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz (GenuineIntel 686-class) 2.27 GHz cpu0: FPU,V86,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,SBF,NXE,LONG,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,LAHF real mem = 1998626816 (1906MB) avail mem = 1955852288 (1865MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/07/10, BIOS32 rev. 0 @ 0xfdbe0, SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6QET46WW (1.16 ) date 06/07/2010 bios0: LENOVO 32493DC acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 13 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 2 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4835 serial40 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0x1! 0xd/0x1000 0xd1000/0x1000 0xdd000/0x3000! 0xe/0x1 cpu0: Enhanced SpeedStep 2262 MHz: speeds: 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199, 1066, 933 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel Mobile HD graphics rev 0x02 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 0xd000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 drm0 at inteldrm0 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address f0:de:f1:0a:4a:ee ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x06: msi azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: apic 1 int 20 pci1 at ppb0 bus 13 ppb1 at pci0 dev 28 function 3 Intel 3400 PCIE rev 0x06: apic 1 int 23 pci2 at ppb1 bus 5 ppb2 at pci0 dev 28 function 4 Intel 3400 PCIE rev 0x06: apic 1 int 20 pci3 at ppb2 bus 2 iwn0 at pci3 dev 0 function 0 Intel WiFi Link 1000 rev 0x00: msi, MIMO 1T2R, BGS, address 00:26:c7:5b:20:30 ehci1 at pci0 dev 29 function 0 Intel 3400 USB rev 0x06: apic 1 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xa6 pci4 at ppb3 bus 14 pcib0 at pci0 dev 31 function 0 Intel QM57 LPC rev 0x06 ahci0 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x06: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD2500BEVT-0, 02.0 SCSI3 0/direct fixed naa.50014ee25a080d3b sd0: 238475MB, 512 bytes/sector, 488397168 sectors ichiic0 at pci0 dev 31 function 3 Intel 3400 SMBus rev 0x06: apic 1 int 23 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-8500 SO-DIMM itherm0 at pci0 dev 31 function 6 Intel 3400 Thermal rev 0x06 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 wsmouse1 at pms0 mux 0 pms0: Synaptics touchpad, firmware 7.4 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 aps0 at isa0 port 0x1600/31 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 mtrr: Pentium Pro MTRR support uhub2 at uhub0 port 1 Intel Rate Matching
Re: libc/regcomp vulnerable?
On Sat, Nov 05, 2011 at 11:34:08AM +0100, Otto Moerbeek wrote: Op 5 nov. 2011 om 00:46 heeft Ted Unangst t...@tedunangst.com het volgende geschreven: On Fri, Nov 04, 2011, Johan Ryberg wrote: Hi Just read this: http://securityreason.com/achievement_securityalert/102 Claiming that OpenBSD 5.0 is affected Is it? Red Hat does not consider crash of client application, using regcomp() or regexec() routines on untrusted input without preliminary checking the input for the sanity, to be a security issue. I am, to some extent, inclined to agree. glob() has similar problems which have been fixed because it's frequently used with naughty inputs. regcomp() is different, I think. libc is really not the right layer to be doing input validation. This is a bug in proftpd more than anything else IMO. Yes, although there definitely could be made some improvements to the way out of memory conditions are handled. The use of assert here is ugly. There are also some expressions that could overflow. I need to find some time to dig into these. -Otto Followup on tech@ -Otto
Re: The keyboard doesn't work in X after the most recent update
On Sat Nov 5 2011 22:39, tkdchen wrote:
Hi all,
My keyboard does not work in fvwm, GNOME or KDE after the most recent
update. No key response except the Fn+brightness-up and down.
I run 5.0-current on Thinkpad x201i. Thanks a lot for your help.
This is a known bug in xkb. As suggested on tech@:
_symbols_dir=/usr/X11R6/share/X11/xkb/symbols/srvr_ctrl/srvr_ctrl
mv ${_symbols_dir}/srvr_ctrl ${_symbols_dir}/_srvr_ctrl
mv ${_symbols_dir}/_srvr_ctrl/srvr_ctrl ${_symbols_dir}
rmdir ${_symbols_dir}/_srvr_ctrl
Norman.
Re: The keyboard doesn't work in X after the most recent update
On Sat Nov 5 2011 22:39, tkdchen wrote: Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. Remember to read http://www.openbsd.org/faq/current.html, before applying snapshots or updating your local cvs checkout and compiling from it. Norman.
Re: The keyboard doesn't work in X after the most recent update
2011/11/5 Norman Golisz li...@zcat.de: On Sat Nov 5 2011 22:39, tkdchen wrote: Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. Remember to read http://www.openbsd.org/faq/current.html, before applying snapshots or updating your local cvs checkout and compiling from it. Solved. Thank you all. :) Norman.
Re: The keyboard doesn't work in X after the most recent update
On 11/05/11 15:39, tkdchen wrote: Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. I've noticed that the keyboard of an Asus EEE 701 also doesn't work with Xorg on current (I followed the steps from current.html). However, I didn't test any older versions of OpenBSD on this netbook. Does anybody know if this a known or a new problem with this model? Best Regards Andreas
Re: EeePC, 5.0: acpitz gets wrong temperature
Hi Henri, Le mercredi 2 C 20:48, Henri Kemppainen a C)crit : I just installed a snapshot (dated Oct 19) of -current on a new EeePC 1001PXD. The installation itself went fine. However, on the first boot, even before I can see the login prompt, acpitz decides to shutdown the machine: acpitz0: critical temperature exceeded 255C (5282K), shutting down `dmesg' with this patch is at: http://tar-jx.bz/stuff/dmesg.lapin-5.0-nohaltoncrit From your dmesg: acpiec _REG failed, broken BIOS ASUS has a BIOS update (0702; 2011.04.13) with the this description: Update EC firmware I'd try that. Tell me if it fixes the problem. Thanks for the suggestion. I updated the BIOS. The only relevant difference I see in dmesg is the new version number of the BIOS; I still have the message about a broken BIOS and acpitz finding the temperature too high. For the record: http://tar-jx.bz/stuff/dmesg.lapin-5.0-nohaltoncrit-newbios I've been paying closer attention to the dmesg from Linux and FreeBSD, and indeed, in both cases, I see messages about flaky things in the BIOS. However, both Linux and FreeBSD are able to see the correct temperature. For instanace, under FreeBSD: # sysctl -a ... hw.acpi.thermal.tz0.temperature: 57.0C http://tar-jx.bz/stuff/dmesg.lapin-freebsd9rc1 http://tar-jx.bz/stuff/sysctl-a.lapin-freebsd9rc1 Linux: http://tar-jx.bz/stuff/dmesg.lapin-linux [0.168433] ACPI: EC: EC description table is found, configuring boot EC (I don't know if the EC table was available before the BIOS update; all I know is that Linux was able to get the correct temperature/) [0.249652] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored ... [0.272921] pci:00: Requesting ACPI _OSC control (0x1d) [0.272930] pci:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d Please do tell me if there is more relevant info I can provide. I am far from an expert in ACPI; I have no idea what an EC table is, for instance, and maybe I'm missing something obvious. -- Fred
Re: Has any one had any problem with install50.iso?
Seems I made some things quite unclear here...so, lemme put in a few
words I managed to leave out...
On 11/03/11 18:45, Nick Holland wrote:
On 11/03/11 17:02, Johan Ryberg wrote:
Hi there
I has done some testing with install50.iso and USB stick installations
and yesterday I had problem with corrupt packages like xetc50.tgz and
others and I wanted to debug what happened but today every things
works perfectly.
_corrupt_, or checksum mismatches? HUGE difference.
I haven't changed any scripts that I'm using and the only thing that
is a unknown factor is install50.iso that I downloaded several times
yesterday and several times today. I don't have yesterdays downloaded
iso stored but I'm started to think that the iso was corrupt. I where
using ftp.eu.openbsd.org.
Has any one else experienced any problem with install50.iso?
I don't like loose ends =(
neither do I. :)
Unfortunately, you are very short on details.
Any good OpenBSD mirror will have about 18 files with the name
install50.iso.
that would be nine 5.0-release files, and nine post 5.0 snapshots. It
was not exactly appropriate to assume that people would correctly guess
what I was referring to there.
Some (half!) of them should be absolutely perfect.
The releases, that is.
The other half
the snapshots
will be likely to have checksum mismatches ('specially in
s/will be likely/will potentially from time to time/
things like the X file sets), and are also prone to changes on the fly,
which may result in interesting issues, as they may be updated once a
day (or more. or less).
It was possible to interpret what I said as indicating that many mirrors
may have bad data, and that's just ok. NO IT ISN'T.
Mirrors should not have bad data.
Mirrors should be well maintained and monitored (and hopefully, USED by
those who maintain them!).
Again, mirrors should not have bad data.
Mirrors shipping bad, old, or incomplete data are an error condition
that needs to be fixed. If you spot a bad mirror, bring it up with the
mirror maintainers AND OpenBSD developers, WITH complete information! --
what mirror, what problem you see, exactly where you see it, etc.
(making us guess what and where you are experiencing is not helpful)
Nick.
Re: The keyboard doesn't work in X after the most recent update
Hi Andreas, On Sat Nov 5 2011 18:45, Andreas Bartelt wrote: On 11/05/11 15:39, tkdchen wrote: Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. I've noticed that the keyboard of an Asus EEE 701 also doesn't work with Xorg on current (I followed the steps from current.html). However, I didn't test any older versions of OpenBSD on this netbook. Does anybody know if this a known or a new problem with this model? since 5.0, xenocara uses xkeyboard-config instead of the old /etc/X11/xkb. In the last couple of days, some code has been changed in xkeyboard-config, however, and made keyboards in X non-functional, when the /usr/X11R6/share/X11/xkb/symbols/srvr_ctrl directory was present. This directory was removed and replaced by a bare file [1]. So, chances are, older versions are not affected on your netbook. Best regards, Norman.
Thursday this week: OpenBSD 5.0 release party in Amsterdam
Dear all, The traditional OpenBSD release party in Amsterdam will be held next Thursday the 10th of November. The schedule: 18:00, and earlier, gathering into or in front of cafe De Deugniet (the rascal) close to Amsterdam Central Station. Cafe de Deugniet Oude Brugsteeg 12, 1012 JP Amsterdam http://maps.google.nl/maps?q=De+Deugniet,+Oudebrugsteeg+12,+1012+JP+Amsterdam,+Netherlandshl=nlsll=52.469397,5.509644sspn=8.551394,11.876221vpsrc=0hq=De+Deugniet,+Oudebrugsteeg+12,+1012+JP+Amsterdam,+Netherlandst=hz=15 We will probably have some food at Wing Kee that's located pretty near and easy to find: http://maps.google.nl/maps?saddr=Oudebrugsteeg+12,+1012+JP+Amsterdam+(Caf%C3%A9+De+Deugniet)daddr=Zeedijk+76,+1012+BA+Amsterdamhl=nlie=UTF8sll=52.374453,4.89898sspn=0.008364,0.011598geocode=FT4vHwMdBrtKACEWhC8Zcv0VyilDB1louAnGRzG5LMpY4Vkq2g%3BFcsrHwMdz8ZKACmFEKSguQnGRzHTCZxRGQKfQgvpsrc=0dirflg=wmra=ltmt=hz=18 From 20:00 on we will gather into De Deugniet and have a drink on OpenBSD 5.0. Please don't hesitate to attend, it's a proven opportunity to meet OpenBSD people, developers, system administrators, users and fans. If further information is needed, please contact me or Floor Terra! +++chefren
Tapis d'entrée personnalisé avec logo
nbsp;nbsp;nbsp;nbsp;Actimat, l'entreprise majeure du tapis personnaliseacute; fecirc;te ses 19 ans !nbsp;nbsp; Bonjour, 19 ans pour Actimat, c'est 19 % de reacute;duction pour ses clients. Sans tarder, demandez un chiffrage pour un tapis d'entreacute;e personnaliseacute; et beacute;neacute;ficiez de cette offre exceptionnelle jusqu'au 15/12/2011. Code anniversaire 19% : ANNIV Retrouvez les deacute;tails de l'offre sur Actimat.com nbsp;nbsp;Cordialement, nbsp;nbsp;L'eacute;quipe commerciale Actimat. Disinscrire misc@openbsd.org de notre NewsLetter : Cliquez ici
