On Fri, Jun 12, 2015 at 1:30 AM, Ranjan1018 . <21474...@gmail.com> wrote:
>
>
> 2015-06-12 1:13 GMT+02:00 Henry Hu :
>
>> On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman
>> wrote:
>>
>>> The same issue exists in fusefs, but has an uglier result. The fuse
>>> daemon
>>> shuts down before any fusefs
2015-06-12 1:13 GMT+02:00 Henry Hu :
> On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman wrote:
>
>> The same issue exists in fusefs, but has an uglier result. The fuse daemon
>> shuts down before any fusefs based file systems are unmounted, but, for
>> several R/W file systems including NTFS and exF
s if you hit control-t, i.e. what wait channel does it
> print
> > > out?
> > > - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)?
> > > - What’s your root media (SSDs, SATA/PATA hard drives, etc)?
> > >
> > > Thanks..
> > >
mounted (fuse, NFS, UFS, ZFS)?
> > - What’s your root media (SSDs, SATA/PATA hard drives, etc)?
> >
> > Thanks..
> >
>
> Solved !
>
> The slow shutdown is caused by some remote smbfs shares mounted via
> openvpn: the remote drives are unmounted after the o
of info here to diagnose your issue...
> - What happens if you hit control-t, i.e. what wait channel does it print
> out?
> - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)?
> - What’s your root media (SSDs, SATA/PATA hard drives, etc)?
>
> Thanks..
>
Solved !
The
2015-05-24 22:33 GMT+02:00 Garrett Cooper :
> On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote:
>
> > On my laptop running r283297, after the message “All buffers synced.” and
> > before “Uptime: …..” it takes more than 55 seconds.
>
> Not a lot of info here to diagnose your issue
On Sun, May 24, 2015 at 1:33 PM, Garrett Cooper
wrote:
> On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote:
>
> > On my laptop running r283297, after the message “All buffers synced.” and
> > before “Uptime: …..” it takes more than 55 seconds.
>
> Not a lot of info here to diagnos
On May 24, 2015, at 6:33, Ranjan1018 . <21474...@gmail.com> wrote:
> On my laptop running r283297, after the message “All buffers synced.” and
> before “Uptime: …..” it takes more than 55 seconds.
Not a lot of info here to diagnose your issue...
- What happens if you hit control-t, i.e. what wait
On my laptop running r283297, after the message “All buffers synced.” and
before “Uptime: …..” it takes more than 55 seconds.
Regards,
Maurizio
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsu
On 2000-Aug-07 14:49:34 -0700, David Greenman <[EMAIL PROTECTED]> wrote:
> No, that's not true, and there are many examples in the kernel where a
>bogus wakeup would lead to bad things happening. I recall some code in the
>advisory locking code, and VM system, that assume that there is only one
In message <[EMAIL PROTECTED]>, Stephen McKay writes:
>Regardless of the history of it all, FreeBSD is full of places where
>unexpected wakeups can stuff you right up. Should we regard tsleep() like
>the older sleep() call, as suspect, and program defensively? Should we
>be pragmatic, admit "We
Well, I've failed in my main objective (to deuglify the shutdown messages),
but an interesting debate has resulted instead, so I can't feel too bad.
I did a little research to support my position on sleep/wakeup, and here's
the best I have. This is pretty long, and unlikely to shake your world v
> It's not just that, if you always have to cover your behind when
> doing tsleep you may wind up masking wakeup bugs. Places like
> "vfs_bio.c" line 586 of 3182:
>
> bp->b_xflags |= BX_BKGRDWAIT;
> tsleep(&bp->b_xflags, PRIBIO, "biord", 0);
> if (bp->b_
* David Greenman <[EMAIL PROTECTED]> [000807 23:15] wrote:
> >In article <[EMAIL PROTECTED]>, David Greenman
> ><[EMAIL PROTECTED]> wrote:
>
> >Obviously the waker-upper knows that the condition is true. Otherwise
> >the existing code which doesn't check wouldn't work. In the expensive
> >cases
>In article <[EMAIL PROTECTED]>, David Greenman
><[EMAIL PROTECTED]> wrote:
>> >I will add that this is the pattern that Kirk teaches in his kernel
>> >internals class.
>>
>>If that's true,
>
>Do you want me to fax you a copy of page 15 of his class notes from
>the course he gave at last year'
In article <[EMAIL PROTECTED]>, David Greenman
<[EMAIL PROTECTED]> wrote:
> >I will add that this is the pattern that Kirk teaches in his kernel
> >internals class.
>
>If that's true,
Do you want me to fax you a copy of page 15 of his class notes from
the course he gave at last year's FreeBSD
>I will add that this is the pattern that Kirk teaches in his kernel
>internals class.
If that's true, then he should practice what he preaches. Some of the code
that I'm refering to (e.g. lockf) was apparantly written by him.
I'll say again, however, that some of the cases that rely on the
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> * Poul-Henning Kamp <[EMAIL PROTECTED]> [000807 10:03] wrote:
> >
> > Then this code should be changed to do the right thing, which is
> > to *always* check the condition being slept on before proceeding.
>
> Can you
>I did say "as a general rule". If you know that "by design" nothing else
>is going to mess with what you're sleeping on before you wake up then
>you can make tighter optimisations but that's not the general case.
>There is such a thing as over optimisation though and for the sake of a
>simple if
David Greenman wrote:
>
> >In the particular case of sleeping though, a woken process does need to
> >check the condition that it slept on because one of the other processes
> >sleeping on that resource may have had a chance to run first and changed
> >some state. So as a general rule, you should
>In the particular case of sleeping though, a woken process does need to
>check the condition that it slept on because one of the other processes
>sleeping on that resource may have had a chance to run first and changed
>some state. So as a general rule, you shouldn't assume that everything
>is fi
David Greenman wrote:
>
> >>Can you give a reason why we'll have to now start coding defensively
> >>because our arguments to tsleep() are just "advisory" now?
> >
> >It is not something we "suddenly have to do" it's been The Right Way
> >even since I first sharpened my teeth on unix kernels many
Just a quick perusal of the kernel code shows a number of possible
unexpected side effects from unexpected wakeups. I see several places
where a 'WANTED' flag is set in a loop waiting for something and assumed
to be cleared after the tsleep() returns. Some of these side effects
>>Can you give a reason why we'll have to now start coding defensively
>>because our arguments to tsleep() are just "advisory" now?
>
>It is not something we "suddenly have to do" it's been The Right Way
>even since I first sharpened my teeth on unix kernels many years ago.
Uh, Poul, I think y
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> Then this code should be changed to do the right thing, which is
>> to *always* check the condition being slept on before proceeding.
>
>Can you give a reason why we'll have to now start coding defensively
>because our arguments to tslee
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000807 10:03] wrote:
> In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> >:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> >:> >
> >:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> >:> > syncer are sleeping wh
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
>:> >
>:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
>:> > syncer are sleeping when they are told to suspend. This delays shutdown
>:> > by a few boring
:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
:> >
:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
:> > syncer are sleeping when they are told to suspend. This delays shutdown
:> > by a few boring seconds. With this patch, it is zippier. I expect peop
In message <[EMAIL PROTECTED]> Stephen McKay writes:
: And back to the simpler bit (the bike shed bit). Does everyone else actually
: *like* the verbose messages currently used? And the gratuitous extra newline
: in the "syncing..." message?
I like the newer messages in your patch, but I don't
> * Mike Smith <[EMAIL PROTECTED]> [000807 01:25] wrote:
> > > * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> > > >
> > > > ... every sleeping process should expect
> > > > to be woken for no reason at all. Basic kernel premise.
> > >
> > > You better bet it's controversial, this i
* Mike Smith <[EMAIL PROTECTED]> [000807 01:25] wrote:
> > * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> > >
> > > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> > > syncer are sleeping when they are told to suspend. This delays shutdown
> > > by a few bor
> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
> >
> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> > syncer are sleeping when they are told to suspend. This delays shutdown
> > by a few boring seconds. With this patch, it is zippier. I expect people
>
* Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
>
> Patch 2 is smaller and possibly controversial. Normally bufdaemon and
> syncer are sleeping when they are told to suspend. This delays shutdown
> by a few boring seconds. With this patch, it is zippier. I expect people
> to complai
On Sun, 06 Aug 2000 01:49:49 +1000, Stephen McKay wrote:
> I think shutdown time has gotten uglier and slower than it needs to be.
Probably because you already understand what's going on. The existing
text for the "stopping process" messages is designed to help folks stay
calm while their mac
I'm off in a few days for a couple months of tourism in Europe (no, no need
for sympathy!), so I'm dumping these couple ideas on you and running.
I think shutdown time has gotten uglier and slower than it needs to be.
I want to apply these patches (well, at least the first one) before I escape
ra
35 matches
Mail list logo
