Re: PPPoE (5.9 still): https gets stuck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Stuart,
On 09/16/16 14:08, Stuart Henderson wrote:
> On 2016-09-14, Harald Dunkel wrote:
>>
>> AFAIU setting the max-mss affects TCP traffic only (e.g. HTTPS). It defines
>> the maximum payload block size on sending and receiving(!) data via TCP. UDP
>> and other protocols are not affected. Very important to know if you run
>> IPsec or openvpn or other non-TCP protocols over the PPPoE tunnel.
>>
>> The mtu works on ethernet level, giving the maximum packet size to send(!)
>> to the next hop without fragmentation, regardless if the higher level
>> protocol is TCP, UDP, ESP or whatever.
>
> You are supposed to be able to get large packets through; routers are meant
> to either fragment or send ICMP "frag-needed" messages to allow the end host
> to do it. But some idiots misconfigure their firewalls to drop the necessary
> ICMP messages causing breakage to some sites.
>
Would you say that setting "scrub (no-df random-id)" is best practice
for IPv4 traffic forwarded into the internet?
>
> The MSS in the TCP handshake is based on the MTU on the outgoing route from
> the end host. So if you have
>
> router - pppoe0 - 1492 router - internal - 1500 host - internal - 1500
>
> the host will base its calculation on 1500 not 1492.
>
> "scrub (max-mss ..)" will cap this in the TCP handshake (and adjust checksums
> to match).
>
I figured this out, but maybe pf.conf(5) could be more explicit on
this detail, too?
> However: if you have working 1500 MTU pppoe via baby jumbos on the ethernet
> interface, "scrub (max-mss..)" shouldn't fix anything. The restricted MTU is
> usually towards the "client" side of things rather than towards the server,
> plus if it's towards the server then many people will be affected
> so it's easier for the server admin to spot problems.
>
>> My current configuration uses both baby jumbo frames (mtu = 1508 on re0 and
>> mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for TCP traffic on pppoe0
>> (1500 bytes - 40 bytes TCP/IP header - 8 bytes PPPoE frame).
>
> You should not need both. If baby jumbos are working correctly (you can "ping
> -D -s 1472 $some_internet_host" from an end host) then you should be able to
> get rid of the scrub. If they are not working correctly, you should get rid
> of the baby jumbo config and just use 1492, this will at least
> fix things for larger packets in the normal case where there is no bad
> firewall config in the way.
>
Deutsche Telekom seems to support baby jumbo frames ("Dumbos"? :-) )
on my side, but they told me that they don't actively support per-
customer MTUs on their BNGs.
Thanx for your detailed response. That was really helpful.
Regards
Harri
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJX4h2HAAoJEAqeKp5m04HLwokH/2+c7vGc7Wn21M3qPBbDqjmw
/qJKQ9CrQUUXnQOcEPl9eMqVdM6hLJO6OBMpUoKWvIa9vxuSBy79IXIXv0vpXbtv
aC40rHUJViG3EB1YX0KLIpF7p0iAgv9+5vr7/7obmHfBSUogZAcARL0TwrAU9CAN
/gVMkfiYIyJyxRwmw194QoNmrfq33wXAC2QDWJANhRLTokPy6i1H9dOXNVuxpIs9
d/Ua0bvELT6Ak0xIieShWzL37wwnnu1aHS9bT/9utHU6JPSGPm85lPVpiFhgJU8J
7DxClVeRy4IIQ0FvxQgGotuT+dXZFqV/1D7WGfqu4F6TgrnCFYk9e/VH918Oeyw=
=2oHP
-END PGP SIGNATURE-
6.0 CDs arrived west coast of Canada
arrived in 2016-09-19 mail
Re: i386 or amd64?
On Tue, Sep 20, 2016 at 08:36:40PM -0700, Mike Larkin wrote: > On Tue, Sep 20, 2016 at 05:38:50PM -0600, Jeff Ross wrote: > > Hi all, > > > > I've had a server with corenetworks for quite a few years now but after > > changes at corenetworks (their recent name change after acquisition by > > another company, no current servers available, no communication about the > > change of ownership with existing customers and an email exchange with > > sales@), I've decided it is best jump ship now rather than wait for a hard > > and possibly immediate deadline. > > > > I've just rented a server with 8GB of ram from m5hosting (based in large > > part from the many recommendations I read while searching misc@ on > > marc.info). Now the question is: i386 which is what I've always run on my 2 > > GB ram server, or amd64? http://www.openbsd.org/amd64.html and > > http://www.openbsd.org/i386.html are curiously silent on the amount of ram > > that can be accessed. If I have 8GB, I for sure want to use it all. > > Then your only choice is amd64. PAE, as discussed below, is only used to > enable NX, and not for "gigantisch memory i386". > Also, to answer the concern you posed below more directly, any recent CPU will have NX. > -ml > > > > > I know there was a time when i386 was limited to the amount of ram it can > > access (32 bit) but now amd64 has this caveat: "(Some Intel processors lack > > support for important PAE NX bit, which means those machines will run > > without any W^X support -- it is thus safer to run those machines in i386 > > mode)." How does this fit with the recent work in 6.0+? How can I tell if > > the Xeon 3220 processor has the PAE NX bit? I see nothing in the tech sheet > > about PAE NX. > > http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB > > > > I have a little less than 2 weeks to make the transition so not a lot of > > time for install and try. > > > > Thanks in advance for any suggestions--dmesgs supplied once I get access. > > > > Jeff Ross > > > > Open Vistas Networking
Re: i386 or amd64?
On Tue, Sep 20, 2016 at 05:38:50PM -0600, Jeff Ross wrote: > Hi all, > > I've had a server with corenetworks for quite a few years now but after > changes at corenetworks (their recent name change after acquisition by > another company, no current servers available, no communication about the > change of ownership with existing customers and an email exchange with > sales@), I've decided it is best jump ship now rather than wait for a hard > and possibly immediate deadline. > > I've just rented a server with 8GB of ram from m5hosting (based in large > part from the many recommendations I read while searching misc@ on > marc.info). Now the question is: i386 which is what I've always run on my 2 > GB ram server, or amd64? http://www.openbsd.org/amd64.html and > http://www.openbsd.org/i386.html are curiously silent on the amount of ram > that can be accessed. If I have 8GB, I for sure want to use it all. Then your only choice is amd64. PAE, as discussed below, is only used to enable NX, and not for "gigantisch memory i386". -ml > > I know there was a time when i386 was limited to the amount of ram it can > access (32 bit) but now amd64 has this caveat: "(Some Intel processors lack > support for important PAE NX bit, which means those machines will run > without any W^X support -- it is thus safer to run those machines in i386 > mode)." How does this fit with the recent work in 6.0+? How can I tell if > the Xeon 3220 processor has the PAE NX bit? I see nothing in the tech sheet > about PAE NX. > http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB > > I have a little less than 2 weeks to make the transition so not a lot of > time for install and try. > > Thanks in advance for any suggestions--dmesgs supplied once I get access. > > Jeff Ross > > Open Vistas Networking
Re: Using isc-dhcp-client as alternate dhclient
On 16-09-20 15:36:52, Theodore Wynnychenko wrote:
> Hello
> I would like to get the isc-dhcp-client working as a replacement for the base
> dhclient.
>
> The primary reason for this is so that I can assign an alias to the interface.
>
> But, I can't seem to figure out how to get this done. I have two issues.
>
> First, I can't get the isc-dhcp-client to assign an alias to the interface,
> despite the documentation that states it should.
>
> I have created an /etc/isc-dhclient.conf file:
> ---
> timeout 60;
> retry 60;
> reboot 10;
> select-timeout 5;
> initial-interval 2;
> script "/usr/local/sbin/dhclient-script";
>
> supersede domain-name "domain.com";
> supersede domain-name-servers d.n.s.1,d.n.s.2;
>
> request subnet-mask, broadcast-address, time-offset, routers;
>
> alias {
> interface "em0";
> fixed-address fi.xed.ip.addr;
> option subnet-mask 255.255.255.0;
> }
> ---
>
> But, after killing the running dhclient process (from base), removing the
> leases
> at /var/db/dhclient.leases* and starting isc-dhcp-client with:
>
> # /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0
>
> the isc client is able to get a an offer from the dhcp server, but it does
> _not_
> assign the alias address to the interface. The only address is the
> dynamically
> assigned one.
>
> I can find no guidance on what I am doing wrong, and why the isc-dhcp-client
> is
> not assigning the alias.
>
> Second, I (apparently) don't understand how to replace the base dhclient with
> the isc dhclient at boot.
>
> I tried modifying /etc/hostname.em0 from:
> ---
> dhcp NONE NONE NONE description "Uplink"
> ---
>
> To:
> ---
> ! /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0
> ---
>
> But this did not work. I now see in the hostname.if manpage that the command
> needs to be available in the single-user environment (/bin or /sbin), but it
> seems to me that if I was doing this "right," I shouldn't need to move the isc
> client from the location that the package installed it in. So, before I start
> moving things around, I wanted to check if this is the way to do it, or if I
> have missed something more appropriate.
>
> Thanks for any advice.
>
> Ted
ALIAS DECLARATIONS
alias { declarations ... }
Some DHCP clients running TCP/IP roaming protocols may require that in
addition to the lease they may acquire via DHCP, their interface also
be configured with a predefined IP alias so that they can have a
permanent IP address even while roaming. The Internet Systems
Consortium DHCP client doesn't support roaming with fixed addresses
directly, but in order to facilitate such experimentation, the dhcp
client can be set up to configure an IP alias using the alias
declaration.
The alias declaration resembles a lease declaration, except that
options other than the subnet-mask option are ignored by the standard
client configuration script, and expiry times are ignored. A typical
alias declaration includes an interface declaration, a fixed-address
declaration for the IP alias address, and a subnet-mask option
declaration. A medium statement should never be included in an alias
declaration.
I think they are saying their dhcp-client cant handle fixed ip's so this is
some sort of workaround. These aren't the droids you're looking for.
--
Edgar Pettijohn
Re: i386 or amd64?
Tue, 20 Sep 2016 17:38:50 -0600 Jeff Ross [...] > I have a little less than 2 weeks to make the transition so not a lot of > time for install and try. > > Thanks in advance for any suggestions--dmesgs supplied once I get access. Hi Jeff, Go amd64 as others advised, X3220 processor supports 64-bit instructions. OpenBSD amd64 [http://www.openbsd.org/amd64.html] Tue, 20 Sep 2016 19:49:30 -0400 STeve Andre' > > AMD64. There isn't a real future in 32-bit stuff. [...] > So look forwards at 65-bit. I don't think you'll look back. Hi STeve, You may have to reconsider this for embedded & other applications given the patents expired and the architecture's become fully open over time. [https://en.wikipedia.org/wiki/X86] [https://en.wikipedia.org/wiki/IA-32] Surely, you meant to say 64-bit architectures, given they are more than 12 years old now, as practically current there is not much to look for. This means you can simply stop looking forward to 65-bit architectures. Wed, 21 Sep 2016 01:58:22 +0100 Pedro Tender [...] > You should use amd64. > > As a side note, in the processor you've linked here it says it will launch > in the first quarter of 2017, so if what says there is true you have to > wait a little longer to upgrade. Hi Pedro, You must have been very tired when you read the Intel product sheet, the CPU in question was released first quarter 2007, and is now end of life. Intel Xeon Processor X3220 (8M Cache, 2.40 GHz, 1066 MHz FSB) [http://ark.intel.com/products/28034] It is known hosting companies offer quite old servers especially if they are a lower tier provider. It is recommended you pick another host with more recent line up, a newer server for the same cost, or just go amd64. The server CPU you got was meant to run 64-bit OS more than 7 years ago. Kind regards, Anton
Video card recommendation
Hello, I have recently installed OpenBSD for the first time on some hardware I would like to use now as an OpenBSD workstation (motherboard Asus P6T deluxe, processor Intel i7 920, I bought it ~10 years ago) Install worked fine :) But I didn't manage to configure Xorg and change my display resolution because I am running an Nvidia 660 GTX and I read Nvidia video cards are not very well supported by OpenBSD (because of their own policies on driver publication). I searched on the documentation but didn't found a list with recommended video cards for OpenBSD, except avoiding Nvidia ones. I would like to buy a new video card (with some preference for a passive cooling model) but I don't know what to choose, so your assistance / advice here would be greatly appreciated. If I can run OpenBSD 6.0 with success on a new video card, it would be my pleasure to buy you in the future CD distributions and to make donations to support your work, as I have huge respect for your awesome distribution and am also very worried about NSA global surveillance rise, showing no respect on basic privacy rights... Long live MIT and Berkeley's great researchers on security computing ! Regards
Re: i386 or amd64?
Very shortcutted the PAE is for 32bits to allow more RAM like 64bits
processors. Search the math about those RAM numbers regarding CPU
architecture.
Some (very old) 32 bits processors may lack the NX bit.
64 bits all have the NX bit.
You should use amd64.
As a side note, in the processor you've linked here it says it will launch
in the first quarter of 2017, so if what says there is true you have to
wait a little longer to upgrade.
On Sep 21, 2016 1:01 AM, "STeve Andre'" wrote:
> On 09/20/16 19:38, Jeff Ross wrote:
>
>> Hi all,
>>
>> I've had a server with corenetworks for quite a few years now but after
>> changes at corenetworks (their recent name change after acquisition by
>> another company, no current servers available, no communication about
>> the change of ownership with existing customers and an email exchange
>> with sales@), I've decided it is best jump ship now rather than wait for
>> a hard and possibly immediate deadline.
>>
>> I've just rented a server with 8GB of ram from m5hosting (based in large
>> part from the many recommendations I read while searching misc@ on
>> marc.info). Now the question is: i386 which is what I've always run on
>> my 2 GB ram server, or amd64? http://www.openbsd.org/amd64.html and
>> http://www.openbsd.org/i386.html are curiously silent on the amount of
>> ram that can be accessed. If I have 8GB, I for sure want to use it all.
>>
>> I know there was a time when i386 was limited to the amount of ram it
>> can access (32 bit) but now amd64 has this caveat: "(Some Intel
>> processors lack support for important PAE NX bit, which means those
>> machines will run without any W^X support -- it is thus safer to run
>> those machines in i386 mode)." How does this fit with the recent work
>> in 6.0+? How can I tell if the Xeon 3220 processor has the PAE NX bit?
>> I see nothing in the tech sheet about PAE NX.
>> http://ark.intel.com/products/28034/Intel-Xeon-Processor-X32
>> 20-8M-Cache-2_40-GHz-1066-MHz-FSB
>>
>>
>> I have a little less than 2 weeks to make the transition so not a lot of
>> time for install and try.
>>
>> Thanks in advance for any suggestions--dmesgs supplied once I get access.
>>
>> Jeff Ross
>>
>> Open Vistas Networking
>>
>>
>>
> AMD64. There isn't a real future in 32-bit stuff. I have some great
> old Dells ("white optiplex") that I'll eventually get rid of but have
> kept because of their quality. But they do have the 3G problem. So
> look forwards at 65-bit. I don't think you'll look back.
>
> --STeve Andre'
Re: i386 or amd64?
On Tue, 20 Sep 2016, Jeff Ross wrote: > How can I tell if the Xeon 3220 > processor has the PAE NX bit? I see nothing in the tech sheet about PAE NX. > http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB Look at the very bottom: it says ``Execute Disable Bit: Yes.'' That is the NX bit. (Intel calls it the XD bit.) This has been around a while. Anything you come across that isn't ancient will include it. Martin
Re: i386 or amd64?
On 09/20/16 19:38, Jeff Ross wrote:
Hi all,
I've had a server with corenetworks for quite a few years now but after
changes at corenetworks (their recent name change after acquisition by
another company, no current servers available, no communication about
the change of ownership with existing customers and an email exchange
with sales@), I've decided it is best jump ship now rather than wait for
a hard and possibly immediate deadline.
I've just rented a server with 8GB of ram from m5hosting (based in large
part from the many recommendations I read while searching misc@ on
marc.info). Now the question is: i386 which is what I've always run on
my 2 GB ram server, or amd64? http://www.openbsd.org/amd64.html and
http://www.openbsd.org/i386.html are curiously silent on the amount of
ram that can be accessed. If I have 8GB, I for sure want to use it all.
I know there was a time when i386 was limited to the amount of ram it
can access (32 bit) but now amd64 has this caveat: "(Some Intel
processors lack support for important PAE NX bit, which means those
machines will run without any W^X support -- it is thus safer to run
those machines in i386 mode)." How does this fit with the recent work
in 6.0+? How can I tell if the Xeon 3220 processor has the PAE NX bit?
I see nothing in the tech sheet about PAE NX.
http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB
I have a little less than 2 weeks to make the transition so not a lot of
time for install and try.
Thanks in advance for any suggestions--dmesgs supplied once I get access.
Jeff Ross
Open Vistas Networking
AMD64. There isn't a real future in 32-bit stuff. I have some great
old Dells ("white optiplex") that I'll eventually get rid of but have
kept because of their quality. But they do have the 3G problem. So
look forwards at 65-bit. I don't think you'll look back.
--STeve Andre'
i386 or amd64?
Hi all, I've had a server with corenetworks for quite a few years now but after changes at corenetworks (their recent name change after acquisition by another company, no current servers available, no communication about the change of ownership with existing customers and an email exchange with sales@), I've decided it is best jump ship now rather than wait for a hard and possibly immediate deadline. I've just rented a server with 8GB of ram from m5hosting (based in large part from the many recommendations I read while searching misc@ on marc.info). Now the question is: i386 which is what I've always run on my 2 GB ram server, or amd64? http://www.openbsd.org/amd64.html and http://www.openbsd.org/i386.html are curiously silent on the amount of ram that can be accessed. If I have 8GB, I for sure want to use it all. I know there was a time when i386 was limited to the amount of ram it can access (32 bit) but now amd64 has this caveat: "(Some Intel processors lack support for important PAE NX bit, which means those machines will run without any W^X support -- it is thus safer to run those machines in i386 mode)." How does this fit with the recent work in 6.0+? How can I tell if the Xeon 3220 processor has the PAE NX bit? I see nothing in the tech sheet about PAE NX. http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB I have a little less than 2 weeks to make the transition so not a lot of time for install and try. Thanks in advance for any suggestions--dmesgs supplied once I get access. Jeff Ross Open Vistas Networking
Re: [solved] Re: cuaU0 problems
On Tue, Sep 20, 2016 at 06:11:14PM -0500, Edgar Pettijohn wrote: > The latest snapshot fixed it for me. However, it added these lines at boot: > > splassert: sorwakeup: want 64 have 0 > splassert: sorwakeup: want 64 have 0 That's because of this commit: https://marc.info/?l=openbsd-cvs&m=147436994029593&w=2 CVSROOT:/cvs Module name:src Changes by: bl...@cvs.openbsd.org 2016/09/20 05:11:44 Modified files: sys/kern : uipc_socket.c Log message: Add some spl softnet assertions that will help us to find the right places for the upcoming network lock. This might trigger some asserts, but we have to find the missing code paths. OK mpi@ See also this thread on tech: https://marc.info/?t=14743742264&r=1&w=2 These should all be fixed now. If you still get them with the next snapshot, set sysctl kern.splassert=2 to get a backtrace which you can report.
[solved] Re: cuaU0 problems
The latest snapshot fixed it for me. However, it added these lines at boot:
splassert: sorwakeup: want 64 have 0
splassert: sorwakeup: want 64 have 0
I don't recall seeing them before.
Thanks,
Edgar
On 16-09-20 10:01:33, Edgar Pettijohn wrote:
> Sent from my iPhone
>
> > On Sep 20, 2016, at 6:32 AM, Z??? Loff wrote:
> >
> >> On Tue, Sep 20, 2016 at 09:53:58PM +1200, Richard Procter wrote:
> >>> On 20/09/2016, at 8:00 AM, Edgar Pettijohn wrote:
> >>>
> On 16-09-19 19:56:31, Kapfhammer, Stefan wrote:
> Hello Edgar,
>
> I have no Soekris, but Apu2 is also connected
> with a serial cable.
>
> When cable is plugged in the controlling pc
> before booting, it is to be found as /dev/cuaU???0.
>
> When I plug it in after the boot completed, it is to be
> found as /dev/cuaU3. (0/1/2 is normally int. 3G modem)
>
> Hope this helps debugging. Feedback would be fine.
> >>>
> >>> Thanks for the reply. It has always worked with:
> >>>
> >>> # cu -l cuaU0
> >>>
> >>> when it stopped working I tried cuaU{1,2} with same result.
> >>
> >> Although my MacBook works at
> >>
> >> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
> >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >>
> >> (dmesg attached)
> >>
> >> , it breaks at
> >>
> >> OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016
> >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >>
> >> I see some disabled USB ports and my keyboard is apparently attached to
> one
> >> of them because I cannot log in via console.
> >>
> >> sys/dev/usb/usb_subr.c revision 1.129 lies between these dates. Reverting
> >> this to revision 1.128 restores my keyboard, etc.
> >
> > Assuming it is the same problem referred to in the "USB ports disabled
> > on Lenovo Thinkpad T61" thread (and all signs point to yes) according to
> > Mike Schreckengost's message the problem has been fixed on current. Can
> > you confirm this, Edgar?
>
> I will give it a shot when I get a chance tonight hopefully.
>
> Thanks
> >
> >>
> >> best,
> >> Richard.
> >>
> >> [known good - and working FDTI USB->serial attached at end]
> >>
> >> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
> >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >> RTC BIOS diagnostic error
> >>
> ff
> >> real mem = 4005785600 (3820MB)
> >> avail mem = 3879882752 (3700MB)
> >> mpath0 at root
> >> scsibus0 at mpath0: 256 targets
> >> mainbus0 at root
> >> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbf719000 (44 entries)
> >> bios0: vendor Apple Inc. version "MBP71.88Z.0039.B05.1003251322" date
> >> 03/25/10
> >> bios0: Apple Inc. MacBookPro7,1
> >> acpi0 at bios0: rev 2
> >> acpi0: sleep states S0 S3 S4 S5
> >> acpi0: tables DSDT FACP HPET APIC APIC ASF! SBST ECDT SSDT SSDT SSDT MCFG
> >> acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3)
> OHC2(S3)
> >> EHC2(S3) ARPT(S5) GIGE(S5)
> >> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> >> acpihpet0 at acpi0: 2500 Hz
> >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> >> cpu0 at mainbus0: apid 0 (boot processor)
> >> cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2389.57 MHz
> >> cpu0:
> >>
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> >>
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
> >> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> >> cpu0: 3MB 64b/line 8-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 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 P8600 @ 2.40GHz, 2389.25 MHz
> >> cpu1:
> >>
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> >>
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
> >> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> >> cpu1: 3MB 64b/line 8-way L2 cache
> >> cpu1: smt 0, core 1, package 0
> >> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
> >> acpiec0 at acpi0
> >> acpimcfg0 at acpi0 addr 0xf000, bus 0-4
> >> acpiprt0 at acpi0: bus 0 (PCI0)
> >> acpiprt1 at acpi0: bus 4 (IXVE)
> >> acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
> C1(1000@1
> >> mwait), PSS
> >> acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
> C1(1000@1
> >> mwait), PSS
> >> acpiac0 at acpi0: AC unit offline
> >> acpibtn0 at acpi0: LID0
> >> "APP0002" at acpi0 not configured
> >> acpibtn1 at acpi0: PWRB
> >> acpibtn2 at acpi0: SLPB
> >> "APP0001" at acpi0 not configured
> >> "APP0003" at acpi0 not configured
> >> acpials0 at acpi0: ALS0
> >> "ACPI0002" at acpi0 not configured
> >> acpibat0 at acpi0: BAT0 model "354579798102340
Using isc-dhcp-client as alternate dhclient
Hello
I would like to get the isc-dhcp-client working as a replacement for the base
dhclient.
The primary reason for this is so that I can assign an alias to the interface.
But, I can't seem to figure out how to get this done. I have two issues.
First, I can't get the isc-dhcp-client to assign an alias to the interface,
despite the documentation that states it should.
I have created an /etc/isc-dhclient.conf file:
---
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
script "/usr/local/sbin/dhclient-script";
supersede domain-name "domain.com";
supersede domain-name-servers d.n.s.1,d.n.s.2;
request subnet-mask, broadcast-address, time-offset, routers;
alias {
interface "em0";
fixed-address fi.xed.ip.addr;
option subnet-mask 255.255.255.0;
}
---
But, after killing the running dhclient process (from base), removing the leases
at /var/db/dhclient.leases* and starting isc-dhcp-client with:
# /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0
the isc client is able to get a an offer from the dhcp server, but it does _not_
assign the alias address to the interface. The only address is the dynamically
assigned one.
I can find no guidance on what I am doing wrong, and why the isc-dhcp-client is
not assigning the alias.
Second, I (apparently) don't understand how to replace the base dhclient with
the isc dhclient at boot.
I tried modifying /etc/hostname.em0 from:
---
dhcp NONE NONE NONE description "Uplink"
---
To:
---
! /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0
---
But this did not work. I now see in the hostname.if manpage that the command
needs to be available in the single-user environment (/bin or /sbin), but it
seems to me that if I was doing this "right," I shouldn't need to move the isc
client from the location that the package installed it in. So, before I start
moving things around, I wanted to check if this is the way to do it, or if I
have missed something more appropriate.
Thanks for any advice.
Ted
Today's snapshot fixed a USB problem I wasn't aware I had
yes, really. Today for the first time in weeks I inserted a USB storage drive on my laptop, only to have the thing not react at all, as in no sign of anything USB related appearing in any logs or dmesg when I inserted the device. Now for those files it was possible to transfer using a different method, so I held off trying to write up a bug report until I had a fresh snapshot installed. In the meantime I noticed in dmesg output messages like usb0 at xhci0: USB revision 3.0 usb0: root hub problem which would of course explain why USB devices were not behaving. But after I'd gotten around to installing today's snapshot, I got usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 and the USB drive was recognized and mountable. I had vaguely noticed some USB related commits recently, but hey, you fixed things! dmesg from today is up at https://home.nuug.no/~peter/dmesg_elke_20160920.txt. Thanks! - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. '
It is too late for that all the developers to do the right thing?
Theo de Raadt wrote: "The Race is there to be run, for ourselves, not for others. We do what we do to run our own race, and finish it the best we can. We don't rush off at every distraction, or worry how this will affect our image. We are here to have fun doing right." It is too late for that all the developers to do the right thing? I want to have fun doing right.
Re: cuaU0 problems
Sent from my iPhone
> On Sep 20, 2016, at 6:32 AM, Z� Loff wrote:
>
>> On Tue, Sep 20, 2016 at 09:53:58PM +1200, Richard Procter wrote:
>>> On 20/09/2016, at 8:00 AM, Edgar Pettijohn wrote:
>>>
On 16-09-19 19:56:31, Kapfhammer, Stefan wrote:
Hello Edgar,
I have no Soekris, but Apu2 is also connected
with a serial cable.
When cable is plugged in the controlling pc
before booting, it is to be found as /dev/cuaU???0.
When I plug it in after the boot completed, it is to be
found as /dev/cuaU3. (0/1/2 is normally int. 3G modem)
Hope this helps debugging. Feedback would be fine.
>>>
>>> Thanks for the reply. It has always worked with:
>>>
>>> # cu -l cuaU0
>>>
>>> when it stopped working I tried cuaU{1,2} with same result.
>>
>> Although my MacBook works at
>>
>> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
>>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> (dmesg attached)
>>
>> , it breaks at
>>
>> OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016
>>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> I see some disabled USB ports and my keyboard is apparently attached to
one
>> of them because I cannot log in via console.
>>
>> sys/dev/usb/usb_subr.c revision 1.129 lies between these dates. Reverting
>> this to revision 1.128 restores my keyboard, etc.
>
> Assuming it is the same problem referred to in the "USB ports disabled
> on Lenovo Thinkpad T61" thread (and all signs point to yes) according to
> Mike Schreckengost's message the problem has been fixed on current. Can
> you confirm this, Edgar?
I will give it a shot when I get a chance tonight hopefully.
Thanks
>
>>
>> best,
>> Richard.
>>
>> [known good - and working FDTI USB->serial attached at end]
>>
>> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
>>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> RTC BIOS diagnostic error
>>
ff
>> real mem = 4005785600 (3820MB)
>> avail mem = 3879882752 (3700MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbf719000 (44 entries)
>> bios0: vendor Apple Inc. version "MBP71.88Z.0039.B05.1003251322" date
>> 03/25/10
>> bios0: Apple Inc. MacBookPro7,1
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP HPET APIC APIC ASF! SBST ECDT SSDT SSDT SSDT MCFG
>> acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3)
OHC2(S3)
>> EHC2(S3) ARPT(S5) GIGE(S5)
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpihpet0 at acpi0: 2500 Hz
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2389.57 MHz
>> cpu0:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>>
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
>> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
>> cpu0: 3MB 64b/line 8-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 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 P8600 @ 2.40GHz, 2389.25 MHz
>> cpu1:
>>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
>>
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
>> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
>> cpu1: 3MB 64b/line 8-way L2 cache
>> cpu1: smt 0, core 1, package 0
>> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
>> acpiec0 at acpi0
>> acpimcfg0 at acpi0 addr 0xf000, bus 0-4
>> acpiprt0 at acpi0: bus 0 (PCI0)
>> acpiprt1 at acpi0: bus 4 (IXVE)
>> acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
C1(1000@1
>> mwait), PSS
>> acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10),
C1(1000@1
>> mwait), PSS
>> acpiac0 at acpi0: AC unit offline
>> acpibtn0 at acpi0: LID0
>> "APP0002" at acpi0 not configured
>> acpibtn1 at acpi0: PWRB
>> acpibtn2 at acpi0: SLPB
>> "APP0001" at acpi0 not configured
>> "APP0003" at acpi0 not configured
>> acpials0 at acpi0: ALS0
>> "ACPI0002" at acpi0 not configured
>> acpibat0 at acpi0: BAT0 model "3545797981023400290" type
3545797981528607052
>> oem "3545797981528673619"
>> cpu0: Enhanced SpeedStep 2389 MHz: speeds: 2394, 2128, 1862, 1596, 798 MHz
>> pci0 at mainbus0 bus 0
>> 0:3:4: mem address conflict 0xd340/0x8
>> pchb0 at pci0 dev 0 function 0 "NVIDIA MCP89 Host" rev 0xa1
>> "NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 0 function 1 not configured
>> vendor "NVIDIA", unknown product 0x0d6d (class memory subclass RAM, rev
0xa1)
>> at pci0 dev 1 function 0 not configured
>> vendor "NVIDIA", unknown prod
Re: usb disk dirty after every reboot
Craig Skinner wrote:
> Hi Jan,
>
> On Mon, 19 Sep 2016 18:22:37 +0200 Jan Stary wrote:
> >
> > 9d24108772d1158c.a /backup ffs rw,softdep,noatime,nodev,noexec
> >
>
> With softdep everywhere, would this help in /etc/rc.shutdown?
>
> for i in 4 3 2 1
>
> do
>
> sync
>
> sleep ${i}
>
> done
Only if there is a bug that should be fixed instead.
Re: Man page for md5(1)
On Tue, Sep 20, 2016 at 10:20:05AM +1000, bytevolc...@safe-mail.net wrote: > For md5(1) (and therefore, sha1(1), sha256(1), sha512(1)), the man page > has this: > > "-q Only print the checksum (quiet mode)." > > Since this has the same behaviour as "cksum -q", would it be best to > keep it in line with it: > > "-q Only print the checksum (quiet mode) or if used in > conjunction with the -c flag, only print the failed cases." > fixed, thanks. jmc
Re: cuaU0 problems
On Tue, Sep 20, 2016 at 09:53:58PM +1200, Richard Procter wrote:
> On 20/09/2016, at 8:00 AM, Edgar Pettijohn wrote:
>
> > On 16-09-19 19:56:31, Kapfhammer, Stefan wrote:
> >> Hello Edgar,
> >>
> >> I have no Soekris, but Apu2 is also connected
> >> with a serial cable.
> >>
> >> When cable is plugged in the controlling pc
> >> before booting, it is to be found as /dev/cuaU???0.
> >>
> >> When I plug it in after the boot completed, it is to be
> >> found as /dev/cuaU3. (0/1/2 is normally int. 3G modem)
> >>
> >> Hope this helps debugging. Feedback would be fine.
> >
> > Thanks for the reply. It has always worked with:
> >
> > # cu -l cuaU0
> >
> > when it stopped working I tried cuaU{1,2} with same result.
>
> Although my MacBook works at
>
> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> (dmesg attached)
>
> , it breaks at
>
> OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> I see some disabled USB ports and my keyboard is apparently attached to one
> of them because I cannot log in via console.
>
> sys/dev/usb/usb_subr.c revision 1.129 lies between these dates. Reverting
> this to revision 1.128 restores my keyboard, etc.
Assuming it is the same problem referred to in the "USB ports disabled
on Lenovo Thinkpad T61" thread (and all signs point to yes) according to
Mike Schreckengost's message the problem has been fixed on current. Can
you confirm this, Edgar?
>
> best,
> Richard.
>
> [known good - and working FDTI USB->serial attached at end]
>
> OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error
> ff
> real mem = 4005785600 (3820MB)
> avail mem = 3879882752 (3700MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbf719000 (44 entries)
> bios0: vendor Apple Inc. version "MBP71.88Z.0039.B05.1003251322" date
> 03/25/10
> bios0: Apple Inc. MacBookPro7,1
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC APIC ASF! SBST ECDT SSDT SSDT SSDT MCFG
> acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3)
> EHC2(S3) ARPT(S5) GIGE(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2500 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2389.57 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 3MB 64b/line 8-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 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 P8600 @ 2.40GHz, 2389.25 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
> T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 3MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
> acpiec0 at acpi0
> acpimcfg0 at acpi0 addr 0xf000, bus 0-4
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 4 (IXVE)
> acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
> mwait), PSS
> acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
> mwait), PSS
> acpiac0 at acpi0: AC unit offline
> acpibtn0 at acpi0: LID0
> "APP0002" at acpi0 not configured
> acpibtn1 at acpi0: PWRB
> acpibtn2 at acpi0: SLPB
> "APP0001" at acpi0 not configured
> "APP0003" at acpi0 not configured
> acpials0 at acpi0: ALS0
> "ACPI0002" at acpi0 not configured
> acpibat0 at acpi0: BAT0 model "3545797981023400290" type 3545797981528607052
> oem "3545797981528673619"
> cpu0: Enhanced SpeedStep 2389 MHz: speeds: 2394, 2128, 1862, 1596, 798 MHz
> pci0 at mainbus0 bus 0
> 0:3:4: mem address conflict 0xd340/0x8
> pchb0 at pci0 dev 0 function 0 "NVIDIA MCP89 Host" rev 0xa1
> "NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 0 function 1 not configured
> vendor "NVIDIA", unknown product 0x0d6d (class memory subclass RAM, rev 0xa1)
> at pci0 dev 1 function 0 not configured
> vendor "NVIDIA", unknown product 0x0d6e (class memory subclass RAM, rev 0xa1)
> at pci0 dev 1 function 1 not configured
> vendor "NVIDIA", unknown product 0x0d6f (class memory subclass RAM, rev 0xa1)
> at pci0 dev 1 function 2 not configured
> vendor "NVIDIA", unknow
Re: cuaU0 problems
On 20/09/2016, at 9:53 PM, Richard Procter wrote:
>
> On 20/09/2016, at 8:00 AM, Edgar Pettijohn wrote:
>
>> On 16-09-19 19:56:31, Kapfhammer, Stefan wrote:
>>> Hello Edgar,
>>>
>>> I have no Soekris, but Apu2 is also connected
>>> with a serial cable.
>>>
>>> When cable is plugged in the controlling pc
>>> before booting, it is to be found as /dev/cuaU???0.
>>>
>>> When I plug it in after the boot completed, it is to be
>>> found as /dev/cuaU3. (0/1/2 is normally int. 3G modem)
>>>
>>> Hope this helps debugging. Feedback would be fine.
>>
>> Thanks for the reply. It has always worked with:
>>
>> # cu -l cuaU0
>>
>> when it stopped working I tried cuaU{1,2} with same result.
>
> Although my MacBook works at
> [ details on breakage ]
P.S. here's the dmesg for the snapshot where I can't login via console.
best,
Richard
OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
ff
real mem = 4005785600 (3820MB)
avail mem = 3879882752 (3700MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbf719000 (44 entries)
bios0: vendor Apple Inc. version "MBP71.88Z.0039.B05.1003251322" date
03/25/10
bios0: Apple Inc. MacBookPro7,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC APIC ASF! SBST ECDT SSDT SSDT SSDT MCFG
acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3)
EHC2(S3) ARPT(S5) GIGE(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2500 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2389.64 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-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 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 P8600 @ 2.40GHz, 2389.25 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xf000, bus 0-4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (IXVE)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
mwait), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
mwait), PSS
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"APP0001" at acpi0 not configured
"APP0003" at acpi0 not configured
acpials0 at acpi0: ALS0
"ACPI0002" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "3545797981023400290" type 3545797981528607052
oem "3545797981528673619"
cpu0: Enhanced SpeedStep 2389 MHz: speeds: 2394, 2128, 1862, 1596, 798 MHz
pci0 at mainbus0 bus 0
0:3:4: mem address conflict 0xd340/0x8
pchb0 at pci0 dev 0 function 0 "NVIDIA MCP89 Host" rev 0xa1
"NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 0 function 1 not configured
vendor "NVIDIA", unknown product 0x0d6d (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 0 not configured
vendor "NVIDIA", unknown product 0x0d6e (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 1 not configured
vendor "NVIDIA", unknown product 0x0d6f (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 2 not configured
vendor "NVIDIA", unknown product 0x0d70 (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 3 not configured
vendor "NVIDIA", unknown product 0x0d71 (class memory subclass RAM, rev 0xa1)
at pci0 dev 2 function 0 not configured
vendor "NVIDIA", unknown product 0x0d72 (class memory subclass RAM, rev 0xa1)
at pci0 dev 2 function 1 not configured
pcib0 at pci0 dev 3 function 0 "NVIDIA MCP89 LPC" rev 0xa2
"NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 3 function 1 not configured
nviic0 at pci0 dev 3 function 2 "NVIDIA MCP89 SMBus" rev 0xa1
iic0 at nviic0
iic1 at nviic0
"NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 3 function 3 not configured
"NVIDIA MCP89 Co-processor" rev 0xa1 at pci0 dev 3 function 4 not configured
ohci0 at pci0 dev 4 function 0 "NVIDIA MCP89 USB" rev 0xa1: apic 1 int 17,
version 1.0, legacy support
ehci0 at pci0 dev 4 function 1 "NVIDIA MCP89 USB" rev 0xa2: apic 1 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "NVIDIA EHCI root hub" rev 2.00/1.00
addr 1
Re: bugs
[ moving this to misc@ as this isn't actually a bug report ] Check http://www.openbsd.org/report.html for how to write a useful problem report. On Tue, Sep 20, 2016 at 09:05:06AM +, Chri Fish wrote: > > 1. > > > > nfe0: watchodg timeout interval 1 Where do you see this message? What did you do? > > 2. > > > > with vlan0 > > > > vlan0:watchdog timeout interval 1 See above. > > 3. > > > > i made the pkg_path > > > > pkg_add -v nano > > > > cant find nano check your PKG_PATH > > pkg_add -v wget > > > > cant find wget See previous. > > 4. > > > > cd /usr/games > > > > hangman Check your PATH. > > nothing works Start with the FAQ. It has lots of useful information and possibly some useful links to other resources. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: ral(4) problems on current/i396 ALIX
On Tue, Sep 20, 2016 at 10:46:54AM +0200, Jan Stary wrote: > This is ALIX 2C1, just upgraded to current/i386 (dmesg below). > It serves as a wifi AP using ral(4). The console gets spammed with > > ral0: sending data frame failed 0x02faaafa > > This used to work fine since 5.9/i386. This is the only known fallout from ieee80211_proto.c r1.68 and seems to affect ral 2560 chips only. Apparently this driver has always had a bug with RTS/CTS and the wireless stack is now triggering it. It's on my TODO list. In the mean time you can back out r1.68 as a workaround, for example like this: Index: ieee80211_proto.c === RCS file: /cvs/src/sys/net80211/ieee80211_proto.c,v retrieving revision 1.68 diff -u -p -r1.68 ieee80211_proto.c --- ieee80211_proto.c 20 Jul 2016 15:40:27 - 1.68 +++ ieee80211_proto.c 20 Sep 2016 09:45:32 - @@ -88,7 +88,7 @@ ieee80211_proto_attach(struct ifnet *ifp ifp->if_hdrlen = sizeof(struct ieee80211_frame); - ic->ic_rtsthreshold = IEEE80211_RTS_DEFAULT; + ic->ic_rtsthreshold = IEEE80211_RTS_MAX; ic->ic_fragthreshold = 2346;/* XXX not used yet */ ic->ic_fixed_rate = -1; /* no fixed rate */ ic->ic_fixed_mcs = -1; /* no fixed mcs */ > How can I help debug this? sebastia@ reported this to me already, and he kindly spent the time involved in tracking down the commit that introduced this problem. You could have done that, too, but now sebastia@ already did that work. You could still help by becoming a wireless hacker and fix the driver yourself.
Re: cuaU0 problems
On 20/09/2016, at 8:00 AM, Edgar Pettijohn wrote:
> On 16-09-19 19:56:31, Kapfhammer, Stefan wrote:
>> Hello Edgar,
>>
>> I have no Soekris, but Apu2 is also connected
>> with a serial cable.
>>
>> When cable is plugged in the controlling pc
>> before booting, it is to be found as /dev/cuaU???0.
>>
>> When I plug it in after the boot completed, it is to be
>> found as /dev/cuaU3. (0/1/2 is normally int. 3G modem)
>>
>> Hope this helps debugging. Feedback would be fine.
>
> Thanks for the reply. It has always worked with:
>
> # cu -l cuaU0
>
> when it stopped working I tried cuaU{1,2} with same result.
Although my MacBook works at
OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
(dmesg attached)
, it breaks at
OpenBSD 6.0-current (GENERIC.MP) #2473: Sun Sep 18 23:24:19 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
I see some disabled USB ports and my keyboard is apparently attached to one
of them because I cannot log in via console.
sys/dev/usb/usb_subr.c revision 1.129 lies between these dates. Reverting
this to revision 1.128 restores my keyboard, etc.
best,
Richard.
[known good - and working FDTI USB->serial attached at end]
OpenBSD 6.0-current (GENERIC.MP) #2466: Sat Sep 17 23:07:05 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
ff
real mem = 4005785600 (3820MB)
avail mem = 3879882752 (3700MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbf719000 (44 entries)
bios0: vendor Apple Inc. version "MBP71.88Z.0039.B05.1003251322" date
03/25/10
bios0: Apple Inc. MacBookPro7,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC APIC ASF! SBST ECDT SSDT SSDT SSDT MCFG
acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3)
EHC2(S3) ARPT(S5) GIGE(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2500 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2389.57 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-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 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 P8600 @ 2.40GHz, 2389.25 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,ES
T,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xf000, bus 0-4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (IXVE)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
mwait), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1
mwait), PSS
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"APP0001" at acpi0 not configured
"APP0003" at acpi0 not configured
acpials0 at acpi0: ALS0
"ACPI0002" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "3545797981023400290" type 3545797981528607052
oem "3545797981528673619"
cpu0: Enhanced SpeedStep 2389 MHz: speeds: 2394, 2128, 1862, 1596, 798 MHz
pci0 at mainbus0 bus 0
0:3:4: mem address conflict 0xd340/0x8
pchb0 at pci0 dev 0 function 0 "NVIDIA MCP89 Host" rev 0xa1
"NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 0 function 1 not configured
vendor "NVIDIA", unknown product 0x0d6d (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 0 not configured
vendor "NVIDIA", unknown product 0x0d6e (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 1 not configured
vendor "NVIDIA", unknown product 0x0d6f (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 2 not configured
vendor "NVIDIA", unknown product 0x0d70 (class memory subclass RAM, rev 0xa1)
at pci0 dev 1 function 3 not configured
vendor "NVIDIA", unknown product 0x0d71 (class memory subclass RAM, rev 0xa1)
at pci0 dev 2 function 0 not configured
vendor "NVIDIA", unknown product 0x0d72 (class memory subclass RAM, rev 0xa1)
at pci0 dev 2 function 1 not configured
pcib0 at pci0 dev 3 function 0 "NVIDIA MCP89 LPC" rev 0xa2
"NVIDIA MCP89 Memory" rev 0xa1 at pci0 dev 3 function 1 not configured
nviic0 at pci0 dev 3 function 2 "NVIDIA MCP89 SMBus" rev 0xa1
iic0 at nviic0
iic1
Re: minor updates to radiusd.8
On Sun, Sep 18, 2016 at 12:33:24PM -0400, Rob Pierce wrote: > New diff excluding the history section. > > Rob > fixed, thanks. jmc > Index: radiusd.8 > === > RCS file: /cvs/src/usr.sbin/radiusd/radiusd.8,v > retrieving revision 1.6 > diff -u -p -r1.6 radiusd.8 > --- radiusd.8 25 Aug 2015 01:12:59 - 1.6 > +++ radiusd.8 18 Sep 2016 16:32:01 - > @@ -29,6 +29,12 @@ The > .Nm > daemon implements the RADIUS protocol. > .Pp > +.Nm > +can be enabled during system boot by setting the following in > +.Pa /etc/rc.conf.local : > +.Pp > +.Dl radiusd_flags=\&"\&" > +.Pp > The options are as follows: > .Bl -tag -width Ds > .It Fl d > @@ -49,7 +55,10 @@ Only check the configuration file for va > Default configuration file. > .El > .Sh SEE ALSO > -.Xr radiusd.conf 5 > +.Xr radiusd.conf 5 , > +.Xr radiusctl 8 , > +.Xr rc.conf 8 > +.Sh STANDARDS > .Rs > .%R RFC 2865 > .%T "Remote Authentication Dial In User Service (RADIUS)"
Re: usb disk dirty after every reboot
Hi Jan,
On Mon, 19 Sep 2016 18:22:37 +0200 Jan Stary wrote:
>
> 9d24108772d1158c.a /backup ffs rw,softdep,noatime,nodev,noexec
>
With softdep everywhere, would this help in /etc/rc.shutdown?
for i in 4 3 2 1
do
sync
sleep ${i}
done
ral(4) problems on current/i396 ALIX
This is ALIX 2C1, just upgraded to current/i386 (dmesg below).
It serves as a wifi AP using ral(4). The console gets spammed with
ral0: sending data frame failed 0x02faaafa
This used to work fine since 5.9/i386.
$ cat /hostname.ral0
inet 192.168.33.1 255.255.255.0 NONE\
media autoselect mediaopt hostap nwid stare.cz chan 11 \
wpakey XXX
$ netstat -I ral0
NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls
ral0150000:11:09:0d:d3:36 310 327 326 120 0
ral01500 192.168.33/ 192.168.33.1 310 327 326 120 0
Typical wifi clients of this AP are the phones
and tablets in the family; they all seem to connect fine.
How can I help debug this?
Jan
OpenBSD 6.0-current (GENERIC) #2064: Mon Sep 19 20:35:29 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 432
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 133713920 (127MB)
avail mem = 118611968 (113MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
pcibios0 at bios0: rev 2.1 @ 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: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address
00:0d:b9:12:9f:2c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:0d:b9:12:9f:2d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:0d:b9:12:9f:2e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
ral0 at pci0 dev 12 function 0 "Ralink RT2560" rev 0x01: irq 9, address
00:11:09:0d:d3:36
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 15 function 2 "AMD CS5536 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, LBA, 7279MB, 14909328 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0,
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (bf940e6c7aaf2c50.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02f9aafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003fa
ral0: sending data frame failed 0x02faaafa
ral0: sending data frame failed 0x001003f
Re: error building -stable 6.0/amd64 from source on qemu
On Tuesday 20 September 2016 18:26:42 Joel Sing wrote: > On Tuesday 20 September 2016 09:54:31 soko.tica wrote: > > Hello, > > > > In trying to build -stable from source, I get an error. I have downloaded > > and unterred sys.tar.gz and src.tar.gz according to > > http://www.openbsd.org/faq/faq5.html#Release and updated the sources > > through cvs, according to the instructions http://man.openbsd.org/release > > . > > After I execute (as root, the first time doas produced the same error) > > > > #cd /usr/src && make build > > > > I get the following: > > > > cc > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i > > nc lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i > > n > > clude > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot > > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > > -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror > > -fno-stack-protector > > -DMDRANDOM > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i > > nc lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/i > > n > > clude > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot > > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > > -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW -DNOBYFOUR > > -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > t > > raid.c: In function 'sr_crypto_decrypt_keys': > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:155: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in > > this function) > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > t > > raid.c:155: error: (Each undeclared identifier is reported only once > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:155: error: for each function it appears in.) > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:156: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in > > this function) > > I'm not sure what you've done (since the actual commands you ran are not > specified), however this is -current source, not -stable. Further more > you've ended up with a mix - sys/dev/softraidvar.h is older than > sys/lib/libsa/softraid.c. Actually, sys/lib/libsa/softraid.c is using your installed headers - so your source is possibly all -current. > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > t > > raid.c:157: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:180: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:183: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:183: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:185: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:191: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:191: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:193: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/sof > > tr aid.c:198: error: dereferencing pointer to incomplete type > > *** Error 1 in sys/arch/amd64/stand/efiboot/bootx64 (:87 > > 'softraid.o') > > *** Error 1 in sys/arch/amd64/stand/efiboot (:48 'all') > > *** Error 1 in sys/arch/amd64/stand (:48 'all') > > *** Error 1 in sys/arch/amd64 (:48 'all') > > *** Error 1 in sys (:48 'all') > > *** Error 1 in . (:4
Re: error building -stable 6.0/amd64 from source on qemu[SOLVED]
Many thanks. That was it. On Tue, Sep 20, 2016 at 10:26 AM, Joel Sing wrote: > On Tuesday 20 September 2016 09:54:31 soko.tica wrote: > > Hello, > > > > In trying to build -stable from source, I get an error. I have downloaded > > and unterred sys.tar.gz and src.tar.gz according to > > http://www.openbsd.org/faq/faq5.html#Release and updated the sources > > through cvs, according to the instructions > http://man.openbsd.org/release . > > After I execute (as root, the first time doas produced the same error) > > > > #cd /usr/src && make build > > > > I get the following: > > > > cc > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/efi/inc > > lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/efi/in > > clude > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/boot > > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > > -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror > -fno-stack-protector > > -DMDRANDOM > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/efi/inc > > lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/efi/in > > clude > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../.. > /../../stand/boot > > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > > -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I. > > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW > -DNOBYFOUR > > -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/soft > > raid.c: In function 'sr_crypto_decrypt_keys': > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:155: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in > this > > function) > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/soft > > raid.c:155: error: (Each undeclared identifier is reported only once > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:155: error: for each function it appears in.) > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:156: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in > this > > function) > > I'm not sure what you've done (since the actual commands you ran are not > specified), however this is -current source, not -stable. Further more > you've > ended up with a mix - sys/dev/softraidvar.h is older than > sys/lib/libsa/softraid.c. > > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/soft > > raid.c:157: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:180: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:183: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:183: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:185: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:191: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:191: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:193: error: dereferencing pointer to incomplete type > > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > /lib/libsa/softr > > aid.c:198: error: dereferencing pointer to incomplete type > > *** Error 1 in sys/arch/amd64/stand/efiboot/bootx64 (:87 > > 'softraid.o') > > *** Error 1 in sys/arch/amd64/stand/efiboot (:48 'all') > > *** Error 1 in sys/arch/amd64/stand (:48 'all') > > *** Error 1 in sys/arch/amd64 (:48 'all') > > *** Error 1 in sys (:48 'all') > > *** Error 1 in . (:48 'all') > > *** Error 1 in /usr/src (Makefile:82 'build')
Re: error building -stable 6.0/amd64 from source on qemu
On Tuesday 20 September 2016 09:54:31 soko.tica wrote: > Hello, > > In trying to build -stable from source, I get an error. I have downloaded > and unterred sys.tar.gz and src.tar.gz according to > http://www.openbsd.org/faq/faq5.html#Release and updated the sources > through cvs, according to the instructions http://man.openbsd.org/release . > After I execute (as root, the first time doas produced the same error) > > #cd /usr/src && make build > > I get the following: > > cc > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/inc > lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/in > clude > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror -fno-stack-protector > -DMDRANDOM > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/inc > lude/amd64 -DEFIBOOT -DNEEDS_HEAP_H > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/in > clude > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot > -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID > -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I. > -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW -DNOBYFOUR > -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft > raid.c: In function 'sr_crypto_decrypt_keys': > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:155: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in this > function) > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft > raid.c:155: error: (Each undeclared identifier is reported only once > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:155: error: for each function it appears in.) > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:156: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in this > function) I'm not sure what you've done (since the actual commands you ran are not specified), however this is -current source, not -stable. Further more you've ended up with a mix - sys/dev/softraidvar.h is older than sys/lib/libsa/softraid.c. > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/soft > raid.c:157: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:180: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:183: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:183: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:185: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:191: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:191: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:193: error: dereferencing pointer to incomplete type > /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softr > aid.c:198: error: dereferencing pointer to incomplete type > *** Error 1 in sys/arch/amd64/stand/efiboot/bootx64 (:87 > 'softraid.o') > *** Error 1 in sys/arch/amd64/stand/efiboot (:48 'all') > *** Error 1 in sys/arch/amd64/stand (:48 'all') > *** Error 1 in sys/arch/amd64 (:48 'all') > *** Error 1 in sys (:48 'all') > *** Error 1 in . (:48 'all') > *** Error 1 in /usr/src (Makefile:82 'build') > # ^D > > Script done on Tue Sep 20 07:16:08 2016 > == > > Thanks in advance for your input.
Re: 6.0 appreciation
There are no callouts for suggestions. The themes are chosen internally, described on http://www.openbsd.org/lyrics.html. Thanks for enjoying the releases, and of course: Be sure to drink your OpenBSD. Or Ovaltine. I mean OpenBSD. On 2016 Sep 20 (Tue) at 13:52:39 +1000 (+1000), Aaron Mason wrote: :Can I just say that if I'd known you guys were doing tech-inspired :parodies for this release's songs, I'd have submitted my effort, :though it isn't a Pink Floyd parody - it's Crash Test Dummies' "In the :Days of the Caveman", but about mainframes. If I missed the callout, :that'll teach me to walk away from the mailing list for ages. : :On Tue, Sep 20, 2016 at 3:37 AM, Jack J. Woehr wrote: :> Props to the team. It's amazing that with the rapid march to W^X that 6.0 :> works at all, but it works well. :> :> All the ports I need are updated successfully with only one that I would :> hope for being broken (Seamonkey). :> :> I can continue to do everything I need to do to stay in business on OpenBSD :> 6.0. Donation sent. Thanks! -- Those who do not do politics will be done in by politics. -- French Proverb
error building -stable 6.0/amd64 from source on qemu
Hello, In trying to build -stable from source, I get an error. I have downloaded and unterred sys.tar.gz and src.tar.gz according to http://www.openbsd.org/faq/faq5.html#Release and updated the sources through cvs, according to the instructions http://man.openbsd.org/release . After I execute (as root, the first time doas produced the same error) #cd /usr/src && make build I get the following: cc -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/include/amd64 -DEFIBOOT -DNEEDS_HEAP_H -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/include -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID -D_STANDALONE -nostdinc -fno-builtin -Os -Wall -Werror -fno-stack-protector -DMDRANDOM -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/include/amd64 -DEFIBOOT -DNEEDS_HEAP_H -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/.. -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/efi/include -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../stand/boot -ffreestanding -std=gnu99 -fshort-wchar -fPIC -mno-red-zone -DSOFTRAID -D_STANDALONE -nostdinc -fno-builtin -Wno-pointer-sign -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../.. -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../libsa -I. -I/usr/src/sys/arch/amd64/stand/efiboot/bootx64 -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD -DHEAP_LIMIT=0xc0 -c /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c: In function 'sr_crypto_decrypt_keys': /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:155: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:155: error: 'SR_CRYPTOKDFT_PKCS5_PBKDF2' undeclared (first use in this function) /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:155: error: (Each undeclared identifier is reported only once /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:155: error: for each function it appears in.) /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:156: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:156: error: 'SR_CRYPTOKDFT_BCRYPT_PBKDF' undeclared (first use in this function) /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:157: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:180: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:183: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:183: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:185: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:191: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:191: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:193: error: dereferencing pointer to incomplete type /usr/src/sys/arch/amd64/stand/efiboot/bootx64/../../../../../lib/libsa/softraid.c:198: error: dereferencing pointer to incomplete type *** Error 1 in sys/arch/amd64/stand/efiboot/bootx64 (:87 'softraid.o') *** Error 1 in sys/arch/amd64/stand/efiboot (:48 'all') *** Error 1 in sys/arch/amd64/stand (:48 'all') *** Error 1 in sys/arch/amd64 (:48 'all') *** Error 1 in sys (:48 'all') *** Error 1 in . (:48 'all') *** Error 1 in /usr/src (Makefile:82 'build') # ^D Script done on Tue Sep 20 07:16:08 2016 == Thanks in advance for your input.
Re: cuaU0 problems
I am not, that is exactly what I was pointing out. On 20 September 2016 03:06:20 Zé Loff wrote: On Tue, Sep 20, 2016 at 01:30:35AM +, Stuart Henderson wrote: On 2016-09-19, Fred wrote: > According to the dmesg you have: > > puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 1 com > com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo > com4: probed fifo depth: 0 bytes > did you try cuaU3? That one would be (tty|cua)04 (which will need additional device nodes creating with MAKEDEV. But it's PCI not USB. It might be behind one of these disabled hubs though: uhub2 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 uhub2: device problem, disabling port 1 uvideo0 at uhub2 port 6 configuration 1 interface 0 "Chicony Electronics Co., Ltd. Integrated Camera" rev 2.00/7.52 addr 3 video0 at uvideo0 uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 uhub3: device problem, disabling port 5 (btw, dmesg after the email signature means it gets stripped by most email programs, so hard to quote :) Aren't you guys mixing com* and ucom*? If it is a USB dongle it should show up as ucom0 on dmesg. (plus, it used to work as cuaU0) --
