Date: Mon, 16 Aug 2004 10:27:38 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Marc van Kempen <marc@bowtie.nl> Cc: =?ISO-8859-15?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> Subject: Re: ATA write-dma interrupt was seen but timeout fired LBA=53346288 Message-ID: <Pine.NEB.3.96L.1040816101337.76591D-100000@fledge.watson.org> In-Reply-To: <41209DDA.3090504@bowtie.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Aug 2004, Marc van Kempen wrote: > > Something is holding on to one of the taskqueues blocking the request > > processesing. I'm not sure what caused it but backstepping ATA doesn't > > make things work at least, suggesting to look somewhere else... > > > > For me at least network seems to be troublesome, if I exclude as much > > network related code as possible in the config, I can resume just fine. > > > > YMMV as usual... > I have taken out all the network related options/devices that I could > live without and it resumes fine now. > > Below is my current config file. There are a number of variables we could look at here, so it would be useful if we could sort through them some by trying a few cases -- this may take a bit! Before we start -- are you running with debug.mpsafenet=1, or any more experimental or custom network features? I.e., changes in default network allocation, etc? Could you let me know if the interrupt (and ithread) used by the network device are being shared by any other devices? On notebooks, interrupts are frequently shared (and also Dell desktop systems). This might point at a problem with ithread registration, suspension, restart, and related races. Could you try compiling in support for all the network foo, but leaving the network entirely unused (disable DHCP, don't configure an IP address, don't raise the interface, etc. Maybe even do this in single-user). This might help us determine if it's related specifically to network activity or not -- i.e., an active ithread. If this doesn't help, could you try compiling out all the network service options (inet, NFS, etc), but leaving in the network interfaces? This will help determine if we may be looking at a bug in a service, or perhaps a problem with network interrupt registration or a small set of devices. If you compile out the network interface, but do configure the services, does it still hang? If you compile out the network interface, but configure the services and use them actively over the localhost interface when you suspend, does it hang then? This would also help point at a possible problem in the protocol implementation. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040816101337.76591D-100000>