scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Brad Midgley]

paul,

what was the result of testing this patch? i see it isn't present at vger.
but does it make scsi activity safer? does it need more testing? should i
test it as-is?

dan, have you figured out a setup to burn cd's without panics?

brad

> Paul Mackerras <paulus@cs.anu.edu.au> wrote:
> 
> Daniel Jacobowitz <drow@drow.res.cmu.edu> wrote:
> > Anything involving general heavy load (say, compiling XFree86) on an
> > external disk causes either lockups or panics (inactive in
> 
> There used to be some cli's in drivers/scsi/sd.c which disappeared at
> some stage (I don't know why).  The following patch puts them back
> in.  Could you try this?  One person said that it helped but that then
> 
> --- linux/drivers/scsi/sd.c	Tue Oct 20 21:44:44 1998
> +++ linux-pmac/drivers/scsi/sd.c	Wed Nov  4 13:48:30 1998
> @@ -531,10 +531,14 @@
>      Scsi_Cmnd * SCpnt = NULL;
>      Scsi_Device * SDev;
>      struct request * req = NULL;
> +    unsigned long flags;
>      int flag = 0;
>  
> +    save_flags(flags);
>      while (1==1){
> +	cli();
>  	if (CURRENT != NULL && CURRENT->rq_status == RQ_INACTIVE) {
> +	    restore_flags(flags);
>  	    return;
>  	}
>  
> @@ -549,6 +553,7 @@
>           */
>          if( SDev->host->in_recovery )
>            {
> +	    restore_flags(flags);
>              return;
>            }
>  
> @@ -601,6 +606,7 @@
>  	 * Using a "sti()" gets rid of the latency problems but causes
>  	 * race conditions and crashes.
>  	 */
> +	restore_flags(flags);
>  
>  	/* This is a performance enhancement. We dig down into the request
>  	 * list and try to find a queueable request (i.e. device not busy,
> @@ -618,6 +624,7 @@
>  	if (!SCpnt && sd_template.nr_dev > 1){
>  	    struct request *req1;
>  	    req1 = NULL;
> +	    cli();
>  	    req = CURRENT;
>  	    while(req){
>  		SCpnt = scsi_request_queueable(req,
> @@ -632,6 +639,7 @@
>  		else
>  		    req1->next = req->next;
>  	    }
> +	    restore_flags(flags);
>  	}
>  
>  	if (!SCpnt) return; /* Could not find anything to do */
> 
> 



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[satadru pramanik]

Please let me know!!! And if this _does- fix the problem, it should go to
linus asap, before 2.2 gets finalized.  This certainly is a problem for
me, and I can't imagine seeing a 2.2 final kernel that hangs on serious
scsi activity. ( it crashes my web server every ten minutes.)


On Sat, 2 Jan 1999, Brad Midgley wrote:


paul,

what was the result of testing this patch? i see it isn't present at vger.
but does it make scsi activity safer? does it need more testing? should i
test it as-is?

dan, have you figured out a setup to burn cd's without panics?

brad

> Paul Mackerras <paulus@cs.anu.edu.au> wrote:
> 
> Daniel Jacobowitz <drow@drow.res.cmu.edu> wrote:
> > Anything involving general heavy load (say, compiling XFree86) on an
> > external disk causes either lockups or panics (inactive in
> 
> There used to be some cli's in drivers/scsi/sd.c which disappeared at
> some stage (I don't know why).  The following patch puts them back
> in.  Could you try this?  One person said that it helped but that then
> 
> --- linux/drivers/scsi/sd.c	Tue Oct 20 21:44:44 1998
> +++ linux-pmac/drivers/scsi/sd.c	Wed Nov  4 13:48:30 1998
> @@ -531,10 +531,14 @@
>      Scsi_Cmnd * SCpnt = NULL;
>      Scsi_Device * SDev;
>      struct request * req = NULL;
> +    unsigned long flags;
>      int flag = 0;
>  
> +    save_flags(flags);
>      while (1==1){
> +	cli();
>  	if (CURRENT != NULL && CURRENT->rq_status == RQ_INACTIVE) {
> +	    restore_flags(flags);
>  	    return;
>  	}
>  
> @@ -549,6 +553,7 @@
>           */
>          if( SDev->host->in_recovery )
>            {
> +	    restore_flags(flags);
>              return;
>            }
>  
> @@ -601,6 +606,7 @@
>  	 * Using a "sti()" gets rid of the latency problems but causes
>  	 * race conditions and crashes.
>  	 */
> +	restore_flags(flags);
>  
>  	/* This is a performance enhancement. We dig down into the request
>  	 * list and try to find a queueable request (i.e. device not busy,
> @@ -618,6 +624,7 @@
>  	if (!SCpnt && sd_template.nr_dev > 1){
>  	    struct request *req1;
>  	    req1 = NULL;
> +	    cli();
>  	    req = CURRENT;
>  	    while(req){
>  		SCpnt = scsi_request_queueable(req,
> @@ -632,6 +639,7 @@
>  		else
>  		    req1->next = req->next;
>  	    }
> +	    restore_flags(flags);
>  	}
>  
>  	if (!SCpnt) return; /* Could not find anything to do */
> 
> 




----
satadru pramanik www.umich.edu/~satadru
Do, or do not.  There is no try.
-Yoda
---


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Daniel Jacobowitz]

On Sat, Jan 02, 1999 at 06:04:01PM -0500, satadru pramanik wrote:
> Please let me know!!! And if this _does- fix the problem, it should go to
> linus asap, before 2.2 gets finalized.  This certainly is a problem for
> me, and I can't imagine seeing a 2.2 final kernel that hangs on serious
> scsi activity. ( it crashes my web server every ten minutes.)
> 
> 
> On Sat, 2 Jan 1999, Brad Midgley wrote:
> 
> 
> paul,
> 
> what was the result of testing this patch? i see it isn't present at vger.
> but does it make scsi activity safer? does it need more testing? should i
> test it as-is?
> 
> dan, have you figured out a setup to burn cd's without panics?


I am not at my machine for another week, but judging from what I have
heard - the patch does make it safer, is certainly a good idea to
apply, and yet still does not resolve the issue.  I need to find out
how it affects my machine - expect this as soon as I can.

Meanwhile, Satadru, I suggest you invest in an internal drive - or try
using all your devices on the same scsi controller, which I have heard
might help.


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Paul Mackerras]

Brad Midgley <brad@pht.com> wrote:

> what was the result of testing this patch? i see it isn't present at vger.
> but does it make scsi activity safer? does it need more testing? should i
> test it as-is?

[patch to drivers/scsi/sd.c snipped]

It turns out that patch isn't necessary - all that was needed is to do
spin_lock_irqsave(&io_request_lock, flags) before calling the scsi
done function in the mesh driver (and spin_unlock_irqrestore after).
That's done, in different forms, both in vger and Linus' 2.2.0-pre2
and later, so it should be OK now.

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Brad Midgley]

i have tried out the current vger kernel and i'd characterize it as "five
times" as stable. meaning i can copy 125 megabytes from a jaz on the
external bus to a drive on the internal bus before it crashes--with
2.1.130 i could only copy about 25 megabytes before it crashed. the error
when it crashes is always:

Kernel panic: Inactive in scsi_request_queueable
In swapper task - not syncing
Rebooting in 180 seconds...

is there anything i could do to help dig up this problem?

thanks
brad

> 
> Brad Midgley <brad@pht.com> wrote:
> 
> > what was the result of testing this patch? i see it isn't present at vger.
> > but does it make scsi activity safer? does it need more testing? should i
> > test it as-is?
> 
> [patch to drivers/scsi/sd.c snipped]
> 
> It turns out that patch isn't necessary - all that was needed is to do
> spin_lock_irqsave(&io_request_lock, flags) before calling the scsi
> done function in the mesh driver (and spin_unlock_irqrestore after).
> That's done, in different forms, both in vger and Linus' 2.2.0-pre2
> and later, so it should be OK now.
> 
> Paul.
> 


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Geert Uytterhoeven]

On Sun, 3 Jan 1999, Brad Midgley wrote:
> i have tried out the current vger kernel and i'd characterize it as "five
> times" as stable. meaning i can copy 125 megabytes from a jaz on the
> external bus to a drive on the internal bus before it crashes--with
> 2.1.130 i could only copy about 25 megabytes before it crashed. the error
> when it crashes is always:
> 
> Kernel panic: Inactive in scsi_request_queueable
> In swapper task - not syncing
> Rebooting in 180 seconds...
> 
> is there anything i could do to help dig up this problem?

Does the patch for drivers/scsi/sd.c fixes this?

I haven't seen this panic anymore since I moved all my devices except my 40
MB boot disk from my MESH to my Sym875.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Paul Mackerras]

Brad Midgley <brad@pht.com> wrote:

> i have tried out the current vger kernel and i'd characterize it as "five
> times" as stable. meaning i can copy 125 megabytes from a jaz on the
> external bus to a drive on the internal bus before it crashes--with
> 2.1.130 i could only copy about 25 megabytes before it crashed. the error
> when it crashes is always:

Actually, I'm not sure that the vger version had the locking exactly
right before.  The version in vger is now the same as the version
currently in the official tree, and I am moderately confident it's OK.
If you can reproduce it with that version, I really will have to dig
deeper.

We will never get the sd.c patch into the official version because it
breaks SMP machines.  I know because that's what happened on my SMP
powermac. :-)

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Daniel Jacobowitz]

On Mon, Jan 04, 1999 at 10:38:45PM +1100, Paul Mackerras wrote:
> Brad Midgley <brad@pht.com> wrote:
> 
> > i have tried out the current vger kernel and i'd characterize it as "five
> > times" as stable. meaning i can copy 125 megabytes from a jaz on the
> > external bus to a drive on the internal bus before it crashes--with
> > 2.1.130 i could only copy about 25 megabytes before it crashed. the error
> > when it crashes is always:
> 
> Actually, I'm not sure that the vger version had the locking exactly
> right before.  The version in vger is now the same as the version
> currently in the official tree, and I am moderately confident it's OK.
> If you can reproduce it with that version, I really will have to dig
> deeper.
> 
> We will never get the sd.c patch into the official version because it
> breaks SMP machines.  I know because that's what happened on my SMP
> powermac. :-)


I don't have the exact messages, but attempting to use an external CDR
(boot drive on MESH, burner on 53c94) locks up with a bunch of illegal
sense requests.  Then it tries to reset the external bus, times out,
claims to try harder, and more or less locks up.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Brad Midgley]

hi,

the author of cdrecord suggests we look at:

Disabled disconnect/reconnect on the SCSI bus
A bug in the scheduler or pager in the kernel.

full message is below.

brad

From: Joerg Schilling <schilling@fokus.gmd.de>

>From brad@pht.com Sun Jan 17 03:47:57 1999

>i use cdrecord on linux on both pc and ppc. the recent ppc kernels have a
>problem and i hope you can offer insight so i can locate and hopefully fix
>the problem in the kernel. 

>i can use v1.6 on pc (kernel 2.0.35) without problems; but on the ppc,
>v1.6, which used to work on v2.1.24, now dies consistently after writing
>less than 10M using v2.2.0pre5. i've tried the current version of cdrecord
>with the same result: 

>Executing 'write_g1' command on Bus 1 Target 4, Lun 0 timeout 40s
>CDB:  2A 00 00 00 27 00 00 00 10 00
>cdrecord: I/O error. write_g1: scsi sendcmd: retryable error
>CDB:  2A 00 00 00 27 00 00 00 10 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 10 02 00 00
>Sense Key: 0x5 Illegal Request, Segment 0
>Sense Code: 0x10 Qual 0x02 (id crc or ecc error) [No matching qualifier]
>Fru 0x0

>this is a ricoh connected to the ppc's 53C94 bus.

>the complete -v -v -V log is at http://pht.com/~brad/cdrecord/ but it's
>too long to include here. 


As the Sense Key 0x5 (illegal request is illegal in combination
with sense code 0x10, I would guess that this is a buffer underrun.
A buffer underrun usually ends up in an illegal request key as the
next write operation after the underrun will use an illegal
sector address from the point of view of the drive.

Now lets discussw why a buffer underrun may occur:

1)	Disabled disconnect/reconnect on the SCSI bus

2)	Incorrect termination on the SCSI bus

3)	A bug in the scheduler or pager in the kernel.

>ps it might be worth mention in the docs: a suggestion with regard to
>shmmax settings and cdrecord. it appears that the shmmax value can be
>changed at runtime from the default < 4M to a value more optimal for
>cdrecord:

>echo 6000000 >/proc/sys/kernel/shmmax


Interesting, it is not included 2.1.118 for Intel.

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

--------

I don't have the exact messages, but attempting to use an external CDR
(boot drive on MESH, burner on 53c94) locks up with a bunch of illegal
sense requests.  Then it tries to reset the external bus, times out,
claims to try harder, and more or less locks up.



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Brad Midgley]

i did a successful burn today! woohoo!

cdrecord: fifo was 0 times empty and 13164 times full, min fill was 92%.

the solution was to move the hard drive with the data on it to the
internal scsi bus on my 7500. the burner (a ricoh) is still on the
53c94. 

so... the 53c94 driver currently doesn't allow enough access to regular
hard drives when you're using the generic device. i don't know how this
relates to disconnect/reconnect or the scheduler. 

it isn't going to be an option for everybody to move their source drives
to another bus but at least we know burning works in some configurations. 

brad

>the author of cdrecord suggests we look at:
> Disabled disconnect/reconnect on the SCSI bus
> A bug in the scheduler or pager in the kernel.



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Paul Mackerras]

Brad Midgley <brad@pht.com> wrote:

> so... the 53c94 driver currently doesn't allow enough access to regular
> hard drives when you're using the generic device. i don't know how this
> relates to disconnect/reconnect or the scheduler. 

IIRC, the mac53c94.c driver doesn't support disconnect/reconnect.  I
presume it can but I don't know how you make it do it.

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

rsync kernel is incomplete

[Brad Midgley]

paul,

could you open drivers/uusbd?

rsync -avz samba.anu.edu.au::linux-pmac-devel /mnt/nfs/linux
 [...]
receiving file list ... opendir(drivers/uusbd): Permission denied

thanks
brad


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: rsync kernel is incomplete

[Paul Mackerras]

Brad Midgley <brad@pht.com> wrote:

> could you open drivers/uusbd?
> 
> rsync -avz samba.anu.edu.au::linux-pmac-devel /mnt/nfs/linux
>  [...]
> receiving file list ... opendir(drivers/uusbd): Permission denied

Oops, sorry, fixed now.

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: rsync kernel is incomplete

[VALETTE Eric]

>>>>> "Paul" == Paul Mackerras <paulus@cs.anu.edu.au> writes:

Paul> Brad Midgley <brad@pht.com> wrote:

>> could you open drivers/uusbd?
>> 
>> rsync -avz samba.anu.edu.au::linux-pmac-devel /mnt/nfs/linux
>> [...]
>> receiving file list ... opendir(drivers/uusbd): Permission denied

Just because you mention rsync : It is unusable for people like
me that are after firewalls... So CVS access is still required...

-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: rsync kernel is incomplete

[Brad Midgley]

paul,

is there a special keymap or something that i should be using? the 2.2.1
kernel boots great but now i can't type at the console (the result is
garbage). it used to be that i could type at the console but typing inside
X was the only place a problem showed up. now it's both. 

it didn't look like the files at
ftp://samba.anu.edu.au/pub/linux-pmac/imac/ would be of help. 

thanks
brad

ps. does everybody use X with 8-bit ofonly? that's the only way i could
get x on imac to display correctly. 




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: rsync kernel is incomplete

[Paul Mackerras]

Brad Midgley <brad@pht.com> wrote:

> is there a special keymap or something that i should be using? the 2.2.1
> kernel boots great but now i can't type at the console (the result is
> garbage). it used to be that i could type at the console but typing inside
> X was the only place a problem showed up. now it's both. 

I assume you're talking about the iMac. :-)

The kernel should have the correct keymap in it when it boots (well,
correct for US and Australia anyway :-).  You just need to make sure
the init scripts don't load up a keytable for an ADB keyboard.  One
way to do this is to change the definition of KEYTABLE in
/etc/sysconfig/keyboard to something that doesn't exist, for example,
/usr/lib/kbd/keytables/usb.map.

Assuming you're using the XF68_FBDev from Geert's web page, it should
read the keytable from the kernel on startup, provided you have
XkbDisable in your /etc/XF86Config.

> ps. does everybody use X with 8-bit ofonly? that's the only way i could
> get x on imac to display correctly. 

These days I use video=atyfb:vmode:17 and the XF86Config below and it
works great.  You can even use control command KP+ and control command
KP- to change the screen resolution.

Paul.

# $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.21 1996/01/31 11:46:37 dawes Exp $
#
# Copyright (c) 1994 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# 
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#
# $XConsortium: XF86Conf.cpp /main/16 1996/01/31 10:03:57 kaleb $

# **********************************************************************
# Refer to the XF86Config(4/5) man page for details about the format of 
# this file. This man page is installed as /usr/X11R6/man/man5/XF86Config.5x 
# **********************************************************************

# **********************************************************************
# Files section.  This allows default font and rgb paths to be set
# **********************************************************************

Section "Files"

# The location of the RGB database.  Note, this is the name of the
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.

    RgbPath	"/usr/X11R6/lib/X11/rgb"

# Multiple FontPath entries are allowed (which are concatenated together),
# as well as specifying multiple comma-separated entries in one FontPath
# command (or a combination of both methods)

    FontPath	"/usr/X11R6/lib/X11/fonts/misc/"
#    FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
#    FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath	"/usr/X11R6/lib/X11/fonts/Type1/"
    FontPath	"/usr/X11R6/lib/X11/fonts/Speedo/"
    FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/"
    FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/"

EndSection

# **********************************************************************
# Server flags section.
# **********************************************************************

Section "ServerFlags"

# Uncomment this to cause a core dump at the spot where a signal is 
# received.  This may leave the console in an unusable state, but may
# provide a better stack trace in the core dump to aid in debugging

#    NoTrapSignals

# Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
# This allows clients to receive this key event.

#    DontZap

# Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
# sequences.  This allows clients to receive these key events.

#    DontZoom

# Uncomment this to disable tuning with the xvidtune client. With
# it the client can still run and fetch card and monitor attributes,
# but it will not be allowed to change them. If it tries it will
# receive a protocol error.

#	DisableVidModeExtension

# Uncomment this to enable the use of a non-local xvidtune client.

#	AllowNonLocalXvidtune

EndSection

# **********************************************************************
# Input devices
# **********************************************************************

# **********************************************************************
# Keyboard section
# **********************************************************************

Section "Keyboard"

    Protocol	"Standard"

# when using XQUEUE, comment out the above line, and uncomment the
# following line

#    Protocol	"Xqueue"

    AutoRepeat	500 5

# Let the server do the NumLock processing.  This should only be required
# when using pre-R6 clients
#    ServerNumLock

# Specifiy which keyboard LEDs can be user-controlled (eg, with xset(1))
#    Xleds      1 2 3

# To set the LeftAlt to Meta, RightAlt key to ModeShift, 
# RightCtl key to Compose, and ScrollLock key to ModeLock:

#    LeftAlt     Meta
#    RightAlt    ModeShift
#    RightCtl    Compose
#    ScrollLock  ModeLock

# To disable the XKEYBOARD extension, uncomment XkbDisable.

XkbDisable

# To use the default map in ProjectRoot keymap/xfree86, uncomment 
# XkbKeymap. To use one of the alternate maps in keymap/xfree86 
# uncomment and modify the XkbKeymap line, e.g.: 
#    XkbKeymap   "keymap/xfree86(us_microsoft)"
# To tailor a combination not already in keymap/xfree86 modify
# keymap/xfree86 or uncomment and modify the other lines as 
# desired. One way to get a german layout on a 101 key keyboard 
# is to modify the XkbSymbols line, e.g.:
#    XkbSymbols  "symbols/us(pc101)+de"

#    XkbKeymap   "keymap/xfree86"
#    Xkbkeycodes "keycodes/xfree86"
#    XkbTypes    "types/default"
#    XkbCompat   "compat/default"
#    XkbSymbols  "symbols/us(pc101)"
#    XkbGeometry "geometry/pc"

EndSection


# **********************************************************************
# Pointer section
# **********************************************************************

Section "Pointer"

    Protocol	"busmouse"
    Device	"/dev/usbmouse"

# When using XQUEUE, comment out the above two lines, and uncomment
# the following line.

#    Protocol	"Xqueue"

# Baudrate and SampleRate are only for some Logitech mice

#    BaudRate	9600
#    SampleRate	150

# Emulate3Buttons is an option for 2-button Microsoft mice
# Emulate3Timeout is the timeout in milliseconds (default is 50ms)

#    Emulate3Buttons
#    Emulate3Timeout	50

# ChordMiddle is an option for some 3-button Logitech mice

#    ChordMiddle

EndSection


# **********************************************************************
# Xinput section -- this is optional and is required only if you
# are using extended input devices.  This is for example only.  Refer
# to the XF86Config man page for a description of the options.
# **********************************************************************
#
# Section "Xinput"
#    SubSection "WacomStylus"
#        Port "/dev/ttyS1"
#        DeviceName "Wacom"
#    EndSubSection
#    SubSection "WacomCursor"
#    EndSubSection
#    SubSection "WacomEraser"
#    EndSubSection
#
#    SubSection "Elographics"
#        Port "/dev/ttyS1"
#        DeviceName "Elo"
#        MinimumXPosition 300
#        MaximumXPosition 3500
#        MinimumYPosition 300
#        MaximumYPosition 3500
#        Screen 0
#        UntouchDelay 10
#        ReportDelay 10
#    EndSubSection
#   
#    SubSection "Joystick"
#        Port "/dev/joy0"
#        DeviceName "Joystick"
#        TimeOut 10
#        MinimumXPosition 100
#        MaximumXPosition 1300
#        MinimumYPosition 100
#        MaximumYPosition 1100
#        # CenterX 700
#        # CenterY 600
#        Delta 20
#    EndSubSection
# EndSection


# **********************************************************************
# Monitor section
# **********************************************************************

# Any number of monitor sections may be present

Section "Monitor"

    Identifier	"Nokia447Xi"
    VendorName	"Nokia"
    ModelName	"Multigraph 447Xi"

# HorizSync is in kHz unless units are specified.
# HorizSync may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

#    HorizSync   31.5  # typical for a single frequency fixed-sync monitor

#    HorizSync	15-40         # multisync
#    HorizSync	30-64         # multisync
#    HorizSync	31.5, 35.2    # multiple fixed sync frequencies
#    HorizSync	15-25, 30-50  # multiple ranges of sync frequencies

    HorizSync	31-92

# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

#    VertRefresh 60  # typical for a single frequency fixed-sync monitor

#    VertRefresh	50-100        # multisync
#    VertRefresh	60, 65        # multiple fixed sync frequencies
#    VertRefresh	40-50, 80-100 # multiple ranges of sync frequencies

    VertRefresh	50-100

# Modes can be specified in two formats.  A compact one-line format, or
# a multi-line format.

# A generic VGA 640x480 mode (hsync = 31.5kHz, refresh = 60Hz)
# These two are equivalent

#    ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525

    Mode "640x480"
        DotClock	25.175
        HTimings	640 664 760 800
        VTimings	480 491 493 525
    EndMode

# These two are equivalent

#    ModeLine "1024x768i" 45 1024 1048 1208 1264 768 776 784 817 Interlace

    Mode "1024x768i"
        DotClock	45
        HTimings	1024 1048 1208 1264
        VTimings	768 776 784 817
        Flags		"Interlace"
    EndMode

ModeLine "640x480" 30.438 640 704 768 832 480 512 514 546 -HSync -VSync -CSync
ModeLine "800x600" 49.553 800 864 928 992 600 632 634 666 -HSync -VSync -CSync
ModeLine "832x624" 52.995 832 896 960 1024 624 656 658 690 -HSync -VSync -CSync
ModeLine "1024x768" 76.064 1024 1088 1152 1216 768 800 802 834 -HSync -VSync -CSync
ModeLine "1152x870" 94.358 1152 1216 1280 1344 870 902 904 936 -HSync -VSync -CSync

EndSection

Section "Monitor"

    Identifier	"iMac monitor"
    VendorName	"Apple Computer"
    ModelName	"iMac"

# HorizSync is in kHz unless units are specified.
# HorizSync may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.

    HorizSync	58-62

# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.

    VertRefresh	50-130

# Modes can be specified in two formats.  A compact one-line format, or
# a multi-line format.

Mode "1024x768"
    # D: 78.524 MHz, H: 59.850 kHz, V: 74.813 Hz
    DotClock 78.525
    HTimings 1024 1049 1145 1312
    VTimings 768 769 772 800
    Flags    "+HSync" "+VSync"
EndMode

Mode "800x600"
    # D: 62.356 MHz, H: 59.958 kHz, V: 94.869 Hz
    DotClock 62.357
    HTimings 800 821 901 1040
    VTimings 600 601 604 632
    Flags    "+HSync" "+VSync"
EndMode

Mode "640x480"
    # D: 49.885 MHz, H: 59.958 kHz, V: 116.650 Hz
    DotClock 49.886
    HTimings 640 661 725 832
    VTimings 480 481 484 514
    Flags    "+HSync" "+VSync"
EndMode

EndSection

# **********************************************************************
# Graphics device section
# **********************************************************************

# Any number of graphics device sections may be present

Section "Device"
    Identifier	"Generic VGA"
    VendorName	"Unknown"
    BoardName	"Unknown"
    Chipset	"generic"
#    VideoRam	256
#    Clocks	25.2 28.3
EndSection

Section "Device"
    # SVGA server auto-detected chipset
    Identifier	"Generic SVGA"
    VendorName	"Unknown"
    BoardName	"Unknown"
EndSection

# Section "Device"
#    Identifier	"Any Trident TVGA 9000"
#    VendorName	"Trident"
#    BoardName	"TVGA 9000"
#    Chipset	"tvga9000"
#    VideoRam	512
#    Clocks	25 28 45 36 57 65 50 40 25 28 0 45 72 77 80 75
# EndSection

# Section "Device"
#    Identifier	"Actix GE32+ 2MB"
#    VendorName	"Actix"
#    BoardName	"GE32+"
#    Ramdac	"ATT20C490"
#    Dacspeed	110
#    Option	"dac_8_bit"
#    Clocks	 25.0  28.0  40.0   0.0  50.0  77.0  36.0  45.0
#    Clocks	130.0 120.0  80.0  31.0 110.0  65.0  75.0  94.0
# EndSection

# Section "Device"
#    Identifier	"Hercules mono"
# EndSection

# **********************************************************************
# Screen sections
# **********************************************************************

# The colour SVGA server

Section "Screen"
    Driver	"svga"
    Device	"Generic SVGA"
    Monitor	"Nokia447Xi"
    Subsection "Display"
        Depth	    8
        Modes	    "640x480"
        ViewPort    0 0
        Virtual     800 600
    EndSubsection
EndSection

# The 16-colour VGA server

Section "Screen"
    Driver	"vga16"
    Device	"Generic VGA"
    Monitor	"Nokia447Xi"
    Subsection "Display"
        Modes	    "640x480"
        ViewPort    0 0
        Virtual     800 600
    EndSubsection
EndSection

# The Mono server

Section "Screen"
    Driver	"vga2"
    Device	"Generic VGA"
    Monitor	"Nokia447Xi"
    Subsection "Display"
        Modes	    "640x480"
        ViewPort    0 0
        Virtual     800 600
    EndSubsection
EndSection

# The hercules driver in the Mono and VGA16 servers
#
# Section "Screen"
#     Driver	"mono"
#     Device	"Hercules Mono"
#     Monitor	"Generic Monitor"
#     Subsection "Display"
#     EndSubsection
# EndSection

# The accelerated servers (S3, Mach32, Mach8, 8514, P9000, AGX, W32)

# Section "Screen"
#     Driver	"accel"
#     Device	"Actix GE32+ 2MB"
#     Monitor	"Generic Monitor"
#     Subsection  "Display"
#         Depth	    8
#         Modes	    "640x480"
#         ViewPort    0 0
#         Virtual	    1280 1024
#     EndSubsection
#     SubSection "Display"
#         Depth	    16
#         Weight	    565
#         Modes	    "640x480"
#         ViewPort    0 0
#         Virtual	    1024 768
#     EndSubsection
# EndSection


# **********************************************************************
# Server for the Linux Frame Buffer Device
# **********************************************************************

Section "Device"
    Identifier "Linux Frame Buffer Device"
EndSection

Section "Screen"
    Driver	"fbdev"
    Device	"Linux Frame Buffer Device"
    Monitor	"iMac monitor"
    DefaultColorDepth	8
#    SubSection "Display"
#        Modes       "default"
#    EndSubsection
    SubSection "Display"
        Depth	    8
        Modes	    "1024x768" "800x600" "640x480"
        Virtual	    1024 768
    EndSubSection
    SubSection "Display"
        Depth	    16
        Modes	    "1024x768" "800x600" "640x480"
        Virtual	    1024 768
    EndSubSection
    SubSection "Display"
        Depth	    24
        Modes	    "1024x768" "800x600" "640x480"
        Virtual	    1024 768
    EndSubSection
    SubSection "Display"
        Depth	    32
        Modes	    "1024x768" "800x600" "640x480"
        Virtual	    1024 768
    EndSubSection
EndSection

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

modes "default" unfit for general use?

[Brad Midgley]

hi...

Is it a mistake to have a distribution ship with modes "default" in the
default x windows configuration? 

> These days I use video=atyfb:vmode:17 and the XF86Config below

I was trying to use modes "default" on this iMac. Paul was using concrete
graphics modes. That made all the difference in getting a usable screen. 
This brings to light a general problem: is modes "default" being supported
by any developers? 

 1- It doesn't work with virtual screen sizes (modes "default" on imac
results in a 1024x6128--yes, six thousand--virtual screen size and the x
server ignores attempts to set the virtual screen size in XF86Config) 

 2- It appears that some video drivers just don't support modes "default"
eg iMac. The result on this machine is a white screen flecked with
artifacts and a mouse that appears and disappears, leaving a trail behind
it.

so... if we abandon modes default, what modeline generators are out there
that take the output of `fbset -x` and output a complete XF86Config? is
there a safe way to cycle through all the supported vmodes automatically
and capture these settings for several resolutions? 

brad



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: scsi hangs [drow@cs.cmu.edu: Re: CD-writers] (fwd)

[Daniel Jacobowitz]

On Wed, Feb 03, 1999 at 05:54:38PM -0700, Brad Midgley wrote:
> i did a successful burn today! woohoo!
> 
> cdrecord: fifo was 0 times empty and 13164 times full, min fill was 92%.
> 
> the solution was to move the hard drive with the data on it to the
> internal scsi bus on my 7500. the burner (a ricoh) is still on the
> 53c94. 
> 
> so... the 53c94 driver currently doesn't allow enough access to regular
> hard drives when you're using the generic device. i don't know how this
> relates to disconnect/reconnect or the scheduler. 
> 
> it isn't going to be an option for everybody to move their source drives
> to another bus but at least we know burning works in some configurations. 

This is interesting - my failed burns were from internal HD to external
burner.  They do work now, though, with Paul's evil interrupt-disabling
patch to sd.c.  I couldn't track down why the interrupts were
incorrectly enabled...

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]