Re: Very slow response for `eject cd0' command

[Jukka Salmi <j+nbsd%2009.salmi.ch@localhost>]

Jukka Salmi --> current-users (2009-09-01 14:45:15 +0200):
> Nicolas Joly --> current-users (2009-09-01 14:06:55 +0200):
> > On Tue, Sep 01, 2009 at 12:54:43PM +0100, Iain Hibbert wrote:
> > > On Tue, 1 Sep 2009, Nicolas Joly wrote:
> > > 
> > > > I do see the problem on at least 3 of my amd64 machines where `eject
> > > > cd0' takes about 4 min to succeed ... Result does not change if there
> > > > is a disk in the drive.
> > > > [...]
> > > > Anyone else ?
> > > 
> > > yes, running 5.99.15 with i386 (dual core)
> > > 
> > >   galant: {3} time eject cd0
> > >   0.0u 0.0s 4:00.89 0.0% 0+0k 1+0io 0pf+0w
> > >   galant: {4} /usr/bin/time eject cd0
> > >         240.66 real         0.00 user         0.00 sys
> > > 
> > > it seems to spend its time in select() according to top but I don't see
> > > any select in the source. I also see this on the console just before it
> > > does eject
> > 
> > A further look show that problems comes from amd(8) support for this
> > command... Recompiling it with `AMD_SUPPORT=no' make it works fast
> > again.
> 
> As does passing the -f option to an eject(1) built with AMD_SUPPORT=yes?

Likewise running rpcbind(8) should work around the problem until it is
fixed correctly.


> It's problem [1]this problem.  Christos has a patch for it; not sure if
> it is correct though, but it seems to work.
> 
> 
> Regards, Jukka
> 
> [1] http://mail-index.netbsd.org/current-users/2009/05/21/msg009513.html
> 
> -- 
> This email fills a much-needed gap in the archives.

-- 
This email fills a much-needed gap in the archives.