>Number:         2513
>Category:       port-amiga
>Synopsis:       time stops to proceed
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun  4 05:50:02 1996
>Last-Modified:
>Originator:     S.P.Zeidler
>Organization:
spz@serpens.rhein.de (S.P.Zeidler)
>Release:        1.1
>Environment:
	Amiga 3000 NetBSD 1.1 audio-LKM Xdaniver
System: NetBSD serpens 1.1 NetBSD 1.1 (SERPENS) #8: Tue Mar 12 09:34:07 MET 1996 mlelstv@serpens:/usr2/src/sys/arch/amiga/compile/SERPENS amiga


>Description:
	Time stops to proceed. All runs on happily, just things dependent on
	the passing of time (most immediately noticeable: mouse moves and
	keyboard repeat, then date, but also the *stat and top and cron and so
	on) sit & do nothing.

	Since the Isel meeting, which introduced Xdaniver with a patch to
	actually use /dev/audio as X bell to my system, I had to reboot on
	three occasions to make time run again. :-/ First occurrence was after
	four days uptime, second and third after about a day, each. Each
	time I had started arena or Mosaic (which cause the Xserver to go quite 
	busy) shortly before, the frequency of beeps did not increase
	significantly in the latter two uptime periods. 

	I don't see obvious problems with the audio LKM and it didn't cause 
	problems while just playing music samples by cat either; OTOH 
	Xdaniver doesn't look suspicious either. If it's software, it's
	probably some weird side effect of the audio kernel changes, and a
	time race too.

	I can't easily see how making X busy should trigger a hardware
	problem, but this is also a possibility to be taken into account.

	Anyone else seen something like this?

>How-To-Repeat:
	unknown
>Fix:
	I'd be very happy if I even had a fix on the source of the problem. :-)

Regards,
	spz
>Audit-Trail:
>Unformatted: