Re: failure to build current
Hi, nobody has a clue on this? I tried to build twice... getting the same error... Riccardo On 05/11/14 08:46, Riccardo Mottola wrote: Hi, while building distribution I get: includes === external/mit/xorg/include/xf86vidmodeproto includes === external/mit/xorg/include/renderproto includes === external/mit/xorg/include/dri2proto includes === external/mit/xorg/include/dri3proto nbmake[6]: don't know how to make dri3proto.h. Stop
Re: Strange boot problems on amd64-current (6.99.40)
Date:Sun, 11 May 2014 22:53:48 -0400 From:chris...@zoulas.com (Christos Zoulas) Message-ID: 20140512025348.ab23b17f...@rebar.astron.com | This should work... But it is sub-optimal. It returns the state to as it was before the 1.306 commit. That is, previously, the raid autoconfig code was called before anything called cpu_rootconf(). And (assuming it was successful) that set booted_device. Then when something else later called cpu_rootconf() it did nothing, the (almost) first line is to return if booted_device is set (which it now is). Nothing ever set booted_partition, so it got left at its uninitialized value (ie: 0). That means raidNa became the root. After your change, cpu_rootconf() is being called before the raid autoconfig has set booted_device, it sets a (in this case meaningless) value into booted_partition, then booted_device gets set, and booted_partition will never be altered again. Forcing booted_partition to be 0 when raidframe sets booted_device is about as good as it will be possible to be when the raid device contains a disklabel. If it is GPT inside, then it should be possible to use some attribute from the label to find a suitable root partition (defaulting to the partition labelled raidNa as it does now .. it took me a while to figure out that I needed to label my root partition (as in gpt label ...) raid7a to get it to autoconfigure, that isn't docmented anywhere I saw.) One possibility that would be a backwards compatible, and slightly less hacky (and more flexible) solution, might be to use booted_partition = (whatever)-root_partition 8; (where 8 could be anything, and probably not be an inline constant of course). For existing raid arrays, that is going to have the same effect as booted_partition = 0; as root_partition is 0 or 1 (or after your change, perhaps 2). But now there would be the possibility to set the partition number (or for GPT, the index) into root_partition and allow the raidframe config to select whatever it wants to be the root. Index 0 isn't valid for GPT, so that would either mean look for raidNa as now, or perhaps look for some label attribute indicating rootness... kre
Re: failure to build current
On Mon, May 12, 2014 at 09:10:07AM +0200, Riccardo Mottola wrote: nobody has a clue on this? I tried to build twice... getting the same error... Forgotten -Pd when updating your source tree? Thomas
Re: Strange boot problems on amd64-current (6.99.40)
Just for the record, the suggested patch did not make any difference for my problem, which otherwise appears to be linked to this discussion - root on raidframe. In my case GENERIC still boots fine if I enable DEBUG and DIAGNOSTIC. Chavdar On 12 May 2014 09:19, Robert Elz k...@munnari.oz.au wrote: Date:Sun, 11 May 2014 22:53:48 -0400 From:chris...@zoulas.com (Christos Zoulas) Message-ID: 20140512025348.ab23b17f...@rebar.astron.com | This should work... But it is sub-optimal. It returns the state to as it was before the 1.306 commit. That is, previously, the raid autoconfig code was called before anything called cpu_rootconf(). And (assuming it was successful) that set booted_device. Then when something else later called cpu_rootconf() it did nothing, the (almost) first line is to return if booted_device is set (which it now is). Nothing ever set booted_partition, so it got left at its uninitialized value (ie: 0). That means raidNa became the root. After your change, cpu_rootconf() is being called before the raid autoconfig has set booted_device, it sets a (in this case meaningless) value into booted_partition, then booted_device gets set, and booted_partition will never be altered again. Forcing booted_partition to be 0 when raidframe sets booted_device is about as good as it will be possible to be when the raid device contains a disklabel. If it is GPT inside, then it should be possible to use some attribute from the label to find a suitable root partition (defaulting to the partition labelled raidNa as it does now .. it took me a while to figure out that I needed to label my root partition (as in gpt label ...) raid7a to get it to autoconfigure, that isn't docmented anywhere I saw.) One possibility that would be a backwards compatible, and slightly less hacky (and more flexible) solution, might be to use booted_partition = (whatever)-root_partition 8; (where 8 could be anything, and probably not be an inline constant of course). For existing raid arrays, that is going to have the same effect as booted_partition = 0; as root_partition is 0 or 1 (or after your change, perhaps 2). But now there would be the possibility to set the partition number (or for GPT, the index) into root_partition and allow the raidframe config to select whatever it wants to be the root. Index 0 isn't valid for GPT, so that would either mean look for raidNa as now, or perhaps look for some label attribute indicating rootness... kre --
Re: Strange boot problems on amd64-current (6.99.40)
On May 12, 3:19pm, k...@munnari.oz.au (Robert Elz) wrote: -- Subject: Re: Strange boot problems on amd64-current (6.99.40) | One possibility that would be a backwards compatible, and slightly less | hacky (and more flexible) solution, might be to use | | booted_partition = (whatever)-root_partition 8; | | (where 8 could be anything, and probably not be an inline constant of course). | | For existing raid arrays, that is going to have the same effect as | booted_partition = 0; | as root_partition is 0 or 1 (or after your change, perhaps 2). | | But now there would be the possibility to set the partition number (or for | GPT, the index) into root_partition and allow the raidframe config to | select whatever it wants to be the root. Index 0 isn't valid for GPT, so | that would either mean look for raidNa as now, or perhaps look for some | label attribute indicating rootness... Thanks, I will set ot to 0 and add a comment. To that effect. christos
Re: Strange boot problems on amd64-current (6.99.40)
On May 12, 4:24pm, ci4...@gmail.com (Chavdar Ivanov) wrote: -- Subject: Re: Strange boot problems on amd64-current (6.99.40) | Just for the record, the suggested patch did not make any difference | for my problem, which otherwise appears to be linked to this | discussion - root on raidframe. In my case GENERIC still boots fine if | I enable DEBUG and DIAGNOSTIC. That's a different issue. Can I have your boot messages with the same debugging as Paul gave before? christos
interface send-q stall in 6.99.40?
Hi, I have two observations on 6.99.44 (amd64/evbarm) where a wm-interface send-queue is filled to the max. sendto()-calls terminate with ENOBUFS. net.interfaces.wm3.sndq.len = 256 net.interfaces.wm3.sndq.maxlen = 256 net.interfaces.wm3.sndq.drops = 20007 the interface status is: wm3: flags=8a43UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 capabilities=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 enabled=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx enabled=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx enabled=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=0 address: 00:00:xx:xx:xx:xx media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,master,rxpause,txpause) status: active [addresses skipped] traceroute packets from outside look like the are anwsered, but ICMP ECHO is not answered. The interface recovers with an ifconfig wmX down/up. While I do not know how to provoke this on wm (just happens once a week). I found the same phenomenon occurring on a Raspberry Pi when detaching the cable. The same symptoms occur there and ifconfig usmsc0 down/up will recover. Is anybody else seeing this? Best regards, Frank
Re: interface send-q stall in 6.99.40?
Hi, Frank. (2014/05/13 4:56), Frank Kardel wrote: Hi, I have two observations on 6.99.44 (amd64/evbarm) where a wm-interface send-queue is filled to the max. sendto()-calls terminate with ENOBUFS. net.interfaces.wm3.sndq.len = 256 net.interfaces.wm3.sndq.maxlen = 256 net.interfaces.wm3.sndq.drops = 20007 the interface status is: wm3: flags=8a43UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 capabilities=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 enabled=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx enabled=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx enabled=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=0 address: 00:00:xx:xx:xx:xx media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,master,rxpause,txpause) status: active [addresses skipped] traceroute packets from outside look like the are anwsered, but ICMP ECHO is not answered. The interface recovers with an ifconfig wmX down/up. Could you show me the dmesg? While I do not know how to provoke this on wm (just happens once a week). I found the same phenomenon occurring on a Raspberry Pi when detaching the cable. The same symptoms occur there and ifconfig usmsc0 down/up will recover. Is anybody else seeing this? No, I'm not. One of diagnostic way of wm(4) is WM_EVENT_COUNTERS option. Could you enable the option and check with vmstat -ev? Best regards, Frank -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: interface send-q stall in 6.99.40?
On Mon, May 12, 2014 at 09:56:30PM +0200, Frank Kardel wrote: [...] traceroute packets from outside look like the are anwsered, but ICMP ECHO is not answered. The interface recovers with an ifconfig wmX down/up. While I do not know how to provoke this on wm (just happens once a week). I found the same phenomenon occurring on a Raspberry Pi when detaching the cable. The same symptoms occur there and ifconfig usmsc0 down/up will recover. Is anybody else seeing this? I do, on a amd64 host with wm interface. Disabling TSO4 and TSO6 fixed the problem for me. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: interface send-q stall in 6.99.40?
On 05/12/14 22:39, Manuel Bouyer wrote: On Mon, May 12, 2014 at 09:56:30PM +0200, Frank Kardel wrote: [...] traceroute packets from outside look like the are anwsered, but ICMP ECHO is not answered. The interface recovers with an ifconfig wmX down/up. While I do not know how to provoke this on wm (just happens once a week). I found the same phenomenon occurring on a Raspberry Pi when detaching the cable. The same symptoms occur there and ifconfig usmsc0 down/up will recover. Is anybody else seeing this? I do, on a amd64 host with wm interface. Disabling TSO4 and TSO6 fixed the problem for me. Will try that! Thanks for the hint. Frank
daily CVS update output
Updating src tree: P src/crypto/external/bsd/heimdal/dist/kadmin/rpc.c P src/crypto/external/bsd/heimdal/dist/lib/gssapi/krb5/verify_mic.c P src/crypto/external/bsd/heimdal/dist/lib/gssapi/ntlm/creds.c P src/crypto/external/bsd/heimdal/dist/lib/krb5/pac.c P src/crypto/external/bsd/heimdal/dist/lib/krb5/send_to_kdc.c P src/share/man/man9/pcu.9 P src/sys/arch/amd64/amd64/machdep.c P src/sys/arch/amd64/include/mcontext.h P src/sys/arch/x86/acpi/acpi_machdep.c P src/sys/arch/x86/pci/pciide_machdep.c P src/sys/arch/x86/x86/cpu.c P src/sys/dev/mii/makphy.c P src/sys/dev/mii/makphyreg.h P src/sys/dev/mii/miidevs P src/sys/dev/mii/miidevs.h P src/sys/dev/mii/miidevs_data.h P src/sys/dev/pci/pci_subr.c P src/sys/dev/raidframe/rf_netbsdkintf.c P src/tests/fs/nfs/nfsservice/rumpnfsd.c P src/tests/rump/rumpvfs/t_etfs.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue May 13 03:22:30 2014 SUP Scan for current completed at Tue May 13 03:22:59 2014 SUP Scan for mirror starting at Tue May 13 03:22:59 2014 SUP Scan for mirror completed at Tue May 13 03:24:54 2014 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41342552 May 13 03:31 ls-lRA.gz
