Hi, 

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.

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?

Dschau.. Dominik


> -----Urspr�ngliche Nachricht-----
> Von:  Joerg Schilling [SMTP:[EMAIL PROTECTED]]
> Gesendet am:  Montag, 8. Februar 1999 18:06
> An:   [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc:   recipient list not shown; @other.debian.org@SCI-NETRA
> Betreff:      Re: AW: cdrecord problems on recent Linux versions
> 
> >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
> 
> >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)
> >...
> >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
> 
>  EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353
> Berlin
>        [EMAIL PROTECTED]             (uni)  If you don't have iso-8859-1
>        [EMAIL PROTECTED]         (work) chars I am J"org Schilling
>  URL:  http://www.fokus.gmd.de/usr/schilling
> ftp://ftp.fokus.gmd.de/pub/unix
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to