i386 RAMDISK shrinkage suggestion

[Alexey Suslikov]

Hello tech@.

I do believe i386/amd64 RAMDISKs are destined to more or
less mainstream hardware and ISA CGA, MDA, EGA, HGA
stuff isn't there anymore.

So on i386 RAMDISK (like amd64 one), I suggest to remove

pcdisplay0 at isa?
wsdisplay* at pcdisplay?

sys/arch/i386/conf/RAMDISK:

pckbc0 at isa? # PC keyboard controller
pckbd* at pckbc? # PC keyboard
wskbd* at pckbd? mux 1
vga0 at isa?
vga* at pci?
pcdisplay0 at isa? # CGA, MDA, EGA, HGA
wsdisplay* at vga?
wsdisplay* at pcdisplay?

sys/arch/amd64/conf/RAMDISK:

pckbc0 at isa? # PC keyboard controller
pckbd* at pckbc? # PC keyboard
wskbd* at pckbd? mux 1
vga0 at isa?
vga* at pci?
wsdisplay* at vga?

Alexey

[Theo de Raadt]

> I do believe i386/amd64 RAMDISKs are destined to more or
> less mainstream hardware and ISA CGA, MDA, EGA, HGA
> stuff isn't there anymore.
>
> So on i386 RAMDISK (like amd64 one), I suggest to remove
>
> pcdisplay0 at isa?
> wsdisplay* at pcdisplay?
>
> sys/arch/i386/conf/RAMDISK:
>
> pckbc0 at isa? # PC keyboard controller
> pckbd* at pckbc? # PC keyboard
> wskbd* at pckbd? mux 1
> vga0 at isa?
> vga* at pci?
> pcdisplay0 at isa? # CGA, MDA, EGA, HGA
> wsdisplay* at vga?
> wsdisplay* at pcdisplay?
>
> sys/arch/amd64/conf/RAMDISK:
>
> pckbc0 at isa? # PC keyboard controller
> pckbd* at pckbc? # PC keyboard
> wskbd* at pckbd? mux 1
> vga0 at isa?
> vga* at pci?
> wsdisplay* at vga?

You obviously didn't test your changes.

[Martin Schröder]

2009/10/28 Alexey Suslikov <alexey.suslikov@...>:
> So on i386 RAMDISK (like amd64 one), I suggest to remove

If it ain't broke, don't fix it.

Best
    Martin

[Theo de Raadt]

I am going to revisit this.

> I do believe i386/amd64 RAMDISKs are destined to more or
> less mainstream hardware and ISA CGA, MDA, EGA, HGA
> stuff isn't there anymore.
>
> So on i386 RAMDISK (like amd64 one), I suggest to remove
>
> pcdisplay0 at isa?
> wsdisplay* at pcdisplay?

This breaks machines that really do exist out there.

2200    44      88      2332    91c     GENERIC/pcdisplay.o
135     1064    0       1199    4af     GENERIC/pcdisplay_chars.o
907     0       0       907     38b     GENERIC/pcdisplay_subr.o

> sys/arch/i386/conf/RAMDISK:
>
> pckbc0 at isa? # PC keyboard controller
> pckbd* at pckbc? # PC keyboard
> wskbd* at pckbd? mux 1
> vga0 at isa?
> vga* at pci?
> pcdisplay0 at isa? # CGA, MDA, EGA, HGA
> wsdisplay* at vga?
> wsdisplay* at pcdisplay?

This breaks 99% of i386 machines, ie. every machine that has either
a pci vga display or a non-usb keyboard.

> sys/arch/amd64/conf/RAMDISK:
>
> pckbc0 at isa? # PC keyboard controller
> pckbd* at pckbc? # PC keyboard
> wskbd* at pckbd? mux 1
> vga0 at isa?
> vga* at pci?
> wsdisplay* at vga?

This breaks 99% of amd64 machines, ie. every machine that has either
a pci vga display or a non-usb keyboard.

In the last week alone, *two* people mailed in dmesg's that have isa
vga adapters.  You are living in a fantasy if you think that
restricting hardware support like that helps anyone.

[Henning Brauer-5]

* Alexey Suslikov <alexey.suslikov@...> [2009-10-28 23:40]:
> pckbc0 at isa? # PC keyboard controller

yeah, that is a good idea.
who cares about internal keyboards on laptops anyway.

--
Henning Brauer, hb@..., henning@...
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

[Alexey Suslikov]

On Thu, Oct 29, 2009 at 01:08, Theo de Raadt <deraadt@...> wrote:

> I am going to revisit this.
>
>> I do believe i386/amd64 RAMDISKs are destined to more or
>> less mainstream hardware and ISA CGA, MDA, EGA, HGA
>> stuff isn't there anymore.
>>
>> So on i386 RAMDISK (like amd64 one), I suggest to remove
>>
>> pcdisplay0 at isa?
>> wsdisplay*    at pcdisplay?
>
> This breaks machines that really do exist out there.
>
> 2200    44      88      2332    91c     GENERIC/pcdisplay.o
> 135     1064    0       1199    4af     GENERIC/pcdisplay_chars.o
> 907     0       0       907     38b     GENERIC/pcdisplay_subr.o
>
>> sys/arch/i386/conf/RAMDISK:
>>
>> pckbc0                at isa?                 # PC keyboard controller
>> pckbd*                at pckbc?               # PC keyboard
>> wskbd*                at pckbd? mux 1
>> vga0          at isa?
>> vga*          at pci?
>> pcdisplay0    at isa?                 # CGA, MDA, EGA, HGA
>> wsdisplay*    at vga?
>> wsdisplay*    at pcdisplay?
>
> This breaks 99% of i386 machines, ie. every machine that has either
> a pci vga display or a non-usb keyboard.
>
>> sys/arch/amd64/conf/RAMDISK:
>>
>> pckbc0                at isa?         # PC keyboard controller
>> pckbd*                at pckbc?       # PC keyboard
>> wskbd*                at pckbd? mux 1
>> vga0          at isa?
>> vga*          at pci?
>> wsdisplay*    at vga?
>
> This breaks 99% of amd64 machines, ie. every machine that has either
> a pci vga display or a non-usb keyboard.

Well, I'm a bit disappointed.

1.49 of sys/arch/amd64/conf/RAMDISK does not contain
pcdisplay0.

> In the last week alone, *two* people mailed in dmesg's that have isa
> vga adapters.  You are living in a fantasy if you think that
> restricting hardware support like that helps anyone.

I told about removing pcdisplay0 at isa?, not vga0 at isa?

Searching over bugs@ mail archives shows no fresh
dmesgs with pcdisplay0.

Alexey

[Theo de Raadt]

> On Thu, Oct 29, 2009 at 01:08, Theo de Raadt <deraadt@...> wrote:
> > I am going to revisit this.
> >
> >> I do believe i386/amd64 RAMDISKs are destined to more or
> >> less mainstream hardware and ISA CGA, MDA, EGA, HGA
> >> stuff isn't there anymore.
> >>
> >> So on i386 RAMDISK (like amd64 one), I suggest to remove
> >>
> >> pcdisplay0 at isa?
> >> wsdisplay*    at pcdisplay?
> >
> > This breaks machines that really do exist out there.
> >
> > 2200    44      88      2332    91c     GENERIC/pcdisplay.o
> > 135     1064    0       1199    4af     GENERIC/pcdisplay_chars.o
> > 907     0       0       907     38b     GENERIC/pcdisplay_subr.o
> >
> >> sys/arch/i386/conf/RAMDISK:
> >>
> >> pckbc0                at isa?                 # PC keyboard controller
> >> pckbd*                at pckbc?               # PC keyboard
> >> wskbd*                at pckbd? mux 1
> >> vga0          at isa?
> >> vga*          at pci?
> >> pcdisplay0    at isa?                 # CGA, MDA, EGA, HGA
> >> wsdisplay*    at vga?
> >> wsdisplay*    at pcdisplay?
> >
> > This breaks 99% of i386 machines, ie. every machine that has either
> > a pci vga display or a non-usb keyboard.
> >
> >> sys/arch/amd64/conf/RAMDISK:
> >>
> >> pckbc0                at isa?         # PC keyboard controller
> >> pckbd*                at pckbc?       # PC keyboard
> >> wskbd*                at pckbd? mux 1
> >> vga0          at isa?
> >> vga*          at pci?
> >> wsdisplay*    at vga?
> >
> > This breaks 99% of amd64 machines, ie. every machine that has either
> > a pci vga display or a non-usb keyboard.
>
> Well, I'm a bit disappointed.
>
> 1.49 of sys/arch/amd64/conf/RAMDISK does not contain
> pcdisplay0.
>
> > In the last week alone, *two* people mailed in dmesg's that have isa
> > vga adapters.  You are living in a fantasy if you think that
> > restricting hardware support like that helps anyone.
>
> I told about removing pcdisplay0 at isa?, not vga0 at isa?

Your mail was not explicit.  It suggested we remove other things too.

> Searching over bugs@ mail archives shows no fresh
> dmesgs with pcdisplay0.

bugs@ is not the dmesglog.  The private dmesglog people send have
machines which have pre-vga cards.

You think we should simply stop supporting those.  Then those people
would have to run something else.  Or throw them out.

[Alexey Suslikov]

On Thu, Oct 29, 2009 at 09:01, Theo de Raadt <deraadt@...> wrote:
>> On Thu, Oct 29, 2009 at 01:08, Theo de Raadt <deraadt@...>
wrote:

>> > I am going to revisit this.
>> >
>> >> I do believe i386/amd64 RAMDISKs are destined to more or
>> >> less mainstream hardware and ISA CGA, MDA, EGA, HGA
>> >> stuff isn't there anymore.
>> >>
>> >> So on i386 RAMDISK (like amd64 one), I suggest to remove
>> >>
>> >> pcdisplay0 at isa?
>> >> wsdisplay*    at pcdisplay?
>> >
>> > This breaks machines that really do exist out there.
>> >
>> > 2200    44      88      2332    91c     GENERIC/pcdisplay.o
>> > 135     1064    0       1199    4af     GENERIC/pcdisplay_chars.o
>> > 907     0       0       907     38b     GENERIC/pcdisplay_subr.o
>> >
>> >> sys/arch/i386/conf/RAMDISK:
>> >>
>> >> pckbc0                at isa?                 # PC keyboard controller
>> >> pckbd*                at pckbc?               # PC keyboard
>> >> wskbd*                at pckbd? mux 1
>> >> vga0          at isa?
>> >> vga*          at pci?
>> >> pcdisplay0    at isa?                 # CGA, MDA, EGA, HGA
>> >> wsdisplay*    at vga?
>> >> wsdisplay*    at pcdisplay?
>> >
>> > This breaks 99% of i386 machines, ie. every machine that has either
>> > a pci vga display or a non-usb keyboard.
>> >
>> >> sys/arch/amd64/conf/RAMDISK:
>> >>
>> >> pckbc0                at isa?         # PC keyboard controller
>> >> pckbd*                at pckbc?       # PC keyboard
>> >> wskbd*                at pckbd? mux 1
>> >> vga0          at isa?
>> >> vga*          at pci?
>> >> wsdisplay*    at vga?
>> >
>> > This breaks 99% of amd64 machines, ie. every machine that has either
>> > a pci vga display or a non-usb keyboard.
>>
>> Well, I'm a bit disappointed.
>>
>> 1.49 of sys/arch/amd64/conf/RAMDISK does not contain
>> pcdisplay0.
>>
>> > In the last week alone, *two* people mailed in dmesg's that have isa
>> > vga adapters.  You are living in a fantasy if you think that
>> > restricting hardware support like that helps anyone.
>>
>> I told about removing pcdisplay0 at isa?, not vga0 at isa?
>
> Your mail was not explicit.  It suggested we remove other things too.
>
>> Searching over bugs@ mail archives shows no fresh
>> dmesgs with pcdisplay0.
>
> bugs@ is not the dmesglog.  The private dmesglog people send have
> machines which have pre-vga cards.
>
> You think we should simply stop supporting those.  Then those people
> would have to run something else.  Or throw them out.

i386 arch supports hardware starting from 80486. I recall
these old good days and all my machines (386SX and up)
was vga@isa (Trident and Currus Logic). 10+ years ago.

I understand dmesgs are somewhat private, but can you
show one running maintained branch and pre-vga card?

Alexey

[Theo de Raadt]

> i386 arch supports hardware starting from 80486. I recall
> these old good days and all my machines (386SX and up)
> was vga@isa (Trident and Currus Logic). 10+ years ago.
>
> I understand dmesgs are somewhat private, but can you
> show one running maintained branch and pre-vga card?

Here is a modern machine with a pcdisplay.  It is a terrible machine
(look at the interrupt mappings).  It is running 3.9, but there is
nothing which would stop it from running 4.6...  unless we commited
what you suggest.

OpenBSD 3.9 (GENERIC) #617: Thu Mar  2 02:26:48 MST 2006
    deraadt@...:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 134 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
cpu0: F00F bug workaround installed
real mem  = 100245504 (97896K)
avail mem = 84221952 (82248K)
using 1249 buffers containing 5115904 bytes (4996K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(0f) BIOS, date 03/03/98, BIOS32 rev. 0 @ 0xfb0a0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xb518
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd9f0/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 11
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371SB ISA" rev 0x00)
pcibios0: PCI bus #0 is the last bus
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82439TX System" rev 0x01
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <QUANTUM FIREBALL SE2.1A>
wd0: 16-sector PIO, LBA, 2014MB, 4124736 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <ASUS, CD-S360, 2.10> SCSI0 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x01: SMI
iic0 at piixpm0
rl0 at pci0 dev 11 function 0 "Realtek 8139" rev 0x10: irq 11, address
00:30:4f:19:3e:fd
rlphy0 at rl0 phy 0: RTL internal PHY
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcdisplay0 at isa0 port 0x3b0/16 iomem 0xb0000/32768
wsdisplay0 at pcdisplay0 mux 1: console (80x25, vt100 emulation), using wskbd0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: <PC speaker>
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: using exception 16
biomask fffd netmask fffd ttymask ffff

[Alexey Suslikov]

On Thu, Oct 29, 2009 at 09:58, Theo de Raadt <deraadt@...> wrote:

>> i386 arch supports hardware starting from 80486. I recall
>> these old good days and all my machines (386SX and up)
>> was vga@isa (Trident and Currus Logic). 10+ years ago.
>>
>> I understand dmesgs are somewhat private, but can you
>> show one running maintained branch and pre-vga card?
>
> Here is a modern machine with a pcdisplay.  It is a terrible machine
> (look at the interrupt mappings).  It is running 3.9, but there is
> nothing which would stop it from running 4.6...  unless we commited
> what you suggest.

Agreed. But curious, why it isn't there (4.6).

> OpenBSD 3.9 (GENERIC) #617: Thu Mar  2 02:26:48 MST 2006
>    deraadt@...:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 134 MHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
> cpu0: F00F bug workaround installed
> real mem  = 100245504 (97896K)
> avail mem = 84221952 (82248K)
...
> pcdisplay0 at isa0 port 0x3b0/16 iomem 0xb0000/32768
> wsdisplay0 at pcdisplay0 mux 1: console (80x25, vt100 emulation), using
wskbd0

Kinda monochrome adapter...

Ok, you convinced me. Sorry for the noise.

Alexey

[Theo de Raadt]

> Agreed. But curious, why it isn't there (4.6).

I can't control when people submit dmesg's to dmesg@...

Perhaps a reminder is in order.  If you want to help make sure OpenBSD
is better, please submit a dmesg as described in the FAQ.  The subject
of the message should indicate the type of machine it is.  We also like
to see the sensors that are detected, if there are any.   The message
should not be in MIME, but be in clear text.  If in doubt, simply
at the console type

   # (dmesg; sysctl hw.sensors) | mail -s "type of machine" dmesg@...


If the message is in MIME, I am sorry, but we often have to delete those.
There's too much volume in the dmesg mail folder to unpack and our developers
prefer to simply grep through it looking for special things.  So please,
don't use MIME.

[Antti Harri]

On Thu, 29 Oct 2009, Theo de Raadt wrote:

> I can't control when people submit dmesg's to dmesg@...

How often should one re-send dmesglog? After new, perhaps exotic hardware
has been added (not configured ones)? Upgraded to a new release? What
about if I update frequently using -current snaps, is there any harm in
sending too often (interval of about 50 days)?

--
Antti Harri

[Theo de Raadt]

> > I can't control when people submit dmesg's to dmesg@...
>
> How often should one re-send dmesglog? After new, perhaps exotic hardware
> has been added (not configured ones)? Upgraded to a new release? What
> about if I update frequently using -current snaps, is there any harm in
> sending too often (interval of about 50 days)?

Think for yourself.

[Bob Beck-4]

If you're updating frequently using current - there's no harm in
sending one every time you upgrade.

2009/10/29 Antti Harri <iku@...>:

> On Thu, 29 Oct 2009, Theo de Raadt wrote:
>
>> I can't control when people submit dmesg's to dmesg@...
>
> How often should one re-send dmesglog? After new, perhaps exotic hardware
> has been added (not configured ones)? Upgraded to a new release? What about
> if I update frequently using -current snaps, is there any harm in sending
> too often (interval of about 50 days)?
>
> --
> Antti Harri

[Antti Harri]

On Thu, 29 Oct 2009, Bob Beck wrote:

> If you're updating frequently using current - there's no harm in
> sending one every time you upgrade.

OK, thanks.

--
Antti Harri