Re: nmbclusters: how do we want to fix this for 8.3 ?

[Fabien Thomas]

Le 22 févr. 2012 à 22:51, Jack Vogel a écrit :

> On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo  wrote:
> 
>> On Wed, Feb 22, 2012 at 09:09:46PM +, Ben Hutchings wrote:
>>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote:
>> ...
 I have hit this problem recently, too.
 Maybe the issue mostly/only exists on 32-bit systems.
>>> 
>>> No, we kept hitting mbuf pool limits on 64-bit systems when we started
>>> working on FreeBSD support.
>> 
>> ok never mind then, the mechanism would be the same, though
>> the limits (especially VM_LIMIT) would be different.
>> 
 Here is a possible approach:
 
 1. nmbclusters consume the kernel virtual address space so there
   must be some upper limit, say
 
VM_LIMIT = 256000 (translates to 512MB of address space)
 
 2. also you don't want the clusters to take up too much of the
>> available
   memory. This one would only trigger for minimal-memory systems,
   or virtual machines, but still...
 
MEM_LIMIT = (physical_ram / 2) / 2048
 
 3. one may try to set a suitably large, desirable number of buffers
 
TARGET_CLUSTERS = 128000
 
 4. and finally we could use the current default as the absolute minimum
 
MIN_CLUSTERS = 1024 + maxusers*64
 
 Then at boot the system could say
 
nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT)
 
nmbclusters = max(nmbclusters, MIN_CLUSTERS)
 
 
 In turn, i believe interfaces should do their part and by default
 never try to allocate more than a fraction of the total number
 of buffers,
>>> 
>>> Well what fraction should that be?  It surely depends on how many
>>> interfaces are in the system and how many queues the other interfaces
>>> have.
>> 
 if necessary reducing the number of active queues.
>>> 
>>> So now I have too few queues on my interface even after I increase the
>>> limit.
>>> 
>>> There ought to be a standard way to configure numbers of queues and
>>> default queue lengths.
>> 
>> Jack raised the problem that there is a poorly chosen default for
>> nmbclusters, causing one interface to consume all the buffers.
>> If the user explicitly overrides the value then
>> the number of cluster should be what the user asks (memory permitting).
>> The next step is on devices: if there are no overrides, the default
>> for a driver is to be lean. I would say that topping the request between
>> 1/4 and 1/8 of the total buffers is surely better than the current
>> situation. Of course if there is an explicit override, then use
>> it whatever happens to the others.
>> 
>> cheers
>> luigi
>> 
> 
> Hmmm, well, I could make the default use only 1 queue or something like
> that,
> was thinking more of what actual users of the hardware would want.
> 

I think this is more reasonable to setup interface with one queue.
Even if the cluster does not hit the max you will end up with unbalanced 
setting that
let very low mbuf count for other uses.


> After the installed kernel is booted and the admin would do whatever post
> install
> modifications they wish it could be changed, along with nmbclusters.
> 
> This was why i sought opinions, of the algorithm itself, but also anyone
> using
> ixgbe and igb in heavy use, what would you find most convenient?
> 
> Jack
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: nmbclusters: how do we want to fix this for 8.3 ?

[Andreas Nilsson]

On Thu, Feb 23, 2012 at 9:19 AM, Fabien Thomas wrote:

>
> Le 22 févr. 2012 à 22:51, Jack Vogel a écrit :
>
> > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo  wrote:
> >
> >> On Wed, Feb 22, 2012 at 09:09:46PM +, Ben Hutchings wrote:
> >>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote:
> >> ...
>  I have hit this problem recently, too.
>  Maybe the issue mostly/only exists on 32-bit systems.
> >>>
> >>> No, we kept hitting mbuf pool limits on 64-bit systems when we started
> >>> working on FreeBSD support.
> >>
> >> ok never mind then, the mechanism would be the same, though
> >> the limits (especially VM_LIMIT) would be different.
> >>
>  Here is a possible approach:
> 
>  1. nmbclusters consume the kernel virtual address space so there
>    must be some upper limit, say
> 
> VM_LIMIT = 256000 (translates to 512MB of address space)
> 
>  2. also you don't want the clusters to take up too much of the
> >> available
>    memory. This one would only trigger for minimal-memory systems,
>    or virtual machines, but still...
> 
> MEM_LIMIT = (physical_ram / 2) / 2048
> 
>  3. one may try to set a suitably large, desirable number of buffers
> 
> TARGET_CLUSTERS = 128000
> 
>  4. and finally we could use the current default as the absolute
> minimum
> 
> MIN_CLUSTERS = 1024 + maxusers*64
> 
>  Then at boot the system could say
> 
> nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT)
> 
> nmbclusters = max(nmbclusters, MIN_CLUSTERS)
> 
> 
>  In turn, i believe interfaces should do their part and by default
>  never try to allocate more than a fraction of the total number
>  of buffers,
> >>>
> >>> Well what fraction should that be?  It surely depends on how many
> >>> interfaces are in the system and how many queues the other interfaces
> >>> have.
> >>
>  if necessary reducing the number of active queues.
> >>>
> >>> So now I have too few queues on my interface even after I increase the
> >>> limit.
> >>>
> >>> There ought to be a standard way to configure numbers of queues and
> >>> default queue lengths.
> >>
> >> Jack raised the problem that there is a poorly chosen default for
> >> nmbclusters, causing one interface to consume all the buffers.
> >> If the user explicitly overrides the value then
> >> the number of cluster should be what the user asks (memory permitting).
> >> The next step is on devices: if there are no overrides, the default
> >> for a driver is to be lean. I would say that topping the request between
> >> 1/4 and 1/8 of the total buffers is surely better than the current
> >> situation. Of course if there is an explicit override, then use
> >> it whatever happens to the others.
> >>
> >> cheers
> >> luigi
> >>
> >
> > Hmmm, well, I could make the default use only 1 queue or something like
> > that,
> > was thinking more of what actual users of the hardware would want.
> >
>
> I think this is more reasonable to setup interface with one queue.
> Even if the cluster does not hit the max you will end up with unbalanced
> setting that
> let very low mbuf count for other uses.
>

If interfaces have the possibility to use more queues, they should, imo so
I'm all for rasing the default size.

For those systems with very limited memory it's easily changed.


>
> > After the installed kernel is booted and the admin would do whatever post
> > install
> > modifications they wish it could be changed, along with nmbclusters.
> >
> > This was why i sought opinions, of the algorithm itself, but also anyone
> > using
> > ixgbe and igb in heavy use, what would you find most convenient?
> >
> > Jack
> > ___
> > freebsd-...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [CFT] modular kernel config

[Lars Engels]

On Thu, Feb 23, 2012 at 09:18:08AM +0100, Alexander Leidinger wrote:
> Quoting "Bjoern A. Zeeb"  (from Wed,  
> 22 Feb 2012 22:31:36 +):
> 
> > On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote:
> >
> >> You can download from
> >>  http://www.Leidinger.net/FreeBSD/current-patches/
> >> The files are
> >>  - i386_SMALL
> >>  - i386_SMALL_loader.conf
> >>  - amd64_SMALL
> >>  - amd64_SMALL_loader.conf
> >
> > I only looked at the laoder.conf for amd64 and the only comment I  
> > have is that I do not have the time to wait minutes for all  
> > individual modules to be loaded.  This is going to be really bad for  
> > boot time.
> 
> Well, nobody forces you to use it. And as can be seen on the lists,  
> there are patches floating around to improve the loading speed of the  
> loader.

You can also put most of the modules in rc.conf:
kld_list="umass u3g" ...

That speeds up loading the modules a lot.

> 
> This is also just an example to be on par as much as possible with  
> GENERIC. People which want to use this kernel most probably want to  
> cut the loader.conf down and maybe even want to use the rc.conf  
> setting to load modules which are not needed to boot.

One additional advantage is that you have a bigger chance of a working
suspend / resume. Just unload all problematic modules before suspending
and re-load them after resuming.



pgpBd7MK7BhA1.pgp
Description: PGP signature

Re: Can't read a full block, only got 8193 bytes.

[Ask Bjørn Hansen]

On Feb 19, 2012, at 12:10, Artem Belevich wrote:

[...]
>> "Can't read a full block, only got 8193 bytes."
> 
> That's probably just a side effect of ZFS checksum errors. ZFS will
> happily read the file until it hits a record with checksum. If
> redundant info is available (raidz or mirror), ZFS will attempt to
> recover your data. If there's no redundancy you will get read error.
> If you do "zpool status -v" you should see list of files affected by
> corruption.

Hi Artem,

Thank you for the reply and the tips!   

That makes sense and explains why we'd just get checksum errors on a raidz1 
test (but bonnie++ was happy except things were slow), but had the weird errors 
on a single disk pool.

>> This seems to only be when testing a single ZFS disk or a UFS partition.  
>> Testing a raidz1 we just get checksum errors noted in zpool status, but no 
>> errors reading (though read speeds are ~10MB/second across four disks -- 
>> writing sequentially was ~230MB/second).
>> 
>> Any ideas where to start look?
> 
> You need to figure out why you're getting checksum errors. Alas
> there's probably no easy way to troubleshoot it. The issue could be
> hardware related and possible culprits may include bad RAM, bad SATA
> cables, quirks of particular firmware revision on disk controller
> and/or hard drive.

Replacing the 3ware controller with a basic LSI controller fixed the problems 
and improved performance, so I guess the 3ware controller doesn't play nice 
with the Seagate 3TB disks (they're not on their compatibility list).


Ask

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: panic in 8.3-PRERELEASE

[Konstantin Belousov]

On Wed, Feb 22, 2012 at 06:53:55PM -0500, Rick Macklem wrote:
> John Baldwin wrote:
> > On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote:
> > > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote:
> > > > Hiroki Sato wrote:
> > > > > Hi,
> > > > >
> > > > > Just a report, but I got the following panic on an NFS server
> > > > > running
> > > > > 8.3-PRERELEASE:
> > > > >
> > > > > (from here)
> > > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0
> > > > >
> > > > > Tue Feb 21 10:59:44 JST 2012
> > > > >
> > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE
> > > > > #7: Thu
> > > > > Feb 16 19:29:19 JST 2012
> > > > > h...@pool.allbsd.org:/usr/obj/usr/src/sys/POOL
> > > > > amd64
> > > > >
> > > > > panic: Assertion lock == sq->sq_lock failed at
> > > > > /usr/src/sys/kern/subr_sleepqueue.c:335
> > > > >
> > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the
> > > > same
> > > > event wasn't allowed.
> > > > There are two places in the code where it did a:
> > > >   mtx_unlock();
> > > >   tsleep();
> > > > left over from the days when it was written for OpenBSD.
> > > This sequence allows to lost the wakeup which is happen right after
> > > cache unlock (together with clearing the RC_WANTED flag) but before
> > > the thread enters sleep state. The tsleep has a timeout so thread
> > > should
> > > recover in 10 seconds, but still.
> > >
> > > Anyway, you should use consistent outer lock for the same wchan,
> > > i.e.
> > > no lock (tsleep) or mtx (msleep), but not mix them.
> > 
> > Correct.
> > 
> > > > I don't think the mix would actually break anything, except that
> > > > the
> > > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have
> > > > been
> > > > the author of the sleep() stuff.
> > > >
> > > > Anyhow, please try the attached patch which replaces the
> > > > mtx_unlock();
> > tsleep(); with
> > > > msleep()s using PDROP. If the attachment gets lost, the patch is
> > > > also
> > here:
> > > >   http://people.freebsd.org/~rmacklem/tsleep.patch
> > > >
> > > > Thanks for reporting this, rick
> > > > ps: Is mtx_lock() now preferred over msleep()?
> > > What do you mean ?
> > 
> > mtx_sleep() is preferred over msleep(), but I doubt I will remove
> > msleep()
> > anytime soon.
> > 
> Ok, I'll redo the patch with mtx_sleep() and get one of you guys to
> review it.
I do not see a need in the changing to mtx_sleep, esp. if other places
in nfsd use msleep(). There are more then 570 uses of msleep(9) in the
kernel, and undefined number of them in third-party modules.

> 
> One question. Do you think this is serious enough to worry about for
> 8.3? (Just wondering if I need to rush a patch into head with a 1 week
> MFC. I realize it would still be up to re@, even if I rush it.)
I think it is usual routine bugfix, which is as good to have in release
as any other bugfix. 8.3 is in the stabilization period, made exactly
for pushing bugfixes.


pgpsgOJ3O3iIR.pgp
Description: PGP signature

Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Konstantin Belousov]

On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote:
> 
> 
> > -Original Message-
> > From: Konstantin Belousov [mailto:kostik...@gmail.com]
> > Sent: Thursday, February 23, 2012 12:45 AM
> > To: Desai, Kashyap
> > Cc: freebsd-s...@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth
> > D. Merry; McConnell, Stephen
> > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> > prohibited
> > 
> > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote:
> > > Hi,
> > >
> > > I am doing some code changes in mps dirver. While working on those
> > changes, I come to know about something which is new to me.
> > > Some expert help is required to clarify my doubt.
> > >
> > > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING"
> > > pflag. It means though irq in freebsd is treated as thread, We cannot
> > sleep in IRQ because of " "TDP_NOSLEEPING " set.
> > > 2. In mps driver we have below code snippet in ISR routine.
> > >
> > >
> > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > > mps_lock(sc);
> > > mps_intr_locked(data);
> > > mps_unlock(sc);
> > >
> > > I wonder why there is no issue with above code ? Theoretical we cannot
> > > sleep in ISR. (as explained in #1) Any thoughts ?
> > >
> > >
> > > 3. I recently added few place msleep() instead of DELAY in ISR context
> > > and I see " Trying sleep, but thread marked as sleeping prohibited".
> > >
> > FreeBSD has several basic ways to prevent a thread from executing on
> > CPU.
> > They mostly fall into two categories: bounded sleep, sometimes called
> > blocking, and unbounded sleep, usually abbreviated as sleep. The bounded
> > there refers to amount of code executed by other thread that hold
> > resource preventing blocked thread from making a progress.
> > 
> > Examples of the blocking primitives are mutexes, rw locks and rm locks.
> > The blocking is not counted as sleeping, so interrupt threads, which are
> > designated as non-sleeping, still can lock mutexes.
> Thanks for the tech help.  . 
> 
> As per you comment, So now I understood as "TDP_NOSLEEPING" is only
> for unbounded sleep restriction. Just curious to know, What is a
> reason that thread can do blocking sleep but can't do unbounded sleep
> ? Since technically we introduced sleeping restriction on interrupt
> thread is to avoid starvation and that can be fit with either of the
> sleep type. Is this not true ?
No, not to avoid starvation.

The intent of the blocking primitives is to acquire resources for limited
amount of time. In other words, you never take a mutex for undefinitely
long computation process. On the other hand, msleep sleep usually has
no limitations.

You do not want the interrupt thread to be put off the processor for
undefined time, so sleep is prohibited.

Another issue is that sleeping locks do not do priority propagation
to the resource owners, while turnstiles used for blocking do. This way,
interrupt thread waiting for mutex donates its priority to the current
mutex owner, or at least it shall do.

> 
> I will be able to progress on my work based on your comment. A much thanks 
> for correcting my doubt.
> 
> ~ Kashyap
> 
> > 
> > Examples of the sleeping primitives are msleep(), sx locks, lockmgr
> > locks and conditional variables.
> > 
> > In essence, the locking facilities are split into several classes that
> > form the hierarchy, and you cannot legally obtain the lock of higher
> > class while holding a lock of lower class:
> > spin mutexes -> blocking locks -> sleeping locks.
> > It establishes some meta-order on the all locks.
> > 
> > Does this make sense ?
> 


pgpmeKadis1Mc.pgp
Description: PGP signature

Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Ed Schouten]

Hi Kashyap,

* Desai, Kashyap , 20120222 18:51:
> Adding Ed Schouten and Jorg Wunsch  as I see there are author of
> msleep/mtx related APIs.

Am I? :-)

> 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING"
> pflag. It means though irq in freebsd is treated as thread,
> We cannot sleep in IRQ because of " "TDP_NOSLEEPING " set.
> 2. In mps driver we have below code snippet in ISR routine.
> 
> 
> mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> mps_lock(sc);
> mps_intr_locked(data);
> mps_unlock(sc);
> 
> I wonder why there is no issue with above code ? Theoretical we cannot
> sleep in ISR. (as explained in #1)
> Any thoughts ?

The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate
amount of time. Locking a mutex is allowed, as it can only cause the
thread to be blocked for a small amount of time, waiting for another
thread to unlock it.

> 3. I recently added few place msleep() instead of DELAY in ISR context
> and I see
> " Trying sleep, but thread marked as sleeping prohibited".

Which makes sense, as msleep() can be used to sleep for indefinitely.

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpe1XbNxryF5.pgp
Description: PGP signature

Re: [CFT] modular kernel config

[Alexander Leidinger]

Quoting ~Lst  (from Wed, 22 Feb 2012 21:53:56 +0700):


It's typo too ..

net.inet.ip.stealth: IP stealth mode, no TTL decrementation on forwarding

In your file's (i386|amd64)__SMALL_loader.conf :

# Disable stealth forwarding and flowtable.
net.inet.ip.stealt=0
net.inet6.ip6.stealt=0


Fixed.

Thanks,
Alexander.

--
Anoint, v.:
To grease a king or other great functionary already sufficiently
slippery.
-- Ambrose Bierce, "The Devil's Dictionary"

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [CFT] modular kernel config

[Alexander Leidinger]

Quoting "Bjoern A. Zeeb"  (from Wed,  
22 Feb 2012 22:31:36 +):



On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote:


You can download from
 http://www.Leidinger.net/FreeBSD/current-patches/
The files are
 - i386_SMALL
 - i386_SMALL_loader.conf
 - amd64_SMALL
 - amd64_SMALL_loader.conf


I only looked at the laoder.conf for amd64 and the only comment I  
have is that I do not have the time to wait minutes for all  
individual modules to be loaded.  This is going to be really bad for  
boot time.


Well, nobody forces you to use it. And as can be seen on the lists,  
there are patches floating around to improve the loading speed of the  
loader.


This is also just an example to be on par as much as possible with  
GENERIC. People which want to use this kernel most probably want to  
cut the loader.conf down and maybe even want to use the rc.conf  
setting to load modules which are not needed to boot.


The new stuff in the kernel config compared to GENERIC is (in order  
of number of requests from users):

- IPSEC (+ device enc + IPSEC_NAT_T)


You cannot ship that on by default for non-tecnical reasons in a  
kernel.  Please do not commit a kernel config that can be booted (no  
LINT cannot be booted) with these on without consulting appropriate  
hats upfront.


I planned to contact core to ask if there are some US export  
restrictions to take into account before committing. Do you have a  
different hat in mind?



- ALTQ
- SW_WATCHDOG
- QUOTA
- IPSTEALTH (disabled in loader.conf)
- IPFIREWALL_FORWARD (touches every packet, power users which need
  a bigger PPS but not this feature can recompile the kernel,
  discussed with julian@)
- FLOWTABLE (disabled in loader.conf)


Which is not the same as it's not 100% disabled and will still  
allocate memory.


I assume this means that the sideeffects are only some conditionals  
more for the packets which pass the corresponding kernel places (to  
check if the feature is enabled, I had a look for the  
IPFIREWALL_FORWARD and IPSTEALTH options regarding this). Regarding  
the memory usage I assume this means that if someone removes the  
loading of modules he does not use from the loader.conf, he will use  
less memory with those things enabled, than would be used by a GENERIC  
kernel.


Both of those things where taken into account before providing this  
config here. As I wrote above, people which need the last few PPS more  
can compile a kernel without those features (they are power-users),  
while people which do not want to compile kernels at all (and there  
are a lot of such people, just have a look at how many people use  
freebsd-update and you will get an idea about the target audience) get  
more features to play with.


This is also not supposed to replace GENERIC, but it coud be offered  
as an option to install this kernel instead of GENERIC (or we can  
install in in parallel and the user can chose which kernel he wants to  
boot, or ...).


Bye,
Alexander.

--

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Desai, Kashyap]

> -Original Message-
> From: Ed Schouten [mailto:e...@80386.nl]
> Sent: Thursday, February 23, 2012 3:16 PM
> To: Desai, Kashyap
> Cc: freebsd-s...@freebsd.org; freebsd-stable; jo...@freebsd.org; Kenneth
> D. Merry; McConnell, Stephen; Justin T. Gibbs
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
> 
> Hi Kashyap,
> 
> * Desai, Kashyap , 20120222 18:51:
> > Adding Ed Schouten and Jorg Wunsch  as I see there are author of
> > msleep/mtx related APIs.
> 
> Am I? :-)
I am new to FreeBSD and desperate to know the answer. :-). Thanks for your help.
> 
> > 1. When any irq is register with FreeBSD OS, it sets " TDP_NOSLEEPING"
> > pflag. It means though irq in freebsd is treated as thread, We cannot
> > sleep in IRQ because of " "TDP_NOSLEEPING " set.
> > 2. In mps driver we have below code snippet in ISR routine.
> >
> >
> > mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > mps_lock(sc);
> > mps_intr_locked(data);
> > mps_unlock(sc);
> >
> > I wonder why there is no issue with above code ? Theoretical we cannot
> > sleep in ISR. (as explained in #1) Any thoughts ?
> 
> The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate
> amount of time. Locking a mutex is allowed, as it can only cause the
> thread to be blocked for a small amount of time, waiting for another
> thread to unlock it.
So does this assumption that another thread will release mutex fast enough ?
Same as msleep() this can be applicable here as well. I mean another thread  
_can_ (if some bad drivers) take long time to release mutex.

> 
> > 3. I recently added few place msleep() instead of DELAY in ISR context
> > and I see " Trying sleep, but thread marked as sleeping prohibited".
> 
> Which makes sense, as msleep() can be used to sleep for indefinitely.
This part is clear. ! I agree with all experts view. 
> 
> --
>  Ed Schouten 
>  WWW: http://80386.nl/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Desai, Kashyap]

> -Original Message-
> From: Konstantin Belousov [mailto:kostik...@gmail.com]
> Sent: Thursday, February 23, 2012 2:55 PM
> To: Desai, Kashyap
> Cc: freebsd-s...@freebsd.org; freebsd-stable; Justin T. Gibbs; Kenneth
> D. Merry; McConnell, Stephen
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
> 
> On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote:
> >
> >
> > > -Original Message-
> > > From: Konstantin Belousov [mailto:kostik...@gmail.com]
> > > Sent: Thursday, February 23, 2012 12:45 AM
> > > To: Desai, Kashyap
> > > Cc: freebsd-s...@freebsd.org; freebsd-stable; Justin T. Gibbs;
> > > Kenneth D. Merry; McConnell, Stephen
> > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> > > prohibited
> > >
> > > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote:
> > > > Hi,
> > > >
> > > > I am doing some code changes in mps dirver. While working on those
> > > changes, I come to know about something which is new to me.
> > > > Some expert help is required to clarify my doubt.
> > > >
> > > > 1. When any irq is register with FreeBSD OS, it sets "
> TDP_NOSLEEPING"
> > > > pflag. It means though irq in freebsd is treated as thread, We
> > > > cannot
> > > sleep in IRQ because of " "TDP_NOSLEEPING " set.
> > > > 2. In mps driver we have below code snippet in ISR routine.
> > > >
> > > >
> > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > > > mps_lock(sc);
> > > > mps_intr_locked(data);
> > > > mps_unlock(sc);
> > > >
> > > > I wonder why there is no issue with above code ? Theoretical we
> > > > cannot sleep in ISR. (as explained in #1) Any thoughts ?
> > > >
> > > >
> > > > 3. I recently added few place msleep() instead of DELAY in ISR
> > > > context and I see " Trying sleep, but thread marked as sleeping
> prohibited".
> > > >
> > > FreeBSD has several basic ways to prevent a thread from executing on
> > > CPU.
> > > They mostly fall into two categories: bounded sleep, sometimes
> > > called blocking, and unbounded sleep, usually abbreviated as sleep.
> > > The bounded there refers to amount of code executed by other thread
> > > that hold resource preventing blocked thread from making a progress.
> > >
> > > Examples of the blocking primitives are mutexes, rw locks and rm
> locks.
> > > The blocking is not counted as sleeping, so interrupt threads, which
> > > are designated as non-sleeping, still can lock mutexes.
> > Thanks for the tech help.  .
> >
> > As per you comment, So now I understood as "TDP_NOSLEEPING" is only
> > for unbounded sleep restriction. Just curious to know, What is a
> > reason that thread can do blocking sleep but can't do unbounded sleep
> > ? Since technically we introduced sleeping restriction on interrupt
> > thread is to avoid starvation and that can be fit with either of the
> > sleep type. Is this not true ?
> No, not to avoid starvation.
> 
> The intent of the blocking primitives is to acquire resources for
> limited amount of time. In other words, you never take a mutex for
> undefinitely long computation process. On the other hand, msleep sleep
> usually has no limitations.

I got same reply from Ed Schouten. I agree and understood your note. Thanks for 
poring knowledge on this area.
_but_ only query is when thread take mutex, we don't know when it will release. 
So holding time of mutex is really not known.
In case of some bad code, where thread took mutex and not release within short 
time. This can eventually match upto msleep restriction as well.
Do we have  any checks that thread took long time holding mutext ? Similar to 
linux where spinlock has been not release in some specific time, they dump 
warnings with backtrace.

~ Kashyap
> 
> You do not want the interrupt thread to be put off the processor for
> undefined time, so sleep is prohibited.
> 
> Another issue is that sleeping locks do not do priority propagation to
> the resource owners, while turnstiles used for blocking do. This way,
> interrupt thread waiting for mutex donates its priority to the current
> mutex owner, or at least it shall do.
> 
> >
> > I will be able to progress on my work based on your comment. A much
> thanks for correcting my doubt.
> >
> > ~ Kashyap
> >
> > >
> > > Examples of the sleeping primitives are msleep(), sx locks, lockmgr
> > > locks and conditional variables.
> > >
> > > In essence, the locking facilities are split into several classes
> > > that form the hierarchy, and you cannot legally obtain the lock of
> > > higher class while holding a lock of lower class:
> > >   spin mutexes -> blocking locks -> sleeping locks.
> > > It establishes some meta-order on the all locks.
> > >
> > > Does this make sense ?
> >
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: random problem with 8.3 from yesterday

[Stefan Bethke]

Am 22.02.2012 um 07:34 schrieb Erich Dollansky:

> 
> tunefs -L NewDeviceName /dev/da0a
> 
> Either this call or the mount command does not work randomly.
> 
> When I then try to mount the device on /dev/da0a it does not work always.
> 
> I do not know what this causes, I am only randomly able to reproduce it.
> 
> It might be affected by removing the device or keeping it plugged in.

You need to be more specific: what "does not work" mean? Output, results?


Stefan

-- 
Stefan BethkeFon +49 151 14070811

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: panic in 8.3-PRERELEASE

[Hiroki Sato]

Rick Macklem  wrote
  in <476361430.1773817.1329954835308.javamail.r...@erie.cs.uoguelph.ca>:

rm> John Baldwin wrote:
rm> > On Wednesday, February 22, 2012 2:24:14 pm Konstantin Belousov wrote:
rm> > > On Wed, Feb 22, 2012 at 11:29:40AM -0500, Rick Macklem wrote:
rm> > > > Hiroki Sato wrote:
rm> > > > > Hi,
rm> > > > >
rm> > > > > Just a report, but I got the following panic on an NFS server
rm> > > > > running
rm> > > > > 8.3-PRERELEASE:
rm> > > > >
rm> > > > > (from here)
rm> > > > > pool.allbsd.org dumped core - see /var/crash/vmcore.0
rm> > > > >
rm> > > > > Tue Feb 21 10:59:44 JST 2012
rm> > > > >
rm> > > > > FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE
rm> > > > > #7: Thu
rm> > > > > Feb 16 19:29:19 JST 2012
rm> > > > > h...@pool.allbsd.org:/usr/obj/usr/src/sys/POOL
rm> > > > > amd64
rm> > > > >
rm> > > > > panic: Assertion lock == sq->sq_lock failed at
rm> > > > > /usr/src/sys/kern/subr_sleepqueue.c:335
rm> > > > >
rm> > > > Oops, I didn't know that mixing msleep() and tsleep() calls on the
rm> > > > same
rm> > > > event wasn't allowed.
rm> > > > There are two places in the code where it did a:
rm> > > >   mtx_unlock();
rm> > > >   tsleep();
rm> > > > left over from the days when it was written for OpenBSD.
rm> > > This sequence allows to lost the wakeup which is happen right after
rm> > > cache unlock (together with clearing the RC_WANTED flag) but before
rm> > > the thread enters sleep state. The tsleep has a timeout so thread
rm> > > should
rm> > > recover in 10 seconds, but still.
rm> > >
rm> > > Anyway, you should use consistent outer lock for the same wchan,
rm> > > i.e.
rm> > > no lock (tsleep) or mtx (msleep), but not mix them.
rm> >
rm> > Correct.
rm> >
rm> > > > I don't think the mix would actually break anything, except that
rm> > > > the
rm> > > > MPASS() assertion fails, but I've cc'd jhb@ since he seems to have
rm> > > > been
rm> > > > the author of the sleep() stuff.
rm> > > >
rm> > > > Anyhow, please try the attached patch which replaces the
rm> > > > mtx_unlock();
rm> > tsleep(); with
rm> > > > msleep()s using PDROP. If the attachment gets lost, the patch is
rm> > > > also
rm> > here:
rm> > > >   http://people.freebsd.org/~rmacklem/tsleep.patch
rm> > > >
rm> > > > Thanks for reporting this, rick
rm> > > > ps: Is mtx_lock() now preferred over msleep()?
rm> > > What do you mean ?
rm> >
rm> > mtx_sleep() is preferred over msleep(), but I doubt I will remove
rm> > msleep()
rm> > anytime soon.
rm> >
rm> Ok, I'll redo the patch with mtx_sleep() and get one of you guys to
rm> review it.

 Thank you for the patch!  I applied it and put the box under a stress
 testing again.

-- Hiroki


pgphnvwzNb6TV.pgp
Description: PGP signature

Re: [CFT] modular kernel config

[timp]

missing in loader.conf
geom_part_gpt_load="YES"
geom_label_load="YES"

--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/CFT-modular-kernel-config-tp5502195p5508227.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

another panic in 8.3-PRERELEASE

[Hiroki Sato]

Hi,

 This is another reproducible panic.  This seems to happen only when
 top(1) is running for a long time (a sysctl() call for
 CTL_KERN.KERN_PROC.KERN_PROC_PROC MIB triggered it).


pool.allbsd.org dumped core - see /var/crash/vmcore.0

Thu Feb 23 23:21:52 JST 2012

FreeBSD pool.allbsd.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #8: Thu Feb 23 
04:40:54 JST 2012 h...@pool.allbsd.org:/usr/obj/usr/src/sys/POOL  amd64

panic:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address   = 0x800e96000
fault code  = supervisor write data, protection violation
instruction pointer = 0x20:0x809440cb
stack pointer   = 0x28:0xff86c63890b0
frame pointer   = 0x28:0xff86c6389100
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 47211 (top)
lock order reversal: (Giant after non-sleepable)
 1st 0xff0244b85568 process lock (process lock) @ 
/usr/src/sys/kern/kern_proc.c:1211
 2nd 0x80d74c80 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:2018
KDB: stack backtrace:
Dumping 23903 out of 24550 MB:..1%..11%..21%..31% (CTRL-C to abort)  (CTRL-C to 
abort) ..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from 
/boot/kernel/geom_mirror.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_mirror.ko
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from 
/boot/kernel/ipfw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipfw.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:263
263 if (textdump_pending)
(kgdb) #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:263
#1  0x801f8cfc in db_fncall (dummy1=Variable "dummy1" is not available.
)
at /usr/src/sys/ddb/db_command.c:548
#2  0x801f9031 in db_command (last_cmdp=0x80d37f40, 
cmd_table=Variable "cmd_table" is not available.

) at /usr/src/sys/ddb/db_command.c:445
#3  0x801f9280 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:498
#4  0x801fb369 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:229
#5  0x8069dff1 in kdb_trap (type=12, code=0, tf=0xff86c6389000)
at /usr/src/sys/kern/subr_kdb.c:548
#6  0x809461ed in trap_fatal (frame=0xff86c6389000, eva=Variable 
"eva" is not available.
)
at /usr/src/sys/amd64/amd64/trap.c:820
#7  0x809468b5 in trap (frame=0xff86c6389000)
at /usr/src/sys/amd64/amd64/trap.c:326
#8  0x8092d2f4 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#9  0x809440cb in copyout () at /usr/src/sys/amd64/amd64/support.S:258
#10 0x80675f1f in sysctl_old_user (req=0xff86c63899c0,
p=0xff86c6389470, l=1088) at /usr/src/sys/kern/kern_sysctl.c:1276
#11 0x8065f6a6 in sysctl_out_proc_copyout (ki=0xff86c6389470,
req=0xff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085
#12 0x8065ff6c in sysctl_out_proc (p=0xff0244b85470,
req=0xff86c63899c0, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_proc.c:1114
#13 0x8066245e in sysctl_kern_proc (oidp=Variable "oidp" is not 
available.
)
at /usr/src/sys/kern/kern_proc.c:1302
#14 0x806756e8 in sysctl_root (oidp=Variable "oidp" is not available.
)
at /usr/src/sys/kern/kern_sysctl.c:1455
#15 0x8067598e in userland_sysctl (td=0x0, name=0xff86c6389a80,
namelen=3, old=0x800e96000, oldlenp=Variable "oldlenp" is not available.
)
at /usr/src/sys/kern/kern_sysctl.c:1565
#16 0x80675e3a in __sysctl (td=0xff0396ec5460,
uap=0xff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491
#17 0x80945809 in amd64_syscall (td=0xff0396ec5460, traced=0)
at subr_syscall.c:114
#18 0x8092d5ec in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#19 0x000800abecfc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)


db> show alllocks
Process 1169 (sshd) thread 0xff0022cfa460 (100715)
exclusive

SmartyMee

[SmartyMee]

PRESS RELEASE - FOR IMMEDIATE RELEASE

Smartymee.com – the perfect solution for monetizing your courseware and 
tutorials

Berlin, Germany — January 24, 2012 — the guys from http://sciencestage.com, the 
leading international community for academic video streaming, are launching a 
new product called http://smartymee.com.

Smartymee.com is built on top of http://sciencestage.com but nevertheless an 
individual brand. It is a marketplace for digital courseware products and for 
tutorials.

Smartymee.com is the ideal place for producers of fresh and high-quality 
content to monetize their work. All in three simple steps: 1. Create a course 
and set a price, 2. Upload and compile files, 3. Publish.

Unlike Sciencestage.com, Smartymee.com does not just cover academic topics. It 
also focuses on a broad range of other topics, such as business, health, 
lifestyle, hobby, language, music, technology and Internet. Smartymee.com can 
be used to publish free courseware. But the operators also specifically appeal 
to all experts who have always firmly believed that top-quality content can 
only come at a price, even on the web.

If you would like more information about smartymee.com, or to schedule an 
interview with  Dr. Krueger, please contact him directly at +49-(0)30 – 40 50 
04 65 or send an email to cont...@smartymee.com

URL: http://smartymee.com
Press Page (Including Logo and Video): 
http://smartymee.com/press-release-berlin-germany-%E2%80%94-jan-24-2012 
Facebook: http://www.facebook.com/profile.php?id=13269203057
Youtube: http://www.youtube.com/user/smartymeecom

Adress: SmartyMee.com, 10178 Berlin, Germany, Karl-Liebknecht-Str. 13 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: nmbclusters: how do we want to fix this for 8.3 ?

[Ivan Voras]

On 23/02/2012 09:19, Fabien Thomas wrote:

> I think this is more reasonable to setup interface with one queue.

Unfortunately, the moment you do that, two things will happen:
1) users will start complaining again how FreeBSD is slow
2) the setting will be come a "sacred cow" and nobody will change this
default for the next 10 years.

If it really comes down to enabling only one queue, something needs to
complain extremely loudly that this isn't an optimal setting. Only
printing it out at boot may not be enough - what's needed is possibly a
script in periodic/daily which checks "system sanity" every day and
e-mails the operator.



signature.asc
Description: OpenPGP digital signature

Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Alexander Kabaev]

On Thu, 23 Feb 2012 18:45:29 +0530
"Desai, Kashyap"  wrote:

> 
> 
> > -Original Message-
> > From: Ed Schouten [mailto:e...@80386.nl]
> > Sent: Thursday, February 23, 2012 3:16 PM
> > To: Desai, Kashyap
> > Cc: freebsd-s...@freebsd.org; freebsd-stable; jo...@freebsd.org;
> > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs
> > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> > prohibited
> > 
> > Hi Kashyap,
> > 
> > * Desai, Kashyap , 20120222 18:51:
> > > Adding Ed Schouten and Jorg Wunsch  as I see there are author of
> > > msleep/mtx related APIs.
> > 
> > Am I? :-)
> I am new to FreeBSD and desperate to know the answer. :-). Thanks for
> your help.
> > 
> > > 1. When any irq is register with FreeBSD OS, it sets "
> > > TDP_NOSLEEPING" pflag. It means though irq in freebsd is treated
> > > as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING "
> > > set. 2. In mps driver we have below code snippet in ISR routine.
> > >
> > >
> > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > > mps_lock(sc);
> > > mps_intr_locked(data);
> > > mps_unlock(sc);
> > >
> > > I wonder why there is no issue with above code ? Theoretical we
> > > cannot sleep in ISR. (as explained in #1) Any thoughts ?
> > 
> > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate
> > amount of time. Locking a mutex is allowed, as it can only cause the
> > thread to be blocked for a small amount of time, waiting for another
> > thread to unlock it.
> So does this assumption that another thread will release mutex fast
> enough ? Same as msleep() this can be applicable here as well. I mean
> another thread  _can_ (if some bad drivers) take long time to release
> mutex.
> 
>
Bad drivers can just defererence wild pointer to satisfy their need for
wrongdoing. For that reason let us keep them out of conversation.

mtx locks were designed to protect small sections of code where thread
is only allowed to block waiting for other thread to release the lock
of similar class. While threads are blocked, they get benefit of
adaptive sleep and priority propagation and should take precaution of
never taking the path of code that can cause them to sleep. Assertions
are there to help code authors with that.

sleep locks are by definition unbound. There is no spinning, no
priority propagation. Holders are free to take, say, page faults and go
to long journey to disk and back, etc. Hardly the stuff _anyone_ would
want to do from interrupt handler, thread or otherwise. 

 
> > > 3. I recently added few place msleep() instead of DELAY in ISR
> > > context and I see " Trying sleep, but thread marked as sleeping
> > > prohibited".
> > 
> > Which makes sense, as msleep() can be used to sleep for
> > indefinitely.
> This part is clear. ! I agree with all experts view. 
> > 
> > --
> >  Ed Schouten 
> >  WWW: http://80386.nl/
> ___
> freebsd-s...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to
> "freebsd-scsi-unsubscr...@freebsd.org"


-- 
Alexander Kabaev


signature.asc
Description: PGP signature

Re: nmbclusters: how do we want to fix this for 8.3 ?

[Josh Paetzel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/2012 13:51, Jack Vogel wrote:
> 
> 
> On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo  > wrote:
> 
> On Wed, Feb 22, 2012 at 09:09:46PM +, Ben Hutchings wrote:
>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote:
> ...
>>> I have hit this problem recently, too. Maybe the issue
>>> mostly/only exists on 32-bit systems.
>> 
>> No, we kept hitting mbuf pool limits on 64-bit systems when we
>> started working on FreeBSD support.
> 
> ok never mind then, the mechanism would be the same, though the
> limits (especially VM_LIMIT) would be different.
> 
>>> Here is a possible approach:
>>> 
>>> 1. nmbclusters consume the kernel virtual address space so
>>> there must be some upper limit, say
>>> 
>>> VM_LIMIT = 256000 (translates to 512MB of address space)
>>> 
>>> 2. also you don't want the clusters to take up too much of the
> available
>>> memory. This one would only trigger for minimal-memory
>>> systems, or virtual machines, but still...
>>> 
>>> MEM_LIMIT = (physical_ram / 2) / 2048
>>> 
>>> 3. one may try to set a suitably large, desirable number of
>>> buffers
>>> 
>>> TARGET_CLUSTERS = 128000
>>> 
>>> 4. and finally we could use the current default as the
>>> absolute
> minimum
>>> 
>>> MIN_CLUSTERS = 1024 + maxusers*64
>>> 
>>> Then at boot the system could say
>>> 
>>> nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT)
>>> 
>>> nmbclusters = max(nmbclusters, MIN_CLUSTERS)
>>> 
>>> 
>>> In turn, i believe interfaces should do their part and by
>>> default never try to allocate more than a fraction of the total
>>> number of buffers,
>> 
>> Well what fraction should that be?  It surely depends on how
>> many interfaces are in the system and how many queues the other
>> interfaces have.
> 
>>> if necessary reducing the number of active queues.
>> 
>> So now I have too few queues on my interface even after I
>> increase the limit.
>> 
>> There ought to be a standard way to configure numbers of queues
>> and default queue lengths.
> 
> Jack raised the problem that there is a poorly chosen default for 
> nmbclusters, causing one interface to consume all the buffers. If
> the user explicitly overrides the value then the number of cluster
> should be what the user asks (memory permitting). The next step is
> on devices: if there are no overrides, the default for a driver is
> to be lean. I would say that topping the request between 1/4 and
> 1/8 of the total buffers is surely better than the current 
> situation. Of course if there is an explicit override, then use it
> whatever happens to the others.
> 
> cheers luigi
> 
> 
> Hmmm, well, I could make the default use only 1 queue or something
> like that, was thinking more of what actual users of the hardware
> would want.
> 
> After the installed kernel is booted and the admin would do
> whatever post install modifications they wish it could be changed,
> along with nmbclusters.
> 
> This was why i sought opinions, of the algorithm itself, but also
> anyone using ixgbe and igb in heavy use, what would you find most
> convenient?
> 
> Jack
> 

The default setting is a thorn in our (with my ixsystems servers for
freebsd hat on) side.  A system with a quad port igb card and two
onboard igb NICs won't boot stable/8 or 8.x-R to multiuser.  Ditto for
a dual port chelsio or ixgbe alongside dual onboard igb interfaces.

My vote would be having systems over some minimum threshold of system
ram to come up with a higher default for nmbclusters.  You don't see
too many 10gbe NICs in systems with 2GB of RAM


- -- 
Thanks,

Josh Paetzel
FreeBSD -- The power to serve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPRmIGAAoJEKFq1/n1feG229gIAIciDDKnc/K6/dgBA2YFGuuV
V9cYD6+Zm4bVT9nvFhxJCUj+3CTGQFvNwi2sQx6pVMUWQC7Cpb323CShc8BBNjV3
vCzTmvqVshO+LWhx6J8lq4rqTU+PIKajF3GnwIWt4xmZ6WhrjCUySORYSAINQjKr
iXJg/HBA7z/tsPUqOvzU0esZ4moUECapoldEOe0EF2jidARuM4q6MD1+QLMs+JSO
JUS5yMPV022NVYS79NsUfvJ1cuwd6/I7CPvsJsW0E+zMMF2BjKZesU89zyFDST80
0WptoEqR9cuyApwu0OfDDzKyL7Z6G9yaAr0zkCAHATxkK0KArMJP/j2eT5uzZkE=
=b44v
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: nmbclusters: how do we want to fix this for 8.3 ?

[Juli Mallett]

On Thu, Feb 23, 2012 at 07:19, Ivan Voras  wrote:
> On 23/02/2012 09:19, Fabien Thomas wrote:
>> I think this is more reasonable to setup interface with one queue.
>
> Unfortunately, the moment you do that, two things will happen:
> 1) users will start complaining again how FreeBSD is slow
> 2) the setting will be come a "sacred cow" and nobody will change this
> default for the next 10 years.

Is this any better than making queue-per-core a sacred cow?  Even very
small systems with comparatively-low memory these days have an
increasing number of cores.  They also usually have more RAM to go
with those cores, but not always.  Queue-per-core isn't even optimal
for some kinds of workloads, and is harmful to overall performance at
higher levels.  It also assumes that every core should be utilized for
the exciting task of receiving packets.  This makes sense on some
systems, but not all.

Plus more queues doesn't necessarily equal better performance even on
systems where you have the memory and cores to spare.  On systems with
non-uniform memory architectures, routinely processing queues on
different physical packages can make networking performance worse.

More queues is not a magic wand, it can be roughly the equivalent of
go-faster stripes.  Queue-per-core has a sort of logic to it, but is
not necessarily sensible, like the funroll-all-loops school of system
optimization.

Which sounds slightly off-topic, except that dedicating loads of mbufs
to receive queues that will sit empty on the vast majority of systems
and receive a few packets per second in the service of some kind of
magical thinking or excitement about multiqueue reception may be a
little ill-advised.  On my desktop with hardware supporting multiple
queues, do I really want to use the maximum number of them just to
handle a few thousand packets per second?  One core can do that just
fine.

FreeBSD's great to drop-in on forwarding systems that will have
moderate load, but it seems the best justification for this default is
so users need fewer reboots to get more queues to spread what is
assumed to be an evenly-distributed load over other cores.  In
practice, isn't the real problem that we have no facility for changing
the number of queues at runtime?

If the number of queues weren't fixed at boot, users could actually
find the number that suits them best with a plausible amount of work,
and the point about FreeBSD being "slow" goes away since it's perhaps
one more sysctl to set (or one per-interface) or one (or one-per)
ifconfig line to run, along with enabling forwarding, etc.

The big commitment that multi-queue drivers ask for when they use the
maximum number of queues on boot and then demand to fill those queues
up with mbufs is unreasonable, even if it can be met on a growing
number of systems without much in the way of pain.  It's unreasonable,
but perhaps it feels good to see all those interrupts bouncing around,
all those threads running from time to time in top.  Maybe it makes
FreeBSD seem more serious, or perhaps it's something that gets people
excited.  It gives the appearance of doing quite a bit behind the
scenes, and perhaps that's beneficial in and of itself, and will keep
users from imagining that FreeBSD is slow, to your point.  We should
be clear, though, whether we are motivated by technical or
psychological constraints and benefits.

Thanks,
Juli.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

8.3-PRERELEASE panic in linux emulation

[Bengt Ahlgren]

Hi!

I get a consistent panic when starting acroread after updating to
8.3-PRERELEASE.  An 8.2-STABLE from Feb 4th was OK.  Can provide more
info if needed.

Bengt

FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 
21:01:38 CET 2012 ben...@p142.sics.se:/usr/obj/usr/src/sys/P142-82  i386

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xbfbfdffc
fault code  = supervisor write, page not present
instruction pointer = 0x20:0xc50b396c
stack pointer   = 0x28:0xe7481a6c
frame pointer   = 0x28:0xe7481a90
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1997 (bash)
trap number = 12
panic: page fault
KDB: stack backtrace:
db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at 
db_trace_self_wrapper+0x26
kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at 
kdb_backtrace+0x2a
panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf
trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353
trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87
trap(e7481a2c) at trap+0x453
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 ---
elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,10,...) at 
elf_linux_fixup+0x33c
kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6
linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7
syscall(e7481d28) at syscall+0x372
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, 
ebp = 0xbfbfd7e8 ---

#0  doadump () at pcpu.h:244
#1  0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441
#2  0xc05de84f in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:614
#3  0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at 
/usr/src/sys/i386/i386/trap.c:981
#4  0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at 
/usr/src/sys/i386/i386/trap.c:843
#5  0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562
#6  0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#7  0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at 
/usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288
#8  0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at 
/usr/src/sys/kern/kern_exec.c:551
#9  0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at 
/usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143
#10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114
#11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266
#12 0x0033 in ?? ()
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Inconsistent utx.active?

[Vlad Galu]

Hi,

Has anyone else noticed erratic bookkeeping by utmpx in RELENG_9?

Thanks,
Vlad

-- 
Good, fast & cheap. Pick any two.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD9 and the sheer number of problem reports

[Damien Fleuriot]

Hello list,



This is NOT a troll.
This is NOT a flame.
Do NOT hijack this thread to troll/flame.




I'm writing this in light of the *many* problem reports I see on the
lists with 9.0-RELEASE.

I'm getting extremely worried here.




Short introduction in order:

See, we use FreeBSD at work for our firewall boxes, running:
- PF + CARP + PFsync
- nagios-nrpe
- munin-node
- bacula client

and either
- nginx and/or haproxy
- relayd

These boxes serve as frontend firewalls for all our projects/products,
including a few high traffic ones.


For example our most traffic intense project has 4 firewalls, 2 each on
2 different datacenters, sharing 4 CARP IPs with automagic failover.

These firewalls total ~200mb/s , serving only minifi'ed javascript pages.






Now, I find the number of problem reports regarding 9.0-RELEASE alarming
and I'm growing more and more fearful towards it.

In the current state of things, I have *absolutely* no wish to run it in
production :(



I'd love to hear feedback.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Kurt Buff]

On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot  wrote:

> Now, I find the number of problem reports regarding 9.0-RELEASE alarming
> and I'm growing more and more fearful towards it.
>
> In the current state of things, I have *absolutely* no wish to run it in
> production :(
>
> I'd love to hear feedback.

Feedback: If you're worried, wait until you aren't.

Kurt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Adam Strohl]

On 2/24/2012 1:39, Kurt Buff wrote:

On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot  wrote:


Now, I find the number of problem reports regarding 9.0-RELEASE alarming
and I'm growing more and more fearful towards it.

In the current state of things, I have *absolutely* no wish to run it in
production :(

I'd love to hear feedback.

Feedback: If you're worried, wait until you aren't.


Thorough testing ahead of time will either make you confident or give 
you the option to report issues which affect you directly (and help 
improve FreeBSD).


I say that having run into one issue with 9.0 (and reported it).  I am 
still using and deploying more 9.0 servers into production.  My .02.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Adam Strohl]

On 2/24/2012 1:39, Kurt Buff wrote:

On Thu, Feb 23, 2012 at 10:25, Damien Fleuriot  wrote:


Now, I find the number of problem reports regarding 9.0-RELEASE alarming
and I'm growing more and more fearful towards it.

In the current state of things, I have *absolutely* no wish to run it in
production :(

I'd love to hear feedback.

Feedback: If you're worried, wait until you aren't.


Thorough testing ahead of time will either make you confident or give 
you the option to report issues which affect you directly (and help 
improve FreeBSD).


I say that having run into one issue with 9.0 (and reported it).  I am 
still using and deploying more 9.0 servers into production.  My .02.

Re: FreeBSD9 and the sheer number of problem reports

[Torfinn Ingolfsen]

On Thu, 23 Feb 2012 19:25:01 +0100
Damien Fleuriot  wrote:

> 
> In the current state of things, I have *absolutely* no wish to run it in
> production :(

Nobody forces you to jump onto the 9.0-release bandwagon. You can choose to 
skip it.
If you skip 9.0 - will you be better prepared and less fearful when 9.1-release 
comes?
You decide.
-- 
Torfinn

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Mark Felder]

On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot  wrote:



Now, I find the number of problem reports regarding 9.0-RELEASE alarming
and I'm growing more and more fearful towards it.


Then stick with the 8.x train until it's no longer supported. Also, don't  
you know the rule about running .0 releases in production? :)


9.0 had LOTS of changes. They were very important. It's going to take a  
while for the community to fully absorb them and bugs to be worked out. We  
don't have enough testers of -CURRENT to prevent this. Everything seemed  
stable (ie, no release blockers) for the people running -CURRENT and  
-PRERELEASE, BETAs, and RCs, so it was released.


But as always, TEST TEST TEST and please have a proper staging/test  
environment before you throw your production into 9.x.


Only YOU can prevent forest fires^W^W unplanned outages.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: "File too large" error when appending to a file of 130 MB

[Jeremie Le Hen]

On Mon, Feb 20, 2012 at 06:05:16PM -0500, Rick Macklem wrote:
> > 
> Sorry, I have no idea. Maybe one of the ZFS folks knows when ACLs
> are generated. (It might happen as a side effect of a "chmod". You
> could experiment with that?)

Interestingly, such ACLs only appear on my nullfs mounted ZFS
dataset.  If I look directly at the underlying ZFS dataset, there is no
ACL.

-- 
Jeremie Le Hen

Men are born free and equal.  Later on, they're on their own.
Jean Yanne
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Peter Maloney]

Am 23.02.2012 21:15, schrieb Mark Felder:
> On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot  wrote:
>
>>
>> Now, I find the number of problem reports regarding 9.0-RELEASE alarming
>> and I'm growing more and more fearful towards it.
>
> Then stick with the 8.x train until it's no longer supported. Also,
> don't you know the rule about running .0 releases in production? :)
>
> 9.0 had LOTS of changes. They were very important. It's going to take
> a while for the community to fully absorb them and bugs to be worked
> out. We don't have enough testers of -CURRENT to prevent this.
> Everything seemed stable (ie, no release blockers) for the people
> running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released.
This is quite a good explanation, but what can be done in the future, so
either people are testing, or more report problems?

I suggest these concepts should be tested:

Perhaps the testers tested beta1 and beta2, but there were so many
changes after beta2, that bugs appeared in release that did not exist in
beta2. Test this by reproducing things reported in release also in beta1
or 2.

Perhaps the people who know the rule about running .0 releases (such as
myself) never bothered to test beta1, beta2, or even release .0 (true in
my case). If so, then this rule is a very bad one. Test this with a poll.

Perhaps people are more interested in a preview of what new features
they can expect, rather than actually planning on testing and submitting
PRs. Test this also with a poll. To fix this problem, you could add an
automatic bug reporting system like crash handlers in many applications
(Mozilla had this long ago; KDE has this, etc.).When dealing with
drivers, hard disks, removable devices, etc., the devs can't test every
case, but the users can, so until the FreeBSD Foundation can afford a
huge test lab with every combination of hardware, strengthening user
feedback is more important than internal testing.

>
> But as always, TEST TEST TEST and please have a proper staging/test
> environment before you throw your production into 9.x.
>
> Only YOU can prevent forest fires^W^W unplanned outages.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited

[Desai, Kashyap]

> -Original Message-
> From: Alexander Kabaev [mailto:kab...@gmail.com]
> Sent: Thursday, February 23, 2012 8:42 PM
> To: Desai, Kashyap
> Cc: Ed Schouten; freebsd-stable; jo...@freebsd.org; Kenneth D. Merry;
> freebsd-s...@freebsd.org; Justin T. Gibbs; McConnell, Stephen
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
> 
> On Thu, 23 Feb 2012 18:45:29 +0530
> "Desai, Kashyap"  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Ed Schouten [mailto:e...@80386.nl]
> > > Sent: Thursday, February 23, 2012 3:16 PM
> > > To: Desai, Kashyap
> > > Cc: freebsd-s...@freebsd.org; freebsd-stable; jo...@freebsd.org;
> > > Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs
> > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> > > prohibited
> > >
> > > Hi Kashyap,
> > >
> > > * Desai, Kashyap , 20120222 18:51:
> > > > Adding Ed Schouten and Jorg Wunsch  as I see there are author of
> > > > msleep/mtx related APIs.
> > >
> > > Am I? :-)
> > I am new to FreeBSD and desperate to know the answer. :-). Thanks for
> > your help.
> > >
> > > > 1. When any irq is register with FreeBSD OS, it sets "
> > > > TDP_NOSLEEPING" pflag. It means though irq in freebsd is treated
> > > > as thread, We cannot sleep in IRQ because of " "TDP_NOSLEEPING "
> > > > set. 2. In mps driver we have below code snippet in ISR routine.
> > > >
> > > >
> > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__);
> > > > mps_lock(sc);
> > > > mps_intr_locked(data);
> > > > mps_unlock(sc);
> > > >
> > > > I wonder why there is no issue with above code ? Theoretical we
> > > > cannot sleep in ISR. (as explained in #1) Any thoughts ?
> > >
> > > The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate
> > > amount of time. Locking a mutex is allowed, as it can only cause the
> > > thread to be blocked for a small amount of time, waiting for another
> > > thread to unlock it.
> > So does this assumption that another thread will release mutex fast
> > enough ? Same as msleep() this can be applicable here as well. I mean
> > another thread  _can_ (if some bad drivers) take long time to release
> > mutex.
> >
> >
> Bad drivers can just defererence wild pointer to satisfy their need for
> wrongdoing. For that reason let us keep them out of conversation.


OK. 

> 
> mtx locks were designed to protect small sections of code where thread
> is only allowed to block waiting for other thread to release the lock of
> similar class. While threads are blocked, they get benefit of adaptive
> sleep and priority propagation and should take precaution of never
> taking the path of code that can cause them to sleep. Assertions are
> there to help code authors with that.
> 
> sleep locks are by definition unbound. There is no spinning, no priority
> propagation. Holders are free to take, say, page faults and go to long
> journey to disk and back, etc.

I understood your above lines.
> Hardly the stuff _anyone_ would want to
> do from interrupt handler, thread or otherwise.

So the way mps driver does in interrupt handler is as below.

mps_lock(sc);
mps_intr_locked(data);
mps_unlock(sc);

We hold the mtx lock in Interrupt handler and do whole bunch of work(this is 
bit lengthy work) under that. 
It looks mps driver is miss using mtx_lock. Are we ?

~ Kashyap

> 
> 
> > > > 3. I recently added few place msleep() instead of DELAY in ISR
> > > > context and I see " Trying sleep, but thread marked as sleeping
> > > > prohibited".
> > >
> > > Which makes sense, as msleep() can be used to sleep for
> > > indefinitely.
> > This part is clear. ! I agree with all experts view.
> > >
> > > --
> > >  Ed Schouten 
> > >  WWW: http://80386.nl/
> > ___
> > freebsd-s...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> > To unsubscribe, send any mail to
> > "freebsd-scsi-unsubscr...@freebsd.org"
> 
> 
> --
> Alexander Kabaev
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[George Kontostanos]

> Short introduction in order:
>
> See, we use FreeBSD at work for our firewall boxes, running:
> - PF + CARP + PFsync
> - nagios-nrpe
> - munin-node
> - bacula client
>
> and either
> - nginx and/or haproxy
> - relayd
>
> These boxes serve as frontend firewalls for all our projects/products,
> including a few high traffic ones.
>
>
> For example our most traffic intense project has 4 firewalls, 2 each on
> 2 different datacenters, sharing 4 CARP IPs with automagic failover.
>
> These firewalls total ~200mb/s , serving only minifi'ed javascript pages.

> In the current state of things, I have *absolutely* no wish to run it in
> production :(
>
>
>
> I'd love to hear feedback.

This is really a bad example and we shouldn't jump into the .0
releases comparison.

Firewalls are supposed to be super stable. The last thing you need in
a firewall is trying to troubleshoot OS related issues.

Most major brands use well patched long tested OS to build their
firewall software.
So, no you shouldn't jump to 9 before it has been thoroughly tested.
That doesn't mean of course that you should let others do the testing
for you. If you plan on moving your environment to 9 at some point in
the future then you have to start your own testing now.

Best Regards,

-- 
George Kontostanos
Aicom telecoms ltd
http://www.aisecure.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Fatal trap 19, Stopped at bge_init_locked+ and bge booting problems

[YongHyeon PYUN]

On Thu, Feb 23, 2012 at 07:41:25AM +0100, Attila Nagy wrote:
> On 02/23/12 21:44, YongHyeon PYUN wrote:
> >I have to ask more information for the controller to Broadcom.
> >Not sure whether I can get some hint at this moment though. :-(
> Is there anything I can do? I ask this because I have to give back this 
> server very soon.
> >
> >Given that you also have USB related errors, could you completely
> >remove bge(4) in your kernel and see whether it can successfully
> >boot up?
> >I think you can add the following entries to /boot/device.hints
> >without rebuilding kernel.
> >
> >hint.bge.0.disabled="1"
> >hint.bge.1.disabled="1"
> >hint.bge.2.disabled="1"
> >hint.bge.3.disabled="1"
> This does not help.
> Removing bge makes it stop here:
> da0 at ciss0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SCSI-5 device
> da0: 135.168MB/s transfers
> da0: Command Queueing enabled
> da0: 286070MB (585871964 512 byte sectors: 255H 32S/T 65535C)
> panic: bootpc_init: no eligible interfaces
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> kdb_backtrace() at kdb_backtrace+0x37
> panic() at panic+0x187
> bootpc_init() at bootpc_init+0x1205
> mi_startup() at mi_startup+0x77
> btext() at btext+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stopped at  kdb_enter+0x3b: movq$0,0x976972(%rip)
> db>
> 
> Which is completely OK, because there are really no interfaces to boot 
> from. Note that there is no NMI either (maybe because it would happen 
> later in the initialization process).
> Sadly, I can't boot from disk, but I assume it would work.

Ok, I guess you're seeing similar issue that Sean reported.  I'll
let you when I have experimental patch.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Erich Dollansky]

Hi,

On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote:
> 
> This is NOT a troll.
> This is NOT a flame.
> Do NOT hijack this thread to troll/flame.
> 
allow them some fun too.
> 
> 
> Now, I find the number of problem reports regarding 9.0-RELEASE alarming
> and I'm growing more and more fearful towards it.
> 
> In the current state of things, I have *absolutely* no wish to run it in
> production :(
> 
Did you read deeply into the strategy behind the releases? If I remember right, 
the odd numbers are a little bit more experimental compared to the even 
numbers. For myself, I try to stick with even numbers whenever possible. If I 
install FreeBSD on a serious machine, I never use x.0. It must be at least x.1.

So, I have the same wish as you and did not expect much more.

Never forget, if the people behind the scene never put a release out, we never 
have the chance to iron out the problems.

And now the fun. I even run 8.3 beta on my personal workstation. But I still 
would not put 9.0 on any machine I work with or give it to somebody else for 
this purpose.

Erich
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Petro Rossini]

Hi Damien,

On Fri, Feb 24, 2012 at 5:25 AM, Damien Fleuriot  wrote:
> I'm writing this in light of the *many* problem reports I see on the
> lists with 9.0-RELEASE.
>
> I'm getting extremely worried here.
> ..
> See, we use FreeBSD at work for our firewall boxes, running:
> ..
> These boxes serve as frontend firewalls for all our projects/products,
> including a few high traffic ones.
>

Hi Damien,

I guess you wouldn't roll out a new release on all FreeBSD servers in one go.

For most environments there is room to staging it, from test and
developer boxes upwards to production.

At the moment I am running FreeBSD 9 on some developer boxes, Nagios
monitoring and others.

It works without problems even if I am using VIMAGE which is still an
experimental feature.

Sooner or later I will install it on other more relevant production machines.

Don't worry, it isn't that bad;-)

If I can have one wish from the engineering team: please keep the
schedule up to date.

http://www.freebsd.org/releases/9.0R/schedule.html isn't showing the
release yet, http://wiki.freebsd.org/Releng/9.0TODO was also quite
behind.

Maybe one web page is enough..

Thanks
Peter
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD9 and the sheer number of problem reports

[Erich Dollansky]

Hi,

On Friday 24 February 2012 04:21:12 Peter Maloney wrote:
> Am 23.02.2012 21:15, schrieb Mark Felder:
> > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot  wrote:
> >
> >>
> >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming
> >> and I'm growing more and more fearful towards it.
> >
> I suggest these concepts should be tested:
> 
I can tell you what in practical terms stops me from testing very often. The 
switch back to the running version.

Let me suggest this.

Currently, we have on the disk normally two kernels. The current one and the 
last one. Why not add a third one called testing?

Add then an entry into the boot menu that users can switch between the current 
kernel and a kernel they just installed for testing.

I know that I can do this manually. But this is the point where it becomes 
difficult for the majority of people.

As FreeBSD needs a large amount of testing on unknown hardware, this could 
increase the number of actual testers without much effort.

Ok, the developers must then be ready to deal with reports which miss many 
things.

Erich
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: random problem with 8.3 from yesterday

[Erich Dollansky]

Hi,

On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote:
> Am 22.02.2012 um 07:34 schrieb Erich Dollansky:
> 
> > 
> > tunefs -L NewDeviceName /dev/da0a
> > 
> > Either this call or the mount command does not work randomly.
> > 
> > When I then try to mount the device on /dev/da0a it does not work always.
> > 
> > I do not know what this causes, I am only randomly able to reproduce it.
> > 
> > It might be affected by removing the device or keeping it plugged in.
> 
> You need to be more specific: what "does not work" mean? Output, results?
> 
it seems that I forgot to copy the console output for this.

Ok, as far as I remember, tunefs said something like it does not recognise the 
slice.

Mount has had two different messages. One also said that it could not 
find/recognise the slice. The other one said that the file system was unknown 
despite just running a newfs on it.

I am very much aware that this kind of errors are very hard to find especially 
if they are not reproduceable.

Erich

> 
> Stefan
> 
> -- 
> Stefan BethkeFon +49 151 14070811
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"