Re: OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
On Wed, Oct 30, 2019 at 12:14:20PM +0100, Jurjen Oskam wrote: > On Tue, Oct 29, 2019 at 01:25:10PM -0700, Mike Larkin wrote: > > > On Tue, Oct 29, 2019 at 09:16:42PM +0100, Jurjen Oskam wrote: > [...] > > > uvn_flush: obj=0xfd813ee78298, offset=0x33f. error during > > > pageout. > > > uvn_flush: WARNING: changes to page may be lost! > > > uvn_flush: obj=0x0, offset=0x33f. error during pageout. > > > uvn_flush: WARNING: changes to page may be lost! > > > [ repeat last two lines many times ] > [...] > > > nvme0 at pci19 dev 0 function 0 "VMware NVMe" rev 0x00: apic 1 int 16, > > > NVMe 1.0 > > > nvme0: VMware Virtual NVMe Disk, firmware 1.0, serial VMWare NVME- > > > > Why did you assign this non-default disk type to the guest VM? > > > > Try assigning mpi(4) (LSI Logic SAS) instead. I've been using that with my > > ESXi 6.7U3 box here without problems for weeks. > > > > If that works, it's either an error in our nvme(4) driver or ESXi's > > emulation > > of the NVMe hardware. > > I forgot to mention that I tried using different controller types, and > nvme(4) happened to be the one I took the dmesg of. The ones I tried were > LSI Logic SAS, LSI Logic Parallel and VMware Paravirtual (the latter > after working around the lost first write problem). All showed the same > symptom. > > I have been trying old snapshots (thanks to the snapshot archive at > ftp.hostserver.de), and found the point where the problem started to > occur: > > All snapshots I tried up to and including this point did not show the > problem: > OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 > > All snapshots I tried starting from this point show the problem: > OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 > > > Would it be helpful to start a binary search for the exact commit that > introduced the problem? I've been looking at the commit history around > that time but haven't been able to spot an obvious candidate; but that's > probably because I'm not a programmer. > > Regards, > > Jurjen Oskam > > yes.
Re: [6.6] PostgreSQL server: fail to auth
On Wed, Oct 30, 2019 at 05:45:15PM +0100, Stéphane HUC "PengouinBSD" wrote: > Hi, > > On my OpenBSD server, run with 6.6, I installed Postgresql server. > > I have a problem with auth. solene@ is informed of this problem; but > I'll tell you about it. Perhaps you have a solution? > > FYI: I start completely with Postgresql. Usually I use MySQL* > Postgresql has just been installed. > > > > The error message: > > psql: FATAL: password authentication failed for user "***" > > > > Demo: > > # su - _postgresql > arrakiss$ psql -U postgres > Password for user postgres: > psql (11.5) > Type "help" for help. > > postgres=# CREATE USER ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 WITH PASSWORD > '6TsrKeqq93KyVtc5yVjU9dfZsJkPPtKKdSyEnjypZDkVdgtW4aVN3YNQd5vKoFNx'; > CREATE ROLE > postgres=# \connect template1 > You are now connected to database "template1" as user "postgres". > template1=# CREATE DATABASE "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" WITH > ENCODING 'UTF-8';" > CREATE DATABASE > template1"# GRANT ALL PRIVILEGES ON DATABASE > "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" TO ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2; > template1"# ALTER DATABASE "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" OWNER TO > ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2; > template1"# \q > Use control-D to quit. > template1"# \q > arrakiss$ exit > > In fact, I have one created user, named ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 > His password: > 6TsrKeqq93KyVtc5yVjU9dfZsJkPPtKKdSyEnjypZDkVdgtW4aVN3YNQd5vKoFNx > One created DB, named: > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > > And the user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 has all rights on DB > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > > Right?! > > But, when I attempt to connect to DB with user, I have the above the > error message: > # psql -U ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 > Password for user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2: > psql: FATAL: password authentication failed for user > "ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2" > > # psql -U ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 -d > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > Password for user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2: > psql: FATAL: password authentication failed for user > "ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2" > > Ok I found it's necessary to change informations into file > 'pg_hba.conf'. I set as: > # grep A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > /var/postgresql/data/pg_hba.conf > > > local A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 alltrust > > And restart the service/daemon postgresql. > > Despite, I cant connect on! > > --- > > Any idea, please?! > > -- > ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< > > Stephane HUC as PengouinBSD or CIOTBSD > b...@stephane-huc.net > I think the problem might be that the user tC1xQOo7KSLdnc5J1VmGFChhodnH doesn't have the proper password of 47znNtnBlhViIzSm9GZFSQirlb8HIQcSl, which according to your PG installation, is required for accessing the database 'dqXijG7C1GGkuu98ZirPFwu2XTMo3V0QlF4'. Of course, it also might be because the user ZYo43MnD5aW5P4wqqeSE9aInA5SL9HURvpmpOZ doesn't have access to database NfyhoNhUQWZiZKOTtl0K7mR4yPEsMy8sJC to begin with. Seriously, did you expect someone to take the time to decipher what you wrote there? -ml
Re: OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
On 2019-10-30, Jurjen Oskam wrote: > > All snapshots I tried up to and including this point did not show the > problem: > OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 > > All snapshots I tried starting from this point show the problem: > OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 > > > Would it be helpful to start a binary search for the exact commit that > introduced the problem? Yes, definitely! We usually do this with date-based cvs updates. > I've been looking at the commit history around > that time but haven't been able to spot an obvious candidate; but that's > probably because I'm not a programmer. Sometimes diffs are tested in snapshots before they're committed, so you might need to look beyond the snapshot dates to find the commit.
Re: Display flickers after upgrade to 6.6
I haven't tried those settings yet (in my case GNOME Shell and Xfdashboard cause the display to corrupt and seize up except the cursor) but ShadowPrimary is a glamor option that should be irrelevant if EXA is used. For years I've also observed text flickering in the console after drm is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman should be fine with 8 million pixels. -- Patrick Harper paia...@fastmail.com On Wed, 30 Oct 2019, at 13:12, Jeff wrote: > On Sat, 19 Oct 2019 17:59:41 +0200 > Federico Giannici wrote: > > > On 2019-10-19 16:17, Andre Stoebe wrote: > > > Hi, > > > > > > I ran into the same issue this morning. Disabling the compositor > > > worked for me, but I noticed later that this is also documented in > > > the package readme: > > > > > > Screen compositor > > > = > > > If you're using the modesetting X driver and experience window > > > flickering when > > > the compositor is enabled, you should force the window manager to > > > use the XPresent method for vblank: > > > > > > $xfwm4 --vblank=xpresent --replace & > > > > I tried that command but it screwed all my windows (no more window > > decorations and buttons, I cannot operate on windows)! > > Now I had to came back to KDE... > > :-( > > > > Regards > > > > > > > This is documented upstream at > > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114 > > > > > > Haven't tested that yet and left the compositor disabled, but I > > > guess this will fix your issues. If it does, that's probably a good > > > reminder to first look in the readme next time (me included). ;) > > > > > > Regards, > > > André > > > > > Hi, I thought I'd relate my experience: I also experienced this issue on > a machine recently upgraded to OpenBSD 6.6 which uses the aruba > chipset and also running xfce. My workaround > (which was based on 'try stuff to see what works') involved turning off > compositing and > (via xorg.conf.d): > > ... > Option "AccelMethod" "EXA" > Option "ShadowPrimary" "on" > Option "SwapbuffersWait" "off" > Option "EnablePageFlip" "off" > ... > > This resolved issues with flickering, the mouse pointer vanishing and > re-appearing depending on which window is below the pointer (enabling > software mouse pointer for this was worse as garbage was rendered in a > rect surrounding the pointer), and also *some* issues with logging > in-out of an X session via xenodm. > > I still experience problems with the machine going to sleep and waking > up, as sometimes, upon wake-up, the graphics go wonky, or don't update > at all, or the mouse pointer goes wonky. > > Beyond the aforementioned, this set-up seems to allow me to use the > machine as before, however, I am not an X11 expert nor a radeondrm > driver expert; your mileage may very. > > If I ever try Andre's hint in the future (thank-you), I might report on > success/failure. > > regards, > > Jeff > >
minor tcpdump.8 inconsistency
minor inconsistency diff --git a/tcpdump.8 b/tcpdump.8 index ce16951..8c2cf33 100644 --- a/tcpdump.8 +++ b/tcpdump.8 @@ -1257,7 +1257,7 @@ end of this connection. .Ar window is the number of bytes of receive buffer space available at the other end of this connection. -.Ar urg +.Ar urgent indicates there is urgent data in the packet. .Ar options are TCP options enclosed in angle brackets e.g.,
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > minor inconsistency > > diff --git a/tcpdump.8 b/tcpdump.8 > index ce16951..8c2cf33 100644 > --- a/tcpdump.8 > +++ b/tcpdump.8 > @@ -1257,7 +1257,7 @@ end of this connection. > .Ar window > is the number of bytes of receive buffer space available > at the other end of this connection. > -.Ar urg > +.Ar urgent > indicates there is urgent data in the packet. > .Ar options > are TCP options enclosed in angle brackets e.g., > hi. have you established that it's the documentation that is wrong? i.e. that "urgent" is printed, and not actually "urg"? jmc
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 05:23:12PM +, Jason McIntyre wrote: > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > > minor inconsistency > > > > diff --git a/tcpdump.8 b/tcpdump.8 > > index ce16951..8c2cf33 100644 > > --- a/tcpdump.8 > > +++ b/tcpdump.8 > > @@ -1257,7 +1257,7 @@ end of this connection. > > .Ar window > > is the number of bytes of receive buffer space available > > at the other end of this connection. > > -.Ar urg > > +.Ar urgent > > indicates there is urgent data in the packet. > > .Ar options > > are TCP options enclosed in angle brackets e.g., > > > > hi. > > have you established that it's the documentation that is wrong? i.e. > that "urgent" is printed, and not actually "urg"? > > jmc > It is "urg". The correct diff is this, I think. -Otto Index: tcpdump.8 === RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v retrieving revision 1.107 diff -u -p -r1.107 tcpdump.8 --- tcpdump.8 25 Sep 2019 17:02:00 - 1.107 +++ tcpdump.8 31 Oct 2019 17:28:59 - @@ -1219,7 +1219,7 @@ will be of much use to you. The general format of a TCP protocol line is: .Bd -ragged -offset indent .Ar src No > Ar dst : -.Ar flags src-os data-seqno ack window urgent options +.Ar flags src-os data-seqno ack window urg options .Ed .Pp .Ar src
Re: minor tcpdump.8 inconsistency
Jason McIntyre wrote: > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > > minor inconsistency > > > > diff --git a/tcpdump.8 b/tcpdump.8 > > index ce16951..8c2cf33 100644 > > --- a/tcpdump.8 > > +++ b/tcpdump.8 > > @@ -1257,7 +1257,7 @@ end of this connection. > > .Ar window > > is the number of bytes of receive buffer space available > > at the other end of this connection. > > -.Ar urg > > +.Ar urgent > > indicates there is urgent data in the packet. > > .Ar options > > are TCP options enclosed in angle brackets e.g., > > > > hi. > > have you established that it's the documentation that is wrong? i.e. > that "urgent" is printed, and not actually "urg"? The situation is a bit more subtle than that. Just above, the manual page leads with this header. The general format of a TCP protocol line is: src > dst: flags src-os data-seqno ack window urgent options It is saying there's a section of the line regarding the _window_, then a section regarding _urgent_, then a section regarding _options_. In the next paragraph it vaguely describes each of these without getting into the specifics of the actual printed format (for instance, _window_ is actually printed as " win %u". The .Ar above are the "section names" of the line. I think Tim's diff is right.
Re: minor tcpdump.8 inconsistency
Otto Moerbeek wrote: > On Thu, Oct 31, 2019 at 05:23:12PM +, Jason McIntyre wrote: > > > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > > > minor inconsistency > > > > > > diff --git a/tcpdump.8 b/tcpdump.8 > > > index ce16951..8c2cf33 100644 > > > --- a/tcpdump.8 > > > +++ b/tcpdump.8 > > > @@ -1257,7 +1257,7 @@ end of this connection. > > > .Ar window > > > is the number of bytes of receive buffer space available > > > at the other end of this connection. > > > -.Ar urg > > > +.Ar urgent > > > indicates there is urgent data in the packet. > > > .Ar options > > > are TCP options enclosed in angle brackets e.g., > > > > > > > hi. > > > > have you established that it's the documentation that is wrong? i.e. > > that "urgent" is printed, and not actually "urg"? > > > > jmc > > > > It is "urg". The correct diff is this, I think. > > -Otto > > Index: tcpdump.8 > === > RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v > retrieving revision 1.107 > diff -u -p -r1.107 tcpdump.8 > --- tcpdump.8 25 Sep 2019 17:02:00 - 1.107 > +++ tcpdump.8 31 Oct 2019 17:28:59 - > @@ -1219,7 +1219,7 @@ will be of much use to you. > The general format of a TCP protocol line is: > .Bd -ragged -offset indent > .Ar src No > Ar dst : > -.Ar flags src-os data-seqno ack window urgent options > +.Ar flags src-os data-seqno ack window urg options > .Ed > .Pp > .Ar src I don't agree. Because then "window" needs to be replaced with "win" as well, and through the entire next paragraph also, and some people may not win understanding but lose it instead.
Suspend on Dell Inspiron 6000
Hi, All:
I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
doesn't in 6.6.
What is the best way for me to go about debugging this issue? So far,
I have checked:
- dmesg for ACPI wake devices
- syslog for suspend messages
Specifically, the suspend works; however, when I attempt to wake the
device, the laptop seems to respond and attempt to wake, but the
display never turns on, and I cannot SSH into the machine. Below are
the dmesg and relevant syslog entries.
dmesg
=
OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 527790080 (503MB)
avail mem = 502480896 (479MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @
0xf80e0 (44 entries)
bios0: vendor Dell Inc. version "A09" date 09/28/2005
bios0: Dell Inc. Inspiron 6000
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0)
USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30
GHz, 06-0d-06
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE)
acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt)
acpitz0 at acpi0: critical temperature is 99 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
bios0: ROM list: 0xc/0xf800! 0xcf800/0x800
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0: apic 1 int 16
"Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
pci1 at ppb0 bus 3
bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18,
address 00:11:43:70:7f:12
bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
"Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
sdhc0: SDHC 1.0, 33 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17,
address 00:0b:7d:15:3a:24
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 16,
ICH6
ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D
audio0 at auich0
"Intel 82801FB Modem" rev 0x03 at pci0 dev 30 function 3 not configured
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FBM LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 2 "Intel 82801FBM SATA" rev 0x03: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
ad
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote:
> Hi, All:
>
> I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> doesn't in 6.6.
>
> What is the best way for me to go about debugging this issue? So far,
> I have checked:
> - dmesg for ACPI wake devices
> - syslog for suspend messages
>
> Specifically, the suspend works; however, when I attempt to wake the
> device, the laptop seems to respond and attempt to wake, but the
> display never turns on, and I cannot SSH into the machine. Below are
> the dmesg and relevant syslog entries.
>
About a year or so ago I posted a message to either misc@ or tech@ about
how to diagnose suspend/resume failures, by bisecting the resume path and
placing resets or spins at various places to see how far the resume gets
before dying. I would recommend finding that post (I just looked and I
couldn't find it though) and walking through those steps.
I doubt any of us still have machines that old to try debugging this
ourselves, the machine is nearly 15 years old.
-ml
> dmesg
> =
>
> OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 527790080 (503MB)
> avail mem = 502480896 (479MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @
> 0xf80e0 (44 entries)
> bios0: vendor Dell Inc. version "A09" date 09/28/2005
> bios0: Dell Inc. Inspiron 6000
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
> acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0)
> USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30
> GHz, 06-0d-06
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpimcfg0: addr 0x0, bus 0-0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 3 (PCIE)
> acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
> halt)
> acpitz0 at acpi0: critical temperature is 99 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> acpivideo0 at acpi0: VID_
> acpivideo1 at acpi0: VID_
> acpivideo2 at acpi0: VID2
> bios0: ROM list: 0xc/0xf800! 0xcf800/0x800
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xc000, size 0x1000
> inteldrm0: apic 1 int 16
> "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
> pci1 at ppb0 bus 3
> bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18,
> address 00:11:43:70:7f:12
> bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
> cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
> "Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
> sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
> sdhc0: SDHC 1.0, 33 MHz base clock
> sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
> bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17,
> address 00:0b:7d:15:3a:24
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
> pcmcia0 at cardslot0
> auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int
> 16, ICH6
> ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
> ac97: codec features headphone, 20 bit DAC, 20 bit ADC,
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 11:33:14AM -0600, Theo de Raadt wrote: > Jason McIntyre wrote: > > > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > > > minor inconsistency > > > > > > diff --git a/tcpdump.8 b/tcpdump.8 > > > index ce16951..8c2cf33 100644 > > > --- a/tcpdump.8 > > > +++ b/tcpdump.8 > > > @@ -1257,7 +1257,7 @@ end of this connection. > > > .Ar window > > > is the number of bytes of receive buffer space available > > > at the other end of this connection. > > > -.Ar urg > > > +.Ar urgent > > > indicates there is urgent data in the packet. > > > .Ar options > > > are TCP options enclosed in angle brackets e.g., > > > > > > > hi. > > > > have you established that it's the documentation that is wrong? i.e. > > that "urgent" is printed, and not actually "urg"? > > The situation is a bit more subtle than that. Just above, the manual > page leads with this header. > > The general format of a TCP protocol line is: > >src > dst: flags src-os data-seqno ack window urgent options > > It is saying there's a section of the line regarding the _window_, then a > section regarding _urgent_, then a section regarding _options_. In the > next paragraph it vaguely describes each of these without getting into > the specifics of the actual printed format (for instance, _window_ is > actually printed as " win %u". > > The .Ar above are the "section names" of the line. I think Tim's diff is > right. > > ok, i see your point (after a bit of head scratching). i'll commit the diff then. jmc
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > minor inconsistency > > diff --git a/tcpdump.8 b/tcpdump.8 > index ce16951..8c2cf33 100644 > --- a/tcpdump.8 > +++ b/tcpdump.8 > @@ -1257,7 +1257,7 @@ end of this connection. > .Ar window > is the number of bytes of receive buffer space available > at the other end of this connection. > -.Ar urg > +.Ar urgent > indicates there is urgent data in the packet. > .Ar options > are TCP options enclosed in angle brackets e.g., > fixed, thanks. jmc
Re: minor tcpdump.8 inconsistency
On Thu, Oct 31, 2019 at 06:08:12PM +, Jason McIntyre wrote: > On Thu, Oct 31, 2019 at 11:33:14AM -0600, Theo de Raadt wrote: > > Jason McIntyre wrote: > > > > > On Thu, Oct 31, 2019 at 02:15:34PM +0100, Tim Kuijsten wrote: > > > > minor inconsistency > > > > > > > > diff --git a/tcpdump.8 b/tcpdump.8 > > > > index ce16951..8c2cf33 100644 > > > > --- a/tcpdump.8 > > > > +++ b/tcpdump.8 > > > > @@ -1257,7 +1257,7 @@ end of this connection. > > > > .Ar window > > > > is the number of bytes of receive buffer space available > > > > at the other end of this connection. > > > > -.Ar urg > > > > +.Ar urgent > > > > indicates there is urgent data in the packet. > > > > .Ar options > > > > are TCP options enclosed in angle brackets e.g., > > > > > > > > > > hi. > > > > > > have you established that it's the documentation that is wrong? i.e. > > > that "urgent" is printed, and not actually "urg"? > > > > The situation is a bit more subtle than that. Just above, the manual > > page leads with this header. > > > > The general format of a TCP protocol line is: > > > >src > dst: flags src-os data-seqno ack window urgent options > > > > It is saying there's a section of the line regarding the _window_, then a > > section regarding _urgent_, then a section regarding _options_. In the > > next paragraph it vaguely describes each of these without getting into > > the specifics of the actual printed format (for instance, _window_ is > > actually printed as " win %u". > > > > The .Ar above are the "section names" of the line. I think Tim's diff is > > right. > > > > > > ok, i see your point (after a bit of head scratching). i'll commit the > diff then. > > jmc > i should have added that the macros in this page are poorly used, and that caused my confusion. it's another issue though. jmc
Re: Display flickers after upgrade to 6.6
I can confirm that switching to EXA made GNOME usable. This'll only work up to Northern Islands cards/IGPs though. Guess I'll be holding off of a GPU upgrade for a while longer. -- Patrick Harper paia...@fastmail.com On Thu, 31 Oct 2019, at 13:47, Patrick Harper wrote: > I haven't tried those settings yet (in my case GNOME Shell and > Xfdashboard cause the display to corrupt and seize up except the > cursor) but ShadowPrimary is a glamor option that should be irrelevant > if EXA is used. > > For years I've also observed text flickering in the console after drm > is loaded, but in 6.5 and prior 3D-accelerated stuff was usable. Cayman > should be fine with 8 million pixels. > > -- > Patrick Harper > paia...@fastmail.com > > On Wed, 30 Oct 2019, at 13:12, Jeff wrote: > > On Sat, 19 Oct 2019 17:59:41 +0200 > > Federico Giannici wrote: > > > > > On 2019-10-19 16:17, Andre Stoebe wrote: > > > > Hi, > > > > > > > > I ran into the same issue this morning. Disabling the compositor > > > > worked for me, but I noticed later that this is also documented in > > > > the package readme: > > > > > > > > Screen compositor > > > > = > > > > If you're using the modesetting X driver and experience window > > > > flickering when > > > > the compositor is enabled, you should force the window manager to > > > > use the XPresent method for vblank: > > > > > > > > $xfwm4 --vblank=xpresent --replace & > > > > > > I tried that command but it screwed all my windows (no more window > > > decorations and buttons, I cannot operate on windows)! > > > Now I had to came back to KDE... > > > :-( > > > > > > Regards > > > > > > > > > > This is documented upstream at > > > > https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114 > > > > > > > > Haven't tested that yet and left the compositor disabled, but I > > > > guess this will fix your issues. If it does, that's probably a good > > > > reminder to first look in the readme next time (me included). ;) > > > > > > > > Regards, > > > > André > > > > > > > > Hi, I thought I'd relate my experience: I also experienced this issue on > > a machine recently upgraded to OpenBSD 6.6 which uses the aruba > > chipset and also running xfce. My workaround > > (which was based on 'try stuff to see what works') involved turning off > > compositing and > > (via xorg.conf.d): > > > > ... > > Option "AccelMethod" "EXA" > > Option "ShadowPrimary" "on" > > Option "SwapbuffersWait" "off" > > Option "EnablePageFlip" "off" > > ... > > > > This resolved issues with flickering, the mouse pointer vanishing and > > re-appearing depending on which window is below the pointer (enabling > > software mouse pointer for this was worse as garbage was rendered in a > > rect surrounding the pointer), and also *some* issues with logging > > in-out of an X session via xenodm. > > > > I still experience problems with the machine going to sleep and waking > > up, as sometimes, upon wake-up, the graphics go wonky, or don't update > > at all, or the mouse pointer goes wonky. > > > > Beyond the aforementioned, this set-up seems to allow me to use the > > machine as before, however, I am not an X11 expert nor a radeondrm > > driver expert; your mileage may very. > > > > If I ever try Andre's hint in the future (thank-you), I might report on > > success/failure. > > > > regards, > > > > Jeff > > > > > >
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 10:56:38AM -0700, Mike Larkin wrote: > On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote: > > Hi, All: > > > > I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000 > > and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still > > doesn't in 6.6. > > > > What is the best way for me to go about debugging this issue? So far, > > I have checked: > > - dmesg for ACPI wake devices > > - syslog for suspend messages > > > > Specifically, the suspend works; however, when I attempt to wake the > > device, the laptop seems to respond and attempt to wake, but the > > display never turns on, and I cannot SSH into the machine. Below are > > the dmesg and relevant syslog entries. > > > > About a year or so ago I posted a message to either misc@ or tech@ about > how to diagnose suspend/resume failures, by bisecting the resume path and > placing resets or spins at various places to see how far the resume gets > before dying. I would recommend finding that post (I just looked and I > couldn't find it though) and walking through those steps. Possibly this one? https://marc.info/?l=openbsd-bugs&m=152536221312302&w=2 > > I doubt any of us still have machines that old to try debugging this > ourselves, the machine is nearly 15 years old. > > -ml > > > dmesg > > = > > > > OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019 > > r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC [cut]
Following current - pkg_add update forward depedencies don't match question
Hello I just updated a system to current the other day. OpenBSD 6.6 GENERIC.MP#411 amd64 The last time I updated was probably 2-3 months ago. Anyway, when I went to updated packages (also following current/snapshots), I got a number of "forward dependencies - don't match" notices and the packages don't update. For example: gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies: | Dependencies of php-apache-7.1.27p0 on gettext-* don't match | Dependencies of gnupg-1.4.23p1 on gettext-* don't match | Dependencies of glib2-2.58.3p8 on gettext-* don't match | Dependencies of courier-imap-4.18.2p0 on gettext-* don't match | Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match | Dependencies of libgpg-error-1.36 on gettext-* don't match | Dependencies of python-3.6.8p0 on gettext-* don't match | Dependencies of samba-4.8.9 on gettext-* don't match | Dependencies of gdbm-1.16 on gettext-* don't match | Dependencies of popt-1.16p1 on gettext-* don't match | Dependencies of aspell-0.60.6.1p8 on gettext-* don't match | Dependencies of libpsl-0.20.2 on gettext-* don't match | Dependencies of wget-1.20.2 on gettext-* don't match | Dependencies of php-7.1.27 on gettext-* don't match | Dependencies of libidn-1.35 on gettext-* don't match | Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match | Dependencies of python-2.7.16 on gettext-* don't match | Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match | Dependencies of fetchmail-6.3.26p2 on gettext-* don't match | Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match | Dependencies of p11-kit-0.23.15p0 on gettext-* don't match When I check: # pkg_info | grep gettext gettext-0.19.8.1p3 GNU gettext runtime libraries and programs And the mirror shows: gettext-runtime-0.20.1p0.tgz Or (another example), with similar notices about forward dependencies not matching: # pkg_info | grep php-7 php-7.1.27 server-side HTML-embedded scripting language And the mirror shows: php-7.1.32.tgz I see that I can "force" the update with "pkg_add -u -D updatedepends". It seems like this should be safe to do, but it's not something I have done before. While my system isn't "production" for a large multi-national, I do use it as a file server and stuff, and it is working right now, and I don't want to make it not work. So, before I did this, I was wondering if there was anything I should consider/do to address this issue, other than just "forcing" the update? I guess, when at its core, I don't really completely understand what the notice means, and how and why it happened. Thanks Ted
