Dominik Stadler wrote:
> As far as I understood it (Heiko, please correct me, if this isn't correct),
> the sg_2_0_35.patch allocates one distinct buffer per SCSI-Device in steps
> of exactly 32K, 64K, 128K and for more it allocates the amount needed.
>
> Every device has it's own buffer and tries to use it for the next allocation
> if the size is big enough, otherwise the buffer is thrown away and a
> suitable bigger buffer is allocated.
>
> The intention was to part the allocation for the devices in contrast to the
> earlier SG_BIG_BUF-Implementation where every device shared one buffer, thus
> leading to problems with programs writing/reading concurrently on different
> devices. But we would like to be able to burn CDs and read another in the
> 2nd CD-Device at one time.
The only strategy guaranteed _not_ to fail in 2.0, 2.1 and the new 2.2
kernels
is to compile sg into the kernel (not a module) and get it to allocate
all
the memory it needs before any pesky user processes or disk caches get
started. Mind you if all device drivers adopted this approach ...
So the question is what to do. Apart from the above (impractical)
approach
the sg driver is between a rock and a hard place. Having spent many
hours
fighting with this problem, I would like the the kernel to reserve some
RAM for device drivers to fight over (unlikely to happen) and
application
writers (hello Joerg) to be a bit more flexible. My attempts call for
the following strategy from the application:
- at open() the sg driver reserves 32K (if not 16K, ... down to
PAGE_SIZE)
for this file descriptor. If it can't get PAGE_SIZE then returns
ENOMEM!
- each write() can ask for as much as it likes (eg 512K) _but_ is
prepared
to scale back that request to 32K when ENOMEMs get returned (a
binary
chop algorithm could be used).
An ioctl is available to return the amount of memory the open was able
to
grab so the app writer isn't completely in the dark and is able to
decide
at a safe time whether it is worth while continuing.
> My error arises, because cdrecord opens ALL found SCSI-Devices, doing the
> necessary inquiry and then close ALL devices again, thus needing 32K for
> each found device. On the other hand, I don't know if 192K is really to much
> memory to allocate with kmalloc() on my system? Anybody any information?
Another piece of information that might interest you. The existing 'sg'
and
Heiko's mods (at least the ones I have seen) restricted themselves to
using the bottom 16 Megabytes of RAM on your machine. This is because
ISA
adapters only have a 24 bit address bus. Wait a minute you say, my
machine
has a nice new PCI SCSI adapter. Bad luck.
> Dschau.. Dominik
>
> > -----Urspr�ngliche Nachricht-----
> > Von: Joerg Schilling [SMTP:[EMAIL PROTECTED]]
> > >From [EMAIL PROTECTED] Mon Feb 8 11:32:23 1999
> >
> > >I get a "Not enough memory.."-error regularily while doing "cdrecord
> > >-scanbus" on my Linux-2.0.36-box after some burns and getting one or =
> > >another
> > >error while burning....=20
The very worst time to get an error on a write() to the sg device is
during a CD burn.
> > >As far as I saw my problem isn't concerned with different =
> > >include-files,
> > >because my symbolic-links from /usr/include/[asm;linux;scsi] are in =
> > >place
> > >and I built kernels on my own since over 1 year without this problem in
> > >earlier releases (mybe without the sg-patch!).
> >
> > >I've dug into it and found that "cdrecord -scanbus" will give the =
> > >following
> > >errror-msgs:
> >
> >
> > >a successful "cdrecord -scanbus" would show up like this (you can =
> > >exchange
> > >1.6.1 with 1.8a09, 1.8a14, 1.8a15....)
> > >---------------------------------------------------------------------
> > >Cdrecord release 1.6.1 Copyright (C) 1995-1998 J=F6rg Schilling
> > >scsibus0:
> > > 0) 'SEAGATE ' 'ST52160N ' '0285' Disk
> > > 1) 'IBM ' 'DCAS-34330 ' 'S65A' Disk
> > > 2) 'QUANTUM ' 'MAVERICK 540S ' '0901' Disk
> > > 3) 'PLEXTOR ' 'CD-ROM PX-12TS ' '1.02' Removable CD-ROM
> > > 4) 'TEAC ' 'CD-ROM CD-56S ' '1.0D' Removable CD-ROM
> > > 5) 'TEAC ' 'CD-R55S ' '1.0F' Removable CD-ROM
> > > 6) *
> > > 7) *
> > >---------------------------------------------------------------------
> >
> >
> > >the following strace-output shows my error-msg from "cdrecord =
> > >-scanbus":
> > >---------------------------------------------------------------------
> > >...
> > >open("/dev/sg4", O_RDWR) =3D 6
> > >...
> > >open("/dev/sg4", O_RDWR) =3D 7
> > >....
> > >open("/dev/sg5", O_RDWR) =3D 8
> > >...
> > >open("/dev/sg6", O_RDWR) =3D -1 ENXIO (No such device or
> > >address)
> > >...
> > >write(6, "*\0\0\0$\0\0\0\16\0\0\0\0\0\0\0\0"..., 42) =3D 42
> > >...
> > >write(7, "*\0\0\0$\0\0\0\24\0\0\0\0\0\0\0\0"..., 42) =3D -1 ENOMEM (Out =
> > >of
> > >memory)
^^^^^^^
There she blows ....
> > >...
> > >write(2, "cdrecord: Cannot allocate memory"..., 65cdrecord: Cannot =
> > >allocate
> > >memory. Cannot send SCSI cmd via ioctl
> > >) =3D 65
> > >...
> > >_exit(12) =3D ?
> > >---------------------------------------------------------------------
> >
> >
> > >the syslog would show up=20
> > >---------------------------------------------------------------------
> > >Jan 18 23:26:50 murks kernel: Couldn't get a free page.....=20
> > >---------------------------------------------------------------------
> >
> > >so I looked into sg.c and the sg-patch from Heiko Eissfeldt and found, =
> > >that
> > >on my machine after some work the allocation of subsequent 32K-blocks =
> > >with
> > >kmalloc() does fail after the first 4 scsi-devices. Cdrecord scans =
> > >through
> > >the scsi-devices and opens every one of them, not closing them until =
> > >the end
> > >of the scan.=20
> >
> >
> > It seems that the patch is not yet 100% OK. It may be better to allocate
> > a new big buffer for the sg driver if there is really the need for it.
> > This would usually allow to allocate only one buffer as there is
> > no other program running cuncurrent to cdrecord.
> >
> > J�rg
As stated above Joerg, the solution is in your hands, with some help
from the sg driver.
For those who have read this far, I have written my own version
of the sg driver. It can be found at:
http://www.netwinder.org/~dougg
It adds scatter-gather (forget SG_BIG_BUFF), per file descriptor
sequencing (was per device), uses above 16MB if non-ISA adapter,
command queuing and async notification but requires 2.1.118 or later
(works fine with 2.2.1). It is also backward compatible with the
original sg driver.
------------------------------------------------------------------
Douglas Gilbert [[EMAIL PROTECTED] or [EMAIL PROTECTED]]
48 Windsor Court Road Web: www.interlog.com/~dgilbert
Thornhill, Ontario L3T 4Y5, Canada Tel: +1 905 771 6151
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
