Problem with implicit rule in make
Hi,
I have the following simple Makefile:
CPPFLAGS = -I../inc
all: libcc.a
libcc.a: libcc.a(die.o) libcc.a(xcalloc.o) libcc.a(xmalloc.o)
clean:
rm -f *.o *.a
which should generate a static library using a default rule. This Makefile
works in another systems, and it is accepted by POSIX standards [1]. The
rule in /usr/share/mk/sys.mk is:
.c.a:
${COMPILE.c} ${.IMPSRC}
${AR} ${ARFLAGS} $@ $*.o
rm -f $*.o
but when I run make I get this output:
$ make
cc -O2 -pipe -I../inc -c die.c
cc -O2 -pipe -I../inc -c xcalloc.c
cc -O2 -pipe -I../inc -c xmalloc.c
Anyone could point me what is the problem?
Regards,
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
--
Roberto E. Vargas Caballero
Re: receive error 54 from NetApp NFS server
On Fri, May 2, 2014 at 4:39 AM, Donovan Watteau wrote: > On Tue, 29 Apr 2014, Philip Guenther wrote: > > On Tue, Apr 29, 2014 at 8:17 AM, Donovan Watteau > wrote: > > > I have various mountpoints from a NetApp NFS server with I use on > > > OpenBSD/amd64 5.5. > > > > > > $ grep nfs /etc/fstab > > >server:/vol/foobar /vol/foobar nfs > noauto,rw,nodev,nosuid,noatime,noexec,nfsv3,tcp,soft,intr,noac,-x=300,-t=1000,acregmin=3,acregmax=5,-r=65536,-w=65536 > 0 0 > > >(and some other mountpoints with the same options) > > > > That's a lot of knob turning. What documentation or testing led to > > you adding the tcp, noac, ac*, -x, -t, -r, and -w options? > > Indeed, I don't like turning knobs either, but this problem still > appears with a much simpler fstab (see below). > > My documentation is mount_nfs(8), and "Managing NFS and NIS" > (recommended by books.html). > > Basically: > * tcp: better suited our use case, with a noticeable speed improvement > and a better reliability regarding the files we need to go through > NFS. > * noac: a leftover, but removing it doesn't fix the problem. * ac: required for our use case. > How is that possible when you also set "noac" to *COMPLETELY DISABLE* attribute caching? Is it not obvious that at least *one* of those settings is completely bogus? This casts doubt on your claim that ac* are "required" for your use case. > * -x/-t: we needed a faster timeout/retry rate, but it may be too high. > ...so you just jammed in some bigger values? You *raised* the timeouts and retry counts, meaning a failed server will be *slower* to timeout and/or retry, not faster! Heck, your -t value is above the value that the kernel will clamp it to! What Problem Are You Trying To Solve? (tm) Using a soft,intr mount (so it's completely unreliable already) and then jacking the retry and timeout counts suggests that maybe NFS is the Wrong Solution for your problem, and an rsync'ed mirror makes more sense. > > > However, when I do a simple "ls /vol/foobar" after an hour without > > > anything else using this mountpoint, this appears in the logs: > > > > > > Apr 29 13:53:46 puffy /bsd: receive error 54 from nfs server > server:/vol/foobar > > > Apr 29 13:53:48 puffy last message repeated 833 times > > > > > > $ grep 54 /usr/include/sys/errno.h > > > #define ECONNRESET 54 /* Connection reset by peer */ > > > > Is there an idle timeout on the server or flaky network (NAT?) between > > this client and the server? > ... > > TCP connection is being dropped for some reason and then it takes a > > moment to be reopened when you try to use it again. > > Yes, I was wondering whether there is something left to be configured > on the OpenBSD side to prevent that (since the problem doesn't show up > on Debian running on the same machine), or should I look for a problem > on the NFS server or Cisco side? > A TCP connection, which should be able to stay open, idle, indefinitely, is being reset (as in, a packet with the RST flag is being received!). Linux apparently decides to silently spend CPU and packets and hide that something is breaking connections. If you're fine with that behavior, then just ignore the error messages from the OpenBSD kernel: it retries the connection for you already and is 'just' letting you know that your NFS server or network hates you (and maybe you should fix that). If you don't like that it does so, well, you have the source. Philip Guenther
Re: Problem with implicit rule in make
On Sat, May 03, 2014 at 10:23:58AM +0200, Roberto E. Vargas Caballero wrote:
> Hi,
>
> I have the following simple Makefile:
>
> CPPFLAGS = -I../inc
>
> all: libcc.a
>
> libcc.a: libcc.a(die.o) libcc.a(xcalloc.o) libcc.a(xmalloc.o)
>
> clean:
> rm -f *.o *.a
>
> which should generate a static library using a default rule. This Makefile
> works in another systems, and it is accepted by POSIX standards [1]. The
> rule in /usr/share/mk/sys.mk is:
>
> .c.a:
> ${COMPILE.c} ${.IMPSRC}
> ${AR} ${ARFLAGS} $@ $*.o
> rm -f $*.o
>
> but when I run make I get this output:
>
> $ make
> cc -O2 -pipe -I../inc -c die.c
> cc -O2 -pipe -I../inc -c xcalloc.c
> cc -O2 -pipe -I../inc -c xmalloc.c
>
> Anyone could point me what is the problem?
We don't have any rules that actually handles archive members in the
default setup.
The rule you quote would only work for creating an archive based on a
single c file.
There is nothing in the posix description that says anything about default
rules to recreate archives.
Your "posix system" is using an extended set of rules to create libraries.
(note that the rule above is fairly useless obviously, but it's what's
mandated by posix...)
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On 05/02/14 23:18, Thorsten Bonck wrote:
> On Fri, May 02, 2014 at 08:14:40PM +, Peter J. Philipp wrote:
>> On Fri, May 02, 2014 at 09:14:16PM +0200, thors...@bonck.net wrote:
maybe you could try to put pppoe0 on rl0, untag vlan10 on switch port
where rl0 is connected and tag other vlans on the same port ...
>>>
>>> Sadly, that is not possible for me.
>>> rl0 is directly connected to a Ubiquiti NanoStation M, which is setup as
>>> a blackbox transparent bridge by my ISP.
>>> vlan id 10 is also required by my ISP for all PPP/PPPoE stuff.
>>> I could put a tagging switch in between rl0 and the bridge as a last
>>> resort, but for right now I am still looking for a reason why 5.4 works
>>> and 5.5 seems to answer to a wrong MAC.
>>>
>>> Looking through the changes from 5.4 I found "Stop defining
>>> SIOC{S,G}ETVLAN as SIOC{S,G}IFGENERIC. Lets vlan(4) handle
>>> pppoe(4)-specific ioctls and vice versa without smashing the stack of
>>> the caller". Is it possible my problem is somehow connected to that?
>>
>> Hello,
>>
>> I'd probably do a tcpdump -v -n -e -s 200 -X -i rl0 as well.. perhaps you
>> can see somewhere where the aa:aa:aa:aa:aa:aa is coming from. Perhaps there
>> is an offset logic error somewhere as the pppoe driver reads the PADO source
>> address from the mbuf etherheader which was prepended. If you can't make
>> out any 's in the frame then that's further suspicous.
>
> After some staring at the dumped frames, I can describe the problem more
> detailed.
> Assume listed devices to have following macs:
>
> rl011:22:33:44:55:66
> PPPoE server aa:bb:cc:dd:ee:ff
>
> rl0 broadcasts PADI to ff:ff:ff:ff:ff:ff.
> PPPoE servers mac sends a PADO to rl0 mac.
> rl0 sends a PADR to mac aa:bb:55:66:aa:bb.
> timeout happens, since no device with aa:bb:55:66:aa:bb exists in the
> network.
>
> Now change rl0 mac to 11:22:33:44:77:88:
> PADI,PADO phase unchanged.
> rl0 sends a PADR to mac aa:bb:77:88:aa:bb.
>
> I only have a very basic understanding of C and basically no
> understanding of the OpenBSD kernel.
> The PADR should be assembled around line 703 in src/sys/net/if_pppoe.c
> but I could not find any clues where this mix up happens.
>
> Best Regards,
> Thorsten
>
Hi,
I'm seeing something that may be similar as you, but I can't track it
down, so I'm going to put out what I got.
In my test environment I set up a QEMU host that has a NIC on bridge0
and vether0 on my main host. On the main host I have configured vlan0
to be a member of vether0 like so:
vlan0: flags=8947
mtu 1500
lladdr fe:e1:ba:d0:65:cd
priority: 0
vlan: 10 parent interface: vether0
groups: vlan
status: active
inet6 fe80::fce1:baff:fed0:65cd%vlan0 prefixlen 64 scopeid 0x16
inside the qemu I run pppoe0 inside a vlan with the same tag on its
interface that faces bridge0.
When I sniff then simultaneously with tcpdump on vether0 and vlan0 on
the main host then I get the following:
vether0:
12:02:18.008513 48:01:09:03:04:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid
10 pri 3 PPPoE-Discovery
code Initiation, version 1, type 1, id 0x, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \005^\334G
: 4801 0903 0407 8100 600a ..H...`.
0010: 8863 1109 000c 0101 0103 0004 .c..
0020: 055e dc47.^.G
vlan0:
12:04:18.009041 48:01:09:03:04:07 60:0a:88:63:ff:ff 8863 32: PPPoE-Discovery
code Initiation, version 1, type 1, id 0x, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \005^\334G
: 600a 8863 4801 0903 0407 8863 1109 `..c..H..c..
0010: 000c 0101 0103 0004 055e dc47 .^.G
As you probably can see on the first glance is that the MAC address for
the received changed. It took 600a 8863, which is the vlan tag and the
ethernet type, and overwrote the ethernet dest address with those 4
bytes resulting in 60:0a:88:63:ff:ff. My npppd that I had set up on
vlan0 on the main host doesn't see it as a broadcast anymore and thus it
can't offer a PADO.
Yours, Thorsten, is probably the same concept almost just it's reversed.
Now to my environment.
The mainhost is OpenBSD-current...
vether0 looks like this:
vether0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:65:cd
priority: 0
groups: vether
media: Ethernet autoselect
status: active
inet6 fe80::fce1:baff:fed0:65cd%vether0 prefixlen 64 scopeid 0x5
...
I'm sorry for being all over the place with the data. And I have an
inquiry to the vlan responsible person at OpenBSD:
in /sys/net/if_vlan.c: vlan_input() I see this:
/*
* Having found a valid vlan interface corresponding to
* the given source interface and vlan tag, remove the
* encapsulation, and run the real packet through
* ether_input() a second time (it ha
Re: Weird disklabel problem
> So marking a partition as 'Active/Bootable', (the 00 -> 80 change) > causes your system to hang. Apparently Linux does this when you > 'Label' it. The OpenBSD installer does it for you when you > select 'Whole disk'. Nothing obviously to do with the disklabel. You > could test this by manually > setting the 'Active' flag on the working Linux MBR. Or, conversely > unsetting the flag with fdisk > after the OpenBSD install but before rebooting. In either case does it > get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel -> freeze - Bootflag on, no disklabel -> freeze - Bootflag off, with disklabel -> freeze - Bootflag on, with diskalbel -> freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off -> freeze - Bootflag on -> freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer
Re: Problem with implicit rule in make
> There is nothing in the posix description that says anything about default > rules to recreate archives. Maybe I am wrong, but this part of posix seems to say another thing: 5. The most common use of the archive interface follows. Here, it is assumed that the source files are all C-language source: lib: lib(file1.o) lib(file2.o) lib(file3.o) @echo lib is now up-to-date The .c.a rule is used to make file1.o, file2.o, and file3.o and insert them into lib. You can check it in Examples section of http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html. Regards, -- Roberto E. Vargas Caballero
Re: Weird disklabel problem
On 3 May 2014 06:27, Martijn Rijkeboer wrote: >> So marking a partition as 'Active/Bootable', (the 00 -> 80 change) >> causes your system to hang. Apparently Linux does this when you >> 'Label' it. The OpenBSD installer does it for you when you >> select 'Whole disk'. Nothing obviously to do with the disklabel. You >> could test this by manually >> setting the 'Active' flag on the working Linux MBR. Or, conversely >> unsetting the flag with fdisk >> after the OpenBSD install but before rebooting. In either case does it >> get further before noticing that it can't boot? > > > I did some testing with the following results: > > 1. Partition disk with Linux gparted and use cfdisk to set partition > type to A6 and OpenBSD disklabel to set disklabel. > (partition: 0; start: 2048; size: 1953519616) > - Bootflag off, no disklabel -> boot > - Bootflag on, no disklabel -> boot > - Bootflag off, with disklabel -> freeze > - Bootflag on, with disklabel -> freeze > > 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). > (partition: 3, start: 64; size: 1953520001) > - Bootflag off, no disklabel -> freeze > - Bootflag on, no disklabel -> freeze > - Bootflag off, with disklabel -> freeze > - Bootflag on, with diskalbel -> freeze > > 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). > (partition: 3: start: 2048; size: 1953519616) > - Bootflag off, no disklabel -> boot > - Bootflag on, no disklabel -> boot > - Bootflag off, with disklabel -> freeze > - Bootflag on, with disklabel -> freeze > > 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). > (partition: 3, start: 64; size: 1953520001) > - Bootflag off -> freeze > - Bootflag on -> freeze > > It looks like the motherboard doesn't like the partition to start at 64 and > it also doesn't like disklabels. > > Any suggestions on what to try next or should I just buy a different > motherboard? > > Kind regards, > > > Martijn Rijkeboer > Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken
Re: Weird disklabel problem
On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer wrote: So marking a partition as 'Active/Bootable', (the 00 -> 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel -> freeze - Bootflag on, no disklabel -> freeze - Bootflag off, with disklabel -> freeze - Bootflag on, with diskalbel -> freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off -> freeze - Bootflag on -> freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken such problems also seem to occur on some ASUS boards -- but only when SATA drives are used. OpenBSD did boot fine from a USB stick: http://marc.info/?l=openbsd-misc&m=137862502730004&w=2 Best Regards Andreas
Re: Weird disklabel problem
On 3 May 2014 08:49, Andreas Bartelt wrote: > On 05/03/14 14:10, Kenneth Westerback wrote: >> >> On 3 May 2014 06:27, Martijn Rijkeboer wrote: So marking a partition as 'Active/Bootable', (the 00 -> 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? >>> >>> >>> >>> I did some testing with the following results: >>> >>> 1. Partition disk with Linux gparted and use cfdisk to set partition >>> type to A6 and OpenBSD disklabel to set disklabel. >>> (partition: 0; start: 2048; size: 1953519616) >>> - Bootflag off, no disklabel -> boot >>> - Bootflag on, no disklabel -> boot >>> - Bootflag off, with disklabel -> freeze >>> - Bootflag on, with disklabel -> freeze >>> >>> 2. Partition disk with OpenBSD fdisk + disklabel (installer start + >>> size). >>> (partition: 3, start: 64; size: 1953520001) >>> - Bootflag off, no disklabel -> freeze >>> - Bootflag on, no disklabel -> freeze >>> - Bootflag off, with disklabel -> freeze >>> - Bootflag on, with diskalbel -> freeze >>> >>> 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). >>> (partition: 3: start: 2048; size: 1953519616) >>> - Bootflag off, no disklabel -> boot >>> - Bootflag on, no disklabel -> boot >>> - Bootflag off, with disklabel -> freeze >>> - Bootflag on, with disklabel -> freeze >>> >>> 4. Partition disk with OpenBSD fdisk with type 83 (installer start + >>> size). >>> (partition: 3, start: 64; size: 1953520001) >>> - Bootflag off -> freeze >>> - Bootflag on -> freeze >>> >>> It looks like the motherboard doesn't like the partition to start at 64 >>> and >>> it also doesn't like disklabels. >>> >>> Any suggestions on what to try next or should I just buy a different >>> motherboard? >>> >>> Kind regards, >>> >>> >>> Martijn Rijkeboer >>> >> >> Looking around I found that one of my machines has a gigabyte >> GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk >> was from another machine and had a working OpenBSD system. Lo and >> behold, plugged it into the GA-Z87-D3HP board and the system hung in >> the POST. Put the disk back on the other system, dd'ed /dev/zero over >> the disklabel, moved it back and the system booted. >> >> How extremely interesting. And weird. >> >> Ken >> >> > > such problems also seem to occur on some ASUS boards -- but only when SATA > drives are used. OpenBSD did boot fine from a USB stick: > http://marc.info/?l=openbsd-misc&m=137862502730004&w=2 > > Best Regards > Andreas Indeed. Experiments here show that plugging in a pci <-> sata card to avoid the Intel SATA chip makes the disk work fine. Disks smaller than 1TB also work. So I'm guessing it's something magical about 4K-sector disks presenting themselves as 512-byte sector disks that is the source of problems. I'm still a bit fogged as to how a disklabel triggers the problem. Ken
Re: receive error 54 from NetApp NFS server
On Sat, 3 May 2014, Philip Guenther wrote: > On Fri, May 2, 2014 at 4:39 AM, Donovan Watteau wrote: > * noac: a leftover, but removing it doesn't fix the problem. > > * ac: required for our use case. > > > How is that possible when you also set "noac" to *COMPLETELY DISABLE* > attribute caching? Is it not obvious that at least *one* of those settings > is completely bogus? This casts doubt on your claim that ac* are "required" > for your use case. > > ... As I said, "noac" was a leftover (from an unrelated previous test). Which has no effect on the problem I was asking help for, because it still happens with "rw,noauto,tcp". > > Yes, I was wondering whether there is something left to be configured > > on the OpenBSD side to prevent that (since the problem doesn't show up > > on Debian running on the same machine), or should I look for a problem > > on the NFS server or Cisco side? > > > A TCP connection, which should be able to stay open, idle, indefinitely, is > being reset (as in, a packet with the RST flag is being received!). Linux > apparently decides to silently spend CPU and packets and hide that something > is breaking connections. If you're fine with that behavior, then just > ignore the error messages from the OpenBSD kernel: it retries the connection > for you already and is 'just' letting you know that your NFS server or > network hates you (and maybe you should fix that). If you don't like that > it does so, well, you have the source. So: there's indeed nothing to configure on OpenBSD to avoid this behaviour; the problem lies elsewhere in the network or with the NFS server (which I don't manage). That's what I wanted to know. I'm not bothering you any further. Thanks.
RTL8402 realtek card reader
Hello there ... I had to produce this ugly one on fresh 5.5 release in order to get my cardreader operational. diff on pcidevs : 5687a5688 > product REALTEK RTL8402 0x5286 RTL8402 Card Reader and diff on rtsx_pci.c : 61c61,62 < PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTS5229) --- > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTS5229 || > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTL8402) tested with GENERIC.MP on amd64 with W310CZ-T notebook and SDHC card freshly extracted from my camera. Eric.
Re: RTL8402 realtek card reader
On Sat, May 03, 2014 at 03:52:30PM +0200, Eric Huiban wrote: > Hello there ... > > I had to produce this ugly one on fresh 5.5 release in order to get my > cardreader operational. > > diff on pcidevs : > > 5687a5688 > > product REALTEK RTL8402 0x5286 RTL8402 Card Reader > > and diff on rtsx_pci.c : > > 61c61,62 > < PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTS5229) > --- > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTS5229 || > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_REALTEK_RTL8402) > > tested with GENERIC.MP on amd64 with W310CZ-T notebook and SDHC card > freshly extracted from my camera. > > Eric. Nice, thanks. Can you also send me a dmesg and pcidump -vvv output please?
Re: Weird disklabel problem
On 05/03/14 15:01, Kenneth Westerback wrote: On 3 May 2014 08:49, Andreas Bartelt wrote: On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer wrote: So marking a partition as 'Active/Bootable', (the 00 -> 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel -> freeze - Bootflag on, no disklabel -> freeze - Bootflag off, with disklabel -> freeze - Bootflag on, with diskalbel -> freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel -> boot - Bootflag on, no disklabel -> boot - Bootflag off, with disklabel -> freeze - Bootflag on, with disklabel -> freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off -> freeze - Bootflag on -> freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken such problems also seem to occur on some ASUS boards -- but only when SATA drives are used. OpenBSD did boot fine from a USB stick: http://marc.info/?l=openbsd-misc&m=137862502730004&w=2 Best Regards Andreas Indeed. Experiments here show that plugging in a pci <-> sata card to avoid the Intel SATA chip makes the disk work fine. Disks smaller than 1TB also work. So I'm guessing it's something magical about 4K-sector disks presenting themselves as 512-byte sector disks that is the source of problems. I'm still a bit fogged as to how a disklabel triggers the problem. I also saw these problems with a Chronos MKNSSDCR120GB SSD drive. I don't know which sector size these drives use internally... Actually, I didn't get any of my drives to work with OpenBSD on this mainboard. I don't know if it helps -- I've also unsuccessfully tested a 320GB WD3200AAKS from 08/2010. Best Regards Andreas
Page fault trap when switching from wscons to X and wsmoused is running
Hello,
I'm experiencing a systematic crash in a fresh 5.5 install, starting the
wsmoused service and then switch from console to X.
The following steps reliably reproduce the problem:
1) (from a X session) sudo wsconsctl display.focus=1
2) (from the wscons) sudo /etc/rc.d/wsmoused -f start
3) (from the wscons) sudo wsconsctl display.focus=4
(sometimes I need to switch back and forth between wscons and X to
trigger the fault; as far as I can tell, it didn't happen on 5.4.
This is the output of a ddb trace:
kernel: page fault trap, code=0
Stopped at wsmux_do_close+0x35: cmpq %r12,0x98(%rbx)
ddb{0}>trace
wsmux_do_close() at wsmux_do_close+0x35
wsmuxclose() at wsmuxclose+0x42
spec_close() at spec_close+0x232
VOP_CLOSE() at VOP_CLOSE+0x2f
vn_close() at vn_close+0x52
vn_closefile() at vn_closefile+0x6d
fdrop() at fdrop+0x28
closef() at closef+0xab
sysclose() at sys_close+0x52
syscall() at syscall+0x24f
--- syscall (number 6) ---
end of kernel
end trace frame: 0x7f7ce700, count: -10
0x142785b0157a:
ddb{0}>
I found a thread initially describing a similar issue, but then
focusing on a different kind of crash, which unfortunately doesn't help
me at all:
http://openbsd.7691.n7.nabble.com/Hard-Freeze-with-Snapshots-After-Aug-19-on-ThinkPad-X1-Carbon-td233555.html
Tested with GENERIC.MP/amd64 on a Lenovo R61:
just22@poseidon:[~]> uname -a
OpenBSD poseidon.atlantide.net 5.5 GENERIC.MP#315 amd64
dmesg output follows:
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2087387136 (1990MB)
avail mem = 2023268352 (1929MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (73 entries)
bios0: vendor LENOVO version "7LETC1WW (2.21 )" date 07/01/2008
bios0: LENOVO 7735WX2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT ASF! SSDT SSDT SSDT
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) IGBE(S4) EXP0(S4)
EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3)
USB3(S3) USB4(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz, 2294.67 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz, 2094.76 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB4, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T5264" serial 4317 type LION oem "Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2294 MHz: speeds: 2101, 2100, 1600, 1200, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM965 Host" rev 0x0c
vga1 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM965 Video" rev 0x0c at pci0 dev 2 function 1 not configured
em0 at pci0 dev 25 function 0 "Intel ICH8 IGP M AMT" rev 0x03: msi, address
00:21:86:94:34:8e
uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x03: apic 1 int 21
ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x03: apic 1 int 22
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHC
Re: Problems with PPPoE, VLAN, 5.5 (amd64)
On Sat, May 03, 2014 at 12:20:24PM +0200, Peter J. Philipp wrote:
>
> 12:02:18.008513 48:01:09:03:04:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid
> 10 pri 3 PPPoE-Discovery
> code Initiation, version 1, type 1, id 0x, length 12
> tag Service-Name, length 0
> tag Host-Uniq, length 4 \005^\334G
> : 4801 0903 0407 8100 600a ..H...`.
> 0010: 8863 1109 000c 0101 0103 0004 .c..
> 0020: 055e dc47.^.G
>
>
> vlan0:
>
> 12:04:18.009041 48:01:09:03:04:07 60:0a:88:63:ff:ff 8863 32: PPPoE-Discovery
> code Initiation, version 1, type 1, id 0x, length 12
> tag Service-Name, length 0
> tag Host-Uniq, length 4 \005^\334G
> : 600a 8863 4801 0903 0407 8863 1109 `..c..H..c..
> 0010: 000c 0101 0103 0004 055e dc47 .^.G
>
>
> As you probably can see on the first glance is that the MAC address for
> the received changed. It took 600a 8863, which is the vlan tag and the
> ethernet type, and overwrote the ethernet dest address with those 4
> bytes resulting in 60:0a:88:63:ff:ff. My npppd that I had set up on
> vlan0 on the main host doesn't see it as a broadcast anymore and thus it
> can't offer a PADO.
>
> Yours, Thorsten, is probably the same concept almost just it's reversed.
>
> Now to my environment.
>
> The mainhost is OpenBSD-current...
>
> vether0 looks like this:
>
> vether0: flags=8943 mtu 1500
> lladdr fe:e1:ba:d0:65:cd
> priority: 0
> groups: vether
> media: Ethernet autoselect
> status: active
> inet6 fe80::fce1:baff:fed0:65cd%vether0 prefixlen 64 scopeid 0x5
> ...
>
> I'm sorry for being all over the place with the data. And I have an
> inquiry to the vlan responsible person at OpenBSD:
>
>
> in /sys/net/if_vlan.c: vlan_input() I see this:
>
>
> /*
> * Having found a valid vlan interface corresponding to
> * the given source interface and vlan tag, remove the
> * encapsulation, and run the real packet through
> * ether_input() a second time (it had better be
> * reentrant!).
> */
> m->m_pkthdr.rcvif = &ifv->ifv_if;
> if (m->m_flags & M_VLANTAG) {
> m->m_flags &= ~M_VLANTAG;
> } else {
> eh->ether_type = mtod(m, u_int16_t *)[1];
> m->m_len -= EVL_ENCAPLEN;
> m->m_data += EVL_ENCAPLEN;
> m->m_pkthdr.len -= EVL_ENCAPLEN;
> }
>
>
> in the else statement, isn't the manipulation of the mbuf the same as an
> m_adj(m, EVL_ENCAPLEN); ?
>
> If not, pardon my ignorance/newbishness.
Hi list,
I wrote many many debug printf's into net/if_vlan.c's vlan_input() and I can
pinpoint at what function it changes the value of struct ether_header *eh.
Here is what my debugs look like against a 5.5 source and against cat -n:
272
273 printf("check 1: %s\n", ether_sprintf((unsigned char
*)eh->ether_dhost));
274 if (m->m_flags & M_VLANTAG) {
275 etype = ETHERTYPE_VLAN;
276 tagh = vlan_tagh;
277 } else {
278 if (m->m_len < EVL_ENCAPLEN &&
279 (m = m_pullup(m, EVL_ENCAPLEN)) == NULL) {
280 ifp->if_ierrors++;
281 return (0);
282 }
283 printf("check 1a: %s\n", ether_sprintf((unsigned char
*)eh->ether_dhost));
284
285 etype = ntohs(eh->ether_type);
286 printf("check 1b: %s\n", ether_sprintf((unsigned char
*)eh->ether_dhost));
287 tagh = etype == ETHERTYPE_QINQ ? svlan_tagh : vlan_tagh;
288 printf("check 1c: %s\n", ether_sprintf((unsigned char
*)eh->ether_dhost));
-
The result is this:
check 1: ff:ff:ff:ff:ff:ff
check 1a: 60:0a:88:63:ff:ff
check 1b: 60:0a:88:63:ff:ff
so at the point between check 1 and check 1a is the offending function that
changes *eh. it's m_pullup().
Now then I'll leave it there as that's way over my head, but perhaps I've
done the basic work for someone looking over this.
Good luck Thorsten!
-peter
Re: Weird disklabel problem
On 3 May 2014 10:13, Andreas Bartelt wrote: > On 05/03/14 15:01, Kenneth Westerback wrote: >> >> On 3 May 2014 08:49, Andreas Bartelt wrote: >>> >>> On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer wrote: >> >> >> So marking a partition as 'Active/Bootable', (the 00 -> 80 change) >> causes your system to hang. Apparently Linux does this when you >> 'Label' it. The OpenBSD installer does it for you when you >> select 'Whole disk'. Nothing obviously to do with the disklabel. You >> could test this by manually >> setting the 'Active' flag on the working Linux MBR. Or, conversely >> unsetting the flag with fdisk >> after the OpenBSD install but before rebooting. In either case does it >> get further before noticing that it can't boot? > > > > > I did some testing with the following results: > > 1. Partition disk with Linux gparted and use cfdisk to set partition > type to A6 and OpenBSD disklabel to set disklabel. > (partition: 0; start: 2048; size: 1953519616) > - Bootflag off, no disklabel -> boot > - Bootflag on, no disklabel -> boot > - Bootflag off, with disklabel -> freeze > - Bootflag on, with disklabel -> freeze > > 2. Partition disk with OpenBSD fdisk + disklabel (installer start + > size). > (partition: 3, start: 64; size: 1953520001) > - Bootflag off, no disklabel -> freeze > - Bootflag on, no disklabel -> freeze > - Bootflag off, with disklabel -> freeze > - Bootflag on, with diskalbel -> freeze > > 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). > (partition: 3: start: 2048; size: 1953519616) > - Bootflag off, no disklabel -> boot > - Bootflag on, no disklabel -> boot > - Bootflag off, with disklabel -> freeze > - Bootflag on, with disklabel -> freeze > > 4. Partition disk with OpenBSD fdisk with type 83 (installer start + > size). > (partition: 3, start: 64; size: 1953520001) > - Bootflag off -> freeze > - Bootflag on -> freeze > > It looks like the motherboard doesn't like the partition to start at 64 > and > it also doesn't like disklabels. > > Any suggestions on what to try next or should I just buy a different > motherboard? > > Kind regards, > > > Martijn Rijkeboer > Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken >>> >>> such problems also seem to occur on some ASUS boards -- but only when >>> SATA >>> drives are used. OpenBSD did boot fine from a USB stick: >>> http://marc.info/?l=openbsd-misc&m=137862502730004&w=2 >>> >>> Best Regards >>> Andreas >> >> >> Indeed. Experiments here show that plugging in a pci <-> sata card to >> avoid the Intel SATA chip makes the disk work fine. >> >> Disks smaller than 1TB also work. So I'm guessing it's something >> magical about 4K-sector disks presenting themselves as 512-byte sector >> disks that is the source of problems. I'm still a bit fogged as to how >> a disklabel triggers the problem. >> > > I also saw these problems with a Chronos MKNSSDCR120GB SSD drive. I don't > know which sector size these drives use internally... > > Actually, I didn't get any of my drives to work with OpenBSD on this > mainboard. I don't know if it helps -- I've also unsuccessfully tested a > 320GB WD3200AAKS from 08/2010. > > Best Regards > Andreas OK, I got it booting. In a fairly useless config, but ... Booting from a -current amd64 cd55.iso cd-rom, I (E)dited the MBR so that the OpenBSD 'A6' partition started on sector 2048, and was 500MB in size. I accepted the auto configured disklabel (i.e. all space in 'a') and installed w/o X, Compiler or games sets. Removing the CD and rebooting got me to the usual login prompt. I'm going to experiment some more, but I'm now suspicious that the old '512MB' limit is coming into play somehow. So for those following along, try a tiny OpenBSD MBR partition starting at sector 2048 and see what happens. And of course if it works, how big can your partition be before it stops working. Ken
crash initializing CPUs after 2014-05-02 snapshot
Machine is a Dell 2950. 2014-04-30 snapshot and new bsd.rd boot fine
>> OpenBSD/amd64 BOOT 3.28
boot>
booting hd0a:/bsd: 10561372+2235930+1045688+0+614336
[100+556344+369943]=0x12ac5b8
entry point at 0x10001e0 [7205c766, 3404, 24448b12, 1ba0a304]
[ using 927224 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.5-current (GENERIC.MP) #98: Fri May 2 16:21:27 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34338045952 (32747MB)
avail mem = 33412399104 (31864MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0uvm_fault(0x8205bc00, 0x8221c000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at bios_attach+0x71: movl0(%rax),%eax
bios_attach() at bios_attach+0x71
config_attach() at config_attach+0x2ff
config_found_sm() at config_found_sm+0x49
mainbus_attach() at mainbus_attach+0x78
config_attach() at config_attach+0x2ff
config_rootfound() at config_rootfound+0x44
cpu_configure() at cpu_configure+0x1e
main() at main+0x5e4
end trace frame: 0x0, count: 3
ddb{0}> machine ddbcpu 1
Invalid cpu 1
--
05-02 bsd.rd boot:
boot> bsd.rd
booting hd0a:bsd.rd: 4184744+1360149+2920032+0+520640
[100+344520+223635]=0xd1d0c8
entry point at 0x10001e0 [7205c766, 3404, 24448b12, 45b0a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.5-current (RAMDISK_CD) #94: Fri May 2 16:27:25 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 34338045952 (32747MB)
avail mem = 33418633216 (31870MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x7fb9c000 (67 entries)
bios0: vendor Dell Inc. version "2.7.0" date 10/30/2010
bios0: Dell Inc. PowerEdge 2950
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT
EINJ TCPA SSDT SSDT SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz, 2992.92 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,F
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: apic clock running at 332MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
ioapic1 at mainbus0: apid 9 pa 0xfec81000, version 20, 24 pins
ioapic1: misconfigured as apic 0, remapped to apid 9
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 6 (PEX2)
acpiprt2 at acpi0: bus 7 (UPST)
acpiprt3 at acpi0: bus 8 (DWN1)
acpiprt4 at acpi0: bus 10 (DWN2)
acpiprt5 at acpi0: bus 1 (PEX3)
acpiprt6 at acpi0: bus 2 (PE2P)
acpiprt7 at acpi0: bus 12 (PEX4)
acpiprt8 at acpi0: bus 14 (PEX6)
acpiprt9 at acpi0: bus 4 (SBEX)
acpiprt10 at acpi0: bus 16 (COMP)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 5000X Host" rev 0x12
ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0x12
pci1 at ppb0 bus 6
ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci2 at ppb1 bus 7
ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci3 at ppb2 bus 8
ppb3 at pci3 dev 0 function 0 "ServerWorks PCIE-PCIX" rev 0xc3
pci4 at ppb3 bus 9
bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 8 int 16
ppb4 at pci2 dev 1 function 0 "Intel 6321ESB PCIE" rev 0x01: msi
pci5 at ppb4 bus 10
ppb5 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01
pci6 at ppb5 bus 11
ppb6 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0x12
pci7 at ppb6 bus 1
ppb7 at pci7 dev 0 function 0 "Intel IOP333 PCIE-PCIX" rev 0x00
pci8 at ppb7 bus 2
mfi0 at pci8 dev 14 function 0 "Dell PERC 5" rev 0x00: apic 9 int 14
mfi0: "PERC 5/i Integrated", firmware 5.2.2-0072, 256MB cache
scsibus0 at mfi0: 64 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct
fixed naa.60019b90c3691800174702a3594f9123
sd0: 3574400MB, 512 bytes/sector, 7320371200 sectors
ppb8 at pci7 dev 0 function 2 "Intel IOP333 PCIE-PCIX" rev 0x00
pci9 at ppb8 bus 3
ppb9 at pci0 dev 4 function 0 "Intel 5000 PCIE x8" rev 0x12: msi
pci10 at ppb9 bus 12
ppb10 at pci0 dev 5 function 0 "Intel 5000 PCIE" rev 0x12
pci11 at ppb10 bus 13
ppb11 at pci0 dev 6 function 0 "Intel 5000 PCIE x8" rev 0x12: msi
pci12 at ppb11 bus 14
ppb12 at pci0 dev 7 function 0 "Intel 5000 PCIE" rev 0x12
pci13 at ppb12 bus 15
pchb1 at pci0 dev 16 function 0 "Intel 5000 Error Reporting" rev 0x12
pchb2 at pci0 dev 16 function 1 "Intel 5000 Error Reporting" rev 0x12
pchb3 at pci0 dev 16 function 2 "Intel 5
Re: crash initializing CPUs after 2014-05-02 snapshot
On Sat, May 3, 2014 at 11:22 AM, Luke Tidd wrote: > Machine is a Dell 2950. 2014-04-30 snapshot and new bsd.rd boot fine > ... > OpenBSD 5.5-current (GENERIC.MP) #98: Fri May 2 16:21:27 MDT 2014 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34338045952 (32747MB) > avail mem = 33412399104 (31864MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0uvm_fault(0x8205bc00, 0x8221c000, 0, 1) > -> e > kernel: page fault trap, code=0 > Stopped at bios_attach+0x71: movl0(%rax),%eax > bios_attach() at bios_attach+0x71 > Thank you for the reports; the issue with the May 2nd amd64 snapshot is believed to be a build problem from a certain combination of patches in testing. That seems to have been resolved; if you have problems with builds after that one, please let us know. Sorry about the headache, and please keep up the excellent exercising of snaps! Philip Guenther
Re: crash initializing CPUs after 2014-05-02 snapshot
May 3rd did the trick, thanks. On Sat, May 3, 2014 at 7:51 PM, Philip Guenther wrote: > On Sat, May 3, 2014 at 11:22 AM, Luke Tidd wrote: >> >> Machine is a Dell 2950. 2014-04-30 snapshot and new bsd.rd boot fine > > ... >> >> OpenBSD 5.5-current (GENERIC.MP) #98: Fri May 2 16:21:27 MDT 2014 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> real mem = 34338045952 (32747MB) >> avail mem = 33412399104 (31864MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0uvm_fault(0x8205bc00, 0x8221c000, 0, 1) >> -> e >> kernel: page fault trap, code=0 >> Stopped at bios_attach+0x71: movl0(%rax),%eax >> bios_attach() at bios_attach+0x71 > > > Thank you for the reports; the issue with the May 2nd amd64 snapshot is > believed to be a build problem from a certain combination of patches in > testing. That seems to have been resolved; if you have problems with builds > after that one, please let us know. > > Sorry about the headache, and please keep up the excellent exercising of > snaps! > > > Philip Guenther > -- Luke Tidd Google 7055 Pleasant Dr Austell, GA 30168 404-939-0306
