Re: Limiting RAM on boot to emulate low-memory situation

[Mike Larkin]

On Sat, Oct 21, 2023 at 10:22:45AM -, Stuart Henderson wrote:
> On 2023-10-21, Chris Narkiewicz  wrote:
> > Is it possible to decrease amount of available RAM at boot time?
> >
> > I'm about to migrate some VPS system to a significantly cheaper option
> > that comes with less RAM and I need to evaluate how existing system
> > will behave.
> >
> > Sadly, I can't reconfigure RAM in VPS config.
>
> At least for x86, see "machine mem" in boot(8).
>
> --
> Please keep replies on the mailing list.
>

While mach mem in boot> will work for BIOS based machines, it does not work
in EFI (or at least it didn't, last time I checked). FYI.

Re: Limiting RAM on boot to emulate low-memory situation

[Stuart Henderson]

On 2023-10-21, Chris Narkiewicz  wrote:
> Is it possible to decrease amount of available RAM at boot time?
>
> I'm about to migrate some VPS system to a significantly cheaper option
> that comes with less RAM and I need to evaluate how existing system
> will behave.
>
> Sadly, I can't reconfigure RAM in VPS config.

At least for x86, see "machine mem" in boot(8).

-- 
Please keep replies on the mailing list.

Limiting RAM on boot to emulate low-memory situation

[Chris Narkiewicz]

Is it possible to decrease amount of available RAM at boot time?

I'm about to migrate some VPS system to a significantly cheaper option
that comes with less RAM and I need to evaluate how existing system
will behave.

Sadly, I can't reconfigure RAM in VPS config.

Cheers,
Chris

/var in ram

[Masturbating monkey]

hi guys. how to move /var to ram correctly?
what i do: 
i run nfs and mountd(and portmap, without it does not work), then i mount /var 
via mountd to some place, for example in /mnt/var (here i have to say "thanks" 
to the dude who sawed out LKM, you all know his name).
via mount_mfs i replace /var on disk with /var in ram, all this i writing in 
fstab. 
then i put openrsync in cron for synchronization /var in ram to original /var 
in /mnt/var. i also put openrsync in rc.shutdown in order to synchronize on 
shutdown (i can't use syncthing because in a critical task for the life of the 
system you can use only what is already in the system). 
finally, i edit /etc/rc and replace "mount -a -t nonfs,vnd" with "mount -a -t 
nonfs,vnd,mfs"(to be honest, i do not know what i am doing, but it works), 
otherwise when the system boots not everything from /var on disk is copied to 
/var in ram.
the first problem is that after a while, without any declaration of war, the 
system stops responding to anything. no, she's not crashing. so i do not know 
what exactly is going on, there is nothing interesting in the log. 
the second problem is that the use of openrsync leads to the fact that mbufs 
grow by a thousand at once, and do not return back. and plus a thousand is not 
the limit, and maybe this is the reason that the system hangs.
the third problem is that when the system is shutdowning, openrsync starts its 
dark deeds, but suddenly something kills him (i have some vague memories that 
this can be prevented somehow).
in general, it doesn't look like my path is right. what is the right way?

ps: and i also have a terrible feeling of deja vu. it was be somewhere before? 
i was looking for a match, but, unfortunately, most of my archive is lost, and 
google is no longer the same as before

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Nick Holland]

On 9/7/22 08:09, Jan Stary wrote:

> > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > the usb stick. I took out the NVMe-card, and whether or not that was the
> > problem the machine anyhow behaved better long enough for me to get
> > network and do a fw_update.
> 
> sure sounds like it could be a bad USB stick.

> Very common.  For important things, I have learned to write zeros over
> the entire USB stick before expecting it to actually work.  Nothing to
> do with the T5500.


I am puzzled: how exactly is a zero filled USB stick
less panicky than another USB stick?


My experience with floating gate storage (SSD, Flash) has been less
than stellar, and I'm a bit cynical about billions of microscopic
capacitors holding their charge reliably.  Well, perhaps I'm TOO
cynical, but I've had a lot of issues over the years. (I'm also cynical
about trillions of bits of magnetic flux, but my experience with
that has been better).

Especially with the "cheap" stuff (or top dollar stuff that is
actually cheap stuff with a big price tag), there often seem to have
bad spots on the drives that sometimes OpenBSD doesn't handle
gracefully.  Writing the entire surface of the drive seems to find
and lock out the bad spots in advance of their use for data.  Ideally,
I should probably write all zeros AND all ones, but if I'm in a rush
to get something in production (or BACK into production), I just do
zeros.  Writing zeros seems to help, I can't think of a case where
I can state with confidence that writing zeros and ones did something
better than just zeros.

For example, last week, I stuck a 60g USB drive on a machine, rsync'd
a bunch of data to it, and a little way in, it dropped to near zero
performance.  No obvious error, but the data stopped moving and the
USB system seemed to basically stop.  Could not reboot because the
OS couldn't umount the USB stick.  Power cycled, dd'ed zeros over
the drive, and now I've got no issues with it.

I've been able to extend the life of flakey SSDs the same way (don't
say "write fatigue", these drives haven't had a fraction of the
writes to be worried about "write fatigue".  They just weren't good
drives).

Plus...probably not a bad idea to know what data is on a USB drive
anyway.

Nick.

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Erling Westenvik]

On Wed, Sep 07, 2022 at 01:16:50PM +0100, Tom Smyth wrote:
> Hi Erling,
> 
> it depends do you mean soft raid, that will be either  AHCI  using intel
> driver or LSI  Raid emulation (where you can onfigure the raid in the
> option rom (after POST  just before the OS Boots)  it depneds on the
> chipset setup ...

Thanksn. And good question. I meant (and specified) softraid. The
machine has RAID options in BIOS but I have simply "standardized" on
using softraid on all hardware over the years.  

Are there gains (performance- or stability wise) in letting the hardware
do the RAID 1 mirroring instead of softraid?

Erling


> Dell may put  the LIS as a PERC,  it also may be a separate card or i/o
> module to the onboard sata ...
> Hope this helps
> 
> 
> On Wed, 7 Sept 2022 at 12:19, Erling Westenvik 
> wrote:
> 
> > On Wed, Sep 07, 2022 at 11:41:49AM +0100, Tom Smyth wrote:
> > > hi
> > >
> > > i would check bios / firmware settings
> > >
> > > try disabling memory mapped i/o in bios
> > >
> > > check processor settings enable vt-d disable hyper threading ensure
> > execute
> > > disable is enabled
> > >
> > > update the bios as it will update cpu microcode ...
> >
> > Great. Thanks, Tom.
> >
> > > dell alow you to select the emulation of sata
> > > ahci vs raid vs sata vs legacy
> >
> > For 2 x 525GB SSD's in RAID (softraid) 1, that setting would be...?
> >
> > Erling
> >
> > >
> > > On Wed 7 Sep 2022, 03:02 Erling Westenvik, 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > A friend donated an old Dell Precision T5500 workstation, a heavy
> > > > bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> > > > believe. At least it does for me. I would like it to replace my old i7
> > > > 3770k. However, I'm starting to have doubts:
> > > >
> > > > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > > > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > > > the usb stick. I took out the NVMe-card, and whether or not that was
> > the
> > > > problem the machine anyhow behaved better long enough for me to get
> > > > network and do a fw_update.
> > > >
> > > > 2) After fw_update the radeondrm was detected and I got a nice
> > 2560x1600
> > > > console. However, before it would give me a login prompt the machine
> > got
> > > > stuck with repeating complaints about "ehci_device_clear_toggle: queue
> > > > active". So – USB related, right?  Very well! Out with the usb stick,
> > in
> > > > with an old SSD with OpenBSD 6.7.
> > > >
> > > > 3) The machine behaves better, xenodm starts fine with cwm, but it
> > won't
> > > > resume after suspend (zzz).
> > > >
> > > > Some or all of the above problems may have solutions, trivial or not,
> > > > but more problems may perhaps lurk under the surface..?
> > > >
> > > > So I guess my question is if someone knows whether these Dell machines
> > > > are known to be error prone in general, or problematic with OpenBSD in
> > > > particular, and if I should stop before wasting time!?
> > > >
> > > > Sincerely,
> > > >
> > > > Erling
> > > >
> > > > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> > GENERIC.MP
> > > > real mem = 77290508288 (73709MB)
> > > > avail mem = 74930786304 (71459MB)
> > > > random: good seed from bootblocks
> > > > mpath0 at root
> > > > scsibus0 at mpath0: 256 targets
> > > > mainbus0 at root
> > > > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> > > > bios0: vendor Dell Inc. version "A18" date 10/15/2018
> > > > bios0: Dell Inc. Precision WorkStation T5500
> > > > acpi0 at bios0: ACPI 3.0
> > > > acpi0: sleep states S0 S3 S4 S5
> > > > acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT
> > SLIC
> > > > SSDT
> > > > acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5)
> > > > PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
> > > > PCI8(S5) PCIA(S5) PCIB(S5)
> > > > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> >

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Tom Smyth]

Hi Jan,
I have seen a number of cases where
partitions on the fixed disks from other osses being on the system
prevented some installers working  / detecting free space to install to
...

I have seen where usb writing software (on other operating systems) did not
write the installiimage properly to the usb stick,
clearing the partitions and writing zeros ahead of writing the image to the
usb did help me with installs before ...
but less so about panics and more to do with either booting the install os
,  or writing the sets to the fixed disks on the box..


On Wed, 7 Sept 2022 at 13:13, Jan Stary  wrote:

> > > > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > > > immediately panicked into ddb when I tried to pipe dmesg into a file
> on
> > > > the usb stick. I took out the NVMe-card, and whether or not that was
> the
> > > > problem the machine anyhow behaved better long enough for me to get
> > > > network and do a fw_update.
> > >
> > > sure sounds like it could be a bad USB stick.
> > > Very common.  For important things, I have learned to write zeros over
> > > the entire USB stick before expecting it to actually work.  Nothing to
> > > do with the T5500.
>
> I am puzzled: how exactly is a zero filled USB stick
> less panicky than another USB stick?
>
>

-- 
Kindest regards,
Tom Smyth.

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Tom Smyth]

Hi Erling,

it depends do you mean soft raid, that will be either  AHCI  using intel
driver or LSI  Raid emulation (where you can onfigure the raid in the
option rom (after POST  just before the OS Boots)  it depneds on the
chipset setup ...
Dell may put  the LIS as a PERC,  it also may be a separate card or i/o
module to the onboard sata ...
Hope this helps


On Wed, 7 Sept 2022 at 12:19, Erling Westenvik 
wrote:

> On Wed, Sep 07, 2022 at 11:41:49AM +0100, Tom Smyth wrote:
> > hi
> >
> > i would check bios / firmware settings
> >
> > try disabling memory mapped i/o in bios
> >
> > check processor settings enable vt-d disable hyper threading ensure
> execute
> > disable is enabled
> >
> > update the bios as it will update cpu microcode ...
>
> Great. Thanks, Tom.
>
> > dell alow you to select the emulation of sata
> > ahci vs raid vs sata vs legacy
>
> For 2 x 525GB SSD's in RAID (softraid) 1, that setting would be...?
>
> Erling
>
> >
> > On Wed 7 Sep 2022, 03:02 Erling Westenvik, 
> > wrote:
> >
> > > Hello,
> > >
> > > A friend donated an old Dell Precision T5500 workstation, a heavy
> > > bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> > > believe. At least it does for me. I would like it to replace my old i7
> > > 3770k. However, I'm starting to have doubts:
> > >
> > > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > > the usb stick. I took out the NVMe-card, and whether or not that was
> the
> > > problem the machine anyhow behaved better long enough for me to get
> > > network and do a fw_update.
> > >
> > > 2) After fw_update the radeondrm was detected and I got a nice
> 2560x1600
> > > console. However, before it would give me a login prompt the machine
> got
> > > stuck with repeating complaints about "ehci_device_clear_toggle: queue
> > > active". So – USB related, right?  Very well! Out with the usb stick,
> in
> > > with an old SSD with OpenBSD 6.7.
> > >
> > > 3) The machine behaves better, xenodm starts fine with cwm, but it
> won't
> > > resume after suspend (zzz).
> > >
> > > Some or all of the above problems may have solutions, trivial or not,
> > > but more problems may perhaps lurk under the surface..?
> > >
> > > So I guess my question is if someone knows whether these Dell machines
> > > are known to be error prone in general, or problematic with OpenBSD in
> > > particular, and if I should stop before wasting time!?
> > >
> > > Sincerely,
> > >
> > > Erling
> > >
> > > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> > > real mem = 77290508288 (73709MB)
> > > avail mem = 74930786304 (71459MB)
> > > random: good seed from bootblocks
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> > > bios0: vendor Dell Inc. version "A18" date 10/15/2018
> > > bios0: Dell Inc. Precision WorkStation T5500
> > > acpi0 at bios0: ACPI 3.0
> > > acpi0: sleep states S0 S3 S4 S5
> > > acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT
> SLIC
> > > SSDT
> > > acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5)
> > > PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
> > > PCI8(S5) PCIA(S5) PCIB(S5)
> > > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > cpu0 at mainbus0: apid 32 (boot processor)
> > > cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
> > > 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> > > cpu0: 256KB 64b/line 8-way L2 cache
> > > cpu0: smt 0, core 0, package 1
> > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > > cpu0: apic clock running at 132MHz
> > > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > > cpu1 at mainbus0: apid 34 

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Jan Stary]

> > > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > > the usb stick. I took out the NVMe-card, and whether or not that was the
> > > problem the machine anyhow behaved better long enough for me to get
> > > network and do a fw_update.
> > 
> > sure sounds like it could be a bad USB stick.
> > Very common.  For important things, I have learned to write zeros over
> > the entire USB stick before expecting it to actually work.  Nothing to
> > do with the T5500.

I am puzzled: how exactly is a zero filled USB stick
less panicky than another USB stick?

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Stuart Henderson]

On 2022-09-07, Erling Westenvik  wrote:
> On Wed, Sep 07, 2022 at 11:41:49AM +0100, Tom Smyth wrote:
>> hi
>> 
>> i would check bios / firmware settings
>> 
>> try disabling memory mapped i/o in bios
>> 
>> check processor settings enable vt-d disable hyper threading ensure execute
>> disable is enabled
>> 
>> update the bios as it will update cpu microcode ...
>
> Great. Thanks, Tom.

You're already on the newest bios (I checked that).
cpu microcode is handled in OpenBSD anyway.

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Erling Westenvik]

On Wed, Sep 07, 2022 at 11:41:49AM +0100, Tom Smyth wrote:
> hi
> 
> i would check bios / firmware settings
> 
> try disabling memory mapped i/o in bios
> 
> check processor settings enable vt-d disable hyper threading ensure execute
> disable is enabled
> 
> update the bios as it will update cpu microcode ...

Great. Thanks, Tom.

> dell alow you to select the emulation of sata
> ahci vs raid vs sata vs legacy

For 2 x 525GB SSD's in RAID (softraid) 1, that setting would be...?

Erling

> 
> On Wed 7 Sep 2022, 03:02 Erling Westenvik, 
> wrote:
> 
> > Hello,
> >
> > A friend donated an old Dell Precision T5500 workstation, a heavy
> > bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> > believe. At least it does for me. I would like it to replace my old i7
> > 3770k. However, I'm starting to have doubts:
> >
> > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > the usb stick. I took out the NVMe-card, and whether or not that was the
> > problem the machine anyhow behaved better long enough for me to get
> > network and do a fw_update.
> >
> > 2) After fw_update the radeondrm was detected and I got a nice 2560x1600
> > console. However, before it would give me a login prompt the machine got
> > stuck with repeating complaints about "ehci_device_clear_toggle: queue
> > active". So – USB related, right?  Very well! Out with the usb stick, in
> > with an old SSD with OpenBSD 6.7.
> >
> > 3) The machine behaves better, xenodm starts fine with cwm, but it won't
> > resume after suspend (zzz).
> >
> > Some or all of the above problems may have solutions, trivial or not,
> > but more problems may perhaps lurk under the surface..?
> >
> > So I guess my question is if someone knows whether these Dell machines
> > are known to be error prone in general, or problematic with OpenBSD in
> > particular, and if I should stop before wasting time!?
> >
> > Sincerely,
> >
> > Erling
> >
> > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 77290508288 (73709MB)
> > avail mem = 74930786304 (71459MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> > bios0: vendor Dell Inc. version "A18" date 10/15/2018
> > bios0: Dell Inc. Precision WorkStation T5500
> > acpi0 at bios0: ACPI 3.0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT SLIC
> > SSDT
> > acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5)
> > PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
> > PCI8(S5) PCIA(S5) PCIB(S5)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 32 (boot processor)
> > cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
> > 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: smt 0, core 0, package 1
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 132MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > cpu1 at mainbus0: apid 34 (application processor)
> > cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> > 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> > cpu1: 256KB 64b/line 8-way L2 cache
> > cpu1: smt 0, core 1, package 1
> > cpu2 at mainbus0: apid 36 (application processor)
> > cpu2: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> > 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,DCA,SSE4.1,SSE4

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Erling Westenvik]

On Wed, Sep 07, 2022 at 09:08:32AM -, Stuart Henderson wrote:
> On 2022-09-07, Erling Westenvik  wrote:
> > Hello,
> >
> > A friend donated an old Dell Precision T5500 workstation, a heavy
> > bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> > believe. At least it does for me. I would like it to replace my old i7
> > 3770k. However, I'm starting to have doubts:
> 
> Looks like rather an expensive machine to run, power-wise. Got to be
> in the 200W region with dual xeon X series and fully loaded on RAM
> (and presumably not low-voltage RAM given the choice of cpu). 

Good point.

> 
> > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > the usb stick. I took out the NVMe-card, and whether or not that was the
> > problem the machine anyhow behaved better long enough for me to get
> > network and do a fw_update.
> 
> https://www.openbsd.org/report.html "If OpenBSD panics with a particular
> error, say which"...

Duly noted.

> 
> > 2) After fw_update the radeondrm was detected and I got a nice 2560x1600
> > console. However, before it would give me a login prompt the machine got
> > stuck with repeating complaints about "ehci_device_clear_toggle: queue
> > active". So – USB related, right?  Very well! Out with the usb stick, in
> > with an old SSD with OpenBSD 6.7.
> >
> > 3) The machine behaves better, xenodm starts fine with cwm, but it won't
> > resume after suspend (zzz). 
> >
> > Some or all of the above problems may have solutions, trivial or not,
> > but more problems may perhaps lurk under the surface..?
> >
> > So I guess my question is if someone knows whether these Dell machines
> > are known to be error prone in general, or problematic with OpenBSD in
> > particular, and if I should stop before wasting time!?
> 
> I don't know specifically about workstations, but I'd expect them to be
> fairly similar to PowerEdge servers which are generally known to work
> well. However they are rarely suspended so there's probably not much
> knowledge of how well that works.
> 

Thanks. Sorry for being vague or not having done my research. Every now
and then a particular machine/model "just won't work" and I just wanted
to see if anyone knew some damning details that would save me wasting
hours. I recently lost several disks and is still in the process of
rebuilding a couple of machines, so I'm simply a bit stressed.

Since Nick Holland says he's using a similar T5500 I've decided to give
it a serious try. At least it supports SpeedStep, and I could always be
better at shutting down workstations (and laptops) when they're not in
use.

Erling

> 
> 
> >
> > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 77290508288 (73709MB)
> > avail mem = 74930786304 (71459MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> > bios0: vendor Dell Inc. version "A18" date 10/15/2018
> > bios0: Dell Inc. Precision WorkStation T5500
> > acpi0 at bios0: ACPI 3.0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT SLIC 
> > SSDT
> > acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) 
> > PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) PCI8(S5) 
> > PCIA(S5) PCIB(S5)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 32 (boot processor)
> > cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
> > 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: smt 0, core 0, package 1
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 132MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > cpu1 at mainbus0: apid 34 (application processor)
> > cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> > cpu1: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFL

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Tom Smyth]

hi

i would check bios / firmware settings

try disabling memory mapped i/o in bios




check processor settings enable vt-d disable hyper threading ensure execute
disable is enabled

update the bios as it will update cpu microcode ...

dell alow you to select the emulation of sata

ahci vs raid vs sata vs legacy





On Wed 7 Sep 2022, 03:02 Erling Westenvik, 
wrote:

> Hello,
>
> A friend donated an old Dell Precision T5500 workstation, a heavy
> bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> believe. At least it does for me. I would like it to replace my old i7
> 3770k. However, I'm starting to have doubts:
>
> 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> immediately panicked into ddb when I tried to pipe dmesg into a file on
> the usb stick. I took out the NVMe-card, and whether or not that was the
> problem the machine anyhow behaved better long enough for me to get
> network and do a fw_update.
>
> 2) After fw_update the radeondrm was detected and I got a nice 2560x1600
> console. However, before it would give me a login prompt the machine got
> stuck with repeating complaints about "ehci_device_clear_toggle: queue
> active". So – USB related, right?  Very well! Out with the usb stick, in
> with an old SSD with OpenBSD 6.7.
>
> 3) The machine behaves better, xenodm starts fine with cwm, but it won't
> resume after suspend (zzz).
>
> Some or all of the above problems may have solutions, trivial or not,
> but more problems may perhaps lurk under the surface..?
>
> So I guess my question is if someone knows whether these Dell machines
> are known to be error prone in general, or problematic with OpenBSD in
> particular, and if I should stop before wasting time!?
>
> Sincerely,
>
> Erling
>
> OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 77290508288 (73709MB)
> avail mem = 74930786304 (71459MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> bios0: vendor Dell Inc. version "A18" date 10/15/2018
> bios0: Dell Inc. Precision WorkStation T5500
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT SLIC
> SSDT
> acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5)
> PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
> PCI8(S5) PCIA(S5) PCIB(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 32 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 1
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 132MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 34 (application processor)
> cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 1
> cpu2 at mainbus0: apid 36 (application processor)
> cpu2: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 1
> cpu3 at mainbus0: apid 48 (application processor)
> cpu3: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,ST

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Erling Westenvik]

On Tue, Sep 06, 2022 at 11:19:12PM -0400, Nick Holland wrote:
> On 9/6/22 21:52, Erling Westenvik wrote:
> > Hello,
> > 
> > A friend donated an old Dell Precision T5500 workstation, a heavy
> > bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> > believe. At least it does for me. I would like it to replace my old i7
> > 3770k. However, I'm starting to have doubts:
> > 
> > 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> > immediately panicked into ddb when I tried to pipe dmesg into a file on
> > the usb stick. I took out the NVMe-card, and whether or not that was the
> > problem the machine anyhow behaved better long enough for me to get
> > network and do a fw_update.
> 
> sure sounds like it could be a bad USB stick.
> Very common.  For important things, I have learned to write zeros over
> the entire USB stick before expecting it to actually work.  Nothing to
> do with the T5500.

Right. It's a general purpuse stick I use to boot up different machines
for diagnostics etc. No problems on other machines but I'll keep your
advice in mind.

> 
> NVMe??  don't think I have that in mine...But then, I probably wasn't
> looking.
> 
> This an add-on board?  I'd certainly strip it down as much as possible.

Yes. Add-on card. Poor grammar on my part. Should've read "a NVMe-card" and
not "the" I guess. Probably not the culprit anyway but I'll follow your
advice and strip it down.

> 
> > 2) After fw_update the radeondrm was detected and I got a nice 2560x1600
> > console. However, before it would give me a login prompt the machine got
> > stuck with repeating complaints about "ehci_device_clear_toggle: queue
> > active". So – USB related, right?  Very well! Out with the usb stick, in
> > with an old SSD with OpenBSD 6.7.
> > 
> > 3) The machine behaves better, xenodm starts fine with cwm, but it won't
> > resume after suspend (zzz).
> 
> haven't tried suspending.  Thing has been on pretty much 24x7 for five+
> years.

I see. As Stuart mentions, the machine is a potential resource hog.
(Electricity has always been very cheap here in Norway. That is, until
last autumn when the grid became part of the EU/ACER trading pool and
the energy bills skyrocketed to 20 times what they used to be. It has
caused quite a political scandal. Ongoing as we speak..)

> > Some or all of the above problems may have solutions, trivial or not,
> > but more problems may perhaps lurk under the surface..?
> > 
> > So I guess my question is if someone knows whether these Dell machines
> > are known to be error prone in general, or problematic with OpenBSD in
> > particular, and if I should stop before wasting time!?
> 
> well, I have one, looks very similar to yours.  I've been using it for
> quite a few years, this message is being composed on it, in fact.  Like
> it enough that when a friend of mine told me he had another one, I got
> it as a spare.
> 
> In short: you have a potentially good machine.  I have no idea of the
> condition that yours is actually in, but "Run OpenBSD on a T5500? Yes".

Thanks. That answers my question and I'll give it a chance and put some
effort into it.

(I guess subject should've been the other way around: "Is an old Dell
Precision T5500 suited for OpenBSD". Insult not intended! : )

Erling

> 
> Nick.
> 
> OpenBSD 7.2-beta (GENERIC.MP) #702: Sun Aug 21 00:29:07 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34340835328 (32749MB)
> avail mem = 33282695168 (31740MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> bios0: vendor Dell Inc. version "A16" date 05/28/2013
> bios0: Dell Inc. Precision WorkStation T5500
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR _RAT SLIC SSDT
> acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) 
> PCI6(S5) KBD_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
> PCI8(S5) PCIA(S5) [...]
> 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) Xeon(R) CPU X5670 @ 2.93GHz, 3192.40 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTD

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Stuart Henderson]

On 2022-09-07, Erling Westenvik  wrote:
> Hello,
>
> A friend donated an old Dell Precision T5500 workstation, a heavy
> bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
> believe. At least it does for me. I would like it to replace my old i7
> 3770k. However, I'm starting to have doubts:

Looks like rather an expensive machine to run, power-wise. Got to be
in the 200W region with dual xeon X series and fully loaded on RAM
(and presumably not low-voltage RAM given the choice of cpu). 

> 1) On initial boot (with 7.1 release, on a usb stick) it more or less
> immediately panicked into ddb when I tried to pipe dmesg into a file on
> the usb stick. I took out the NVMe-card, and whether or not that was the
> problem the machine anyhow behaved better long enough for me to get
> network and do a fw_update.

https://www.openbsd.org/report.html "If OpenBSD panics with a particular
error, say which"...

> 2) After fw_update the radeondrm was detected and I got a nice 2560x1600
> console. However, before it would give me a login prompt the machine got
> stuck with repeating complaints about "ehci_device_clear_toggle: queue
> active". So – USB related, right?  Very well! Out with the usb stick, in
> with an old SSD with OpenBSD 6.7.
>
> 3) The machine behaves better, xenodm starts fine with cwm, but it won't
> resume after suspend (zzz). 
>
> Some or all of the above problems may have solutions, trivial or not,
> but more problems may perhaps lurk under the surface..?
>
> So I guess my question is if someone knows whether these Dell machines
> are known to be error prone in general, or problematic with OpenBSD in
> particular, and if I should stop before wasting time!?

I don't know specifically about workstations, but I'd expect them to be
fairly similar to PowerEdge servers which are generally known to work
well. However they are rarely suspended so there's probably not much
knowledge of how well that works.



>
> OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 77290508288 (73709MB)
> avail mem = 74930786304 (71459MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
> bios0: vendor Dell Inc. version "A18" date 10/15/2018
> bios0: Dell Inc. Precision WorkStation T5500
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT SLIC SSDT
> acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) 
> PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) PCI8(S5) 
> PCIA(S5) PCIB(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 32 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 1
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 132MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 34 (application processor)
> cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 1
> cpu2 at mainbus0: apid 36 (application processor)
> cpu2: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 1
> cpu3 at mainbus0: apid 48 (application processor)
> cpu3: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,

Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Nick Holland]

On 9/6/22 21:52, Erling Westenvik wrote:

Hello,

A friend donated an old Dell Precision T5500 workstation, a heavy
bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
believe. At least it does for me. I would like it to replace my old i7
3770k. However, I'm starting to have doubts:

1) On initial boot (with 7.1 release, on a usb stick) it more or less
immediately panicked into ddb when I tried to pipe dmesg into a file on
the usb stick. I took out the NVMe-card, and whether or not that was the
problem the machine anyhow behaved better long enough for me to get
network and do a fw_update.


sure sounds like it could be a bad USB stick.
Very common.  For important things, I have learned to write zeros over
the entire USB stick before expecting it to actually work.  Nothing to
do with the T5500.

NVMe??  don't think I have that in mine...But then, I probably wasn't
looking.

This an add-on board?  I'd certainly strip it down as much as possible.


2) After fw_update the radeondrm was detected and I got a nice 2560x1600
console. However, before it would give me a login prompt the machine got
stuck with repeating complaints about "ehci_device_clear_toggle: queue
active". So – USB related, right?  Very well! Out with the usb stick, in
with an old SSD with OpenBSD 6.7.

3) The machine behaves better, xenodm starts fine with cwm, but it won't
resume after suspend (zzz).


haven't tried suspending.  Thing has been on pretty much 24x7 for five+
years.
 

Some or all of the above problems may have solutions, trivial or not,
but more problems may perhaps lurk under the surface..?

So I guess my question is if someone knows whether these Dell machines
are known to be error prone in general, or problematic with OpenBSD in
particular, and if I should stop before wasting time!?


well, I have one, looks very similar to yours.  I've been using it for
quite a few years, this message is being composed on it, in fact.  Like
it enough that when a friend of mine told me he had another one, I got
it as a spare.

In short: you have a potentially good machine.  I have no idea of the
condition that yours is actually in, but "Run OpenBSD on a T5500? Yes".

Nick.

OpenBSD 7.2-beta (GENERIC.MP) #702: Sun Aug 21 00:29:07 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34340835328 (32749MB)
avail mem = 33282695168 (31740MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
bios0: vendor Dell Inc. version "A16" date 05/28/2013
bios0: Dell Inc. Precision WorkStation T5500
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR _RAT SLIC SSDT
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) 
PCI6(S5) KBD_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
PCI8(S5) PCIA(S5) [...]
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) Xeon(R) CPU X5670 @ 2.93GHz, 3192.40 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.02 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.02 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, packa

Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)

[Erling Westenvik]

Hello,

A friend donated an old Dell Precision T5500 workstation, a heavy
bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I
believe. At least it does for me. I would like it to replace my old i7
3770k. However, I'm starting to have doubts:

1) On initial boot (with 7.1 release, on a usb stick) it more or less
immediately panicked into ddb when I tried to pipe dmesg into a file on
the usb stick. I took out the NVMe-card, and whether or not that was the
problem the machine anyhow behaved better long enough for me to get
network and do a fw_update.

2) After fw_update the radeondrm was detected and I got a nice 2560x1600
console. However, before it would give me a login prompt the machine got
stuck with repeating complaints about "ehci_device_clear_toggle: queue
active". So – USB related, right?  Very well! Out with the usb stick, in
with an old SSD with OpenBSD 6.7.

3) The machine behaves better, xenodm starts fine with cwm, but it won't
resume after suspend (zzz). 

Some or all of the above problems may have solutions, trivial or not,
but more problems may perhaps lurk under the surface..?

So I guess my question is if someone knows whether these Dell machines
are known to be error prone in general, or problematic with OpenBSD in
particular, and if I should stop before wasting time!?

Sincerely,

Erling

OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 77290508288 (73709MB)
avail mem = 74930786304 (71459MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries)
bios0: vendor Dell Inc. version "A18" date 10/15/2018
bios0: Dell Inc. Precision WorkStation T5500
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA  _RAT SLIC SSDT
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) 
PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) PCI8(S5) 
PCIA(S5) PCIB(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 32 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 1
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 34 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 1
cpu2 at mainbus0: apid 36 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 1
cpu3 at mainbus0: apid 48 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 8, package 1
cpu4 at mainbus0: apid 50 (application processor)
cpu4: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
cpu4: 
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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 9, package 1
cpu5 at mainbus0: apid 52 (application processor)
cpu5: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Dave Voutila]

"Ted Unangst"  writes:

> On 2022-02-25, Robert Nagy wrote:
>> Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>

The reminder is good, but we still need to fix the problem that the vmm
process can abort given the child dies so quickly. On my machine, the
call to read(2) results in a zero byte read, tripping the existing fatal
path.


diff ff838b72f50de699ee43d3dac58ff7e8435669ee /usr/src
blob - 4c6c99f1133cec7cb1e38dfd22e595e4d2023842
file + usr.sbin/vmd/vm.c
--- usr.sbin/vmd/vm.c
+++ usr.sbin/vmd/vm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);

if (ret) {
+   struct rlimit lim;
+   const char *msg = "could not allocate guest memory - exiting";
+   if (getrlimit(RLIMIT_DATA, ) == 0)
+   msg = "could not allocate guest memory (data limit is 
%llu) - exiting";
errno = ret;
-   fatal("could not allocate guest memory - exiting");
+   fatal(msg, lim.rlim_cur);
}

ret = vmm_create_vm(vcp);
blob - eb75b4c587884ec43704420ef4172386a5b39bd9
file + usr.sbin/vmd/vmm.c
--- usr.sbin/vmd/vmm.c
+++ usr.sbin/vmd/vmm.c
@@ -616,6 +616,7 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
int  ret = EINVAL;
int  fds[2];
size_t   i, j;
+   ssize_t  sz;

if ((vm = vm_getbyvmid(imsg->hdr.peerid)) == NULL) {
log_warnx("%s: can't find vm", __func__);
@@ -674,9 +675,13 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
}

/* Read back the kernel-generated vm id from the child */
-   if (read(fds[0], >vcp_id, sizeof(vcp->vcp_id)) !=
-   sizeof(vcp->vcp_id))
+   sz = read(fds[0], >vcp_id, sizeof(vcp->vcp_id));
+   if (sz < 0)
fatal("read vcp id");
+   else if (sz != sizeof(vcp->vcp_id)) {
+   log_warn("failed to read vcp id");
+   goto err;
+   }

if (vcp->vcp_id == 0)
goto err;

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Mike Larkin]

On Fri, Feb 25, 2022 at 06:36:35PM -, Stuart Henderson wrote:
> On 2022-02-25, Robert Nagy  wrote:
> > Maybe we need a default vmd class? What do you guys think?
>
> I definitely think it makes sense. Not sure whether it should just go in
> etc.amd64 or the others too (vmd only exists on amd64 so far, but if it's
> ever added e.g. to arm64 then adding it in the other files would avoid
> having to remember to add it later..)
>
> Maybe the same 16G limit as bgpd by default..
>
>

I am in support of this change as well. Thanks everyone.

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Mike Larkin]

On Fri, Feb 25, 2022 at 01:46:00PM -0500, Ted Unangst wrote:
> On 2022-02-25, Robert Nagy wrote:
> > Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>

ok mlarkin on this one. thanks

>
> Index: vm.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 vm.c
> --- vm.c  30 Dec 2021 08:12:23 -  1.67
> +++ vm.c  25 Feb 2022 18:42:39 -
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
>   ret = alloc_guest_mem(vcp);
>
>   if (ret) {
> + struct rlimit lim;
> + const char *msg = "could not allocate guest memory - exiting";
> + if (getrlimit(RLIMIT_DATA, ) == 0)
> + msg = "could not allocate guest memory (data limit is 
> %llu) - exiting";
>   errno = ret;
> - fatal("could not allocate guest memory - exiting");
> + fatal(msg, lim.rlim_cur);
>   }
>
>   ret = vmm_create_vm(vcp);
>

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Ted Unangst]

On 2022-02-25, Robert Nagy wrote:
> Maybe we need a default vmd class? What do you guys think?

Regardless of what the limit is, this seems like a daemon where people
will bump into the limit. Perhaps a reminder is in order too?


Index: vm.c
===
RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
retrieving revision 1.67
diff -u -p -r1.67 vm.c
--- vm.c30 Dec 2021 08:12:23 -  1.67
+++ vm.c25 Feb 2022 18:42:39 -
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);
 
if (ret) {
+   struct rlimit lim;
+   const char *msg = "could not allocate guest memory - exiting";
+   if (getrlimit(RLIMIT_DATA, ) == 0)
+   msg = "could not allocate guest memory (data limit is 
%llu) - exiting";
errno = ret;
-   fatal("could not allocate guest memory - exiting");
+   fatal(msg, lim.rlim_cur);
}
 
ret = vmm_create_vm(vcp);

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Stuart Henderson]

On 2022-02-25, Robert Nagy  wrote:
> Maybe we need a default vmd class? What do you guys think?

I definitely think it makes sense. Not sure whether it should just go in
etc.amd64 or the others too (vmd only exists on amd64 so far, but if it's
ever added e.g. to arm64 then adding it in the other files would avoid
having to remember to add it later..)

Maybe the same 16G limit as bgpd by default..

Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Robert Nagy]

Maybe we need a default vmd class? What do you guys think?

On 25/02/22 15:34 +0100, Paul de Weerd wrote:
> Hi all,
> 
> In commit Eg1WuG7hzCoCPdcz, robert@ changed the ulimit for the daemon
> class in /etc/login.conf for amd64 from 'infinity' to 4096M (see [0]
> and [1]).
> 
> This change broke my vmd setup, and I had to dig around to understand
> what happened.  Sharing here in hopes of preventing others from
> wasting their time like I did.
> 
> 
> I have a VM that is configured with 4GB of RAM:
> 
> [weerd@pom] $ grep -B2 4G /etc/vm.conf
> vm "builder" {
>   owner weerd
>   memory 4G
> 
> After upgrading to a newer snapshot (and sysmerge'ing login.conf), vmd
> crashes when this VM gets started:
> 
> pom vmd[98555]: builder: could not allocate guest memory - exiting: Cannot 
> allocate memory
> pom vmd[71874]: vmm: read vcp id
> pom vmd[10670]: priv exiting, pid 10670
> pom vmd[73889]: control exiting, pid 73889
> 
> (resource limits doing exactly what they're supposed to do here!)
> 
> It took me longer than I care to admit to realize that this would be
> caused by the newly reduced datasize limit imposed by Robert's change.
> I fixed this by adding a dedicated login.conf stanza for vmd:
> 
> [weerd@pom] $ tail -n7 /etc/login.conf
> ##
> # Local changes
> #
> # vmd runs VMs with 4GB, so it needs an increased datasize limit:
> vmd:\
>   :datasize=5120M:\
>   :tc=daemon:
> 
> Alternatively, I could've stuck that bit in /etc/login.conf.d/vmd
> which would've had the same effect.  But with that change everything
> is working just fine again.  When you run into a similar issue, make
> sure not to just revert back to "infinite" - find a suitable limit for
> whatever piece of software you have and adjust accordingly.
> 
> Cheers,
> 
> Paul
> 
> [0]: https://marc.info/?l=openbsd-cvs=164542553811748=2
> [1]: 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/login.conf.diff?r1=1.21=1.22
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

-- 
Regards,
Robert Nagy

login.conf daemon datasize limit effects on VMs with 4GB+ RAM

[Paul de Weerd]

Hi all,

In commit Eg1WuG7hzCoCPdcz, robert@ changed the ulimit for the daemon
class in /etc/login.conf for amd64 from 'infinity' to 4096M (see [0]
and [1]).

This change broke my vmd setup, and I had to dig around to understand
what happened.  Sharing here in hopes of preventing others from
wasting their time like I did.


I have a VM that is configured with 4GB of RAM:

[weerd@pom] $ grep -B2 4G /etc/vm.conf
vm "builder" {
owner weerd
memory 4G

After upgrading to a newer snapshot (and sysmerge'ing login.conf), vmd
crashes when this VM gets started:

pom vmd[98555]: builder: could not allocate guest memory - exiting: Cannot 
allocate memory
pom vmd[71874]: vmm: read vcp id
pom vmd[10670]: priv exiting, pid 10670
pom vmd[73889]: control exiting, pid 73889

(resource limits doing exactly what they're supposed to do here!)

It took me longer than I care to admit to realize that this would be
caused by the newly reduced datasize limit imposed by Robert's change.
I fixed this by adding a dedicated login.conf stanza for vmd:

[weerd@pom] $ tail -n7 /etc/login.conf
##
# Local changes
#
# vmd runs VMs with 4GB, so it needs an increased datasize limit:
vmd:\
:datasize=5120M:\
:tc=daemon:

Alternatively, I could've stuck that bit in /etc/login.conf.d/vmd
which would've had the same effect.  But with that change everything
is working just fine again.  When you run into a similar issue, make
sure not to just revert back to "infinite" - find a suitable limit for
whatever piece of software you have and adjust accordingly.

Cheers,

Paul

[0]: https://marc.info/?l=openbsd-cvs=164542553811748=2
[1]: 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/login.conf.diff?r1=1.21=1.22

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Andre Smagin]

On Wed, 22 Sep 2021 17:27:30 +0100
"Patrick Harper"  wrote:

> If the situation isn't going to change anytime soon then I have some 
> diffs for INSTALL.i386 and INSTALL.amd64. The latter has not specified 
> disk requirements, I guess since anyone who owns an amd64 system will 
> very likely be using a disk big enough for X, so I figured that the 
> same would apply to any user of an i386 system that meets the proposed 
> minimum RAM. These are based on the 2021-09-21 snapshot versions.
> 
> --- INSTALL.i386.txtWed Sep 22 16:52:38 2021
> +++ INSTALL.i386_newWed Sep 22 16:51:17 2021
> @@ -201,10 +201,7 @@ OpenBSD/i386 7.0 supports most SMP (Symmetrical 
> MultiP
>  systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
>  is included with the installation file sets.
>  
> -The minimal configuration to install the system is 32MB of RAM and
> -at least 250MB of disk space to accommodate the `base' set.
> -To install the entire system, at least 600MB of disk are required,
> -and to run X or compile the system, more RAM is recommended.
> +The minimal configuration to install the system is 512MB of RAM.
>  
>  Please refer to the website for a full list of supported hardware:
>  https://www.openbsd.org/i386.html

Hello.

I have Soekris net4801 gateway/firewall and it only has 128Mb of RAM.
I usually upgrade to -current by putting the CF card into a different
machine, since writing to CF card is slow on Soekris, but tonight I
upgraded to -current using the box itself and timed how long it took to
relink the kernel - 25 minutes.
It has 256Mb of swap. Eh, 259.9M apparently.

After-reboot relinking is currently disabled until I figure out
what to put in the new bsd.re-config to change flags for
wd to 0x0ff0 automatically, no luck yet.


Soekris dmesg:

OpenBSD 7.0 (GENERIC) #203: Wed Sep 22 19:24:38 MDT 2021
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 133709824 (127MB)
avail mem = 114921472 (109MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/80/03, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
586-class) 267 MHz, 05-04-00
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815" rev 0x00, DP83816A: irq 10, address 
00:00:24:c3:54:68
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815" rev 0x00, DP83816A: irq 10, address 
00:00:24:c3:54:69
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815" rev 0x00, DP83816A: irq 10, address 
00:00:24:c3:54:6a
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
ral0 at pci0 dev 10 function 0 "Ralink RT2860" rev 0x00: irq 11, address 
00:1d:6a:0e:80:cd
ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (MIMO 2T3R)
ral1 at pci0 dev 14 function 0 "Ralink RT2560" rev 0x01: irq 5, address 
00:13:d3:00:9f:7a
ral1: MAC/BBP RT2560 (rev 0x04), RF RT2525
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA48, 3811MB, 7806960 sectors
wd0(pciide0:0:0): using PIO mode 4
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 
wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 9, version 
1.0, legacy support
isa0 at gscpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Compaq OHCI root hub" rev 1.00/1.00 
addr 1
dt: 445 probes
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (1f081011692bae0c.a) swap on wd0b dump on wd0b

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

If the situation isn't going to change anytime soon then I have some 
diffs for INSTALL.i386 and INSTALL.amd64. The latter has not specified 
disk requirements, I guess since anyone who owns an amd64 system will 
very likely be using a disk big enough for X, so I figured that the 
same would apply to any user of an i386 system that meets the proposed 
minimum RAM. These are based on the 2021-09-21 snapshot versions.

--- INSTALL.i386.txtWed Sep 22 16:52:38 2021
+++ INSTALL.i386_newWed Sep 22 16:51:17 2021
@@ -201,10 +201,7 @@ OpenBSD/i386 7.0 supports most SMP (Symmetrical 
MultiP
 systems.  To support SMP operation, a separate SMP kernel (bsd.mp)
 is included with the installation file sets.
 
-The minimal configuration to install the system is 32MB of RAM and
-at least 250MB of disk space to accommodate the `base' set.
-To install the entire system, at least 600MB of disk are required,
-and to run X or compile the system, more RAM is recommended.
+The minimal configuration to install the system is 512MB of RAM.
 
 Please refer to the website for a full list of supported hardware:
 https://www.openbsd.org/i386.html


--- INSTALL.amd64.txt   Wed Sep 22 16:52:48 2021
+++ INSTALL.amd64_new   Wed Sep 22 16:51:12 2021
@@ -202,6 +202,8 @@ is included with the installation file sets.
 OpenBSD/amd64 7.0 supports both UEFI/GPT booting and BIOS/MBR
 booting.
 
+The minimal configuration to install the system is 512MB of RAM.
+
 Please refer to the website for a full list of supported hardware.
 
 https://www.openbsd.org/amd64.html


Patrick Harper

Re: Minimum RAM for Chrome

[tetrahedra]

On Sat, Aug 07, 2021 at 01:15:52PM -, Stuart Henderson wrote:

Am I running into system memory limits ("minimum 8GB RAM to surf the
web"? what is the world coming to?) or is another issue likely the
cause?


I wouldn't rule that possibility out… I manage with Firefox on Linux
with a 2GB netbook, but only just: some websites just eat RAM like it's
going out of fashion.  Playing videos definitely makes the problem
worse.  Comparatively "simple" websites work okay but anything that's
real-time: all bets are off!

I haven't tried OpenBSD on the same machine, but I suspect the problem
isn't limited to browser or OS.  Your mileage will definitely depend on
the sort of website you frequently like to visit.


OpenBSD doesn't do brilliantly with swapping.


Thanks. That's all rather depressing...

Re: Minimum RAM for Chrome

[Stuart Henderson]

On 2021-08-07, Stuart Longland  wrote:
> On Fri, 6 Aug 2021 14:19:04 +
> tetrahe...@danwin1210.me wrote:
>
>> Am I running into system memory limits ("minimum 8GB RAM to surf the
>> web"? what is the world coming to?) or is another issue likely the
>> cause?
>
> I wouldn't rule that possibility out… I manage with Firefox on Linux
> with a 2GB netbook, but only just: some websites just eat RAM like it's
> going out of fashion.  Playing videos definitely makes the problem
> worse.  Comparatively "simple" websites work okay but anything that's
> real-time: all bets are off!
>
> I haven't tried OpenBSD on the same machine, but I suspect the problem
> isn't limited to browser or OS.  Your mileage will definitely depend on
> the sort of website you frequently like to visit.

OpenBSD doesn't do brilliantly with swapping.

Re: Minimum RAM for Chrome

[Stuart Longland]

On Fri, 6 Aug 2021 14:19:04 +
tetrahe...@danwin1210.me wrote:

> Am I running into system memory limits ("minimum 8GB RAM to surf the
> web"? what is the world coming to?) or is another issue likely the
> cause?

I wouldn't rule that possibility out… I manage with Firefox on Linux
with a 2GB netbook, but only just: some websites just eat RAM like it's
going out of fashion.  Playing videos definitely makes the problem
worse.  Comparatively "simple" websites work okay but anything that's
real-time: all bets are off!

I haven't tried OpenBSD on the same machine, but I suspect the problem
isn't limited to browser or OS.  Your mileage will definitely depend on
the sort of website you frequently like to visit.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Minimum RAM for Chrome

[tetrahedra]

I've got a spare laptop that I use for web browsing. Since it only has
4GB RAM, OpenBSD seemed a good fit for it.

However Chrome is extremely slow. I've increased system resource limits
as mentioned in the email list archives, but that didn't resolve the
issue.

If I turn off video acceleration blacklisting in Chrome, videos play
faster but starting the browser takes ages and sometimes fails entirely.
Regardless, there is still lots of lag when loading pages.

Am I running into system memory limits ("minimum 8GB RAM to surf the
web"? what is the world coming to?) or is another issue likely the
cause?

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

> Your swap is only 256MB.  That seem too low.  (We have walked away 
> from making it correspond to physical memory, but still, it seems 
> uncomfortably low).
>
> As well, /usr seems a bit large, leaving not much for /home.
>
> The autoallocation scheme might have made a less than perfect 
> decision here.

I tried the same thing except for editing the partition layout to allow 
for 512M of swap:

wd1*> p m
OpenBSD area: 64-15662304; size: 7647.6M; free: 955.0M
#size   offset  fstype [fsize bsize   cpg]
  a:  1060.6M   64  4.2BSD   2048 16384 1 # /
  b:   512.0M  2172128swap
  c:  7647.6M0  unused
  d:  3072.0M  3220704  4.2BSD   2048 16384 1 # /usr
  e:  2048.0M  9512128  4.2BSD   2048 16384 1 # 
/home

and 768M:

wd1*> p m
OpenBSD area: 64-15662304; size: 7647.6M; free: 699.0M
#size   offset  fstype [fsize bsize   cpg]
  a:  1060.6M   64  4.2BSD   2048 16384 1 # /
  b:   768.0M  2172128swap
  c:  7647.6M0  unused
  d:  3072.0M  3744992  4.2BSD   2048 16384 1 # /usr
  e:  2048.0M 10036416  4.2BSD   2048 16384 1 # 
/home

...and there's no practical difference, the system will just sit for 
half an hour, print one or two seg faults in that time and then reboot. 
memtest86 didn't print any errors so I'm assuming my memory is fine. 
I'd say x86 computers without INT 13h Extensions support in the BIOS 
are pretty much obsolete at this point given that nearly all of them 
are going to be a combo of very small memory (>128MB was very rare 
before 1998) and small disk (8.4GB limit).

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Otto Moerbeek]

On Thu, Jul 15, 2021 at 08:48:54AM -0600, Theo de Raadt wrote:

> Otto Moerbeek  wrote:
> 
> > On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:
> > 
> > > The problem appears to be here:
> > > 
> > > > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> > > > wd1 at wdc2 channel 0 drive 0: 
> > > > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> > > > wd1(wdc2:0:0): using BIOS timings
> > > 
> > > >   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
> > > >   b:   256.0M  2172128swap
> > > >   c:  7647.6M0  unused
> > > >   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
> > > >   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # 
> > > > /home
> > > 
> > > Your swap is only 256MB.  That seem too low.  (We have walked away from
> > > making it correspond to physical memory, but still, it seems 
> > > uncomfortably low).
> > > 
> > > As well, /usr seems a bit large, leaving not much for /home.
> > > 
> > > The autoallocation scheme might have made a less than perfect decision 
> > > here.
> > > 
> > 
> > Thhis is bassed on the "medium" allocation, swap, /usr and /home have
> > reached there max according to the table. We can make swap have a
> > alrager max and take more of the pie. What would be a good max size
> > for swap these days omn such a small disk?
> 
> I suspect, but don't know, that 400MB would be enough for the link.

So how aboht this? allocate a bit more to swap and increase the max,
plus increase the max for /home.

Index: editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.368
diff -u -p -r1.368 editor.c
--- editor.c30 May 2021 19:02:30 -  1.368
+++ editor.c16 Jul 2021 12:14:27 -
@@ -103,9 +103,9 @@ struct space_allocation alloc_big[] = {
 
 struct space_allocation alloc_medium[] = {
{  MEG(800), GIG(2),   5, "/"   },
-   {   MEG(80),   MEG(256),  10, "swap"},
-   { MEG(1300), GIG(3),  78, "/usr"},
-   {  MEG(256), GIG(2),   7, "/home"   }
+   {   MEG(80),   MEG(512),  20, "swap"},
+   { MEG(1300), GIG(3),  68, "/usr"},
+   {  MEG(256), GIG(3),   7, "/home"   }
 };
 
 struct space_allocation alloc_small[] = {


This produces:

vnd0*> p g
OpenBSD area: 0-15662305; size: 7.5G; free: 0.0G
#size   offset  fstype [fsize bsize   cpg]
  a: 1.0G0  4.2BSD   2048 16384 1 # /
  b: 0.5G  2172064swap
  c: 7.5G0  unused
  d: 3.0G  3220640  4.2BSD   2048 16384 1 # /usr
  e: 2.9G  9512096  4.2BSD   2048 16384 1 # /home


-Otto

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Theo de Raadt]

Otto Moerbeek  wrote:

> On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:
> 
> > The problem appears to be here:
> > 
> > > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> > > wd1 at wdc2 channel 0 drive 0: 
> > > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> > > wd1(wdc2:0:0): using BIOS timings
> > 
> > >   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
> > >   b:   256.0M  2172128swap
> > >   c:  7647.6M0  unused
> > >   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
> > >   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # /home
> > 
> > Your swap is only 256MB.  That seem too low.  (We have walked away from
> > making it correspond to physical memory, but still, it seems uncomfortably 
> > low).
> > 
> > As well, /usr seems a bit large, leaving not much for /home.
> > 
> > The autoallocation scheme might have made a less than perfect decision here.
> > 
> 
> Thhis is bassed on the "medium" allocation, swap, /usr and /home have
> reached there max according to the table. We can make swap have a
> alrager max and take more of the pie. What would be a good max size
> for swap these days omn such a small disk?

I suspect, but don't know, that 400MB would be enough for the link.

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Theo de Raadt]

Stuart Henderson  wrote:

> On 2021-07-15, Otto Moerbeek  wrote:
> > On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:
> >
> >> The problem appears to be here:
> >> 
> >> > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> >> > wd1 at wdc2 channel 0 drive 0: 
> >> > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> >> > wd1(wdc2:0:0): using BIOS timings
> >> 
> >> >   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
> >> >   b:   256.0M  2172128swap
> >> >   c:  7647.6M0  unused
> >> >   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
> >> >   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # /home
> >> 
> >> Your swap is only 256MB.  That seem too low.  (We have walked away from
> >> making it correspond to physical memory, but still, it seems uncomfortably 
> >> low).
> >> 
> >> As well, /usr seems a bit large, leaving not much for /home.
> >> 
> >> The autoallocation scheme might have made a less than perfect decision 
> >> here.
> >> 
> >
> > Thhis is bassed on the "medium" allocation, swap, /usr and /home have
> > reached there max according to the table. We can make swap have a
> > alrager max and take more of the pie. What would be a good max size
> > for swap these days omn such a small disk?
> >
> > -Otto
> >
> >
> 
> It depends on the RAM really, normally that space is better in /usr
> so that upgrades don't break quite as easily...

Swap allocation should not depend on available RAM.  That outdated meme
is silly, because it is impossible to come up with a reasonable
calculation of how much memory a machine WOULD USE.  Instead, we should
just grab a piece of the disk, for swap.

256MB just seems too small.

OTOH, machines like this should not be a priority for us.

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Stuart Henderson]

On 2021-07-15, Otto Moerbeek  wrote:
> On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:
>
>> The problem appears to be here:
>> 
>> > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
>> > wd1 at wdc2 channel 0 drive 0: 
>> > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
>> > wd1(wdc2:0:0): using BIOS timings
>> 
>> >   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
>> >   b:   256.0M  2172128swap
>> >   c:  7647.6M0  unused
>> >   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
>> >   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # /home
>> 
>> Your swap is only 256MB.  That seem too low.  (We have walked away from
>> making it correspond to physical memory, but still, it seems uncomfortably 
>> low).
>> 
>> As well, /usr seems a bit large, leaving not much for /home.
>> 
>> The autoallocation scheme might have made a less than perfect decision here.
>> 
>
> Thhis is bassed on the "medium" allocation, swap, /usr and /home have
> reached there max according to the table. We can make swap have a
> alrager max and take more of the pie. What would be a good max size
> for swap these days omn such a small disk?
>
>   -Otto
>
>

It depends on the RAM really, normally that space is better in /usr
so that upgrades don't break quite as easily...

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Otto Moerbeek]

On Wed, Jul 14, 2021 at 05:28:06PM -0600, Theo de Raadt wrote:

> The problem appears to be here:
> 
> > wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> > wd1 at wdc2 channel 0 drive 0: 
> > wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> > wd1(wdc2:0:0): using BIOS timings
> 
> >   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
> >   b:   256.0M  2172128swap
> >   c:  7647.6M0  unused
> >   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
> >   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # /home
> 
> Your swap is only 256MB.  That seem too low.  (We have walked away from
> making it correspond to physical memory, but still, it seems uncomfortably 
> low).
> 
> As well, /usr seems a bit large, leaving not much for /home.
> 
> The autoallocation scheme might have made a less than perfect decision here.
> 

Thhis is bassed on the "medium" allocation, swap, /usr and /home have
reached there max according to the table. We can make swap have a
alrager max and take more of the pie. What would be a good max size
for swap these days omn such a small disk?

-Otto

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Stuart Henderson]

On 2021-07-14, Patrick Harper  wrote:
> Hi All,
>
> The installation program on my Intel P5/80MB RAM machine works fine up 
> to 'Relinking to create unique kernel...', during which the system 
> either reboots or eventually prints a kernel panic message. If 80MB is 
> not enough under normal circumstances then it's not worth debugging. 

I've had enough problems on even 256MB machines with the relinking
that's done in the background after booting. The LLVM linker uses quite
a lot of memory, you have better chances if you hack the script to use
the old binutils one (IIRC it's something like putting "-fuse-ld=bfd" in
the right place).

> Apparently 64MB was enough for 6.7 
> (https://www.uninformativ.de/blog/postings/2020-06-21/0/POSTING-en.html)
>  but that was then, e.t.c.

The author does disable kernel and library relinking though.

Re: Should 80MB of RAM be enough for kernel relinking on i386?

[Theo de Raadt]

The problem appears to be here:

> wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
> wd1 at wdc2 channel 0 drive 0: 
> wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
> wd1(wdc2:0:0): using BIOS timings

>   a:  1060.6M   64  4.2BSD   2048 16384 1 # /
>   b:   256.0M  2172128swap
>   c:  7647.6M0  unused
>   d:  3072.0M  2696416  4.2BSD   2048 16384 1 # /usr
>   e:  2048.0M  8987872  4.2BSD   2048 16384 1 # /home

Your swap is only 256MB.  That seem too low.  (We have walked away from
making it correspond to physical memory, but still, it seems uncomfortably low).

As well, /usr seems a bit large, leaving not much for /home.

The autoallocation scheme might have made a less than perfect decision here.

Should 80MB of RAM be enough for kernel relinking on i386?

[Patrick Harper]

Hi All,

The installation program on my Intel P5/80MB RAM machine works fine up 
to 'Relinking to create unique kernel...', during which the system 
either reboots or eventually prints a kernel panic message. If 80MB is 
not enough under normal circumstances then it's not worth debugging. 
Apparently 64MB was enough for 6.7 
(https://www.uninformativ.de/blog/postings/2020-06-21/0/POSTING-en.html)
 but that was then, e.t.c.

paianni$ doas cu
Connected to /dev/cua00 (speed 9600)
>> OpenBSD/i386 BOOT 3.44
boot> machine mem
Region 0: type 1 at 0x0 for 639KB
Region 1: type 1 at 0x10 for 80896KB
Low ram: 639KB  High ram: 15360KB
Total free memory: 81535KB
boot> wd0a:/bsd.rd
boot> boot wd0a:/bsd.rd
cannot open wd0a:/etc/random.seed: No such file or directory
booting wd0a:/bsd.rd: 3213847+1405952+3358728+0+421888 
[88+160+28]=0x805300
entry point at 0x201000

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights 
reserved.
Copyright (c) 1995-2021 OpenBSD. All rights reserved.  
https://www.OpenBSD.org

OpenBSD 6.9 (RAMDISK_CD) #768: Sat Apr 17 22:27:31 MDT 2021
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem  = 83423232 (79MB)
avail mem = 7228 (69MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: date 11/15/96
pcibios at bios0 function 0x1a not configured
bios0: ROM list: 0xc/0xc000 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 134 MHz, 05-02-0c
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MELTDOWN
cpu0: F00F bug workaround installed
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Opti 82C557 Host" rev 0x00
pcib0 at pci0 dev 1 function 0 "Opti 82C558 ISA" rev 0x00
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD7543" rev 0x00
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
wd0(wdc0:0:0): using BIOS timings
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pcic0 at isa0 port 0x3e0/2 iomem 0xd/16384
pcic0 controller 0:  has sockets A and B
pcmcia0 at pcic0 controller 0 socket 0
wdc2 at pcmcia0 function 0 "TRANSCEND, TS8GCF133, " port 0x340/16: irq 3
wd1 at wdc2 channel 0 drive 0: 
wd1: 1-sector PIO, LBA48, 7647MB, 15662304 sectors
wd1(wdc2:0:0): using BIOS timings
pcmcia1 at pcic0 controller 0 socket 1
ne3 at pcmcia1 function 0 "D-Link, DE-660, 118B6603" port 0x300/32, irq 
9, address 00:80:c8:8b:ec:8e
pcic0: irq 10, polling enabled
softraid0 at root
scsibus0 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
WARNING: CHECK AND RESET THE DATE!
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/i386 6.9 installation program.
WARNING: /mnt was not properly unmounted
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i
At any prompt except password prompts you can escape to a shell by
typing '!'. Default answers are shown in []'s and are selected by
pressing RETURN.  You can exit this program at any time by pressing
Control-C, but this can leave your system in an inconsistent state.

Terminal type? [vt220] 
System hostname? (short form, e.g. 'foo') paipaq

Available network interfaces are: ne3 vlan0.
Which network interface do you wish to configure? (or 'done') [ne3] 
IPv4 address for ne3? (or 'dhcp' or 'none') [dhcp] 
ne3: no lease..sleeping
IPv6 address for ne3? (or 'autoconf' or 'none') [none] 
Available network interfaces are: ne3 vlan0.
Which network interface do you wish to configure? (or 'done') [done] 
DNS domain name? (e.g. 'example.com') [my.domain] home
DNS nameservers? (IP address list or 'none') [none] 

Password for root account? (will not echo) 
Password for root account? (again) 
Start sshd(8) by default? [yes] 
Do you expect to run the X Window System? [yes] no
Change the default console to com0? [yes] no
Setup a user? (enter a lower-case loginname, or 'no') [no] paianni
Full name for user paianni? [paianni] Patrick Harper
Password for user paianni? (will not echo) 
Password for user paianni? (again) 
WARNING: root is targeted by password guessing attacks, pubkeys are 
safer.
Allow root ssh login? (yes, no, prohibit-password) [no] 

Available disks are: wd0 wd1.
Which disk is the root disk? ('?' for details) [wd0] wd1
Disk: wd1   geometry: 15538/16/63 [15662304 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending 

Re: Swap partition should equal exactly RAM size, for crash dump+savecore(8) to always work on crash?

[Joseph Mayer]

On Sunday, 14 March 2021 08:46, Otto Moerbeek  wrote:
> On Sun, Mar 14, 2021 at 01:17:05AM +, Joseph Mayer wrote:
>
> > Hi,
> > Apologies if I missed any earlier clarification on the mailing list of
> > this question:
> > What should the size of my swap partition be exactly, at least, for it
> > to guaranteedly be big enough to contain a whole kernel crash dump, if
> > the kernel crashes?
> > I would presume the exact size of the RAM, or are there headings that add
> > some bytes or kilobytes, or some further annotations that may take how
> > much, a gigabyte extra?
> > Thanks,
> > Joseph
>
> A crash dump needs a bit more than physical RAM. If you use the
> autoallocater when creating a disklabel, it uses max 2 * physmem + 256M,
> to have room for two crash dumps. See
> src/sbin/disklable/editor.c:editor_allocspace().
>
> -Otto

Hi Otto,

Thank you very much for your response.

Just curious, when would a dump partition ever contain two crash dumps,
would this be in case the subsequent reboot would crash before reaching
savecore(8)?

(Then followup on an old feature request: If crash dumping could be
done to swap files would be great. To my best awareness this is not
supported today.

Actually for machines that ordinarily don't actually use swap memory
anyhow as in all memory used always fits in RAM, crash dumping is the
only reason to have a swap partition today.)

Joseph

Re: Swap partition should equal exactly RAM size, for crash dump+savecore(8) to always work on crash?

[Otto Moerbeek]

On Sun, Mar 14, 2021 at 10:53:22AM +, Joseph Mayer wrote:

> On Sunday, 14 March 2021 08:46, Otto Moerbeek  wrote:
> > On Sun, Mar 14, 2021 at 01:17:05AM +, Joseph Mayer wrote:
> >
> > > Hi,
> > > Apologies if I missed any earlier clarification on the mailing list of
> > > this question:
> > > What should the size of my swap partition be exactly, at least, for it
> > > to guaranteedly be big enough to contain a whole kernel crash dump, if
> > > the kernel crashes?
> > > I would presume the exact size of the RAM, or are there headings that add
> > > some bytes or kilobytes, or some further annotations that may take how
> > > much, a gigabyte extra?
> > > Thanks,
> > > Joseph
> >
> > A crash dump needs a bit more than physical RAM. If you use the
> > autoallocater when creating a disklabel, it uses max 2 * physmem + 256M,
> > to have room for two crash dumps. See
> > src/sbin/disklable/editor.c:editor_allocspace().
> >
> > -Otto
> 
> Hi Otto,
> 
> Thank you very much for your response.
> 
> Just curious, when would a dump partition ever contain two crash dumps,
> would this be in case the subsequent reboot would crash before reaching
> savecore(8)?

Ugh, I was wrong */var* is sized to be able to contain two crash dumps.
swap is set to physmem + 256MB.

> (Then followup on an old feature request: If crash dumping could be
> done to swap files would be great. To my best awareness this is not
> supported today.
> 
> Actually for machines that ordinarily don't actually use swap memory
> anyhow as in all memory used always fits in RAM, crash dumping is the
> only reason to have a swap partition today.)
> 
> Joseph

Dumping to a swap file is much more complex than dumping to "real"
swap, is you would need to be able to interpret filesystems.

-Otto

Re: Swap partition should equal exactly RAM size, for crash dump+savecore(8) to always work on crash?

[Otto Moerbeek]

On Sun, Mar 14, 2021 at 01:17:05AM +, Joseph Mayer wrote:

> Hi,
> 
> Apologies if I missed any earlier clarification on the mailing list of
> this question:
> 
> What should the size of my swap partition be exactly, at least, for it
> to guaranteedly be big enough to contain a whole kernel crash dump, if
> the kernel crashes?
> 
> I would presume the exact size of the RAM, or are there headings that add
> some bytes or kilobytes, or some further annotations that may take how
> much, a gigabyte extra?
> 
> Thanks,
> Joseph
> 

A crash dump needs a bit more than physical RAM. If you use the
autoallocater when creating a disklabel, it uses max 2 * physmem + 256M,
to have room for two crash dumps. See
src/sbin/disklable/editor.c:editor_allocspace().

-Otto

Swap partition should equal exactly RAM size, for crash dump+savecore(8) to always work on crash?

[Joseph Mayer]

Hi,

Apologies if I missed any earlier clarification on the mailing list of
this question:

What should the size of my swap partition be exactly, at least, for it
to guaranteedly be big enough to contain a whole kernel crash dump, if
the kernel crashes?

I would presume the exact size of the RAM, or are there headings that add
some bytes or kilobytes, or some further annotations that may take how
much, a gigabyte extra?

Thanks,
Joseph

Re: Acer Extensa 5635Z RAM and net boards.

[Isaia Luciano]

Hi,
thanks for your reply.
It was a new installation on this notebook so I had to change the SO.
With FreeBSD (11.2) no problem for this interface.
But theconfiguration of the sound cart is a bit difficult.
On OpenBSD was most simple to configure.


Il 30/12/20 23:46, pcost ha scritto:

Ciao Luciano,
I am writing using the same notebook you have, an Acer Extensa 5635, 
with 4GB Ram.

My Bios version is 1.3311 and OpenBSD version is 6.8.
Same behavior here: the wifi card works correctly only with one memory 
card inserted (2GB); inserting the second memory card (2+2GB), the 
wifi card stops to work.

The 'dmesg' output is almost the same of yours
(alc0: phy write timeout: phy 0, reg 30) and so on.
I confirm everything works correctly with debian (kernel 5.9).
My workaround is to use a TPLink mini usb wifi network card, that is 
better than decrease the ram...

Ciao.


Il 12/20/20 8:08 PM, Isaia Luciano ha scritto:

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD) 
properly activate the interface.



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net 
interface not running.The dmesg is:

OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) 
EHC2(S3) HDEF(S3) GLAN(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN 


cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN 


cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem 
"SANYO"

acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 f

Re: Acer Extensa 5635Z RAM and net boards.

[pcost]

Ciao Luciano,
I am writing using the same notebook you have, an Acer Extensa 5635, 
with 4GB Ram.

My Bios version is 1.3311 and OpenBSD version is 6.8.
Same behavior here: the wifi card works correctly only with one memory 
card inserted (2GB); inserting the second memory card (2+2GB), the wifi 
card stops to work.

The 'dmesg' output is almost the same of yours
(alc0: phy write timeout: phy 0, reg 30) and so on.
I confirm everything works correctly with debian (kernel 5.9).
My workaround is to use a TPLink mini usb wifi network card, that is 
better than decrease the ram...

Ciao.


Il 12/20/20 8:08 PM, Isaia Luciano ha scritto:

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD) properly 
activate the interface.



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net 
interface not running.The dmesg is:

OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) 
EHC2(S3) HDEF(S3) GLAN(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN 


cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN 


cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem "SANYO"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 

Re: Acer Extensa 5635Z RAM and net boards.

[Bodie]

On 21.12.2020 19:00, Isaia Luciano wrote:

Hello

I tried  with the current.

Unfortunelly not work.

Thanks.



Any chance to test that particular module with some memtest app?



Il 21/12/20 17:59, Isaia Luciano ha scritto:

Hello.
The BIOS is the last version for this old model.
I don't understand why if remove the second bank of RAM the interfaces 
work.

I will try with the current snapshot.

Thanks.



Il 20/12/20 21:01, Bodie ha scritto:




On 20.12.2020 20:08, Isaia Luciano wrote:

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD)
properly activate the interface.



OpenBSD is using own implementation of https://man.openbsd.org/acpi

BIOS seems to be latest available for that machine, which does not
mean that most of the problems really get fixed at that time 10
years ago

Can you try with current snapshot?



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space 
available

.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net 
interface not running.The dmesg is:

OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) 
EHC2(S3) HDEF(S3) GLAN(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 
06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 
06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem 
"SANYO"

acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp

Re: Acer Extensa 5635Z RAM and net boards.

[Isaia Luciano]

Hello.
The BIOS is the last version for this old model.
I don't understand why if remove the second bank of RAM the interfaces work.
I will try with the current snapshot.

Thanks.


Il 20/12/20 21:01, Bodie ha scritto:



On 20.12.2020 20:08, Isaia Luciano wrote:

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD)
properly activate the interface.



OpenBSD is using own implementation of https://man.openbsd.org/acpi

BIOS seems to be latest available for that machine, which does not
mean that most of the problems really get fixed at that time 10
years ago

Can you try with current snapshot?



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net 
interface not running.The dmesg is:

OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) 
EHC2(S3) HDEF(S3) GLAN(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem 
"SANYO"

acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 
mwait.1@0x10), C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 
int

Re: Acer Extensa 5635Z RAM and net boards.

[Bodie]

On 20.12.2020 20:08, Isaia Luciano wrote:

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD)
properly activate the interface.



OpenBSD is using own implementation of https://man.openbsd.org/acpi

BIOS seems to be latest available for that machine, which does not
mean that most of the problems really get fixed at that time 10
years ago

Can you try with current snapshot?



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net 
interface not running.The dmesg is:

OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) 
EHC2(S3) HDEF(S3) GLAN(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem 
"SANYO"

acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 
int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 
int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 2 
int 19

usb0 at ehci0: USB revision 2.0

Re: Acer Extensa 5635Z RAM and net boards.

[Isaia Luciano]

Hello,

it would seam a OpenBSB problem, the other SO (Linux, FreeBSD) properly 
activate the interface.



# sh /etc/netstart alc0
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: writev(DHCPDISCOVER): No buffer space available
alc0: no leasealc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space avialable
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
.alc0: writev(DHCPDISCOVER): No buffer space available
sleeping

# ifconfig alc0 down
alc0: could not disable RxQ/TxQ (0x)!
alc0: could not disable Rx/Tx MAC(0x)!


I tried with live CD of Sistem Rescue CD and MidnighBSD.
It has already happened to someone.

Thanks.

Luciano.

Il 19/12/20 11:36, luis...@tin.it ha scritto:

  Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM.
I have upgrade the memory added a new 2 GB RAM bank.On boot the net interface 
not running.The dmesg is:
OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) EHC2(S3) 
HDEF(S3) GLAN(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem "SANYO"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 2 int 19
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
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi
pci1 at ppb0 bu

Acer Extensa 5635Z RAM and net boards.

[luis...@tin.it]

 Hi,I have install OpenBSD 6.8 on Acer Laptop with 2GB of RAM. 
I have upgrade the memory added a new 2 GB RAM bank.On boot the net interface 
not running.The dmesg is:
OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4105977856 (3915MB)
avail mem = 3966488576 (3782MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xb5ec (33 entries)
bios0: vendor Phoenix version "V1.3311" date 12/21/2009
bios0: Acer Extensa 5635Z
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG APIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices USB0(S3) USB1(S3) USBR(S3) EHC1(S3) USB3(S3) EHC2(S3) 
HDEF(S3) GLAN(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2095.34 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 1MB 64b/line 4-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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Pentium(R) Dual-Core CPU T4300 @ 2.10GHz, 2094.99 MHz, 06-17-0a
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 10 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 7 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiec0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "AS09C31" serial 9418 type LION oem "SANYO"
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"SYN1B20" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpitz0 at acpi0: critical temperature is 108 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: GFX0
acpivout0 at acpivideo1: DD02
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2100, 1600, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 2 int 19
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
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi
pci2 at ppb1 bus 7
athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19
athn0: could not reset chip
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x03: msi
pci3 at ppb2 bus 9
alc0 at pci3 dev 0 function 0 "Attansic Technology L1C" rev 0xc0: msialc0: phy 
write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy write timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 29
alc0: phy read timeout: phy 0, reg 30
alc0: phy write timeout: phy 0, reg 30
alc0: phy write 

Re: macbook only sees 1GB of a 2GB RAM module

[Stuart Henderson]

On 2020-05-31, obs...@loopw.com  wrote:
> (this is a 32 bit issue in general - x86 hardware usually defaults
> to a 3.5GB/512MB split, but the 32bit uefi/64bit cpu macs went with a
> 3GB/1GB split)

not specifically macs, but with the chipsets used for skylake or newer
intel this is even worse.

Re: macbook only sees 1GB of a 2GB RAM module

[rgc]

On Sat, May 30, 2020 at 07:23:58PM +0200, Jan Stary wrote:
> This is current/amd64 on a macbook2,1 (dmesg below).
> It has two RAM slots, each holding a 2GB module:

if you like using older Apple HW then

https://everymac.com/

is a very good resource. searching Macbook2,1 reveals the HW issue. 

this specific limitation
https://everymac.com/systems/apple/macbook_pro/faq/macbook-pro-core-2-duo-3-gb-memory-limitation-details.html

> 
> spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> 
> But of one of the 2GB, only 1GB is seen:
> 
> real mem = 3171909632 (3024MB)
> 
> I have tried swapping the mdules, it only happens
> in one of the two slots. If I put a 1GB module in there,
> the available memory is the same (in the other slot,
> 2GB is 2GB and 1GB is 1GB).
> 
> Why is this? Does it have anthing to do with
> the memory map conflicts I see in the dmesg?
> 

~rgc

Re: macbook only sees 1GB of a 2GB RAM module

[obsdml]

You have a 32bit uefi on the MacBook2,1

Its set to only ever address 3GB of ram, even though you can physically have 
more in the box.

(this is a 32 bit issue in general - x86 hardware usually defaults to a 
3.5GB/512MB split, but the 32bit uefi/64bit cpu macs went with a 3GB/1GB split)


> On May 30, 2020, at 10:23 AM, Jan Stary  wrote:
> 
> This is current/amd64 on a macbook2,1 (dmesg below).
> It has two RAM slots, each holding a 2GB module:
> 
> spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
> 
> But of one of the 2GB, only 1GB is seen:
> 
> real mem = 3171909632 (3024MB)
> 
> I have tried swapping the mdules, it only happens
> in one of the two slots. If I put a 1GB module in there,
> the available memory is the same (in the other slot,
> 2GB is 2GB and 1GB is 1GB).
> 
> Why is this? Does it have anthing to do with
> the memory map conflicts I see in the dmesg?
> 
>   Jan
> 
> 
> OpenBSD 6.7-current (GENERIC.MP) #0: Sat May 30 17:45:54 CEST 2020
>h...@mb64.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3171909632 (3024MB)
> avail mem = 3063046144 (2921MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (37 entries)
> bios0: vendor Apple Inc. version "MB21.88Z.00A5.B07.0706270922" date 06/27/07
> bios0: Apple Inc. MacBook2,1
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
> acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) 
> USB3(S3) USB4(S3) USB7(S3) EC__(S3)
> 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)2 CPU T7400 @ 2.16GHz, 2161.59 MHz, 06-0f-06
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 4MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz, 2161.28 MHz, 06-0f-06
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu1: 4MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-255
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus 2 (RP02)
> acpiprt3 at acpi0: bus 3 (PCIB)
> acpicpu0 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
> mwait), PSS
> acpicpu1 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
> mwait), PSS
> acpisbs0 at acpi0: SBS0 model "ASMB016" serial 19351 type LION oem "DP"
> acpiac0 at acpi0: AC unit online
> acpibtn0 at acpi0: LID0
> "APP0002" at acpi0 not configured
> acpibtn1 at acpi0: PWRB
> acpibtn2 at acpi0: SLPB
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0xmemory map conflict 
> 0xbef0/0x10
> memory map conflict 0xbf00/0x100
> memory map conflict 0xf00f8000/0x1000
> memory map conflict 0xfed1c000/0x4000
> memory map conflict 0xfffb/0x3
> 
> extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> extent `pciio' (0x0 - 0x), flags=0
> 0x1 - 0x
> extent `pcimem' (0x0 - 0x), flags=0
> 0x0 - 0xbfff
> 0xf000 - 0xf3ff
> 0xfec0 - 0xfec00fff
> 0xfed14000 - 0xfed19fff
> 0xfed1c000 - 0xfed1
> 0xfee0 - 0xfee00fff
> 0xffe0 - 0x
> 0x400 - 0x
> "APP0001" at acpi0 not configured
> "APP0003" at acpi0 not configured
> "ACPI0001" at acpi0 not configured
> acpicmos0 at acpi0
> acpivideo0 at acpi0: GFX0
> cpu0: Enhanced SpeedStep 2161 MHz: speeds: 2167, 2000, 1833, 1667, 1500, 
> 1333, 1000 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 

Re: thinkpad T400 only sees 4GB of every 8GB of RAM

[Jan Stary]

On May 30 20:44:11, h...@stare.cz wrote:
> This is current/amd64 on a Thinkpad T400 (dmesg below).
> It has two RAM slots; each holds a 8GB module,
> but dmesg only shows 8GB in total.
> 
> With just one module in (either one), dmesg reports 4GB.
> So it seems the system only sees 4GB of every 8GB.
> 
> Is that a known limitation?
> On another amd64 machine, the 8+8 is seen as 16.

Eh, nevermind: it is a limitation of the Thinkpad.
Sorry for the noise.

Jan



> OpenBSD 6.7-current (GENERIC.MP) #0: Tue May 26 19:11:06 CEST 2020
> h...@lenovo.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8463781888 (8071MB)
> avail mem = 8194666496 (7815MB)
> random: good seed from bootblocks
> 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 "7UET94WW (3.24 )" date 10/17/2012
> bios0: LENOVO 64741EG
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA 
> SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(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 P8400 @ 2.26GHz, 798.13 MHz, 06-17-06
> 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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> 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 265MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.01 MHz, 06-17-06
> 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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> 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, remapped
> acpimcfg0 at acpi0
> acpimcfg0: 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 5 (EXP3)
> acpiprt6 at acpi0: bus 13 (EXP4)
> acpiprt7 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), 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
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> extent `pciio' (0x0 - 0x), flags=0
>  0x1 - 0x
> extent `pcimem' (0x0 - 0x), flags=0
>  0x0 - 0xbfff
>  0xe000 - 0xefff
>  0xfec0 - 0xfec0
>  0xfed0 - 0xfed003ff
>  0xfed1 - 0xfed13fff
>  0xfed18000 - 0xfed19fff
>  0xfed1c000 - 0xfed8
>  0xfee0 - 0xfee00fff
>  0xff80 - 0x
>  0x400 - 0x
> acpicmos0 at acpi0
> tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x10208086 rev 0x6
> acpibat0 at acpi0: BAT0 model "92P1137" serial57 type LION oem "SANYO"
> acpiac0 at acpi0: AC unit offline
> acpithinkpad0 at acpi0: version 1.0
> "PNP0C14" at acpi0 not configured
> acpidock0 at acpi0: GDCK not docked (0)
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> cpu0: Enhanced SpeedStep 798 MHz: speeds: 2267, 2266, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: apic 1 int 16, GM45, gen 4
> "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 

thinkpad T400 only sees 4GB of every 8GB of RAM

[Jan Stary]

This is current/amd64 on a Thinkpad T400 (dmesg below).
It has two RAM slots; each holds a 8GB module,
but dmesg only shows 8GB in total.

With just one module in (either one), dmesg reports 4GB.
So it seems the system only sees 4GB of every 8GB.

Is that a known limitation?
On another amd64 machine, the 8+8 is seen as 16.

Is this related to the "extent `pcimem'" lines in the dmesg?

Jan


OpenBSD 6.7-current (GENERIC.MP) #0: Tue May 26 19:11:06 CEST 2020
h...@lenovo.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8463781888 (8071MB)
avail mem = 8194666496 (7815MB)
random: good seed from bootblocks
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 "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 64741EG
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(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 P8400 @ 2.26GHz, 798.13 MHz, 06-17-06
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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
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 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.01 MHz, 06-17-06
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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
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, remapped
acpimcfg0 at acpi0
acpimcfg0: 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 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), 
C1(1000@1 mwait.1), 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
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `pciio' (0x0 - 0x), flags=0
 0x1 - 0x
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0xbfff
 0xe000 - 0xefff
 0xfec0 - 0xfec0
 0xfed0 - 0xfed003ff
 0xfed1 - 0xfed13fff
 0xfed18000 - 0xfed19fff
 0xfed1c000 - 0xfed8
 0xfee0 - 0xfee00fff
 0xff80 - 0x
 0x400 - 0x
acpicmos0 at acpi0
tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x10208086 rev 0x6
acpibat0 at acpi0: BAT0 model "92P1137" serial57 type LION oem "SANYO"
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0: version 1.0
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD0
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 798 MHz: speeds: 2267, 2266, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 1 int 16, GM45, gen 4
"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
puc0 at pci0 dev 3 function 3 "Intel GM45 KT" rev 0x07: ports: 16 com
com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo
com4: probed fifo depth: 15 bytes
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1c:25:9b:0a:23
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
uhci

macbook only sees 1GB of a 2GB RAM module

[Jan Stary]

This is current/amd64 on a macbook2,1 (dmesg below).
It has two RAM slots, each holding a 2GB module:

spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM
spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM

But of one of the 2GB, only 1GB is seen:

real mem = 3171909632 (3024MB)

I have tried swapping the mdules, it only happens
in one of the two slots. If I put a 1GB module in there,
the available memory is the same (in the other slot,
2GB is 2GB and 1GB is 1GB).

Why is this? Does it have anthing to do with
the memory map conflicts I see in the dmesg?

Jan


OpenBSD 6.7-current (GENERIC.MP) #0: Sat May 30 17:45:54 CEST 2020
h...@mb64.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3171909632 (3024MB)
avail mem = 3063046144 (2921MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (37 entries)
bios0: vendor Apple Inc. version "MB21.88Z.00A5.B07.0706270922" date 06/27/07
bios0: Apple Inc. MacBook2,1
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) 
USB3(S3) USB4(S3) USB7(S3) EC__(S3)
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)2 CPU T7400 @ 2.16GHz, 2161.59 MHz, 06-0f-06
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz, 2161.28 MHz, 06-0f-06
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (PCIB)
acpicpu0 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
mwait), PSS
acpicpu1 at acpi0: !C3(100@55 mwait@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
mwait), PSS
acpisbs0 at acpi0: SBS0 model "ASMB016" serial 19351 type LION oem "DP"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0xmemory map conflict 
0xbef0/0x10
memory map conflict 0xbf00/0x100
memory map conflict 0xf00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict 0xfffb/0x3

extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `pciio' (0x0 - 0x), flags=0
 0x1 - 0x
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0xbfff
 0xf000 - 0xf3ff
 0xfec0 - 0xfec00fff
 0xfed14000 - 0xfed19fff
 0xfed1c000 - 0xfed1
 0xfee0 - 0xfee00fff
 0xffe0 - 0x
 0x400 - 0x
"APP0001" at acpi0 not configured
"APP0003" at acpi0 not configured
"ACPI0001" at acpi0 not configured
acpicmos0 at acpi0
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 2161 MHz: speeds: 2167, 2000, 1833, 1667, 1500, 1333, 
1000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc000, size 0x1000
inteldrm0: apic 1 int 16, I945GM, gen 3
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and Frequency, 
rev 0x03) at pci0 dev 7 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Sigmatel STAC9220/1
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC 
rev. A3 (0x2): apic 1 int 16
msk0 at mskc0 port A: address 00:1b:63:36:2b:5d
eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2
ppb1 at

Re: 6.6 VMs need 320Mb of ram in bhyve

[Florian Viehweger]

Hi,


>I'd report this to FreeBSD, since this looks like a bhyve issue. I
>tried 256MB
>here using a 6.6 vmm(4) guest VM and it worked fine

I second that. I use 6.6 on a Pentium 2 Laptop and it's fine. Until kernel 
relinking is finished its sluggish, but after that the machine runs quite well.

-- 
Greetings,

Florian Viehweger

Re: 6.6 VMs need 320Mb of ram in bhyve

[Mike Larkin]

On Fri, Oct 25, 2019 at 11:38:52AM +0200, Noth wrote:
> Hi,
> 
>   I just upgraded a couple of VMs to 6.6 (thanks to everyone for another
> brilliant release!) that used to manage in 256Mb of RAM. They crash at the
> stage the kernel loads with that amount in 6.6, and with 288Mb the kernel
> loading process hangs. It takes 320Mb for them to boot without any issues. I
> don't know what's changed but I thought it'd be worth reporting. I'm using
> bhyve on FreeBSD 12.0.
> 
> Cheers,
> 
> Noth
> 

I'd report this to FreeBSD, since this looks like a bhyve issue. I tried 256MB
here using a 6.6 vmm(4) guest VM and it worked fine, so I reduced it all
the way down to 40MB about 16MB at a time and it still worked (but it was
obviously pretty slow). Even 32MB might work but I didn't go that low.

dmesg of that vm below.

-ml

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 25149440 (23MB)
avail mem = 11948032 (11MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 (10 entries)
bios0: vendor SeaBIOS version "1.11.0p2-OpenBSD-vmm" date 01/01/2011
bios0: OpenBSD VMM
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz, 3000.78 MHz, 06-9e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: OpenBSD
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio1: address fe:e1:bb:d1:6e:85
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio2
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0: 
sd0: 51200MB, 512 bytes/sector, 104857600 sectors
virtio2: irq 6
virtio3 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk1 at virtio3
scsibus2 at vioblk1: 2 targets
sd1 at scsibus2 targ 0 lun 0: 
sd1: 51200MB, 512 bytes/sector, 104857600 sectors
virtio3: irq 7
virtio4 at pci0 dev 5 function 0 "OpenBSD VMM Control" rev 0x00
vmmci0 at virtio4
virtio4: irq 9
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (0ba42bba827b17f1.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (0ba42bba827b17f1.a): file system is clean; not checking
/dev/sd0m (0ba42bba827b17f1.m): file system is clean; not checking
/dev/sd1a (831a0bf34b37f69c.a): file system is clean; not checking
/dev/sd0n (0ba42bba827b17f1.n): file system is clean; not checking
/dev/sd0d (0ba42bba827b17f1.d): file system is clean; not checking
/dev/sd0f (0ba42bba827b17f1.f): file system is clean; not checking
/dev/sd0g (0ba42bba827b17f1.g): file system is clean; not checking
/dev/sd0h (0ba42bba827b17f1.h): file system is clean; not checking
/dev/sd0j (0ba42bba827b17f1.j): file system is clean; not checking
/dev/sd0o (0ba42bba827b17f1.o): file system is clean; not checking
/dev/sd0i (0ba42bba827b17f1.i): file system is clean; not checking
/dev/sd0k (0ba42bba827b17f1.k): file system is clean; not checking
/dev/sd0l (0ba42bba827b17f1.l): file system is clean; not checking
/dev/sd0e (0ba42bba827b17f1.e): file system is clean; not checking
kern.bufcachepercent: 20 -> 90
kern.timecounter.hardware: tsc -> tsc
starting network
vio0: 172.16.19.109 lease accepted from 172.16.19.1 (fe:e1:ba:db:63:5e)
starting early daemons: syslogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd.
starting local daemons: cron.
Sun Oct 27 20:35:29 PDT 2019

OpenBSD/amd64 (test-amd64.int.azathoth.net) (tty00)

login: 

Re: 6.6 VMs need 320Mb of ram in bhyve

[Kenneth Gober]

On Fri, Oct 25, 2019 at 7:33 AM Noth  wrote:

>I just upgraded a couple of VMs to 6.6 (thanks to everyone for
> another brilliant release!) that used to manage in 256Mb of RAM. They
> crash at the stage the kernel loads with that amount in 6.6, and with
> 288Mb the kernel loading process hangs. It takes 320Mb for them to boot
> without any issues. I don't know what's changed but I thought it'd be
> worth reporting. I'm using bhyve on FreeBSD 12.0.
>

I recently installed 6.6 under VMware ESXi 5.5 (both amd64 and i386
flavors) and they booted fine set to only 256MB (although bootup did
take a long time).  I can't help but wonder if it makes a difference
whether you install from scratch on 256MB, or upgrade from an
earlier release.  Or maybe disk size makes a difference (i.e. if you
are loading the kernel from a bigger disk, the boot loader needs
more RAM?).  My VMs are all built with 8GB disks.

Either way, it's clear I need to increase the minimum RAM on my
VMs, so thanks for confirming my own observation that 256MB
is becoming problematic.

-ken

6.6 VMs need 320Mb of ram in bhyve

[Noth]

Hi,

  I just upgraded a couple of VMs to 6.6 (thanks to everyone for 
another brilliant release!) that used to manage in 256Mb of RAM. They 
crash at the stage the kernel loads with that amount in 6.6, and with 
288Mb the kernel loading process hangs. It takes 320Mb for them to boot 
without any issues. I don't know what's changed but I thought it'd be 
worth reporting. I'm using bhyve on FreeBSD 12.0.


Cheers,

Noth

Re: Can minecraft run on OpenBSD i386 with less than 2Gb Ram ?

[Edgar Pettijohn]

On Oct 5, 2019 8:02 AM, Solene Rapenne  wrote:
>
> On Sat, Oct 05, 2019 at 12:20:09PM +0100, Tom Smyth wrote:
> > Hi all,
> > My 5 year old son as a laptop .. Running OpenBSD 6.5 stable and im trying
> > to
> > I figured current would be a little tricky for him :) ...
> > I have tried to get minecraft working on it but I think I probably don't
> > have enough ram...
> > I have tried upping the staff limits in limits .conf etc..
> > there also seems to be a bug with the current launcher that is included in
> > ports
> > as there is a "you need java script enabled to view this site" message
> > displayed on the launcher after you click the play button ...
> > 
> > Perhaps I just need to shell out for a laptop that will run x86-64 ..  :)
> > 
> > Kindest regards,
> > Tom Smyth.
>
> I think it can run, but you may prefer running games/minetest, it's an
> opensource minecraft clone which requires a LOT less ressources and
> which should bring a lot of fun too.
>
> The main difference would be the lack of monsters, less blocks and no
> redstone, but there are lots of mods to fill thoses gaps IIRC.
>

I enjoyed minetest. He should too. My son eventually outgrew it and wanted the 
real deal at around 8. I don't remember if I tried to install it on OBSD or 
not. It currently lives on a Debian amd64 desktop where it runs pretty good. 
Plus there is an official .deb package which makes things easier for me.

Good luck.

Edgar

Re: Can minecraft run on OpenBSD i386 with less than 2Gb Ram ?

[Solene Rapenne]

On Sat, Oct 05, 2019 at 12:20:09PM +0100, Tom Smyth wrote:
> Hi all,
> My 5 year old son as a laptop .. Running OpenBSD 6.5 stable and im trying
> to
> I figured current would be a little tricky for him :) ...
> I have tried to get minecraft working on it but I think I probably don't
> have enough ram...
> I have tried upping the staff limits in limits .conf etc..
> there also seems to be a bug with the current launcher that is included in
> ports
> as there is a "you need java script enabled to view this site" message
> displayed on the launcher after you click the play button ...
> 
> Perhaps I just need to shell out for a laptop that will run x86-64 ..  :)
> 
> Kindest regards,
> Tom Smyth.

I think it can run, but you may prefer running games/minetest, it's an
opensource minecraft clone which requires a LOT less ressources and
which should bring a lot of fun too.

The main difference would be the lack of monsters, less blocks and no
redstone, but there are lots of mods to fill thoses gaps IIRC.

Can minecraft run on OpenBSD i386 with less than 2Gb Ram ?

[Tom Smyth]

Hi all,
My 5 year old son as a laptop .. Running OpenBSD 6.5 stable and im trying
to
I figured current would be a little tricky for him :) ...
I have tried to get minecraft working on it but I think I probably don't
have enough ram...
I have tried upping the staff limits in limits .conf etc..
there also seems to be a bug with the current launcher that is included in
ports
as there is a "you need java script enabled to view this site" message
displayed on the launcher after you click the play button ...

Perhaps I just need to shell out for a laptop that will run x86-64 ..  :)

Kindest regards,
Tom Smyth.

Re: Write to DVD-RAM

[Zhi-Qiang Lei]

According to https://www.openbsd.org/faq/faq13.html#writeDVD 
<https://www.openbsd.org/faq/faq13.html#writeDVD>,

> A pretty different format is DVD-RAM, which was mainly developed as a data 
> drive and has advanced packet writing functions, allowing it to be used like 
> a kind of optical hard disk.

I was mainly looking for a method to make the DVD-RAM works like a hard drive. 
It seems the package is the only option though.

Thanks and best regards,
Siegfried

> On Jul 27, 2019, at 6:42 PM, Brian Brombacher  wrote:
> 
> See cd(4): https://man.openbsd.org/cd.4 <https://man.openbsd.org/cd.4>
> 
> It’s not a real block device.  You’ll need to use something like the dvd+rw 
> tools package already mentioned in order to write data to it.  The man page 
> talks about how cd devices are represented as block devices for consistency 
> with other tools like disklabel and mount.  Look at the list of ioctl’s 
> supported in the man page.  It talks of tracks of data (like audio tracks) 
> and such.
> 
> -Brian
> 
> On Jul 26, 2019, at 8:23 PM, gwes mailto:g...@oat.com>> wrote:
> 
>> 
>> 
>> On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote:
>>> On Jul 25, 2019, at 10:24 PM, gwes mailto:g...@oat.com>> 
>>> wrote:
>>>> 
>>>> On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:
>>>>> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on 
>>>>> my OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work 
>>>>> on the drive. Did I miss something?
>>>>> 
>>>>> $ dmesg | grep cd
>>>>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>>>>> removable serial.13fd3940302020202020
>>>>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>>>>> removable serial.13fd3940302020202020
>>>>> 
>>>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
>>>>> dd: /dev/rcd0c: Invalid argument
>>>>> 1+0 records in
>>>>> 0+0 records out
>>>>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>>>>> 
>>>>> $ doas disklabel -E cd0
>>>>> cd0> a
>>>>> partition: [a]
>>>>> offset: [0]
>>>>> size: [2236704]
>>>>> FS type: [4.2BSD]
>>>>> cd0> w
>>>>> cd0> p
>>>>> OpenBSD area: 0-2236704; size: 2236704; free: 0
>>>>> #size   offset  fstype [fsize bsize   cpg]
>>>>>   a:  22367040  4.2BSD   2048 16384 1
>>>>>   c:  22367040  unused
>>>>> cd0> q
>>>>> No label changes.
>>>>> 
>>>>> The same drive can be formatted and used on Mac OS X.
>>>>> 
>>>>> Thanks and best regards,
>>>>> Siegfried
>>>>> 
>>>> Did you try 2K blocks? The low level of CDROM only works that way.
>>>> 
>>> 
>>> Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on 
>>> character device”. Regarding to cd(4) I thought the device is readonly, so 
>>> dd(1) and disklabel(8) cannot write on it, but fdisk(8)  works fine.
>>> 
>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k
>>> dd: /dev/rcd0c: short write on character device
>>> dd: /dev/rcd0c: Invalid argument
>>> 1+0 records in
>>> 0+1 records out
>>> 512 bytes transferred in 0.008 secs (57960 bytes/sec)
>>> 
>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=512
>>> dd: /dev/rcd0c: Invalid argument
>>> 1+0 records in
>>> 0+0 records out
>>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>>> 
>> /dev/cd0 is likely a symbolic link to something else in /dev.
>> It's not clear what's going on unless we know exactly what's being used.
>> "cd0" is not a usual OpenBSD device access even though one sees
>> that in dmesg.
>> 
>> OpenBSD disk-like devices are usually referenced in the very
>> old style which distinguishes "raw" [unbuffered direct to device]
>> from "cooked" [system buffered]. This differs from at least Linux practice.
>> Dunno about other BSDs or Macs.
>> Buffered devices are essentially only used to mount as filesystems.
>> 
>> A raw device is /dev/r
>> A buffered device is 
>> /dev/
>> Note that there is always a partition letter.
>> The kernel will always emulate a 'c' partition = whole device if necessary.
>> 
>> So the most specific way to refer to your cd device is /dev/rcd0c.
>> 
>> As a convenience and to reduce operator errors, many system maintenance
>> programs will deduce /dev/rc from a bare device
>> like sd0. This can be confusing to people new to OpenBSD.
>> 

Re: Write to DVD-RAM

[Brian Brombacher]

See cd(4): https://man.openbsd.org/cd.4

It’s not a real block device.  You’ll need to use something like the dvd+rw 
tools package already mentioned in order to write data to it.  The man page 
talks about how cd devices are represented as block devices for consistency 
with other tools like disklabel and mount.  Look at the list of ioctl’s 
supported in the man page.  It talks of tracks of data (like audio tracks) and 
such.

-Brian

> On Jul 26, 2019, at 8:23 PM, gwes  wrote:
> 
> 
> 
>> On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote:
>>> On Jul 25, 2019, at 10:24 PM, gwes  wrote:
>>> 
>>>> On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:
>>>> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on 
>>>> my OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on 
>>>> the drive. Did I miss something?
>>>> 
>>>> $ dmesg | grep cd
>>>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>>>> removable serial.13fd3940302020202020
>>>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>>>> removable serial.13fd3940302020202020
>>>> 
>>>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
>>>> dd: /dev/rcd0c: Invalid argument
>>>> 1+0 records in
>>>> 0+0 records out
>>>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>>>> 
>>>> $ doas disklabel -E cd0
>>>> cd0> a
>>>> partition: [a]
>>>> offset: [0]
>>>> size: [2236704]
>>>> FS type: [4.2BSD]
>>>> cd0> w
>>>> cd0> p
>>>> OpenBSD area: 0-2236704; size: 2236704; free: 0
>>>> #size   offset  fstype [fsize bsize   cpg]
>>>>   a:  22367040  4.2BSD   2048 16384 1
>>>>   c:  22367040  unused
>>>> cd0> q
>>>> No label changes.
>>>> 
>>>> The same drive can be formatted and used on Mac OS X.
>>>> 
>>>> Thanks and best regards,
>>>> Siegfried
>>>> 
>>> Did you try 2K blocks? The low level of CDROM only works that way.
>>> 
>> 
>> Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on 
>> character device”. Regarding to cd(4) I thought the device is readonly, so 
>> dd(1) and disklabel(8) cannot write on it, but fdisk(8)  works fine.
>> 
>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k
>> dd: /dev/rcd0c: short write on character device
>> dd: /dev/rcd0c: Invalid argument
>> 1+0 records in
>> 0+1 records out
>> 512 bytes transferred in 0.008 secs (57960 bytes/sec)
>> 
>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=512
>> dd: /dev/rcd0c: Invalid argument
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>> 
> /dev/cd0 is likely a symbolic link to something else in /dev.
> It's not clear what's going on unless we know exactly what's being used.
> "cd0" is not a usual OpenBSD device access even though one sees
> that in dmesg.
> 
> OpenBSD disk-like devices are usually referenced in the very
> old style which distinguishes "raw" [unbuffered direct to device]
> from "cooked" [system buffered]. This differs from at least Linux practice.
> Dunno about other BSDs or Macs.
> Buffered devices are essentially only used to mount as filesystems.
> 
> A raw device is /dev/r
> A buffered device is /dev/
> Note that there is always a partition letter.
> The kernel will always emulate a 'c' partition = whole device if necessary.
> 
> So the most specific way to refer to your cd device is /dev/rcd0c.
> 
> As a convenience and to reduce operator errors, many system maintenance
> programs will deduce /dev/rc from a bare device
> like sd0. This can be confusing to people new to OpenBSD.
> 

Re: Write to DVD-RAM

[gwes]

On 7/25/19 7:14 PM, Zhi-Qiang Lei wrote:

On Jul 25, 2019, at 10:24 PM, gwes  wrote:


On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:

Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my 
OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the 
drive. Did I miss something?

$ dmesg | grep cd
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)

$ doas disklabel -E cd0
cd0> a
partition: [a]
offset: [0]
size: [2236704]
FS type: [4.2BSD]
cd0> w
cd0> p
OpenBSD area: 0-2236704; size: 2236704; free: 0
#size   offset  fstype [fsize bsize   cpg]
   a:  22367040  4.2BSD   2048 16384 1
   c:  22367040  unused
cd0> q
No label changes.

The same drive can be formatted and used on Mac OS X.

Thanks and best regards,
Siegfried


Did you try 2K blocks? The low level of CDROM only works that way.



Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on 
character device”. Regarding to cd(4) I thought the device is readonly, so dd(1) and 
disklabel(8) cannot write on it, but fdisk(8)  works fine.

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k
dd: /dev/rcd0c: short write on character device
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+1 records out
512 bytes transferred in 0.008 secs (57960 bytes/sec)

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=512
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)


/dev/cd0 is likely a symbolic link to something else in /dev.
It's not clear what's going on unless we know exactly what's being used.
"cd0" is not a usual OpenBSD device access even though one sees
that in dmesg.

OpenBSD disk-like devices are usually referenced in the very
old style which distinguishes "raw" [unbuffered direct to device]
from "cooked" [system buffered]. This differs from at least Linux practice.
Dunno about other BSDs or Macs.
Buffered devices are essentially only used to mount as filesystems.

A raw device is /dev/r
A buffered device is 
/dev/

Note that there is always a partition letter.
The kernel will always emulate a 'c' partition = whole device if necessary.

So the most specific way to refer to your cd device is /dev/rcd0c.

As a convenience and to reduce operator errors, many system maintenance
programs will deduce /dev/rc from a bare device
like sd0. This can be confusing to people new to OpenBSD.

Re: Write to DVD-RAM

[Zhi-Qiang Lei]

On Jul 25, 2019, at 10:24 PM, gwes  wrote:
> 
> 
> On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:
>> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my 
>> OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the 
>> drive. Did I miss something?
>> 
>> $ dmesg | grep cd
>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>> removable serial.13fd3940302020202020
>> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
>> removable serial.13fd3940302020202020
>> 
>> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
>> dd: /dev/rcd0c: Invalid argument
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000 secs (0 bytes/sec)
>> 
>> $ doas disklabel -E cd0
>> cd0> a
>> partition: [a]
>> offset: [0]
>> size: [2236704]
>> FS type: [4.2BSD]
>> cd0> w
>> cd0> p
>> OpenBSD area: 0-2236704; size: 2236704; free: 0
>> #size   offset  fstype [fsize bsize   cpg]
>>   a:  22367040  4.2BSD   2048 16384 1
>>   c:  22367040  unused
>> cd0> q
>> No label changes.
>> 
>> The same drive can be formatted and used on Mac OS X.
>> 
>> Thanks and best regards,
>> Siegfried
>> 
> Did you try 2K blocks? The low level of CDROM only works that way.
> 


Blocks larger than or equal to 2k get a "dd: /dev/rcd0c: short write on 
character device”. Regarding to cd(4) I thought the device is readonly, so 
dd(1) and disklabel(8) cannot write on it, but fdisk(8)  works fine.

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=2k  
dd: /dev/rcd0c: short write on character device
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+1 records out
512 bytes transferred in 0.008 secs (57960 bytes/sec)

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=512
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)

Re: Write to DVD-RAM

[gwes]

On 7/24/19 10:19 PM, Zhi-Qiang Lei wrote:

Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my 
OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the 
drive. Did I miss something?

$ dmesg | grep cd
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)

$ doas disklabel -E cd0
cd0> a
partition: [a]
offset: [0]
size: [2236704]
FS type: [4.2BSD]
cd0> w
cd0> p
OpenBSD area: 0-2236704; size: 2236704; free: 0
#size   offset  fstype [fsize bsize   cpg]
   a:  22367040  4.2BSD   2048 16384 1
   c:  22367040  unused
cd0> q
No label changes.

The same drive can be formatted and used on Mac OS X.

Thanks and best regards,
Siegfried


Did you try 2K blocks? The low level of CDROM only works that way.

Re: Write to DVD-RAM

[Stefan Sperling]

On Thu, Jul 25, 2019 at 10:19:11AM +0800, Zhi-Qiang Lei wrote:
> Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my 
> OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the 
> drive. Did I miss something?
> 
> $ dmesg | grep cd
> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
> removable serial.13fd3940302020202020
> cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
> removable serial.13fd3940302020202020
> 
> $ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k 
>   
>   
> dd: /dev/rcd0c: Invalid argument
> 1+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000 secs (0 bytes/sec)
> 
> $ doas disklabel -E cd0
> cd0> a
> partition: [a] 
> offset: [0] 
> size: [2236704] 
> FS type: [4.2BSD] 
> cd0> w
> cd0> p
> OpenBSD area: 0-2236704; size: 2236704; free: 0
> #size   offset  fstype [fsize bsize   cpg]
>   a:  22367040  4.2BSD   2048 16384 1 
>   c:  22367040  unused
> cd0> q
> No label changes.
> 
> The same drive can be formatted and used on Mac OS X.

Try growisofs from sysutils/dvd+rw-tools in ports.

Write to DVD-RAM

[Zhi-Qiang Lei]

Hi, I’m trying to encrypt a DVD-RAM before putting some files onto it on my 
OpenBSD 6.5 desktop. But neither dd nor disklabel seems able to work on the 
drive. Did I miss something?

$ dmesg | grep cd
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020
cd0 at scsibus3 targ 1 lun 0:  ATAPI 5/cdrom 
removable serial.13fd3940302020202020

$ doas dd if=/dev/urandom of=/dev/rcd0c bs=1k   

  
dd: /dev/rcd0c: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000 secs (0 bytes/sec)

$ doas disklabel -E cd0
cd0> a
partition: [a] 
offset: [0] 
size: [2236704] 
FS type: [4.2BSD] 
cd0> w
cd0> p
OpenBSD area: 0-2236704; size: 2236704; free: 0
#size   offset  fstype [fsize bsize   cpg]
  a:  22367040  4.2BSD   2048 16384 1 
  c:  22367040  unused
cd0> q
No label changes.

The same drive can be formatted and used on Mac OS X.

Thanks and best regards,
Siegfried

Re: 4GB RAM too little for Firefox?

[Dumitru Moldovan]

On Sat, Jul 06, 2019 at 01:10:08PM +0200, Richard Ulmer wrote:


I have a desktop from 2009 with 8GB of RAM and faced a similar issue
with recent Firefox versions.  For me, the problem was two-fold:

  1. Recent Firefox versions start 8 rendering processes for my system
  with 2 CPUs.  I limited this in the preferences to just 2, ending up
  with a total of 4 firefox processes at all times.

You are refering to the "Content process limit" option in about:preferences,
right? I haven't changed it and it was still at 8. I set it to 2 and compared
the memory usage with the script I mentioned before. Memory usage went from
1474M to 1188M. That's a 20% improvement, not too bad, but will probably not
stop my computer from swapping. Thanks for the tip, I'll keep this setting!


Beware that a setting of 2 might hurt responsiveness too much, which
translates into hiccups of 1-3 seconds, during which Firefox is
unresponsive.  I've settled for 4 on my old system with 8GB of RAM and
a dual-core CPU.

One more thing I've discovered in the mean time...  I use Deezer, which
is one of those heavy web apps that can't be replaced without lots of
hacking and reverse-engineering.  So what I do to alleviate the RAM
leaks is to refresh the deezer.com web app with Ctrl-Shift-R from time
to time.  Once every few hours, this frees lots of RAM from a couple of
Firefox processes, usually about 2GB.  YMMV

Re: 4GB RAM too little for Firefox?

[ropers]

On 10/07/2019, ropers  wrote:
> [1] Strictly by way of loose comparison: Just because unlinked and
> fclose'd files may be well and truly gone from the disk by the time
> you use foremost to search for them
> , [that] doesn't mean that foremost's
> ability to sometimes still recover what you want is useless either.
> Post-unlink recovery-enabling features have their uses; one just
> should rely on them working 100% of the time.

Argh! I of course meant to say, "one just SHOULDN'T rely on them
working 100% of the time."

Sorry about that.

Re: 4GB RAM too little for Firefox?

[Marc Espie]

On Wed, Jul 10, 2019 at 09:52:02AM +0200, ropers wrote:
> I wouldn't say the file name information is "meaningless". On Linux,
> if a program opened and then unlinked a file, but you still remember
> the file name,
> then you can still find the file by grepping for its former name,
> because the system remembers that too, so long as it's not been
  ^

That's not guaranteed by the Unix API.

It's an extra convenience Linux gives you.

Don't be mistaken, it is a trade-off, remembering that name uses extra
kernel memory.

Re: 4GB RAM too little for Firefox?

[ropers]

On 10/07/2019, Marc Espie  wrote:
> On Tue, Jul 09, 2019 at 11:16:24PM +0200, ropers wrote:
>> On 09/07/2019, Stuart Henderson  wrote:
>> > The lsof port didn't display filenames. That information is not
>> > available on OpenBSD (and is not trustworthy on other OS either;
>> > files could have been moved/replaced since opening).
>>
>> Interesting. Thanks.
>> Is the (un)availability of filename info a feature of the filesystem
>> (ext2/3/etc vs FFS) or of the OS?
>> Are there security implications to this info being available/unavailable?
>
> This information is actually meaningless, on *any* Unix-like OS.
>
> You've got data on the disk. That data is accessible through a file
> descriptor. That file descriptor may or may not correspond to a file name.
>
> The following is perfectly okay in unix:
>
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> unlink("/tmp/myfile");
>
> there. You've got a fd with no name attached to it.
>
> similarly:
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> rename("/tmp/myfile", "/tmp/myfile2");
>
> there.  What's the fd name ?
>
> or
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> link("/tmp/myfile", "/tmp/myfile2");
>
> do you return myfile or myfile2 ?
>
> you could keep some correspondence between fds and file names, but it
> might get out of date, or be meaningless.
>
> You've got this one feature: fstat(2) will give you
>  dev_t  st_dev;/* inode's device */
>  ino_t  st_ino;/* inode's number */
> from which you could walk the device and retrieve things
> (and actually it's very useful to uniquely identify files on a system)
>
> And also, there's no guarantee that what information you determine will
> be valid for any amount of time, as files may be renamed.
>
> Guess what ? This is exactly the info fstat(1) displays. And not more,
> with the exact same caveats in its manpage, though in terser fashion.

I wouldn't say the file name information is "meaningless". On Linux,
if a program opened and then unlinked a file, but you still remember
the file name,
then you can still find the file by grepping for its former name,
because the system remembers that too, so long as it's not been
fclose'd yet -- subject to "terms and conditions" like you describe.
We could perhaps think of the former filename as metadata about the
inode; metadata that might or might not get obsoleted before the file
is fclose'd.
It's not a useless feature, but it won't save your bacon in all cases,
because like you showed us above, the system might have "moved on" and
done something else in the meantime. [1]
Whether this is a feature OpenBSD could also implement I'm not in a
position to say, but that doesn't make the feature useless. I'm just
comparing and contrasting, and this has made things clearer to me,
also thanks to some of the replies here.

Ian

[1] Strictly by way of loose comparison: Just because unlinked and
fclose'd files may be well and truly gone from the disk by the time
you use foremost to search for them
, doesn't mean that foremost's
ability to sometimes still recover what you want is useless either.
Post-unlink recovery-enabling features have their uses; one just
should rely on them working 100% of the time.

Re: 4GB RAM too little for Firefox?

[Marc Espie]

On Tue, Jul 09, 2019 at 11:16:24PM +0200, ropers wrote:
> On 09/07/2019, Stuart Henderson  wrote:
> > The lsof port didn't display filenames. That information is not
> > available on OpenBSD (and is not trustworthy on other OS either;
> > files could have been moved/replaced since opening).
> 
> Interesting. Thanks.
> Is the (un)availability of filename info a feature of the filesystem
> (ext2/3/etc vs FFS) or of the OS?
> Are there security implications to this info being available/unavailable?

This information is actually meaningless, on *any* Unix-like OS.

You've got data on the disk. That data is accessible through a file
descriptor. That file descriptor may or may not correspond to a file name.

The following is perfectly okay in unix:

fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
unlink("/tmp/myfile");

there. You've got a fd with no name attached to it.

similarly:
fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
rename("/tmp/myfile", "/tmp/myfile2");

there.  What's the fd name ?

or
fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
link("/tmp/myfile", "/tmp/myfile2");

do you return myfile or myfile2 ?

you could keep some correspondence between fds and file names, but it
might get out of date, or be meaningless.

You've got this one feature: fstat(2) will give you 
 dev_t  st_dev;/* inode's device */
 ino_t  st_ino;/* inode's number */
from which you could walk the device and retrieve things
(and actually it's very useful to uniquely identify files on a system)

And also, there's no guarantee that what information you determine will
be valid for any amount of time, as files may be renamed.

Guess what ? This is exactly the info fstat(1) displays. And not more,
with the exact same caveats in its manpage, though in terser fashion.

Re: 4GB RAM too little for Firefox?

[ropers]

> On 2019-07-09, ropers  wrote:
>> Just for the record, I think *my* (not the OP's) problem when trying
>> to grep fstat results was that unlike lsof, fstat didn't show the
>> former file names (hence unlinked); it only showed inodes, so I never
>> got the "find this former file" part to work on OpenBSD.
>> I have since found this blog post, where your man seems to have had
>> the same problem, and where he had written a script with ncheck_ffs(8)
>> to hack his way around that. That's a 13 year-old post though, and I
>> haven't tried it:
>> http://geek00l.blogspot.com/2006/03/openbsd-fstat-vs-lsof.html
>> There used to be an OpenBSD lsof port, as per what's listed on
>> ports.su, but there's no amd64 package now, and I never got that port
>> to work either.

On 09/07/2019, Stuart Henderson  wrote:
> The lsof port didn't display filenames. That information is not
> available on OpenBSD (and is not trustworthy on other OS either;
> files could have been moved/replaced since opening).

Interesting. Thanks.
Is the (un)availability of filename info a feature of the filesystem
(ext2/3/etc vs FFS) or of the OS?
Are there security implications to this info being available/unavailable?

regards,
Ian

Re: 4GB RAM too little for Firefox?

[Stuart Henderson]

On 2019-07-09, ropers  wrote:
> Just for the record, I think *my* (not the OP's) problem when trying
> to grep fstat results was that unlike lsof, fstat didn't show the
> former file names (hence unlinked); it only showed inodes, so I never
> got the "find this former file" part to work on OpenBSD.
> I have since found this blog post, where your man seems to have had
> the same problem, and where he had written a script with ncheck_ffs(8)
> to hack his way around that. That's a 13 year-old post though, and I
> haven't tried it:
> http://geek00l.blogspot.com/2006/03/openbsd-fstat-vs-lsof.html
> There used to be an OpenBSD lsof port, as per what's listed on
> ports.su, but there's no amd64 package now, and I never got that port
> to work either.

The lsof port didn't display filenames. That information is not
available on OpenBSD (and is not trustworthy on other OS either;
files could have been moved/replaced since opening).

Re: 4GB RAM too little for Firefox?

[ropers]

Just for the record, I think *my* (not the OP's) problem when trying
to grep fstat results was that unlike lsof, fstat didn't show the
former file names (hence unlinked); it only showed inodes, so I never
got the "find this former file" part to work on OpenBSD.
I have since found this blog post, where your man seems to have had
the same problem, and where he had written a script with ncheck_ffs(8)
to hack his way around that. That's a 13 year-old post though, and I
haven't tried it:
http://geek00l.blogspot.com/2006/03/openbsd-fstat-vs-lsof.html
There used to be an OpenBSD lsof port, as per what's listed on
ports.su, but there's no amd64 package now, and I never got that port
to work either.
Still, if someone were determined and actually competent, maybe some
of this info could help in similar situations.

Ian

On 08/07/2019, Todd C. Miller  wrote:
> On Mon, 08 Jul 2019 15:59:54 -0400, Allan Streib wrote:
>
>> It does behave like the file is opened and then unlinked. Sorry for my
>> term "ghost" file I couldn't quite find the right words for what I was
>> seeing.
>
> You can use the fstat command to find these files (even if unlinked)
> as well as the ID of the process that has them open.  For example:
>
> fstat -f /tmp
>
>  - todd
>

Re: 4GB RAM too little for Firefox?

[Todd C . Miller]

On Mon, 08 Jul 2019 15:59:54 -0400, Allan Streib wrote:

> It does behave like the file is opened and then unlinked. Sorry for my
> term "ghost" file I couldn't quite find the right words for what I was
> seeing.

You can use the fstat command to find these files (even if unlinked)
as well as the ID of the process that has them open.  For example:

fstat -f /tmp

 - todd

Re: 4GB RAM too little for Firefox?

[Allan Streib]

ropers  writes:

> 1. I think the same behaviour may be what's going on with your
> so-called "ghost" files.
> I.e.: Files and file descriptors get created, the files get unlinked,
> but Firefox still has them open and *is still growing* them, which
> continues until it actually fclose(3)s them.

Yes, this is the behavior. They are not "dot-files" or any other
obscured file name, as du(1) should find those, and nothing that would
account for the space is found in the output of "ls -alR /tmp" either.

It does behave like the file is opened and then unlinked. Sorry for my
term "ghost" file I couldn't quite find the right words for what I was
seeing.

Allan

Re: 4GB RAM too little for Firefox?

[ropers]

On 08/07/2019, Allan Streib  wrote:
> I have recently encountered another issue with firefox, that is it will
> fill up my /tmp partition with "ghost" files. Meaning, df(1) (and other
> applications) will tell me that my 4GB /tmp is full, but I don't see any
> files there and du(1) will say that /tmp only has 18KB used. If I kill
> firefox, the /tmp space becomes available again.
>
> Have not yet identified which site is triggering this behavior, but I
> suspect it's one of Gmail, Google Sheets, etc which I tend to have open
> for long periods of time.
>
> OpenBSD 6.5 GENERIC.MP#1 amd64
>
> Landry's FF build (67.0.4) with uBlock Origin.
>
> Allan

When you say, "ghost" files, you're not referring to mere dot-files, right?

I wonder if the following observations I made even a few years back
are sort of relevant here:

It used to be that when Firefox's Flash plugin (remember that?) for
Unix-likes used to buffer content like a video for example, that
content was saved as a file in /tmp, and it used to be possible to
easily find such files and e.g. pipe them to vlc or swfdec if the
corresponding online Flash media player was too decrepit. I'm not sure
when those files ultimately used to get deleted back then; maybe on
tab close or on browser restart, certainly on reboot.

However, later on, Firefox changed things so that it would unlink any
such files about as soon as it created them, even while still
appending data to them, by keeping (just) the file descriptor in
memory. On Linux, people could do lsof(8) and grep(1) shenanigans to
copy/recreate the file descriptor out of /dev, and thus resurrect the
file, so long as it was still open. OpenBSD uses fstat(1) instead of lsof,
and I never got those shenanigans to work on OpenBSD.

Similarly, when Firefox used to download files and downloads got
interrupted, Firefox used to always keep those partially downloaded
files, but I've now seen it at least on some recent versions that
those too are deleted, at least as soon as a download fails. At that
point I think the files are fully closed; I don't think I've been able
to recover anything there, not even with lsof on Linux.

Why am I telling you all this?

1. I think the same behaviour may be what's going on with your
so-called "ghost" files.
I.e.: Files and file descriptors get created, the files get unlinked,
but Firefox still has them open and *is still growing* them, which
continues until it actually fclose(3)s them.

2. I do seem to observe a bit of an anti-usability trend here, because
of course prematurely unlinking the files DOESN'T save any disk space,
but it DOES make it harder for users, sysadmins and add-on authors to
manage (pipe, copy, script-process, download-resume and reuse) such
files themselves.
This may be reflective of a wider struggle for control of computers
that we, ostensibly, own -- and ought to control. It jibes with the
increasing trend towards the point where, like Michael Sims put it, if
the desires of remote corporations "conflict with the desires of you,
the owner of the computer, their desires win."[1]
IMNSHO, Mozilla, and others, have largely fallen prey to regulatory
capture,[2] i.e. they're the "regulators", and they've been *captured*
by corporations paying their employees to help out FOSS for
free^W^W^W^W^W inject their desires, corporate philosophy and bad
ideas until their desires win -- possibly without the people pushing
such changed agendas and bad ideas onto the FOSSverse even realising
what they're doing, which is the ultimate in plausible deniability.
Because seriously, why would you unlink files prematurely? Files that
you're continuing to grow? Is there any reason other than you want to
keep things hidden from, and out of the hands of dirty, dirty, pleb
users who had better pay a tax to you every time they click play?[3]

Remember, DRM and DRM-like designs exist to stop you from doing things
that are ALLOWED by copyright. On this, also *vide* Sims.

Sorry for the sermon. I felt it was at least relevant.

Ian

PS: Firefox also has increasingly taken to turning things that used to
be more easily understandable and discoverable files into databases.
I'm sure they had only excellent reasons and no obscurantist agenda...

PPS: Of course, it's not just Firefox/Mozilla; it's just that it's
particularly noticeable with those, because you would expect better
from them -- or maybe *you* wouldn't, but I used to.

[1] https://www.youtube.com/watch?v=VAR42TMIhoU=14m20s
[2] https://en.wikipedia.org/wiki/Regulatory_capture
[3] https://en.wikipedia.org/wiki/Rent-seeking

Re: 4GB RAM too little for Firefox?

[Allan Streib]

Richard Ulmer  writes:

> I heard multiple times now, that Firefox leaks memory. Maybe I'll give
> a new browser a shot. Iridium looked interesting, but upon research I
> found a lot of people concerned about whether this project has the
> resources to keep up with Chromiums security standards. The last
> commit for Iridium was 3 Months ago [1], so I'm not to sure if I want
> to use it..

I have recently encountered another issue with firefox, that is it will
fill up my /tmp partition with "ghost" files. Meaning, df(1) (and other
applications) will tell me that my 4GB /tmp is full, but I don't see any
files there and du(1) will say that /tmp only has 18KB used. If I kill
firefox, the /tmp space becomes available again.

Have not yet identified which site is triggering this behavior, but I
suspect it's one of Gmail, Google Sheets, etc which I tend to have open
for long periods of time.

OpenBSD 6.5 GENERIC.MP#1 amd64

Landry's FF build (67.0.4) with uBlock Origin.

Allan

Re: 4GB RAM too little for Firefox?

[Heppler, J. Scott]

Richard Ulmar wrote

Iridium looked interesting, but upon research
I found a lot of people concerned about whether this project has the
resources to keep up with Chromiums security standards. The last commit
for Iridium was 3 Months ago [1], so I'm not to sure if I want to use
it..


Robert Nagy is the OpenBSD ports maintainer for www/iridium and he also
also one of the iridium developers.  As far as iridium lagging Chromium
development, that is largely on the basis of new features rather than
security.  You can check by searching for Chromium cve's and cross
checking with the iridium version.  Unfortunately, there is not a
buildbot for iridium or chromium so you either have to wait for 6.6 to
get the latest version or run -current.  Still, I do not believe it has
any major security issues at this time.

Scott

Re: 4GB RAM too little for Firefox?

[Richard Ulmer]

Hi Dumitru,

Dumitru Moldovan  wrote:
> On Fri, Jul 05, 2019 at 01:25:10PM +0200, Richard Ulmer wrote:
> >Hi all,
> >after having Firefox running for some time (ca. 30min to 2h) my
> >system seems to become slow. I get frequent freezes for several
> >seconds, mpv instances start crashing and things like switching tabs
> >in Firefox become a pain.
> >
> >I've got 4GB of RAM installed and when I look at htop after my system
> >became slow, I can see that OpenBSD started swapping. When I close
> >Firefox it takes several seconds and I can watch how my memory becomes
> >free again in htop. My system is then again responsive.
> >
> >RAM prices seem to be low right now, but I don't want to spend money
> >uneedingly and I didn't have this problem under Linux. Has anyone had
> >similar experieces and noticed an improvement after a RAM upgrade?
> 
> I have a desktop from 2009 with 8GB of RAM and faced a similar issue
> with recent Firefox versions.  For me, the problem was two-fold:
> 
>   1. Recent Firefox versions start 8 rendering processes for my system
>   with 2 CPUs.  I limited this in the preferences to just 2, ending up
>   with a total of 4 firefox processes at all times.
You are refering to the "Content process limit" option in about:preferences,
right? I haven't changed it and it was still at 8. I set it to 2 and compared
the memory usage with the script I mentioned before. Memory usage went from
1474M to 1188M. That's a 20% improvement, not too bad, but will probably not
stop my computer from swapping. Thanks for the tip, I'll keep this setting!

>   2. Web apps have grown in size disproportionally lately.  You
>   mentioned Reddit, their modern web interface is such a RAM-hungry
>   monster.  Consider using old.reddit.com instead or, even better, an
>   app leveraging their API.  In the same vein, replace Gmail with a
>   light IMAP client, use git CLI tools instead of GitHub's web
>   interface, etc.
I already try to avoid slow websites by using dedicated applications
where possible (rtv for most of reddit, mblaze for mail, mpv for YouTube
videos, partly ytools for browsing YouTube). Sill, I often find myself
opening a bunch of StackOverflow, Reddit, Amazon, GitHub, ... pages in
parallel, when I'm researching something.

> Also, beware that Firefox leaks memory, especially with intensive web
> apps.  I usually restart it once a day or so lately.  Another
> workaround for unavoidable monster web apps is to use a dedicated
> Chromium or Iridium instance per web app, eg. for Deezer's web player:
> "iridium --app=https://deezer.com;.
I heard multiple times now, that Firefox leaks memory. Maybe I'll give
a new browser a shot. Iridium looked interesting, but upon research
I found a lot of people concerned about whether this project has the
resources to keep up with Chromiums security standards. The last commit
for Iridium was 3 Months ago [1], so I'm not to sure if I want to use
it..

Greetings and thanks for your input,
Richard


[1] https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/

Re: 4GB RAM too little for Firefox?

[maillists . rulmer]

Hi Jan,

"Jan Betlach"  wrote:
> 
> Richard,
> 
> have you increased the shared memory limits and kern parameters in the 
> sysctl.conf for more relaxed desktop usage?
> 
> Jan
No I have not and I never heard of it. Here is the output of
`sysctl kern.shminfo`:
kern.shminfo.shmmax=33554432
kern.shminfo.shmmin=1
kern.shminfo.shmmni=128
kern.shminfo.shmseg=128
kern.shminfo.shmall=8192

Do you have a link for further reading on this?

Richard

> 
> On 6 Jul 2019, at 10:11, maillists.rul...@mailbox.org wrote:
> 
> > Otto Moerbeek  wrote:
> >> On Sat, Jul 06, 2019 at 09:32:22AM +0200, 
> >> maillists.rul...@mailbox.org wrote:
> >>
> >>> Otto Moerbeek  wrote:
> >>>> You still did not tell which platform you are running. It matters.
> >>>>
> >>>>  -Otto
> >>> I'm using a ThinkPad T450 (i5-5300U, SSD, FullHD Display for which 
> >>> 0.5G
> >>> of the RAM are used by the graphics card). Im running OpenBSD 6.5 
> >>> and
> >>> use full disk encryption (don't know if this matters for swapping
> >>> performance).
> >>>
> >>> Best Regards,
> >>> Richard Ulmer
> >>
> >> That does not tell us the platform. It matters a lot if you are
> >> running i386 or amd64. To make it explcit: what does "uname -p" say?
> >>
> >>-Otto
> > Oh, sorry, platform is amd64.

Re: 4GB RAM too little for Firefox?

[Dumitru Moldovan]

On Fri, Jul 05, 2019 at 01:25:10PM +0200, Richard Ulmer wrote:

Hi all,
after having Firefox running for some time (ca. 30min to 2h) my
system seems to become slow. I get frequent freezes for several
seconds, mpv instances start crashing and things like switching tabs
in Firefox become a pain.

I've got 4GB of RAM installed and when I look at htop after my system
became slow, I can see that OpenBSD started swapping. When I close
Firefox it takes several seconds and I can watch how my memory becomes
free again in htop. My system is then again responsive.

RAM prices seem to be low right now, but I don't want to spend money
uneedingly and I didn't have this problem under Linux. Has anyone had
similar experieces and noticed an improvement after a RAM upgrade?


I have a desktop from 2009 with 8GB of RAM and faced a similar issue
with recent Firefox versions.  For me, the problem was two-fold:

 1. Recent Firefox versions start 8 rendering processes for my system
 with 2 CPUs.  I limited this in the preferences to just 2, ending up
 with a total of 4 firefox processes at all times.

 2. Web apps have grown in size disproportionally lately.  You
 mentioned Reddit, their modern web interface is such a RAM-hungry
 monster.  Consider using old.reddit.com instead or, even better, an
 app leveraging their API.  In the same vein, replace Gmail with a
 light IMAP client, use git CLI tools instead of GitHub's web
 interface, etc.

Also, beware that Firefox leaks memory, especially with intensive web
apps.  I usually restart it once a day or so lately.  Another
workaround for unavoidable monster web apps is to use a dedicated
Chromium or Iridium instance per web app, eg. for Deezer's web player:
"iridium --app=https://deezer.com;.

Re: 4GB RAM too little for Firefox?

[Jan Betlach]

Richard,

have you increased the shared memory limits and kern parameters in the 
sysctl.conf for more relaxed desktop usage?


Jan


On 6 Jul 2019, at 10:11, maillists.rul...@mailbox.org wrote:


Otto Moerbeek  wrote:
On Sat, Jul 06, 2019 at 09:32:22AM +0200, 
maillists.rul...@mailbox.org wrote:



Otto Moerbeek  wrote:

You still did not tell which platform you are running. It matters.

-Otto
I'm using a ThinkPad T450 (i5-5300U, SSD, FullHD Display for which 
0.5G
of the RAM are used by the graphics card). Im running OpenBSD 6.5 
and

use full disk encryption (don't know if this matters for swapping
performance).

Best Regards,
Richard Ulmer


That does not tell us the platform. It matters a lot if you are
running i386 or amd64. To make it explcit: what does "uname -p" say?

-Otto

Oh, sorry, platform is amd64.

Re: 4GB RAM too little for Firefox?

[maillists . rulmer]

Otto Moerbeek  wrote:
> On Sat, Jul 06, 2019 at 09:32:22AM +0200, maillists.rul...@mailbox.org wrote:
> 
> > Otto Moerbeek  wrote:
> > > You still did not tell which platform you are running. It matters.
> > > 
> > >   -Otto
> > I'm using a ThinkPad T450 (i5-5300U, SSD, FullHD Display for which 0.5G
> > of the RAM are used by the graphics card). Im running OpenBSD 6.5 and
> > use full disk encryption (don't know if this matters for swapping
> > performance).
> > 
> > Best Regards,
> > Richard Ulmer
> 
> That does not tell us the platform. It matters a lot if you are
> running i386 or amd64. To make it explcit: what does "uname -p" say?
> 
>   -Otto
Oh, sorry, platform is amd64.

Re: 4GB RAM too little for Firefox?

[Otto Moerbeek]

On Sat, Jul 06, 2019 at 09:32:22AM +0200, maillists.rul...@mailbox.org wrote:

> Otto Moerbeek  wrote:
> > You still did not tell which platform you are running. It matters.
> > 
> > -Otto
> I'm using a ThinkPad T450 (i5-5300U, SSD, FullHD Display for which 0.5G
> of the RAM are used by the graphics card). Im running OpenBSD 6.5 and
> use full disk encryption (don't know if this matters for swapping
> performance).
> 
> Best Regards,
> Richard Ulmer

That does not tell us the platform. It matters a lot if you are
running i386 or amd64. To make it explcit: what does "uname -p" say?

-Otto

Re: 4GB RAM too little for Firefox?

[maillists . rulmer]

Otto Moerbeek  wrote:
> You still did not tell which platform you are running. It matters.
> 
>   -Otto
I'm using a ThinkPad T450 (i5-5300U, SSD, FullHD Display for which 0.5G
of the RAM are used by the graphics card). Im running OpenBSD 6.5 and
use full disk encryption (don't know if this matters for swapping
performance).

Best Regards,
Richard Ulmer

Re: 4GB RAM too little for Firefox?

[Otto Moerbeek]

On Fri, Jul 05, 2019 at 09:21:48PM +0200, maillists.rul...@mailbox.org wrote:

> > OpenBSD derives some security by confining processes and web browsing
> > with firefox is notorious for memory leaks.
> >
> > If you mobo supports it, more ram will also improve performance with
> > firefox and other memory intensive tasks.
> Firefox is pretty much my only memory intensive task. Thanks for sharing
> your opinion, though! One more incentive to buy the new ram stick.
> 
> > Other options:
> >
> > Adding the Firefox "forget" widget to your panel
> > https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-his
> tory
> > and using it frequently.
> That seems more like a workaround to me.
> 
> > Consider www/iridium as an alternative browser.  You can export your
> > firefox bookmarks.html and import it into iridium.  Although I do not
> > have solid numbers, I thought it was better in this regard than firefox.
> I wrote two little scripts [1] that open five reddit.com threads in each
> browser an print memory usage. The result was (besides my amazement
> about how much RAM the browsers ate), that Firefox used up ca. 1.4G and
> Iridium ca. 0.9G. I obviously haven't set up the same extensions, but it
> seems like Iridium would be able to help me. I'm going to try it some
> more. Thanks for the tip!
> 
> Best regards,
> Richard Ulmer
> 
> 
> [1]
> ```
> printf 'Before starting Firefox:\n\t'
> top | grep Memory
> firefox --private-window 2>&1 > /dev/null &
> sleep 5  # Wait for firefox to open
> for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
> firefox --private-window \
> "https://www.reddit.com/r/openbsd/comments/$i;
> done
> sleep 30  # Wait for all tabs to load
> printf 'After starting Firefox:\n\t'
> top | grep Memory
> ```
> 
> ```
> printf 'Before starting Iridium:\n\t'
> top | grep Memory
> iridium --incognito 2>&1 > /dev/null &
> sleep 5  # Wait for Iridium to open
> for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
> iridium --incognito \
> "https://www.reddit.com/r/openbsd/comments/$i;
> done
> sleep 30  # Wait for all tabs to load
> printf 'After starting Iridium:\n\t'
> top | grep Memory
> ```
> 

You still did not tell which platform you are running. It matters.

-Otto

Re: 4GB RAM too little for Firefox?

[maillists . rulmer]

> OpenBSD derives some security by confining processes and web browsing
> with firefox is notorious for memory leaks.
>
> If you mobo supports it, more ram will also improve performance with
> firefox and other memory intensive tasks.
Firefox is pretty much my only memory intensive task. Thanks for sharing
your opinion, though! One more incentive to buy the new ram stick.

> Other options:
>
> Adding the Firefox "forget" widget to your panel
> https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-his
tory
> and using it frequently.
That seems more like a workaround to me.

> Consider www/iridium as an alternative browser.  You can export your
> firefox bookmarks.html and import it into iridium.  Although I do not
> have solid numbers, I thought it was better in this regard than firefox.
I wrote two little scripts [1] that open five reddit.com threads in each
browser an print memory usage. The result was (besides my amazement
about how much RAM the browsers ate), that Firefox used up ca. 1.4G and
Iridium ca. 0.9G. I obviously haven't set up the same extensions, but it
seems like Iridium would be able to help me. I'm going to try it some
more. Thanks for the tip!

Best regards,
Richard Ulmer


[1]
```
printf 'Before starting Firefox:\n\t'
top | grep Memory
firefox --private-window 2>&1 > /dev/null &
sleep 5  # Wait for firefox to open
for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
firefox --private-window \
"https://www.reddit.com/r/openbsd/comments/$i;
done
sleep 30  # Wait for all tabs to load
printf 'After starting Firefox:\n\t'
top | grep Memory
```

```
printf 'Before starting Iridium:\n\t'
top | grep Memory
iridium --incognito 2>&1 > /dev/null &
sleep 5  # Wait for Iridium to open
for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
iridium --incognito \
"https://www.reddit.com/r/openbsd/comments/$i;
done
sleep 30  # Wait for all tabs to load
printf 'After starting Iridium:\n\t'
top | grep Memory
```

Re: 4GB RAM too little for Firefox?

[maillists . rulmer]

> OpenBSD derives some security by confining processes and web browsing
> with firefox is notorious for memory leaks.
> 
> If you mobo supports it, more ram will also improve performance with
> firefox and other memory intensive tasks.
Firefox is pretty much my only memory intensive task. Thanks for sharing
your opinion, though! One more incentive to buy the new ram stick.

> Other options:
> 
> Adding the Firefox "forget" widget to your panel
> https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-history
> and using it frequently.
That seems more like a workaround to me. 

> Consider www/iridium as an alternative browser.  You can export your
> firefox bookmarks.html and import it into iridium.  Although I do not
> have solid numbers, I thought it was better in this regard than firefox.
I wrote two little scripts [1] that open five reddit.com threads in each
browser an print memory usage. The result was (besides my amazement
about how much RAM the browsers ate), that Firefox used up ca. 1.4G and
Iridium ca. 0.9G. I obviously haven't set up the same extensions, but it
seems like Iridium would be able to help me. I'm going to try it some
more. Thanks for the tip!

Best regards,
Richard Ulmer


[1]
```
printf 'Before starting Firefox:\n\t'
top | grep Memory
firefox --private-window 2>&1 > /dev/null &
sleep 5  # Wait for firefox to open
for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
firefox --private-window \
"https://www.reddit.com/r/openbsd/comments/$i;
done
sleep 30  # Wait for all tabs to load
printf 'After starting Firefox:\n\t'
top | grep Memory
```

```
printf 'Before starting Iridium:\n\t'
top | grep Memory
iridium --incognito 2>&1 > /dev/null &
sleep 5  # Wait for Iridium to open
for i in c48qg7 c916tf c5n06b c0yvsz c2sco0; do
iridium --incognito \
"https://www.reddit.com/r/openbsd/comments/$i;
done
sleep 30  # Wait for all tabs to load
printf 'After starting Iridium:\n\t'
top | grep Memory
```

Re: 4GB RAM too little for Firefox?

[lists]

Fri, 5 Jul 2019 08:09:26 -0700 "Heppler, J. Scott"

> Richard Ulmer wrote:
> > Hi all,
> > after having Firefox running for some time (ca. 30min to 2h) my
> > system seems to become slow. I get frequent freezes for several
> > seconds, mpv instances start crashing and things like switching tabs
> > in Firefox become a pain.
> > 
> > I've got 4GB of RAM installed and when I look at htop after my system
> > became slow, I can see that OpenBSD started swapping. When I close
> > Firefox it takes several seconds and I can watch how my memory becomes
> > free again in htop. My system is then again responsive.
> > 
> > RAM prices seem to be low right now, but I don't want to spend money
> > uneedingly and I didn't have this problem under Linux. Has anyone had
> > similar experieces and noticed an improvement after a RAM upgrade?  
> 
> OpenBSD derives some security by confining processes and web browsing
> with firefox is notorious for memory leaks.
> 
> If you mobo supports it, more ram will also improve performance with
> firefox and other memory intensive tasks.
> 
> Other options:
> 
> Adding the Firefox "forget" widget to your panel
> https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-history
> and using it frequently.
> 
> Under preference disable access to webcams, microphone etc.
> 
> Consider www/iridium as an alternative browser.  You can export your
> firefox bookmarks.html and import it into iridium.  Although I do not
> have solid numbers, I thought it was better in this regard than firefox.
> 

Since you did not attach a single digit, number or figure, as measures of
comparison, consider the above information opinion only and nothing more.
In fact, if you switch the names of the programs, you cannot even notice.
Try to be more specific, at least compare the memory usage: show numbers.
Such fine advice, wasted over the simplest lack of information objection.

Re: 4GB RAM too little for Firefox?

[Heppler, J. Scott]

Richard Ulmer wrote:

Hi all,
after having Firefox running for some time (ca. 30min to 2h) my
system seems to become slow. I get frequent freezes for several
seconds, mpv instances start crashing and things like switching tabs
in Firefox become a pain.

I've got 4GB of RAM installed and when I look at htop after my system
became slow, I can see that OpenBSD started swapping. When I close
Firefox it takes several seconds and I can watch how my memory becomes
free again in htop. My system is then again responsive.

RAM prices seem to be low right now, but I don't want to spend money
uneedingly and I didn't have this problem under Linux. Has anyone had
similar experieces and noticed an improvement after a RAM upgrade?


OpenBSD derives some security by confining processes and web browsing
with firefox is notorious for memory leaks.

If you mobo supports it, more ram will also improve performance with
firefox and other memory intensive tasks.

Other options:

Adding the Firefox "forget" widget to your panel
https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-history
and using it frequently.

Under preference disable access to webcams, microphone etc.

Consider www/iridium as an alternative browser.  You can export your
firefox bookmarks.html and import it into iridium.  Although I do not
have solid numbers, I thought it was better in this regard than firefox.

--
J. Scott Heppler

4GB RAM too little for Firefox?

[Richard Ulmer]

Hi all,
after having Firefox running for some time (ca. 30min to 2h) my
system seems to become slow. I get frequent freezes for several
seconds, mpv instances start crashing and things like switching tabs
in Firefox become a pain.

I've got 4GB of RAM installed and when I look at htop after my system
became slow, I can see that OpenBSD started swapping. When I close
Firefox it takes several seconds and I can watch how my memory becomes
free again in htop. My system is then again responsive.

RAM prices seem to be low right now, but I don't want to spend money
uneedingly and I didn't have this problem under Linux. Has anyone had
similar experieces and noticed an improvement after a RAM upgrade?

Greetings
Richard Ulmer

Re: OpenBSD runs only in RAM from a USB Flash Drive

[Kevin Chadwick]

>FFS isn't a journaling filesystem so any 'wear', even on primitive
>flash storage, won't be enough to worry about.

I disagree, depending on a few variables. If you can't get a better device then 
be prepared to replace the storage or count writes and create new files, 
keeping the old. KARL and randomness development depends on writing and 
shouldn't be disabled.

There is a lot of misinformation about flash out there from fairly respectable 
people too. Maybe because phones are also in the close our eyes and hope 
brigade.

Re: OpenBSD runs only in RAM from a USB Flash Drive

[KAWAMATA Yoshihiro]

Hi,

From: sove...@vivaldi.net
Subject: OpenBSD runs only in RAM from a USB Flash Drive
Date: Thu, 30 May 2019 17:40:11 -0700
Message-ID: <24f3d709e54642fefb33ae3afab7b...@vivaldi.net>

> In order to minimize wear on the USB Flash memory, is there a way to
> command OpenBSD to always run in RAM, and at shutdown to either save
> or not save the session to the USB Flash Drive.

Try FuguIta - http://fuguita.org/
This is the live system based on OpenBSD.

It has several boot mode.

FuguIta mounts USB flash memory with read only.
Or it places the entire file tree on TMPFS memory file system.

Also, you can save your session and can retrieve at next boot time.

It may be similar to Puppy's concept.


Regards,

Yoshihiro KAWAMATA

Re: OpenBSD runs only in RAM from a USB Flash Drive

[Patrick Harper]

FFS isn't a journaling filesystem so any 'wear', even on primitive flash 
storage, won't be enough to worry about.

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 31 May 2019, at 03:41, sove...@vivaldi.net wrote:
> 30 May, 2019
> 
> Greetings OpenBSD aficionados,
> 
> As a newbie to OpenBSD, I am delighted to have the chance to interact 
> with the OpenBSD Mailing Lists community.
> Since I am about to install OpenBSD 6.5 (amd64) on a USB Flash Drive for 
> the first time, I was wondering if anyone has a solution to the 
> following conundrum.
> 
> In order to minimize wear on the USB Flash memory, is there a way to 
> command OpenBSD to always run in RAM, and at shutdown to either save or 
> not save the session to the USB Flash Drive.
> 
> For instance, Precise Puppy Linux 5.7.1 has a package called Puppy Event 
> Manager. Since Precise Puppy is programmed to run in RAM, you can select 
> the 'Save Session' tab and enter the span of minutes for everything in 
> RAM to be saved to the Precise Puppy SaveFile.
> 
> Best of all, you can enter 0 minutes to only do a save at shutdown. 
> Perfect for minimizing wear on a USB Flash Drive.
> 
> Please accept my apologies if this issue has already been solved. My 
> search so far in sites like https://marc.info has come up empty.
> 
> I thank you for your support.
> 
> Best regards,
> Hugh
> 
>

Re: OpenBSD runs only in RAM from a USB Flash Drive

[Jan Stary]

On May 30 17:40:11, sove...@vivaldi.net wrote:
> As a newbie to OpenBSD, I am delighted to have the chance to interact with
> the OpenBSD Mailing Lists community.
> Since I am about to install OpenBSD 6.5 (amd64) on a USB Flash Drive for the
> first time, I was wondering if anyone has a solution to the following
> conundrum.

Why? If this is your first OpenBSD installation,
keep it simple: install on a spare computer.

Do you need to have a portable installation
that you can carry around?

> In order to minimize wear on the USB Flash memory, is there a way to command
> OpenBSD to always run in RAM, and at shutdown to either save or not save the
> session to the USB Flash Drive.

Don't. A USB flash is a disk, just like any other disk.
Install on it like you would on any other disk.

> For instance, Precise Puppy Linux 5.7.1 has a package called Puppy Event
> Manager. Since Precise Puppy is programmed to run in RAM, you can select the
> 'Save Session' tab and enter the span of minutes for everything in RAM to be
> saved to the Precise Puppy SaveFile.
> Best of all, you can enter 0 minutes to only do a save at shutdown. Perfect
> for minimizing wear on a USB Flash Drive.

What 'wear'? What heavy IO are you going to be doing
on your usb flash installation? If you plan to do heavy io,
using USB flash is a mistake in the first place.

Jan