Re: Panic: witness_warn (r191682; shared rw udpinp (udpinp)...netinet6/udp6_usrreq.c:360)

On Thu, Apr 30, 2009 at 10:43:26PM +0100, Bruce Simpson wrote:
> ...
> Can you try this patch? This patch is probably more correct -- but you 
> can see my intent was to avoid thrashing the INP lock on mcast delivery. 
> INP lock use in that routine is goopy to read. That'll teach me to do 
> things from memory for IPv4... bah! 

OK; that one works, too:

lbert(7.1-S)[7] ssh -x freebeast uname -a
FreeBSD freebeast.catwhisker.org 8.0-CURRENT FreeBSD 8.0-CURRENT #332 r191682M: Thu Apr 30 19:19:18
PDT 2009     root <at> freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST  i386
albert(7.1-S)[8] 

Thanks for the patch!

Peace,
david
--

-- 
David H. Wolfskill				david <at> catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Re: cannot compile sched_ule without options SMP

2009/5/1 Jeff Roberson <jroberson <at> jroberson.net>:
> On Thu, 30 Apr 2009, pluknet wrote:
>
>> 2009/4/30 Jeff Roberson <jroberson <at> jroberson.net>:
>>>
>>> On SMP machines you should now see output like this:
>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
>>>
>>> If you detect any irregularities with kern.sched.topology_spec or this
>>> dmesg
>>> line please report them.
>>>
>>
>> Hi, Jeff.
>>
>> I have such mismatch. This is an Intel E7200.
>>
>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
>> cpu0 (BSP): APIC ID:  0
>> cpu1 (AP/HT): APIC ID:  1
>>
>> So it should be instead: 1 package(s) x 2 core(s)
>> cpu0 (BSP): APIC ID:  0
>> cpu1 (AP): APIC ID:  1
>
> Can you please repeat the following steps as I have done here:
>

Re: cannot compile sched_ule without options SMP

2009/5/1 pluknet <pluknet <at> gmail.com>:
> 2009/5/1 Jeff Roberson <jroberson <at> jroberson.net>:
>> On Thu, 30 Apr 2009, pluknet wrote:
>>
>>> 2009/4/30 Jeff Roberson <jroberson <at> jroberson.net>:
>>>>
>>>> On SMP machines you should now see output like this:
>>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
>>>>
>>>> If you detect any irregularities with kern.sched.topology_spec or this
>>>> dmesg
>>>> line please report them.
>>>>
>>>
>>> Hi, Jeff.
>>>
>>> I have such mismatch. This is an Intel E7200.
>>>
>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
>>> cpu0 (BSP): APIC ID:  0
>>> cpu1 (AP/HT): APIC ID:  1
>>>
>>> So it should be instead: 1 package(s) x 2 core(s)
>>> cpu0 (BSP): APIC ID:  0
>>> cpu1 (AP): APIC ID:  1
>>
>> Can you please repeat the following steps as I have done here:
>>

Re: cannot compile sched_ule without options SMP

On Fri, 1 May 2009, pluknet wrote:

> 2009/5/1 pluknet <pluknet <at> gmail.com>:
>> 2009/5/1 Jeff Roberson <jroberson <at> jroberson.net>:
>>> On Thu, 30 Apr 2009, pluknet wrote:
>>>
>>>> 2009/4/30 Jeff Roberson <jroberson <at> jroberson.net>:
>>>>>
>>>>> On SMP machines you should now see output like this:
>>>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
>>>>>
>>>>> If you detect any irregularities with kern.sched.topology_spec or this
>>>>> dmesg
>>>>> line please report them.
>>>>>
>>>>
>>>> Hi, Jeff.
>>>>
>>>> I have such mismatch. This is an Intel E7200.
>>>>
>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>> FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
>>>> cpu0 (BSP): APIC ID:  0
>>>> cpu1 (AP/HT): APIC ID:  1
>>>>
>>>> So it should be instead: 1 package(s) x 2 core(s)
>>>> cpu0 (BSP): APIC ID:  0
>>>> cpu1 (AP): APIC ID:  1

Re: Panic: witness_warn (r191682; shared rw udpinp (udpinp)...netinet6/udp6_usrreq.c:360)

David Wolfskill wrote:
> On Thu, Apr 30, 2009 at 10:43:26PM +0100, Bruce Simpson wrote:
>   
>> ...
>> Can you try this patch? This patch is probably more correct -- but you 
>> can see my intent was to avoid thrashing the INP lock on mcast delivery. 
>> INP lock use in that routine is goopy to read. That'll teach me to do 
>> things from memory for IPv4... bah! 
>>     
>
> OK; that one works, too:
>   

Thanks, I have checked it in.

cheers
BMS
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Re: kernel compile fails without AH_SUPPORT_AR5416

Hi,

Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.

Sam Leffler wrote:
> Bruce Simpson wrote:
>   
>> Hi,
>>
>> Looks like I'm late to the party. I was responsible for committing these
>> ath(4) changes to RELENG_7.
>> I can't remember if I tested the kernel compile without the
>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>> ...
> ru had a change to fix this but decided not to; can't say why.
> Otherwise there is a better way to fix this which I alluded to in
> previous mail--use the config-generated #define that is generated for
> the "ath_hal" device.

thanks,
BMS

Index: UPDATING
===================================================================
--- UPDATING	(revision 191718)
+++ UPDATING	(working copy)
 <at>  <at>  -8,6 +8,11  <at>  <at> 
 /usr/ports/UPDATING.  Please read that file before running

Re: syslogd with log files in /tmp

On Thu, Apr 30, 2009 at 8:10 AM, Matthias Apitz <guru <at> unixarea.de> wrote:
> El día Thursday, April 30, 2009 a las 11:42:18AM +0200, Matthias Apitz escribió:
>
>> syslogd_enable="YES"
>> syslogd_flags="-s -C"
>>
>> on reboot it seems that syslogd has no logfiles (as I can see with
>> lsof), but after I restart it with
>>
>> # /etc/rc.d/syslogd restart
>>
>> all is fine; maybe this is because syslogd is started before tmpmfs is
>> ready? in RELENG_7 it worked exactly this way, now in CURRENT not;
>> any idea how to solve this?
>
> it has todo with the order if rc files:
>
> CURRENT:
>
> # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | cat -n | egrep 'syslogd|tmp'
>    61  /etc/rc.d/syslogd
>    76  /etc/rc.d/tmp
>    77  /etc/rc.d/cleartmp
>
> 7.0-REL:
>
> # rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | cat -n | egrep 'syslogd|tmp'
>    56  /etc/rc.d/tmp
>    57  /etc/rc.d/cleartmp
>    64  /etc/rc.d/syslogd

Re: kernel compile fails without AH_SUPPORT_AR5416

Bruce Simpson wrote:
> Hi,
>
> Can you please try this patch?
> I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
>
> Sam Leffler wrote:
>> Bruce Simpson wrote:
>>  
>>> Hi,
>>>
>>> Looks like I'm late to the party. I was responsible for committing 
>>> these
>>> ath(4) changes to RELENG_7.
>>> I can't remember if I tested the kernel compile without the
>>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>>> ...
>> ru had a change to fix this but decided not to; can't say why.
>> Otherwise there is a better way to fix this which I alluded to in
>> previous mail--use the config-generated #define that is generated for
>> the "ath_hal" device.
Do not modify ah_desc.h like you've done.  Add this to conf/options

ATH_HAL   opt_ah.h

and use that to enable AH_SUPPORT_AR5416.

Also changes must go in head first.

    Sam

Re: kernel compile fails without AH_SUPPORT_AR5416

Sam Leffler wrote:
> Bruce Simpson wrote:
>> Hi,
>>
>> Can you please try this patch?
>> I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
>>
>> Sam Leffler wrote:
>>> Bruce Simpson wrote:
>>>  
>>>> Hi,
>>>>
>>>> Looks like I'm late to the party. I was responsible for committing 
>>>> these
>>>> ath(4) changes to RELENG_7.
>>>> I can't remember if I tested the kernel compile without the
>>>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>>>> ...
>>> ru had a change to fix this but decided not to; can't say why.
>>> Otherwise there is a better way to fix this which I alluded to in
>>> previous mail--use the config-generated #define that is generated for
>>> the "ath_hal" device.
> Do not modify ah_desc.h like you've done.  Add this to conf/options
>
> ATH_HAL   opt_ah.h
>
> and use that to enable AH_SUPPORT_AR5416.
>
> Also changes must go in head first.

Re: kernel compile fails without AH_SUPPORT_AR5416

Sam Leffler wrote:
> ...
>>>> the "ath_hal" device.
>> Do not modify ah_desc.h like you've done.  Add this to conf/options
>>
>> ATH_HAL   opt_ah.h
>>
>> and use that to enable AH_SUPPORT_AR5416.
>>
> To clarify the first comment: you've made it impossible to build code 
> w/o the extended format descriptor; this is what I find unacceptable.

Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device 
name gets pulled into config(5) with the 'device' keyword. Thanks for 
the reminder...

This is a much cleaner fix for the issue than forcing the option to be 
set on always. It looks like HEAD has this issue too and this can go 
right in there.

Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC?
The 'out of box' config hasn't been broken by the change and this is 
identical to to the situation in HEAD as far as I can see.

thanks,
BMS

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current