Re: CUPS printer problems
On 25/11/14 04:30, Antoine Jacoutot wrote: > On Mon, Nov 24, 2014 at 10:04:59PM +, Bernte wrote: >> Hi - >> >> Since upgrading to 5.6, I am having problems to detect my Brother USB >> printer in CUPS. >> >> The problem is that the printer is not found by the 'usb' backend: > > Your cups package is not up to date. You need the one from 5.6 stable. Thanks Antoine, upgrading to cups-1.7.4p1 made CUPS detect my printer. Issue fixed. Bernd
USB hub stopped working
Hi, I have this USB hub, which is connected to my desktop PC; it makes the USB ports accessible w/o need to crawl under the desk. I'll seldom need to transfer files (to/fro) with a USB stick, which I plug into one of the hub ports. I don't quite recall when it was last used. But with 2014-NOV-21 snapshot it doesn't seem to work. OpenBSD 5.6-current (GENERIC) #563: Fri Nov 21 10:09:03 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Plug it in, and it is detected: uhub5 at uhub0 port 1 "Genesys Logic USB2.0 Hub" rev 2.00/7.02 addr 3 Plug in a USB mem-stick and nothing. Unplug the USB stick from hub: nothing. Unplug hub from computer's USB port: uhub5 detached Plug the USB stick directly into the same USB port on the computer: umass0 at uhub0 port 1 configuration 1 interface 0 "Kingston DT 101 G2" rev 2.00/1.00 addr 3 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd1 at scsibus4 targ 1 lun 0: SCSI0 0/direct removable serial.09511EFEFA510245 sd1: 7640MB, 512 bytes/sector, 15646720 sectors Note, that above is pulled from a Gateway LT31 netbook, b/c of easier access, and b/c w/2014-SEP-09 snapshot, the unplugging of the USB stick (or any other USB device) from the USB hub would dump into ddb. Unfortunately I couldn't gather much info from ddb as my USB keyboard wouldn't respond, also, I wanted to try with a newer -current, which doesn't seem to trigger the crash (at least on this netbook it does not). The crash, from memory, was in usb_allocmem(). Regardless, am I missing something with respect to the hub not working, or did something break? Plugging the USB hub into an OSX running MacBook Pro seems to work as expected. USB mem-stick shows up on "desktop" and files stored within can be accessed. Thoughts? --patrick OpenBSD 5.6-current (GENERIC) #563: Fri Nov 21 10:09:03 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1861025792 (1774MB) avail mem = 1807745024 (1724MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1010 (17 entries) bios0: vendor Phoenix Technologies LTD version "v1.3307" date 05/31/2010 bios0: Gateway LT31 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET BOOT SLIC acpi0: wakeup devices PB5_(S5) OHC1(S3) OHC2(S3) EHCI(S3) HDAU(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) Processor L110, 1197.20 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-8 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB3_) acpiprt2 at acpi0: bus -1 (PB4_) acpiprt3 at acpi0: bus 3 (PB5_) acpiprt4 at acpi0: bus 4 (PB6_) acpiprt5 at acpi0: bus -1 (PB7_) acpiprt6 at acpi0: bus 9 (P2P_) acpiprt7 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2 acpitz0 at acpi0: critical temperature is 100 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model "UM09A41" serial 22962 type LION oem "SONY" acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "ATI RS690 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 "ATI RS690 PCIE" rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 "ATI Radeon X1250 IGP" rev 0x00 drm0 at radeondrm0 radeondrm0: msi ppb1 at pci0 dev 5 function 0 "ATI RS690 PCIE" rev 0x00: msi pci2 at ppb1 bus 3 re0 at pci2 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480), msi, address 00:23:8b:ef:ef:ef rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 ppb2 at pci0 dev 6 function 0 "ATI RS690 PCIE" rev 0x00: msi pci3 at ppb2 bus 4 ral0 at pci3 dev 0 function 0 "Ralink RT3090" rev 0x00: apic 1 int 18, address 00:24:1d:f4:3d:86 ral0: MAC/BBP RT3071 (rev 0x0213), RF RT3020 (MIMO 1T1R) ahci0 at pci0 dev 18 function 0 "ATI SB600 SATA" rev 0x00: apic 1 int 22, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5000cca71eed589f sd0: 476940MB, 512 bytes/sector, 976773168 sectors ohci0 at pci0 dev 19 function 0 "ATI SB600 USB" rev 0x00: apic 1 int 16, version 1.0, legacy support ohci1 at pci0 dev 19 function 1 "ATI SB600 USB" rev 0x00: apic 1 int 17, version 1.0, legacy s
Re: CUPS printer problems
On Tue, 25 Nov 2014 07:10:07 +0100 Antoine Jacoutot wrote: > On Mon, Nov 24, 2014 at 10:59:10PM -0700, Duncan Patton a Campbell wrote: > > On Tue, 25 Nov 2014 05:30:53 +0100 > > Antoine Jacoutot wrote: > > > > > On Mon, Nov 24, 2014 at 10:04:59PM +, Bernte wrote: > > > > Hi - > > > > > > > > Since upgrading to 5.6, I am having problems to detect my Brother USB > > > > printer in CUPS. > > > > > > > > The problem is that the printer is not found by the 'usb' backend: > > > > > > Your cups package is not up to date. You need the one from 5.6 stable. > > > > > > > Bj Antoine. > > > > cups-1.7.4p0.tgz is in release, and cups-2.0.1.tgz is in snapshot. Is > > there something in between, that would be in the errata if there was > > one for snapshot like there's a http://www.openbsd.org/plus.html between > > 5.6 and 5.6+ ? > > Use ports. Just checkout the OPENBSD_5_6 branch. > http://www.openbsd.org/faq/faq15.html#PortsSecurity > Well it appears to be building ;-) I don't exaclty run a polyblade machine here. > > I've tried 1.7.4p0 on both i386 and amd64 with results strikingly like > > those describe by Bernte. Hmmm. Do I build 2.0 from ports or up to > > the snap and take my chances on other things Or attempt to backup > > to 1.4 or 1.5? > > 1.7.4p0 is not the latest port for OpenBSD 5.6, it is 1.7.4p1. > > Revision 1.182.2.1 / (download) - annotate - [select for diffs], Thu Sep 11 > 09:55:33 2014 UTC (2 months, 2 weeks ago) by ajacoutot ?>450 ports/packages altho' you might be. merci. > Branch: OPENBSD_5_6 > Changes since 1.182: +2 -2 lines > Diff to previous 1.182 (colored) next main 1.183 (colored) > > Fix USB printing. > > > -- > Antoine > > -- Ne obliviscaris, vix ea nostra voco.
Re: CUPS printer problems
On Mon, Nov 24, 2014 at 10:59:10PM -0700, Duncan Patton a Campbell wrote: > On Tue, 25 Nov 2014 05:30:53 +0100 > Antoine Jacoutot wrote: > > > On Mon, Nov 24, 2014 at 10:04:59PM +, Bernte wrote: > > > Hi - > > > > > > Since upgrading to 5.6, I am having problems to detect my Brother USB > > > printer in CUPS. > > > > > > The problem is that the printer is not found by the 'usb' backend: > > > > Your cups package is not up to date. You need the one from 5.6 stable. > > > > Bj Antoine. > > cups-1.7.4p0.tgz is in release, and cups-2.0.1.tgz is in snapshot. Is > there something in between, that would be in the errata if there was > one for snapshot like there's a http://www.openbsd.org/plus.html between > 5.6 and 5.6+ ? Use ports. Just checkout the OPENBSD_5_6 branch. http://www.openbsd.org/faq/faq15.html#PortsSecurity > I've tried 1.7.4p0 on both i386 and amd64 with results strikingly like > those describe by Bernte. Hmmm. Do I build 2.0 from ports or up to > the snap and take my chances on other things Or attempt to backup > to 1.4 or 1.5? 1.7.4p0 is not the latest port for OpenBSD 5.6, it is 1.7.4p1. Revision 1.182.2.1 / (download) - annotate - [select for diffs], Thu Sep 11 09:55:33 2014 UTC (2 months, 2 weeks ago) by ajacoutot Branch: OPENBSD_5_6 Changes since 1.182: +2 -2 lines Diff to previous 1.182 (colored) next main 1.183 (colored) Fix USB printing. -- Antoine
Re: CUPS printer problems
On Tue, 25 Nov 2014 05:30:53 +0100 Antoine Jacoutot wrote: > On Mon, Nov 24, 2014 at 10:04:59PM +, Bernte wrote: > > Hi - > > > > Since upgrading to 5.6, I am having problems to detect my Brother USB > > printer in CUPS. > > > > The problem is that the printer is not found by the 'usb' backend: > > Your cups package is not up to date. You need the one from 5.6 stable. > Bj Antoine. cups-1.7.4p0.tgz is in release, and cups-2.0.1.tgz is in snapshot. Is there something in between, that would be in the errata if there was one for snapshot like there's a http://www.openbsd.org/plus.html between 5.6 and 5.6+ ? I've tried 1.7.4p0 on both i386 and amd64 with results strikingly like those describe by Bernte. Hmmm. Do I build 2.0 from ports or up to the snap and take my chances on other things Or attempt to backup to 1.4 or 1.5? Thanks, Dhu > > > # /usr/local/libexec/cups/backend/usb > > DEBUG: Loading USB quirks from "/usr/local/share/cups/usb". > > DEBUG: Loaded 68 quirks. > > DEBUG: list_devices > > DEBUG: libusb_get_device_list=8 > > DEBUG: Failed to check whether 04f9:001a has the "usblp" kernel module > > attached > > > > The error looks suspicious, though I did not find anything useful about it > > googling the web (it seems to be an error caused by libusb). > > > > The printer does show up in usbdevs -vd: > > > > # usbdevs -vd > > Controller /dev/usb0: > > addr 1: high speed, self powered, config 1, EHCI root hub(0x), > > RDC(0x17f3), rev 1.00 > > uhub0 > > port 1 powered > > port 2 powered > > Controller /dev/usb1: > > addr 1: high speed, self powered, config 1, EHCI root hub(0x), > > RDC(0x17f3), rev 1.00 > > uhub1 > > port 1 powered > > port 2 powered > > Controller /dev/usb2: > > addr 1: full speed, self powered, config 1, OHCI root hub(0x), > > RDC(0x17f3), rev 1.00 > > uhub2 > > port 1 powered > > port 2 addr 2: full speed, self powered, config 1, product 0x001a(0x001a), > > Brother Industries(0x04f9), rev 1.00 > >ugen0 > > Controller /dev/usb3: > > addr 1: full speed, self powered, config 1, OHCI root hub(0x), > > RDC(0x17f3), rev 1.00 > > uhub3 > > port 1 powered > > port 2 addr 2: full speed, power 100 mA, config 1, Logitech BT > > Mini-Receiver(0x0b04), Logitech(0x046d), rev 49.00 > >uhub4 > > port 1 powered > > port 2 addr 3: full speed, power 98 mA, config 1, Logitech BT > > Mini-Receiver(0xc713), Logitech(0x046d), rev 49.00, iSerialNumber > > 001F203C2558 > > uhidev0 > > port 3 addr 4: full speed, power 98 mA, config 1, Logitech BT > > Mini-Receiver(0xc714), Logitech(0x046d), rev 49.00, iSerialNumber > > 001F203C2558 > > uhidev1 > > > > As explained in the pkg-readme, I have disabled the ulpt driver in the > > kernel, as well as changed the ownership of the devices: > > > > # ls -la /dev/usb2 /dev/ugen0.* > > > > crw-rw 1 _cups wheel 63, 0 Nov 21 19:35 /dev/ugen0.00 > > crw-rw 1 _cups wheel 63, 1 Nov 21 19:35 /dev/ugen0.01 > > crw-rw 1 _cups wheel 63, 2 Nov 21 19:35 /dev/ugen0.02 > > crw-rw 1 _cups wheel 63, 3 Nov 21 19:35 /dev/ugen0.03 > > crw-rw 1 _cups wheel 63, 4 Nov 21 19:35 /dev/ugen0.04 > > crw-rw 1 _cups wheel 63, 5 Nov 21 19:35 /dev/ugen0.05 > > crw-rw 1 _cups wheel 63, 6 Nov 21 19:35 /dev/ugen0.06 > > crw-rw 1 _cups wheel 63, 7 Nov 21 19:35 /dev/ugen0.07 > > crw-rw 1 _cups wheel 63, 8 Nov 21 19:35 /dev/ugen0.08 > > crw-rw 1 _cups wheel 63, 9 Nov 21 19:35 /dev/ugen0.09 > > crw-rw 1 _cups wheel 63, 10 Nov 21 19:35 /dev/ugen0.10 > > crw-rw 1 _cups wheel 63, 11 Nov 21 19:35 /dev/ugen0.11 > > crw-rw 1 _cups wheel 63, 12 Nov 21 19:35 /dev/ugen0.12 > > crw-rw 1 _cups wheel 63, 13 Nov 21 19:35 /dev/ugen0.13 > > crw-rw 1 _cups wheel 63, 14 Nov 21 19:35 /dev/ugen0.14 > > crw-rw 1 _cups wheel 63, 15 Nov 21 19:35 /dev/ugen0.15 > > crw-rw 1 _cups wheel 61, 2 Nov 21 19:35 /dev/usb2 > > > > Any hints on how to track down my problem would be welcome. > > > > Regards, > > Bernd > > > > dmesg: > > > > OpenBSD 5.6 (GENERIC) #2: Tue Oct 28 16:56:54 CET 2014 > > > > r...@stable-56-i386.mtier.org:/binpatchng/work-binpatch56-i386/src/sys/arch/i386/compile/GENERIC > > cpu0: Vortex86 SoC (586-class) 934 MHz > > cpu0: FPU,TSC,CX8,MMX > > real mem = 1039691776 (991MB) > > avail mem = 1010257920 (963MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: AT/286+ BIOS, date 11/26/10, BIOS32 rev. 0 @ 0xf0010 > > apm0 at bios0: Power Management spec V1.2 > > pcibios0 at bios0: rev 3.0 @ 0xf/0x1 > > pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf2fe0/240 (13 entries) > > pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6036 > > pcibios0: Warning, unable to fix up PCI interrupt routing > > pcibios0: PCI bus #0 is the last bus > > bios0: ROM list: 0xc/0x8000 > > cpu0 at mainbus0: (uniproce
Re: CUPS printer problems
Howdy Bernte? I'm having the same problems, with both i386 and amd64. I'm now thinking that I will build an earlier version of cups (say from b4 Fruitco), althouth my suspicions are on the cups/usb interface so I'm thinking of building an earlier port. Dhu On Mon, 24 Nov 2014 22:04:59 + Bernte wrote: > > Any hints on how to track down my problem would be welcome. > > Regards, > Bernd > -- Ne obliviscaris, vix ea nostra voco.
Re: CUPS printer problems
On Mon, Nov 24, 2014 at 10:04:59PM +, Bernte wrote: > Hi - > > Since upgrading to 5.6, I am having problems to detect my Brother USB > printer in CUPS. > > The problem is that the printer is not found by the 'usb' backend: Your cups package is not up to date. You need the one from 5.6 stable. > # /usr/local/libexec/cups/backend/usb > DEBUG: Loading USB quirks from "/usr/local/share/cups/usb". > DEBUG: Loaded 68 quirks. > DEBUG: list_devices > DEBUG: libusb_get_device_list=8 > DEBUG: Failed to check whether 04f9:001a has the "usblp" kernel module > attached > > The error looks suspicious, though I did not find anything useful about it > googling the web (it seems to be an error caused by libusb). > > The printer does show up in usbdevs -vd: > > # usbdevs -vd > Controller /dev/usb0: > addr 1: high speed, self powered, config 1, EHCI root hub(0x), > RDC(0x17f3), rev 1.00 > uhub0 > port 1 powered > port 2 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x), > RDC(0x17f3), rev 1.00 > uhub1 > port 1 powered > port 2 powered > Controller /dev/usb2: > addr 1: full speed, self powered, config 1, OHCI root hub(0x), > RDC(0x17f3), rev 1.00 > uhub2 > port 1 powered > port 2 addr 2: full speed, self powered, config 1, product 0x001a(0x001a), > Brother Industries(0x04f9), rev 1.00 >ugen0 > Controller /dev/usb3: > addr 1: full speed, self powered, config 1, OHCI root hub(0x), > RDC(0x17f3), rev 1.00 > uhub3 > port 1 powered > port 2 addr 2: full speed, power 100 mA, config 1, Logitech BT > Mini-Receiver(0x0b04), Logitech(0x046d), rev 49.00 >uhub4 > port 1 powered > port 2 addr 3: full speed, power 98 mA, config 1, Logitech BT > Mini-Receiver(0xc713), Logitech(0x046d), rev 49.00, iSerialNumber > 001F203C2558 > uhidev0 > port 3 addr 4: full speed, power 98 mA, config 1, Logitech BT > Mini-Receiver(0xc714), Logitech(0x046d), rev 49.00, iSerialNumber > 001F203C2558 > uhidev1 > > As explained in the pkg-readme, I have disabled the ulpt driver in the > kernel, as well as changed the ownership of the devices: > > # ls -la /dev/usb2 /dev/ugen0.* > > crw-rw 1 _cups wheel 63, 0 Nov 21 19:35 /dev/ugen0.00 > crw-rw 1 _cups wheel 63, 1 Nov 21 19:35 /dev/ugen0.01 > crw-rw 1 _cups wheel 63, 2 Nov 21 19:35 /dev/ugen0.02 > crw-rw 1 _cups wheel 63, 3 Nov 21 19:35 /dev/ugen0.03 > crw-rw 1 _cups wheel 63, 4 Nov 21 19:35 /dev/ugen0.04 > crw-rw 1 _cups wheel 63, 5 Nov 21 19:35 /dev/ugen0.05 > crw-rw 1 _cups wheel 63, 6 Nov 21 19:35 /dev/ugen0.06 > crw-rw 1 _cups wheel 63, 7 Nov 21 19:35 /dev/ugen0.07 > crw-rw 1 _cups wheel 63, 8 Nov 21 19:35 /dev/ugen0.08 > crw-rw 1 _cups wheel 63, 9 Nov 21 19:35 /dev/ugen0.09 > crw-rw 1 _cups wheel 63, 10 Nov 21 19:35 /dev/ugen0.10 > crw-rw 1 _cups wheel 63, 11 Nov 21 19:35 /dev/ugen0.11 > crw-rw 1 _cups wheel 63, 12 Nov 21 19:35 /dev/ugen0.12 > crw-rw 1 _cups wheel 63, 13 Nov 21 19:35 /dev/ugen0.13 > crw-rw 1 _cups wheel 63, 14 Nov 21 19:35 /dev/ugen0.14 > crw-rw 1 _cups wheel 63, 15 Nov 21 19:35 /dev/ugen0.15 > crw-rw 1 _cups wheel 61, 2 Nov 21 19:35 /dev/usb2 > > Any hints on how to track down my problem would be welcome. > > Regards, > Bernd > > dmesg: > > OpenBSD 5.6 (GENERIC) #2: Tue Oct 28 16:56:54 CET 2014 > > r...@stable-56-i386.mtier.org:/binpatchng/work-binpatch56-i386/src/sys/arch/i386/compile/GENERIC > cpu0: Vortex86 SoC (586-class) 934 MHz > cpu0: FPU,TSC,CX8,MMX > real mem = 1039691776 (991MB) > avail mem = 1010257920 (963MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: AT/286+ BIOS, date 11/26/10, BIOS32 rev. 0 @ 0xf0010 > apm0 at bios0: Power Management spec V1.2 > pcibios0 at bios0: rev 3.0 @ 0xf/0x1 > pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf2fe0/240 (13 entries) > pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6036 > pcibios0: Warning, unable to fix up PCI interrupt routing > pcibios0: PCI bus #0 is the last bus > bios0: ROM list: 0xc/0x8000 > cpu0 at mainbus0: (uniprocessor) > pci0 at mainbus0 bus 0: configuration mode 1 (bios) > pchb0 at pci0 dev 0 function 0 vendor "RDC", unknown product 0x6022 rev 0x00 > rl0 at pci0 dev 1 function 0 "Realtek 8139" rev 0x10: irq 11, address > 44:4d:50:07:1b:19 > rlphy0 at rl0 phy 0: RTL internal PHY > rl1 at pci0 dev 2 function 0 "Realtek 8139" rev 0x10: irq 11, address > 44:4d:50:07:1b:1a > rlphy1 at rl1 phy 0: RTL internal PHY > pcib0 at pci0 dev 7 function 0 vendor "RDC", unknown product 0x6036 rev 0x00 > vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 6, address > 00:1b:eb:25:30:9e > rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1 > ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x12: irq 7, version > 1.0, legacy support > ehci0 at pci0 dev 10 function 1 "RDC R6061 US
Re: USB ports not working on a mid-2012 MacBookAir5,1
On 10 November 2014 at 19:55, Sevan / Venture37 wrote: > Then I remembered that my previous attempt of successfully installing > OpenBSD on here involved a thunderbolt cinema display, the gigabit > ethernet port on the display was detected as bge(4) and functioned. > I no longer have access to a cinema display but do have a thunderbolt > gigabit ethernet adapter which I hadn't tried yet. > Worked a treat, I was able to boot the laptop from a USB flash drive & > perform a network install via the bge(4) interface. > > the thunderbolt adapter is only detected if it's attached prior to > booting the kernel, I guess this is because it crosses over several > areas and is not seen as a detachable device? > If you do disconnect it after booting, the system hard locks needing a > power cycle. BCM57782 chipset in a thunderbolt gigabit ethernet adapter https://www.flickr.com/photos/osr/15473313617/ Sevan / Venture37
Re: Trackpad after suspend/resume on MacBookAir4,1
* On Mon Nov 24, 2014 at 07:32:51PM -0500 1636 , Maximilian Pichler (maxim.pich...@gmail.com) wrote: > Subject: Re: Trackpad after suspend/resume on MacBookAir4,1 > > That works! In fact, 'xinput enable /dev/wsmouse1' seems to suffice to > fix the trackpad after resume. > > In the text console the keyboard remains broken, though. > For me too. I had not even noticed that before.
Re: Trackpad after suspend/resume on MacBookAir4,1
That works! In fact, 'xinput enable /dev/wsmouse1' seems to suffice to fix the trackpad after resume. In the text console the keyboard remains broken, though. Thanks On Mon, Nov 24, 2014 at 9:09 AM, Jaime Tarrant wrote: > * On Mon Nov 24, 2014 at 08:56:59AM -0500 1558 , Maximilian Pichler > (maxim.pich...@gmail.com) wrote: >> On Mon, Nov 24, 2014 at 8:21 AM, Martin Pieuchot >> wrote: >> > On 24/11/14(Mon) 08:11, Maximilian Pichler wrote: >> >> It's even slightly worse: after resuming, the keyboard still works in >> >> X, but switching to a text console (either via ctrl-alt-f1 or by >> >> quitting X) results in the keyboard being unusable, i.e. typing >> >> anything results in garbled characters. I therefore cannot even try >> >> your previous suggestions of restarting X. >> > >> > This is a bug. >> >> If I can do anything to help diagnose this better, please let me know. >> > > Hi all, I have a macbook pro 8.1 with the same mouse characteristics post > suspend/resume. Its only a work around, however you may be able to get > the mouse back by running the following from a console after resuming: > > xinput disable /dev/wsmouse1 && sleep 1 && xinput enable /dev/wsmouse1 > > Your dmesg looks similar to mine, so hopefully the above will work for > you too.
Re: "Waiting for printer to become available."
On Mon, 24 Nov 2014 23:15:34 + (UTC) Stuart Henderson wrote: > On 2014-11-24, Duncan Patton a Campbell wrote: > > Howdy all? > > > > I'm currently trying to get a USB printer (either Samsung or Brother) to > > work with amd64 OBSD 5.6 (patched to 009). I've had the Brother (DCP7020) > > working with cups since 4.1. Nothing in the cups error log, nothing > > /var/log/*, > > and localhost:631 just tells me "Waiting for printer to become available." > > > > I've disabled ulpt (ukc> disable ulpt ...284 ulpt* already disabled) and > > am seeing mostly linux references to this that say "reinstall the package", > > which I've done to no apparent effect. > > > > If you know something of this or can give me a pointer to something > > salient, > > I'd appreciate it. > > > > Thanks, > > > > Dhu > > > > > > Did you change permissions on the USB devices? See the CUPS pkg-readme if not. > > Yep... # ls -l /dev/ | grep cups crw-rw-rw- 1 _cups wheel 63, 0 Nov 12 10:21 ugen0.00 crw-rw-rw- 1 _cups wheel 63, 1 Nov 12 10:21 ugen0.01 crw-rw-rw- 1 _cups wheel 63, 2 Nov 12 10:21 ugen0.02 crw-rw-rw- 1 _cups wheel 63, 3 Nov 12 10:21 ugen0.03 crw-rw-rw- 1 _cups wheel 63, 4 Nov 12 10:21 ugen0.04 crw-rw-rw- 1 _cups wheel 63, 5 Nov 12 10:21 ugen0.05 crw-rw-rw- 1 _cups wheel 63, 6 Nov 12 10:21 ugen0.06 crw-rw-rw- 1 _cups wheel 63, 7 Nov 12 10:21 ugen0.07 crw-rw-rw- 1 _cups wheel 63, 8 Nov 12 10:21 ugen0.08 crw-rw-rw- 1 _cups wheel 63, 9 Nov 12 10:21 ugen0.09 crw-rw-rw- 1 _cups wheel 63, 10 Nov 12 10:21 ugen0.10 crw-rw-rw- 1 _cups wheel 63, 11 Nov 12 10:21 ugen0.11 crw-rw-rw- 1 _cups wheel 63, 12 Nov 12 10:21 ugen0.12 crw-rw-rw- 1 _cups wheel 63, 13 Nov 12 10:21 ugen0.13 crw-rw-rw- 1 _cups wheel 63, 14 Nov 12 10:21 ugen0.14 crw-rw-rw- 1 _cups wheel 63, 15 Nov 12 10:21 ugen0.15 crw-rw 1 _cups wheel 64, 0 Nov 23 19:18 ulpt0 crw-rw 1 _cups wheel 64, 1 Nov 12 10:21 ulpt1 crw-rw-rw- 1 _cups wheel 61, 3 Nov 23 19:42 usb3 the addition of the 666 is not needed.. I was just trying to rule out perms entirely.. Thanks eh. Any other ideas? My latest is I'm gonna build a shadow root on usb running obsd.i386.5.6 or mebbe snap. I'll have a look at behavioral some diffs in any event. After I poke around with some the usb* stuff.. Dhu -- Ne obliviscaris, vix ea nostra voco.
CUPS printer problems
Hi - Since upgrading to 5.6, I am having problems to detect my Brother USB printer in CUPS. The problem is that the printer is not found by the 'usb' backend: # /usr/local/libexec/cups/backend/usb DEBUG: Loading USB quirks from "/usr/local/share/cups/usb". DEBUG: Loaded 68 quirks. DEBUG: list_devices DEBUG: libusb_get_device_list=8 DEBUG: Failed to check whether 04f9:001a has the "usblp" kernel module attached The error looks suspicious, though I did not find anything useful about it googling the web (it seems to be an error caused by libusb). The printer does show up in usbdevs -vd: # usbdevs -vd Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), RDC(0x17f3), rev 1.00 uhub0 port 1 powered port 2 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), RDC(0x17f3), rev 1.00 uhub1 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, OHCI root hub(0x), RDC(0x17f3), rev 1.00 uhub2 port 1 powered port 2 addr 2: full speed, self powered, config 1, product 0x001a(0x001a), Brother Industries(0x04f9), rev 1.00 ugen0 Controller /dev/usb3: addr 1: full speed, self powered, config 1, OHCI root hub(0x), RDC(0x17f3), rev 1.00 uhub3 port 1 powered port 2 addr 2: full speed, power 100 mA, config 1, Logitech BT Mini-Receiver(0x0b04), Logitech(0x046d), rev 49.00 uhub4 port 1 powered port 2 addr 3: full speed, power 98 mA, config 1, Logitech BT Mini-Receiver(0xc713), Logitech(0x046d), rev 49.00, iSerialNumber 001F203C2558 uhidev0 port 3 addr 4: full speed, power 98 mA, config 1, Logitech BT Mini-Receiver(0xc714), Logitech(0x046d), rev 49.00, iSerialNumber 001F203C2558 uhidev1 As explained in the pkg-readme, I have disabled the ulpt driver in the kernel, as well as changed the ownership of the devices: # ls -la /dev/usb2 /dev/ugen0.* crw-rw 1 _cups wheel 63, 0 Nov 21 19:35 /dev/ugen0.00 crw-rw 1 _cups wheel 63, 1 Nov 21 19:35 /dev/ugen0.01 crw-rw 1 _cups wheel 63, 2 Nov 21 19:35 /dev/ugen0.02 crw-rw 1 _cups wheel 63, 3 Nov 21 19:35 /dev/ugen0.03 crw-rw 1 _cups wheel 63, 4 Nov 21 19:35 /dev/ugen0.04 crw-rw 1 _cups wheel 63, 5 Nov 21 19:35 /dev/ugen0.05 crw-rw 1 _cups wheel 63, 6 Nov 21 19:35 /dev/ugen0.06 crw-rw 1 _cups wheel 63, 7 Nov 21 19:35 /dev/ugen0.07 crw-rw 1 _cups wheel 63, 8 Nov 21 19:35 /dev/ugen0.08 crw-rw 1 _cups wheel 63, 9 Nov 21 19:35 /dev/ugen0.09 crw-rw 1 _cups wheel 63, 10 Nov 21 19:35 /dev/ugen0.10 crw-rw 1 _cups wheel 63, 11 Nov 21 19:35 /dev/ugen0.11 crw-rw 1 _cups wheel 63, 12 Nov 21 19:35 /dev/ugen0.12 crw-rw 1 _cups wheel 63, 13 Nov 21 19:35 /dev/ugen0.13 crw-rw 1 _cups wheel 63, 14 Nov 21 19:35 /dev/ugen0.14 crw-rw 1 _cups wheel 63, 15 Nov 21 19:35 /dev/ugen0.15 crw-rw 1 _cups wheel 61, 2 Nov 21 19:35 /dev/usb2 Any hints on how to track down my problem would be welcome. Regards, Bernd dmesg: OpenBSD 5.6 (GENERIC) #2: Tue Oct 28 16:56:54 CET 2014 r...@stable-56-i386.mtier.org:/binpatchng/work-binpatch56-i386/src/sys/arch/i386/compile/GENERIC cpu0: Vortex86 SoC (586-class) 934 MHz cpu0: FPU,TSC,CX8,MMX real mem = 1039691776 (991MB) avail mem = 1010257920 (963MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/26/10, BIOS32 rev. 0 @ 0xf0010 apm0 at bios0: Power Management spec V1.2 pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf2fe0/240 (13 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x17f3 product 0x6036 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 vendor "RDC", unknown product 0x6022 rev 0x00 rl0 at pci0 dev 1 function 0 "Realtek 8139" rev 0x10: irq 11, address 44:4d:50:07:1b:19 rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci0 dev 2 function 0 "Realtek 8139" rev 0x10: irq 11, address 44:4d:50:07:1b:1a rlphy1 at rl1 phy 0: RTL internal PHY pcib0 at pci0 dev 7 function 0 vendor "RDC", unknown product 0x6036 rev 0x00 vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 6, address 00:1b:eb:25:30:9e rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1 ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x12: irq 7, version 1.0, legacy support ehci0 at pci0 dev 10 function 1 "RDC R6061 USB2" rev 0x03: irq 3 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "RDC EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 11 function 0 "RDC R6060 USB" rev 0x12: irq 5, version 1.0, legacy support ehci1 at pci0 dev 11 function 1 "RDC R6061 USB2" rev 0x03: irq 9 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "RDC EHCI root hub" rev
Re: "Waiting for printer to become available."
On 2014-11-24, Duncan Patton a Campbell wrote: > Howdy all? > > I'm currently trying to get a USB printer (either Samsung or Brother) to > work with amd64 OBSD 5.6 (patched to 009). I've had the Brother (DCP7020) > working with cups since 4.1. Nothing in the cups error log, nothing > /var/log/*, > and localhost:631 just tells me "Waiting for printer to become available." > > I've disabled ulpt (ukc> disable ulpt ...284 ulpt* already disabled) and > am seeing mostly linux references to this that say "reinstall the package", > which I've done to no apparent effect. > > If you know something of this or can give me a pointer to something salient, > I'd appreciate it. > > Thanks, > > Dhu > > Did you change permissions on the USB devices? See the CUPS pkg-readme if not.
Re: vnconfig crypto alternative
> With crypto being deprecated (and possibly removed in future versions > - depending on dev direction) from vnconfig, would the following be > assumed one way of providing an encrypted container? That deprecation is not going to happen. Keep using what you are using now.
vnconfig crypto alternative
With crypto being deprecated (and possibly removed in future versions - depending on dev direction) from vnconfig, would the following be assumed one way of providing an encrypted container? To create 200MB encrypted container: sudo dd if=/dev/zero of=/var/encrypt/container.encrypt bs=1m count=200 sudo chmod 600 /var/encrypt/container.encrypt sudo vnconfig vnd0 /var/encrypt/container.encrypt printf "a\n\n\n\nRAID\nw\nq\n\n" | sudo disklabel -E vnd0 sudo bioctl -c C -l vnd0a softraid0 ## Enter your secret passphrase here sudo dd if=/dev/zero of=/dev/rsd1c bs=1m count=1 printf "a\n\n\n\n4.2BSD\nw\nq\n\n" | sudo disklabel -E sd1 sudo newfs /dev/rsd1a sudo mount /dev/sd1a /encrypt ## sudo umount /encrypt sudo bioctl -d sd1 sudo vnconfig -u vnd0 Then to re-use: sudo vnconfig vnd0 /var/encrypt/container.encrypt sudo bioctl -c C -l vnd0a softraid0 ## Enter your secret passphrase here sudo mount /dev/sd1a /encrypt ## sudo umount /encrypt sudo bioctl -d sd1 sudo vnconfig -u vnd0
"Waiting for printer to become available."
Howdy all? I'm currently trying to get a USB printer (either Samsung or Brother) to work with amd64 OBSD 5.6 (patched to 009). I've had the Brother (DCP7020) working with cups since 4.1. Nothing in the cups error log, nothing /var/log/*, and localhost:631 just tells me "Waiting for printer to become available." I've disabled ulpt (ukc> disable ulpt ...284 ulpt* already disabled) and am seeing mostly linux references to this that say "reinstall the package", which I've done to no apparent effect. If you know something of this or can give me a pointer to something salient, I'd appreciate it. Thanks, Dhu -- Ne obliviscaris, vix ea nostra voco.
Re: Can't boot Nov 21 amd64/bsd.rd - finishes at 'entry point'...
On Sat, Nov 22, 2014 at 12:40:22PM -0700, Theo de Raadt wrote: > > I can't boot bsd.rd (amd64) from Nov 21 2014. I've tried to > > upgrade my FDE-based amd64 installation. > > > > I entered passphrase for crypto softraid in boot loader, typed > > 'bsd.rd' and after one line it finished: > > > > entry point at 0x1000160 [7205c768, 3404, 24448b12, 6670a304] > > > > (I hope I wrote it down correctly.) > > As you and other readers of this list know very well, the above > is an incomplete bug report. > > It is nice to know that you have spotted a problem, but there simply > is not enough information for anyone to move forward. I just tested > the same stuff on 3 of my machines. > > Considering the effort we put into making this code, please put a bit > more effort into it yourself? Thanks. Hi, yeah I should have to include my working dmesg, so here it is from my Lenovo T500. I don't know what else I could provide, I can't boot anymore bsd.mp, bsd.rd and even cdboot.iso I burnt (all amd64). They all finish on just 2nd line as state above, no idea. If those numbers are important I would do a photo (laptop, no console) and write it down. How else could I help? OpenBSD 5.6-current (GENERIC.MP) #544: Fri Nov 7 10:36:24 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4166717440 (3973MB) avail mem = 4051992576 (3864MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "6FET82WW (3.12 )" date 11/26/2009 bios0: LENOVO 2089A35 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(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: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.37 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.01 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 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-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus -1 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4621" serial 1562 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) cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1680x1050 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:27:13:b7:d2:45 uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: 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 "Inte
Re: secure(er) image viewer?
On Sun, Nov 23, 2014 at 21:13, Jonathan Thornburg wrote: > Libraries for loading/parsing/processing common image formats like > JPEG, PNG, GIF, TIFF, etc, have a long history of buffer overruns and > other security problems. This in turn has been reflected in various > exploits for command-line image-viewing tools like xv(1), xloadimage(1), > display(1) [ImageMagick], etc. > > Do we (OpenBSD) have any image-viewing software that's written to > OpenBSD-style security standards? Notably, do we have any image-viewing > software that's privilige-separated? (I.e., which does the (dangerous) > image parsing/processing in a separate process which is chrooted, sending > back bitmaps/pixmaps over a constrained channel to a display process?) Well, you basically just described running any image viewer of choice as a different user and displaying it on your X session. X channels aren't entirely constrained, though you can play around with Xephyr or so.
Re: New power management
-C option is aliased to -A, and seems it's left there only for backwards compat, and it's removed from documentation. So we should not rely on presence of that. On Thu, Nov 13, 2014 at 08:35:38AM +0100, Peter Hessler wrote: > apmd_flags='-C' still works. You can also use -A, since they now behave > the same. > > > On 2014 Nov 12 (Wed) at 23:28:46 -0800 (-0800), Nathan Van Ymeren wrote: > :Hello, > : > :I'm running -current on a thinkpad x220 tablet, with an intel i7. > : > :I had been running with apmd_flags="-C" but I see that that has been > :removed. > : > :1) For best battery life, should I just go apmd_flags="" ? > : > :2) I've seen some mailing list messages about hw.perfpolicy=auto > :and hw.setperf=-1 but the man page doesn't explain what these actually > :do. Do they conflict? Should they be used instead of apmd flags? > : > :Thanks > : > :N > : > > -- > It is only people of small moral stature who have to stand on their > dignity.
Re: lii0 no link on 5.6-current i386
On Mon, Nov 24, 2014 at 3:12 PM, trondd wrote: > >> Just to clarify, these have been fresh installs of 5.6-release and >> 5.6-current. Both bsd.rd and bsd seem not to find the lii interface. >> 5.5-release behaves almost the same way, though the link status light >> stays on until I try to use dhclient on lii0, both in bsd and bsd.rd. >> >> > Well if I'm looking in the right place. There was a change made after 5.4 > that was in 5.5 and 5.6. > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/mii/acphy.c?r1=1.7 > > If you have the means, you could recompile the kernel without that change > and see if that is the problem. > > Tim. > > Edit: That commit is multiple files, atphy.c being what's probably more relevant to you. But the commit might need to be rolledback as a whole. Anyway, it's just a suggestion to narrow down where the problem might be without knowing the details of the change, nor having the hardware. Tim.
Re: lii0 no link on 5.6-current i386
> Just to clarify, these have been fresh installs of 5.6-release and > 5.6-current. Both bsd.rd and bsd seem not to find the lii interface. > 5.5-release behaves almost the same way, though the link status light > stays on until I try to use dhclient on lii0, both in bsd and bsd.rd. > > Well if I'm looking in the right place. There was a change made after 5.4 that was in 5.5 and 5.6. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/mii/acphy.c?r1=1.7 If you have the means, you could recompile the kernel without that change and see if that is the problem. Tim.
Re: Trackpad after suspend/resume on MacBookAir4,1
Thanks for explaining! On Sun, Nov 23, 2014 at 12:44 AM, Martin Pieuchot wrote: > The best you can do for the moment is restart X after resuming, > it should recalibrate your touchpad properly. Quitting X after resuming results in the keyboard becoming unusable in the text console, i.e. garbled characters appear when typing (my keyboard layout is dvorak, but the output is neither dovark nor qwerty). Therefore I'm unable to restart X. The keyboard does work correctly in the text console before suspending. It also works correctly inside X after resuming. Max
Re: lii0 no link on 5.6-current i386
On Mon, 24 Nov 2014, Lars Nooden wrote: > I've been trying to move from 5.4 to 5.6 on an old machine. Neither > 5.6-release from the CD nor 5.6-current from the recent snapshots seem > to be able to use the Ethernet device. During power up, the link status > light is on, but then as the kernel loads it goes out and stays out. Just to clarify, these have been fresh installs of 5.6-release and 5.6-current. Both bsd.rd and bsd seem not to find the lii interface. 5.5-release behaves almost the same way, though the link status light stays on until I try to use dhclient on lii0, both in bsd and bsd.rd. Regards, /Lars
Re: 5.5-to-5.6 upgrade with mtier binpatch pkgs?
On 14-11-24 12:28 PM, David Higgs wrote: On Mon, Nov 24, 2014 at 1:12 PM, Adam Thompson wrote: I just upgraded one of a matched pair of 5.5 systems to 5.6, and after the upgrade finished, it occured to me to wonder "what about the binpatch55-amd64-* packages from m:tier"? They're all still installed (unsurprisingly), and I'm uncertain what to do about it now. I'm thinking that if I uninstall the packages normally, they'll revert certain system files to 5.5-RELEASE, which would be undesirable. So I now have two cases: 1) for a post-5.6-upgraded system, should I just manually remove /var/db/pkg/binpatch55* and /var/db/binpatch/*, or is there a better way to handle this? 2) for the not-yet-upgraded system, should I remove the patches normally, reverting to 5.5-RELEASE, or ... ? Did you run openup after your upgrade? I think it cleaned up after itself. If you're installing them manually, you can consult the openup source to see exactly how it does this. No, I hadn't run openup yet - I was afraid to, as the openup page doesn't mention this case and I hadn't read the source yet. For the record, this appears to be the situation: - You can follow the normal upgrade procedure on a system that has m:tier binpatches on it. - If you were using their openup tool, simply run it again after you've completed all the other upgrade steps and it'll clean up the old binpkgs. - If you weren't using their openup tool, manually remove all the /var/db/pkg/binpatch-* entries and /var/db/binpatch/* to reset to a non-binpatched state. Leaving them in place is harmless until you run "pkg_add -u" which might suddenly pick up an update for an older OpenBSD release. Sounds like a good reason to use openup :-). -- -Adam Thompson athom...@athompso.net Cell: +1 204 291-7950 Fax: +1 204 489-6515
Re: 5.5-to-5.6 upgrade with mtier binpatch pkgs?
On Mon, Nov 24, 2014 at 12:12:52PM -0600, Adam Thompson wrote: > I just upgraded one of a matched pair of 5.5 systems to 5.6, and after the > upgrade finished, it occured to me to wonder "what about the > binpatch55-amd64-* packages from m:tier"? > > They're all still installed (unsurprisingly), and I'm uncertain what to do > about it now. I'm thinking that if I uninstall the packages normally, > they'll revert certain system files to 5.5-RELEASE, which would be > undesirable. Hi Adam. > So I now have two cases: > 1) for a post-5.6-upgraded system, should I just manually remove > /var/db/pkg/binpatch55* and /var/db/binpatch/*, or is there a better way to > handle this? If you use openup, then you can just run it. If not, then yes, you must manually remove these directories. > 2) for the not-yet-upgraded system, should I remove the patches normally, > reverting to 5.5-RELEASE, or ... ? Yes. It's a known drawback of the binpatch-ng framework. -- Antoine
5.5-to-5.6 upgrade with mtier binpatch pkgs?
I just upgraded one of a matched pair of 5.5 systems to 5.6, and after the upgrade finished, it occured to me to wonder "what about the binpatch55-amd64-* packages from m:tier"? They're all still installed (unsurprisingly), and I'm uncertain what to do about it now. I'm thinking that if I uninstall the packages normally, they'll revert certain system files to 5.5-RELEASE, which would be undesirable. So I now have two cases: 1) for a post-5.6-upgraded system, should I just manually remove /var/db/pkg/binpatch55* and /var/db/binpatch/*, or is there a better way to handle this? 2) for the not-yet-upgraded system, should I remove the patches normally, reverting to 5.5-RELEASE, or ... ? Thanks, -Adam -- -Adam Thompson athom...@athompso.net Cell: +1 204 291-7950 Fax: +1 204 489-6515
upd0 detached - can I reset USB
It appears that my UPS has detached. Is there a programmatic way to reset a USB port? I'm confident if I unplug the UPS and plug it back in it will reattach, but I don't have physical access to the server. I'd prefer not to reboot either. Thanks. FROM DMESG uhidev0 at uhub1 port 1 configuration 1 interface 0 "American Power Conversion Smart-UPS 1500 FW:601.3.D USB FW:1.3" rev 1.10/0.06 addr 2 uhidev0: iclass 3/0, 54 report ids upd0 at uhidev0 FROM /var/log/messages Nov 23 15:54:29 builder02 /bsd: upd0 detached Nov 23 15:54:29 builder02 /bsd: uhidev0 detached -Steve S.
Re: weird behaviour of pkg_add -u
On Sun, Nov 23, 2014 at 01:10:21PM +0100, Nils R wrote: > > Did you try pkg_check (man pkg_check) to see if there's nothing > > terribly wrong after first update? > > > > No, in fact this is the first time i heard about pkg_check. I tried it, and > it asked me > to correct some of the dependencies in gnome packages, so maybe there went > something wrong in the past. [...] > Maybe this is resolved now by pkg_check, i'll keep an eye on it the next time > i > do an update. I've used pkg_check(8) successfully on a couple of occations when pkg_add appeared to make a mess. However, the man page states: "Work in progress. The order of checks is not definitive, and more checks may be added. Use with caution". It's not apparent what to be cautious about. Perhaps the man page is a candidate for review? It's from February 11, 2014. Regards, Erling
lii0 no link on 5.6-current i386
I've been trying to move from 5.4 to 5.6 on an old machine. Neither 5.6-release from the CD nor 5.6-current from the recent snapshots seem to be able to use the Ethernet device. During power up, the link status light is on, but then as the kernel loads it goes out and stays out. What have I missed that I need to set for Ethernet? I don't see anything that stands out in the man page lii(4) or on the web page plus56.html Regards, /Lars 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 pms0: Synaptics touchpad, firmware 6.5 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 umass0 at uhub0 port 5 configuration 1 interface 0 "ENE UB6225" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: SCSI0 0/direct removable serial.09511606146030377350 uplcom0 at uhub2 port 2 "Prolific Technology Inc. USB-Serial Controller" rev 1.10/3.00 addr 2 ucom0 at uplcom0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (1aedd50302d13ce8.a) swap on wd0b dump on wd0b OpenBSD 5.6-current (GENERIC) #538: Sun Nov 23 15:37:19 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) M processor 900MHz ("GenuineIntel" 686-class) 631 MHz 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,PERF real mem = 2138066944 (2039MB) avail mem = 2090835968 (1993MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/04/08, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf06e0 (37 entries) bios0: vendor American Megatrends Inc. version "1001" date 05/04/2008 bios0: ASUSTeK Computer INC. 701 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC OEMB MCFG acpi0: wakeup devices P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) MC97(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EUSB(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 70MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (P0P3) acpiprt2 at acpi0: bus 3 (P0P5) acpiprt3 at acpi0: bus 1 (P0P6) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2 acpitz0 at acpi0: critical temperature is 90 degC acpibat0 at acpi0: BAT0 model "701" serial type LION oem "ASUS" acpiac0 at acpi0: AC unit online acpiasus0 at acpi0 acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB bios0: ROM list: 0xc/0xf800! 0xcf800/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x04 vga1 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x04 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 800x480 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 82915GM Video" rev 0x04 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 "Intel 82801FB HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x04: apic 1 int 16 pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x04: apic 1 int 17 pci2 at ppb1 bus 3 lii0 at pci2 dev 0 function 0 "Attansic Technology L2" rev 0xa0: apic 1 int 17, address 00:22:15:45:2c:b4 atphy0 at lii0 phy 1: F2 10/100 PHY, rev. 2 ppb2 at pci0 dev 28 function 2 "Intel 82801FB PCIE" rev 0x04: apic 1 int 18 pci3 at ppb2 bus 1 uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x04: apic 1 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x04: apic 1 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x04: apic 1 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x04: apic 1 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x04: 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 ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd4 pci4 at ppb3 bus 5 ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x04: PM disabled pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x04: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 1 drive 0: wd0: 1-sector PIO, LBA, 3815MB, 7815024 sectors wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 ichiic0 at pci0 dev 31 function 3 "Intel 82801FB SMBus" rev 0x04: apic 1 int 19 iic0 at ichiic0 spdmem
Re: Trackpad after suspend/resume on MacBookAir4,1
* On Mon Nov 24, 2014 at 08:56:59AM -0500 1558 , Maximilian Pichler (maxim.pich...@gmail.com) wrote: > On Mon, Nov 24, 2014 at 8:21 AM, Martin Pieuchot > wrote: > > On 24/11/14(Mon) 08:11, Maximilian Pichler wrote: > >> It's even slightly worse: after resuming, the keyboard still works in > >> X, but switching to a text console (either via ctrl-alt-f1 or by > >> quitting X) results in the keyboard being unusable, i.e. typing > >> anything results in garbled characters. I therefore cannot even try > >> your previous suggestions of restarting X. > > > > This is a bug. > > If I can do anything to help diagnose this better, please let me know. > Hi all, I have a macbook pro 8.1 with the same mouse characteristics post suspend/resume. Its only a work around, however you may be able to get the mouse back by running the following from a console after resuming: xinput disable /dev/wsmouse1 && sleep 1 && xinput enable /dev/wsmouse1 Your dmesg looks similar to mine, so hopefully the above will work for you too.
Re: kernel page fault trap
I just tried this too. Same result. Anyway, it is 100% replicable here. Can anybody else confirm this? I just did an 1G installation of OpenBSD, then I dd-ed the 1G file (logical block device) to a 100G one. I did all the steps I mentioned above in rescue mode and corrupted the file system. Nikos On 24 November 2014 at 15:22, Philip Guenther wrote: > On Monday, November 24, 2014, Nikos Skalkotos wrote: >> >> On 23/11/14 06:27, Philip Guenther wrote: >> ... >> > Note the cssize (cylinder summary size) has grown but csaddr hasn't >> > changed. That means it probably had to relocate allocated blocks. This >> > being your root disk, it may have relocated blocks in /boot, which would >> > require re-running installboot. >> >> ... > >> I tried zeroing the space first, and then copying the openbsd image >> into the zeroed space like this: >> > ... > >> But I get the very same error after resizing. I don't think this is it. >> > > Was that with rerunning installboot after the fsck? > > Philip Guenther
Re: Trackpad after suspend/resume on MacBookAir4,1
On Mon, Nov 24, 2014 at 8:21 AM, Martin Pieuchot wrote: > On 24/11/14(Mon) 08:11, Maximilian Pichler wrote: >> It's even slightly worse: after resuming, the keyboard still works in >> X, but switching to a text console (either via ctrl-alt-f1 or by >> quitting X) results in the keyboard being unusable, i.e. typing >> anything results in garbled characters. I therefore cannot even try >> your previous suggestions of restarting X. > > This is a bug. If I can do anything to help diagnose this better, please let me know.
Re: Trackpad after suspend/resume on MacBookAir4,1
On 24/11/14(Mon) 08:11, Maximilian Pichler wrote: > Thanks for the explanations! > > On Mon, Nov 24, 2014 at 4:19 AM, Martin Pieuchot > wrote: > > On 24/11/14(Mon) 09:04, Peter Hessler wrote: > >> Can you switch from the graphical console (ctrl-alt-f5) to a text > >> console (ctrl-alt-f1), and back? That may help with input device > >> related problems. > > > > That won't work in this case. His pointer isn't behind the mux and > > needs to be calibrated. > > It's even slightly worse: after resuming, the keyboard still works in > X, but switching to a text console (either via ctrl-alt-f1 or by > quitting X) results in the keyboard being unusable, i.e. typing > anything results in garbled characters. I therefore cannot even try > your previous suggestions of restarting X. This is a bug. > Here is yet another experiment: after booting into text console mode, > suspend and resume. The keyboard still works. However, now attempting > to start X results in a black screen. Killing X and starting it a > second time works (and mouse and keyboard are fine within X). The > difference between the logs are: The black screen is another issue related to the graphic driver. Regarding your mouse, it is normal that suspending the machine in console does not have the same effect as in X. Because only X calibrates it. For that it needs to open a specific device node in /dev which is closed when you suspend the machine. The problem is that we have currently no way to tell X to re-open such node in order to re-calibrate your pointer.
Re: kernel page fault trap
On Monday, November 24, 2014, Nikos Skalkotos wrote: > > On 23/11/14 06:27, Philip Guenther wrote: > ... > > Note the cssize (cylinder summary size) has grown but csaddr hasn't > > changed. That means it probably had to relocate allocated blocks. This > > being your root disk, it may have relocated blocks in /boot, which would > > require re-running installboot. > > ... > I tried zeroing the space first, and then copying the openbsd image > into the zeroed space like this: > ... > But I get the very same error after resizing. I don't think this is it. > Was that with rerunning installboot after the fsck? Philip Guenther
Re: Trackpad after suspend/resume on MacBookAir4,1
Thanks for the explanations! On Mon, Nov 24, 2014 at 4:19 AM, Martin Pieuchot wrote: > On 24/11/14(Mon) 09:04, Peter Hessler wrote: >> Can you switch from the graphical console (ctrl-alt-f5) to a text >> console (ctrl-alt-f1), and back? That may help with input device >> related problems. > > That won't work in this case. His pointer isn't behind the mux and > needs to be calibrated. It's even slightly worse: after resuming, the keyboard still works in X, but switching to a text console (either via ctrl-alt-f1 or by quitting X) results in the keyboard being unusable, i.e. typing anything results in garbled characters. I therefore cannot even try your previous suggestions of restarting X. Here is yet another experiment: after booting into text console mode, suspend and resume. The keyboard still works. However, now attempting to start X results in a black screen. Killing X and starting it a second time works (and mouse and keyboard are fine within X). The difference between the logs are: 22c22 < (==) Log file: "/var/log/Xorg.0.log", Time: Mon Nov 24 07:38:46 2014 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Nov 24 07:39:50 2014 45c45 < (II) Loader magic: 0xaceac707520 --- > (II) Loader magic: 0x1a2444b07520 131a132 > (--) intel(0): Output eDP1 using initial mode 1366x768 on pipe 0 160a162,163 > (II) intel(0): switch to mode 1366x768@60.0 on eDP1 using pipe 0, position > (0, 0), rotation normal, reflection none > (II) intel(0): Setting screen physical size to 361 x 203 213c216 < (II) ws: /dev/wsmouse: maximum x position: 1023 --- > (II) ws: /dev/wsmouse: maximum x position: 1365
Re: openbsd 5.6 - pf does not work on local redirects
More tests were conducted and I realized it did not even worked in 5.5 or in 5.4. The trick was that sendmail changed to smtpd (from 55 to 56) but config did not carry over (obviously) and no relayhost was set. Mea culpa that I did not spot it earlier. Split horizon is good solution until you're operating only with DNS names. While I was testing I indeed found the rdr page (quoted by Peter) and tested the other two solutions. - it works with inetd (proxy to nc) - and also works with relayd Do you guys see any cons using relayd (and anchor) with pf replacing my rdr-to rules? (I know, first rule is to read after and I must admit homework is not yet done) Thanks for the help for all of you putting me back on the right track. Regards, Laszlo On 2014.11.23. 22:44, Jason Adams wrote: On 11/23/2014 01:12 PM, Peter N. M. Hansteen wrote: Jason Adams writes: Tom Estep (shorewall) has a faq about this issue (routeback) that applies to the iptables world http://shorewall.net/4.2/FAQ.htm#faq2 also read faq2b at same link. I must confess not reading this thread too carefully, but if what that faq describes is the problem, you need to look at the contortions taken at eg http://www.openbsd.org/faq/pf/rdr.html#reflect Also a variation at http://home.nuug.no/~peter/pf/newest/rdr2servers.html and the slides immediately following. - Peter In the end, I went with a split horizon dns server, as your first link (and Shorewall) suggested. Since I was setting up a dns server anyway, and this did in fact solve all of our problems (mail and web) in one stroke rather than a dozen rules. I believe the RDR-TO and NAT-TO Combination mentioned in your first slide was the alternative but it required two rules for each service, and you can just forget about ftp. Still I wonder why it USED to work for Soós László in 5.5?
Re: kernel page fault trap
Hello, On 23 November 2014 at 06:27, Philip Guenther wrote: > On Wed, 12 Nov 2014, Nikos Skalkotos wrote: >> Hello, here is the complete output: > > okay, fdisk output and disklabel output look sane and match up. > > The diff of the dumpfs output is interesting: > > -^magic 11954 (FFS1)timeWed Nov 12 10:13:55 2014 > +^magic 11954 (FFS1)timeWed Nov 12 10:19:09 2014 > -ncg 6 ncyl6 size522096 blocks 512247 > +ncg 505 ncyl505 size52350320blocks 51522108 > -nbfree 36554 ndir1011nifree 141082 nffree 208 > +nbfree 6412786 ndir1011nifree 13107098nffree 213 > -csaddr 1648cssize 2048 > +csaddr 1648cssize 8192 > > Note the cssize (cylinder summary size) has grown but csaddr hasn't > changed. That means it probably had to relocate allocated blocks. This > being your root disk, it may have relocated blocks in /boot, which would > require re-running installboot. > > (FreeBSD has actually deleted the code to support that and made their > growfs always relocate the cylinder summary to the first of the new > cylinder groups; we may want to do that too; moving allocated blocks > around is a nasty wart.) > > There may also be bugs around growfs assuming the new area is zero-filled, > which it might not be. It may be a good test to try zeroing the new area > with dd before running growfs and see if that makes it behave correctly. > I tried zeroing the space first, and then copying the openbsd image into the zeroed space like this: # lvcreate -L 100G -n test images Logical volume "test" created # dd if=/dev/zero of=/dev/images/test bs=4M dd: writing `/dev/images/test': No space left on device 25601+0 records in 25600+0 records out 107374182400 bytes (107 GB) copied, 172.191 s, 624 MB/s # dd if=/dev/images/openbsd-5.6 of=/dev/images/test bs=4M 256+0 records in 256+0 records out 1073741824 bytes (1.1 GB) copied, 5.06499 s, 212 MB/s But I get the very same error after resizing. I don't think this is it. > >> uvm_fault(0x81d97be0, 0x8d2a5811, 0, 2) -> e >> kernel: page fault trap, code=0 >> Stopped at worklist_print+0x26b: addb%al,acpi_pdirpa+0xbfeeac0 >> ddb> trace >> worklist_print() at worklist_print+0x26b >> ffs_init() at ffs_init+0xa4 >> vfs_register() at vfs_register+0x94 >> vfsinit() at vfsinit+0x80 >> main() at main+0x457 >> end trace frame: 0x0, count: -5 >> ddb> > > That's an odd place to crash, having nothing to do with the filesystem > itself; that's just where it hooks in the code to support FFS filesystems > at all. Being not directly related makes me wonder if growfs is > corrupting your kernel by its relocating of blocks from the first cylinder > group... > > > Philip Guenther Nikos P.S. I tried sending the same mail from skalk...@grnet.gr a few hours ago but It hasn't reached the list yet. I don't know what's going on. I 'll try to only answer from gmail from now on.
Re: Is this a gstreamer-issue?
[ Sorry for top-posting - the web-mailer is awful and breaks any formatting...] Hi Stuart, thank you for the info - is the change to glib2 already in the packages? My system has those as of Sunday. As soon as my system has the latest packages I will reenable 'gst-plugin-scanner' and see what happens. STEFAN Gesendet: Montag, 24. November 2014 um 11:08 Uhr Von: "Stuart Henderson" An: misc@openbsd.org Betreff: Re: Is this a gstreamer-issue?On 2014-11-22, Stefan Wollny wrote: > Hi there! > > The following errors are 100% reproducible on my system: > > ~ $ firefox https://google.de > 1416671415148 GMPInstallManager.simpleCheckAndInstall INFO Last > check was: 55940 seconds ago, minimum seconds: 86400 > 1416671415154 GMPInstallManager.simpleCheckAndInstall INFO Will not > check for updates. > /usr/local/libexec/gstreamer-1.0/gst-plugin-scanner:/usr/lib/libstdc++.so.57.0: > /usr/local/lib/libestdc++.so.16.0 : WARNING: > symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your > program > gst-plugin-scanner(5187) in free(): error: bogus pointer (double free?) > 0xef1f24f8340 > ^C > > ~ $ xombrero https://google.de > xombrero:/usr/local/lib/libestdc++.so.16.0: /usr/lib/libstdc++.so.57.0 : > WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, > relink your program > /usr/local/libexec/gstreamer-1.0/gst-plugin-scanner:/usr/lib/libstdc++.so.57.0: > /usr/local/lib/libestdc++.so.16.0 : WARNING: > symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your > program > gst-plugin-scanner(7894) in free(): error: bogus pointer (double free?) > 0x8ab0c4f3340 > ^C > > This error does not show up with only one regular http-site, but (at > least with Firefox) happens with 7+ tabs opened. > > Both browsers stop responding altogether. I can't even close the window: > If started in an xterm (like shown above) I have to kill the app with > STRG-C; otherwise via "kill -9". I saw something which looked like this, which went away after I rebuilt glib2 (just rebuilding/forcibly reinstalling the same version was enough). I am wondering if somehow a broken package was built. I committed a minor tweak to glib2 which will trigger packages to update, so I'm hoping that just updating to the newest package snapshot will help things, though it would be nice to know how this happened in the first place.
Re: fastcgi support in httpd(8)
On 2014-11-22, Vadim Zhukov wrote: > Crazy idea just out of head: > > 1. Put /bin/sh and /usr/bin/kdump (both are statically linked) inside > chroot. Rename them if you feel unsafe. > 2. Write a shell script that runs 'exec ktrace -if ... perl ... "$@"'. Make > sure ktrace will be able to write its output file, it will be run as CGI > user! > 3. Make this script handle a connection in your web server/FastCGI config. > 4. Run kdump on resulting ktrace output file and investigate problems. > > If you won't get ktrace output, you'll likely have problem with FastCGI > itself, look at its logs then. Simpler way: run slowcgi under ktrace (with the -i flag).
Re: Is this a gstreamer-issue?
On 2014-11-22, Stefan Wollny wrote: > Hi there! > > The following errors are 100% reproducible on my system: > > ~ $ firefox https://google.de > 1416671415148 GMPInstallManager.simpleCheckAndInstall INFOLast > check was: 55940 seconds ago, minimum seconds: 86400 > 1416671415154 GMPInstallManager.simpleCheckAndInstall INFOWill not > check for updates. > /usr/local/libexec/gstreamer-1.0/gst-plugin-scanner:/usr/lib/libstdc++.so.57.0: > /usr/local/lib/libestdc++.so.16.0 : WARNING: > symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your > program > gst-plugin-scanner(5187) in free(): error: bogus pointer (double free?) > 0xef1f24f8340 > ^C > > ~ $ xombrero https://google.de > xombrero:/usr/local/lib/libestdc++.so.16.0: /usr/lib/libstdc++.so.57.0 : > WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, > relink your program > /usr/local/libexec/gstreamer-1.0/gst-plugin-scanner:/usr/lib/libstdc++.so.57.0: > /usr/local/lib/libestdc++.so.16.0 : WARNING: > symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your > program > gst-plugin-scanner(7894) in free(): error: bogus pointer (double free?) > 0x8ab0c4f3340 > ^C > > This error does not show up with only one regular http-site, but (at > least with Firefox) happens with 7+ tabs opened. > > Both browsers stop responding altogether. I can't even close the window: > If started in an xterm (like shown above) I have to kill the app with > STRG-C; otherwise via "kill -9". I saw something which looked like this, which went away after I rebuilt glib2 (just rebuilding/forcibly reinstalling the same version was enough). I am wondering if somehow a broken package was built. I committed a minor tweak to glib2 which will trigger packages to update, so I'm hoping that just updating to the newest package snapshot will help things, though it would be nice to know how this happened in the first place.
Re: openbsd 5.6 - pf does not work on local redirects
On 2014-11-22, Soós László wrote: > Dear List, > > I'm struggling to understand which change in 5.6 implied that my pf > redirects do not work anymore on the openbsd host itself. > It all worked okay in OpenBSD 5.5, I did not change anything in the > ruleset, just updated from 5.5 -> 5.6. > > Is there anybody who is facing similar issue with pf in OpenBSD 5.6? Is > there any solutions for it? > > > > [root ~]# ifconfig em0 > em0: flags=28843 mtu 1500 > lladdr 00:0c:29:xx:xx:xx > inet yy.yy.yy.131 netmask 0xff00 broadcast yy.yy.yy.255 > > [root ~]# pfctl -sr -vv | less > ... > @88 pass in quick inet proto tcp from any to yy.yy.yy.131 port = 25 > flags S/SA keep state (if-bound) rdr-to 10.9.8.4 >[ Evaluations: 783 Packets: 533 Bytes: 126263 States: 1 ] >[ Inserted: uid 0 pid 17457 State Creations: 22] > ... > > pf.conf sniplet > --- > set skip on lo > > pass in quickproto tcp from any to $ext_ip port smtp > rdr-to $int_host_mail I don't see how this can have worked before. A packet generated on the firewall itself would not match a "pass in ..." rule, unless that packet was being sent to another system (ISP router?) which then forwarded it back to the firewall.
Re: Can't Install OpenBSD 5.6 with FTP
On 2014-11-23 Sun 02:34 AM |, Hendrickson, Kenneth wrote: > I now must figure out how to get a http server running. > After 3 hours, it isn't working yet. Make sure you've got the index.txt files. > > Why was this done? http://www.openbsd.org/faq/upgrade55.html#headsup "FTP will no longer be an install option for 5.6. Instead, HTTP will be used. This should not impact users of public mirrors, but if you replicate internally, you may wish to make sure your files can be served by HTTP." http://marc.info/?l=openbsd-misc&m=139579420802409&w=2 -- Spectacular footage of NZ train plowing through deep June snow http://youtu.be/6acPX_00M9Q
Re: Trackpad after suspend/resume on MacBookAir4,1
On 24/11/14(Mon) 09:04, Peter Hessler wrote: > Can you switch from the graphical console (ctrl-alt-f5) to a text > console (ctrl-alt-f1), and back? That may help with input device > related problems. That won't work in this case. His pointer isn't behind the mux and needs to be calibrated.
Re: Trackpad after suspend/resume on MacBookAir4,1
Can you switch from the graphical console (ctrl-alt-f5) to a text console (ctrl-alt-f1), and back? That may help with input device related problems. On 2014 Nov 23 (Sun) at 11:08:23 -0500 (-0500), Maximilian Pichler wrote: :Hi, : :After resuming from suspend (either by closing and reopening the lid :or via zzz) the trackpad behaves erratically -- the pointer jumps :around wildly when using it. The issue is reproducible. : :Here is the dmesg from boot: : :OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug 8 00:20:21 MDT 2014 :dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP :RTC BIOS diagnostic error :fb :real mem = 4185079808 (3991MB) :avail mem = 4064886784 (3876MB) :mpath0 at root :scsibus0 at mpath0: 256 targets :mainbus0 at root :bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (53 entries) :bios0: vendor Apple Inc. version "MBA41.88Z.0077.B11.1310091428" date 10/09/2013 :bios0: Apple Inc. MacBookAir4,1 :acpi0 at bios0: rev 2 :acpi0: sleep states S0 S3 S4 S5 :acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT :SSDT SSDT SSDT MCFG SSDT SSDT SSDT :acpi0: wakeup devices P0P2(S4) EC__(S4) HDEF(S4) ARPT(S4) RP02(S4) :EHC1(S3) EHC2(S3) ADP1(S4) LID0(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) i7-2677M CPU @ 1.80GHz, 1800.24 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 100MHz :cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE :cpu1 at mainbus0: apid 2 (application processor) :cpu1: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz, 1800.02 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 0, core 1, package 0 :cpu2 at mainbus0: apid 1 (application processor) :cpu2: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz, 1800.02 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 1, core 0, package 0 :cpu3 at mainbus0: apid 3 (application processor) :cpu3: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz, 1800.02 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 :ioapic0: misconfigured as apic 0, remapped to apid 2 :acpiec0 at acpi0 :acpimcfg0 at acpi0 addr 0xe000, bus 0-151 :acpiprt0 at acpi0: bus 0 (PCI0) :acpiprt1 at acpi0: bus 3 (P0P2) :acpiprt2 at acpi0: bus 2 (RP02) :acpicpu0 at acpi0: C3, C2, C1, PSS :acpicpu1 at acpi0: C3, C2, C1, PSS :acpicpu2 at acpi0: C3, C2, C1, PSS :acpicpu3 at acpi0: C3, C2, C1, PSS :acpibat0 at acpi0: BAT0 model "3545797981023400290" type :3545797981528607052 oem "3545797981528608836" :acpiac0 at acpi0: AC unit offline :acpibtn0 at acpi0: LID0 :acpibtn1 at acpi0: PWRB :acpibtn2 at acpi0: SLPB :acpivideo0 at acpi0: IGPU :acpivout0 at acpivideo0: DD02 :cpu0: Enhanced SpeedStep 1800 MHz: speeds: 1801, 1800, 1700, 1600, :1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz :memory map conflict 0xe00f8000/0x1000 :memory map conflict 0xfed1c000/0x4000 :memory map conflict 0xffed/0x3 :pci0 at mainbus0 bus 0 :pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 :ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi :pci1 at ppb0 bus 3 :ppb1 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x151a rev 0x01 :pci2 at ppb1 bus 4 :ppb2 at pci2 dev 0 function 0 vendor "Intel", unknown product 0x151a rev 0x01 :pci3 at ppb2 bus 5 :vendor "Intel", unknown product 0x151a (class system subclass :miscellaneous, rev 0x01) at pci3 dev 0 function 0 not configured :ppb3 at pci2 dev 3 function 0 vendor "Intel", unknown product 0x151a rev 0x01 :pci4 at ppb3 bus 6 :ppb4 at pci2 dev 4 function 0 vendor "Intel", unknown product 0x151a rev 0x01 :pci5 at ppb4 bus 55 :vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 :i
Re: making firefox less insecure
On Sun, Nov 23, 2014 at 02:41:10PM -0500, Jonathan Thornburg wrote: > > I can see several possible forms of exploit-mitigation: > > (a) use the noscript firefox extension to block javascript > > (b) use capsicum to sandbox forefox and any plugin processes > > (c) run firefox in a chroot jail > > (d) have firefox talk to an Xephyr(1) instance > > so it's semi-isolated from the main X server > > (e) maybe have firefox go through an ssh tunnel to localhost > > (f) run firefox as an unpriviliged user _firefox, group _firefox, and > > use Unix file permissions to deny that user access to $HOME/ Well, other way could to use Qubes OS as "hypervisor" (yeah x86 virtualization) and run OpenBSD as VMs. Although OpenBSD is not para- virtualized for Xen but Qubes OS supports Windows and they just need to support vmchannel inter-VM communication interface. Qubes OS exploits this interface and wrote lightweight GUI protocol on top of that and other lightweight communication messaging. See https://wiki.qubes-os.org/ IIUC even NetBSD doesn't have vmchannel driver ready :( j.