Re: [Evolution] evolution taking 5+ minutes to shut down

[Jason 'vanRijn' Kasper <vR movingparts net>]

heh.  thanks for your time.  and thanks VERY much for being part of the
ximian team!!

I'll CC the list to bring conclusion to this part of the thread.  =:)

As far as my original problem goes, I'm still at a loss.  I'm running
evolution with "CAMEL_VERBOSE_DEBUG=1 evolution > $HOME/evolution.log
2>&1", but it sure doesn't look like much is being logged.

=:/

On Fri, 2003-06-13 at 00:34, Jeffrey Stedfast wrote:
> yes, looks like it is working for you.
>
> Jeff
>
> On Thu, 2003-06-12 at 21:05, Jason 'vanRijn' Kasper wrote:
> > how did you know they weren't being used?  I'm a tad confused here.
> >
> > Here's what I see that looks relevant per your last post about UDMA
> > kernel support.
> >
> > ICH3M: chipset revision 2
> > ICH3M: not 100% native mode: will probe irqs later
> >     ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
> >     ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio
> >
> > I don't see the line that says "UDMA" like you do, but here's what I
> > see...
> >
> > (gideon gandalf : ~) sudo hdparm -d0 -c0 /dev/hda       
> >
> > /dev/hda:
> >  setting 32-bit IO_support flag to 0
> >  setting using_dma to 0 (off)
> >  IO_support   =  0 (default 16-bit)
> >  using_dma    =  0 (off)
> >
> > (gideon gandalf : ~) sudo hdparm -Tt /dev/hda           
> >
> > /dev/hda:
> >  Timing buffer-cache reads:   128 MB in  0.38 seconds =336.84 MB/sec
> >  Timing buffered disk reads:  64 MB in 23.71 seconds =  2.70 MB/sec
> >
> > (gideon gandalf : ~) sudo hdparm -d1 -c1 /dev/hda       
> >
> > /dev/hda:
> >  setting 32-bit IO_support flag to 1
> >  setting using_dma to 1 (on)
> >  IO_support   =  1 (32-bit)
> >  using_dma    =  1 (on)
> >
> > (gideon gandalf : ~) sudo hdparm -Tt /dev/hda           
> >
> > /dev/hda:
> >  Timing buffer-cache reads:   128 MB in  0.48 seconds =266.67 MB/sec
> >  Timing buffered disk reads:  64 MB in  2.83 seconds = 22.61 MB/sec
> >
> >
> > Now, maybe I'm reading it wrong, but doesn't that look like (since I get
> > a 10-fold increase in read performance), DMA is on and working?
> >
> >
> > On Thu, 2003-06-12 at 20:51, Jeffrey Stedfast wrote:
> > > it was off/disabled by default, but if I used hdparm to set the values
> > > to on, it would say they were 'on' but in reality were not being used.
> > >
> > > sorry if I didn't explain that clearly...
> > >
> > > Jeff
> > >
> > > On Thu, 2003-06-12 at 20:20, Jason 'vanRijn' Kasper wrote:
> > > > not wanting to embarrass myself, I'm replying just to you....
> > > >
> > > > I thought you said that before you had it compiled in your kernel, you
> > > > got "off"/disabled?
> > > >
> > > > On Thu, 2003-06-12 at 19:54, Jeffrey Stedfast wrote:
> > > > > if you have to run hdparm to get those values to be '1', then your
> > > > > kernel doesn't actually support it.
> > > > >
> > > > > I could achieve the same values before I had UDMA support in my kernel
> > > > > my settingthem with hdparm as well, but it wasn't actually being used.
> > > > >
> > > > > Jeff
> > > > >
> > > > > On Thu, 2003-06-12 at 18:56, Jason 'vanRijn' Kasper wrote:
> > > > > > On Thu, 2003-06-12 at 18:44, Jeffrey Stedfast wrote:
> > > > > > > I also run XFS on my home desktop and until I recently rebuilt my kernel
> > > > > > > with UDMA support, any amount of disk I/O would bring my machine to its
> > > > > > > knees.
> > > > > >
> > > > > > *nod*
> > > > > >
> > > > > > > I suggest you make sure that your kernel has UDMA support built in.
> > > > > >
> > > > > > mine does.
> > > > > >
> > > > > > > a quick and dirty check might be to do (as root):
> > > > > > >
> > > > > > > /sbin/hdparm -c -d /dev/hda1
> > > > > >
> > > > > > I have this in my startup script:
> > > > > >
> > > > > > hdparm -u 1 -a 8 -c 1 -d 1 -k 1 /dev/hda
> > > > > >
> > > > > > and I get this when it's run:
> > > > > >
> > > > > >  IO_support   =  1 (32-bit)
> > > > > >  unmaskirq    =  1 (on)
> > > > > >  using_dma    =  1 (on)
> > > > > >  keepsettings =  1 (on)
> > > > > >  readahead    =  8 (on)
> > > > > >
> > > > > > =:/
> > > > > >
> > > > > > Any other thoughts?  =:)  I'm leaning towards notzed's hypothesis of
> > > > > > many, many small temporary files being created, then growing in a big,
> > > > > > big way, then being deleted.
> > > > > >
> > > > > > > If you get something like the following output:
> > > > > > >
> > > > > > > /dev/hda1:
> > > > > > >  IO_support   =  0 (default 16-bit)
> > > > > > >  using_dma    =  0 (off)
> > > > > > >
> > > > > > > then this is what your problem is. After I rebuilt my kernel with UDMA
> > > > > > > support, I get:
> > > > > > >
> > > > > > > /dev/hda1:
> > > > > > >  IO_support   =  1 (32-bit)
> > > > > > >  using_dma    =  1 (on)
> > > > > > >
> > > > > > > or some such. this is what you want :-)
> > > > > > >
> > > > > > > Jeff
-- 

,-----------------------------------------------------------------//
| Jason 'vanRijn' Kasper ::  Numbers 6:22-26 
 `
 | All brontosauruses are thin at one end, much MUCH thicker 
 | in the middle, and then thin again at the far end.  That is 
 | the theory that I have and which is mine, and what it is too.  
 ,
| bash$ :(){ :|:&};:
`----------------------//