Linux-Development-Sys Digest #49, Volume #7 Fri, 13 Aug 99 01:14:32 EDT
Contents:
DRIVER for Toshiba DVD-RAM (for kernel 2.2.11) ([EMAIL PROTECTED])
Re: Group ID maximum (Stephen Satchell)
Stupid question re: sound config (root)
Re: Linux hangs at reboot after recompiling kernel 2.2.10 (Edwin Lim)
Re: Looking for a good utility... (Matthias Kilian)
Re: Compile problem with kernel 2.2.11 (Greg White)
Re: Caldera kernel really 2.2.5?? (Greg White)
Kernel upgrades... why? ("bobrien")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: DRIVER for Toshiba DVD-RAM (for kernel 2.2.11)
Date: 13 Aug 1999 02:08:23 GMT
If you happened to read a message I just posted here about a
driver for the Toshiba DVD-RAM, you'd know that that driver is only
for kernel 2.0.36. I decided to go ahead and make a patch for
kernel 2.2.11 since most people who have a Toshiba DVD-RAM probably
also have a kernel in the 2.2.x series by now. Unfortunately, this
patch HAS NOT BEEN VERIFIED because we don't have 2.2.11 installed
here. BUT, the patch is very small and, in fact, the patch is the
same* between 2.0.36 and 2.2.11 except for line locations. Therefore,
I see no reason why it shouldn't work.
So, this is a patch for the Toshiba SD-W1101/SD-W1111 DVD-RAM drive
against Linux kernel 2.2.11. (SD-W1111 support is now included;
although I don't have the SD-W1111 drive to verify this.) It consists of
three files. File #1 is a set of instructions on how to install the patch
and get things up and running. In theory, if you type the non-comment
lines in this file, things should work. (In theory.) File #2 is the
first of two patch files, "sd.c.patch-2.2.11-toshiba". It patches sd.c to
drive the Toshiba with 10-byte, rather than 6-byte, SCSI commands. File
#3 is the second patch file, "scsi.c.patch-2.2.11-toshiba". It is hacked
from a similar file residing at
http://www.jaist.ac.jp/~sight95/linux/dvd-ram/dvd-ram-english.html,
which happens to be a patch for the Panasonic DVD-RAM. Basically all it
is is the original patch with strings referring to "Panasonic", etc.,
replaced with "Toshiba", etc.
This has ***ONLY*** been verified to work with the Tekram DC-390 SCSI
controller card (+ Linux kernel 2.0.36). Certain other SCSI controller
cards may need patching (basically, any card whose driver contains
the words "WRITE_10", "WRITE_6", "READ_6", or "READ_10" is suspect.
You can easily look to see if this applies to your card by doing a grep
for these phrases in the drivers/scsi directory of your Linux source
directory).
Would anyone be kind enough to tell me who I should submit this patch
to, to get it incorporated into the standard Linux kernel distributions?
Please e-mail: [EMAIL PROTECTED] Thanks in advance!
Good luck!!
---Reed Meyer
[EMAIL PROTECTED]
*Aside from lines patching the kernel for 2048-blocksize filesystem
support; the 2.0.36 kernel needed the lines, but the 2.2.x kernels already
seem to have the 2048-byte support. Also, support for the SD-W1111
is (theoretically) included this time (before, just the Toshiba SD-W1101).
=============================================================================
File #1: Instructions for patching kernel 2.2.11 for Toshiba DVD-RAM.
=============================================================================
# Patch instructions for Toshiba DVD-RAM / Linux kernel 2.2.11.
# Reed D. Meyer, [EMAIL PROTECTED], 8/12/99. Hacked from
# instructions by [EMAIL PROTECTED] (found at:
# www.jaist.ac.jp/~sight95/linux/dvd-ram/dvd-ram-english.html)
#
# *NOT* tested on kernel 2.2.11. Hacked from a patch for 2.0.36.
# Patch was confirmed *ONLY* for the Tekram DC-390 SCSI controller card!
# Some other I/Fs may not work successfully, and then you need to make some
# changes in the correspond driver to your I/F of the kernel source.
su
cd /usr/src/linux/drivers/scsi
patch -p0 < $DVDRAM/sd.c.patch-2.2.11-toshiba
patch -p0 < $DVDRAM/scsi.c.patch-2.2.11-toshiba
cd /usr/src/linux
make menuconfig
# Check "Support SCSI" to Y or M.
make dep; make clean; make bzImage; make modules; make modules_install
# Do the following only if you're sure you want to copy the new
# vmlinuz + modules to the standard area.
mv System.map /boot
mv arch/i386/boot/bzImage /boot/vmlinuz
# Regenerate the master boot record (re-run the LILO configuration)
# (Make sure to edit /etc/lilo.conf as necessary!)
/sbin/lilo
# Reboot your Linux system.
# Make a partition using "fdisk".
# Make sure that the head sector number of each partition is a multiple of 4
# if there's more than one partition (the logical sector size is 512 bytes but
# the physical block size is 2048 so there'd be problems otherwise).
fdisk /dev/sda
n (make new partition)
p (primary)
1 (select 1 at primary)
1 (start cylinder)
303 (last cylinder: if only make 1 partition.)
w (write & quit)
# Then, format. Note the -b 2048 option to mke2fs! Also, note that
# we use /dev/sda, *NOT* /dev/sda1!
# (If making an MSDOS partition is desired, you might want to try
# passing the option "-s 32" to mkdosfs.)
mke2fs -c -b 2048 /dev/sda
# Make a mount point.
mkdir /dvdram
# Now, you test mount.
mount /dev/sda /dvdram
# (After the test you may modify /etc/fstab. General user can mount using
# the command "mount /dvdram".)
vi /etc/fstab
# Add line:
/dev/sda /dvdram ext2 user,noauto,rw,suid,exec 0 0
=============================================================================
File #2: sd.c.patch-2.2.11-toshiba
=============================================================================
--- sd.c.original Mon Aug 9 15:05:05 1999
+++ sd.c Thu Aug 12 20:12:37 1999
@@ -17,6 +17,15 @@
*
* Modified by Jirka Hanika [EMAIL PROTECTED] to support more
* scsi disks using eight major numbers.
+ *
+ * Modified by Reed Meyer <[EMAIL PROTECTED]> to support the Toshiba
+ * SD-W1101 DVD-RAM (which doesn't like 6-byte commands). Changed the
+ * default I/O to 10-byte commands, with the minor side-effect that
+ * the driver doesn't use the slightly-faster(?) 6-byte commands
+ * when circumstances allow. I did this so I wouldn't have to write
+ * code specific to the Toshiba DVD-RAM. If you don't like this
+ * approach, flame me. I have no idea whether it makes a substantial
+ * speed improvement by sticking to 6-byte commands.
*/
#include <linux/module.h>
@@ -734,10 +743,10 @@
SCpnt = end_scsi_request(SCpnt, 0, SCpnt->request.nr_sectors);
goto repeat;
}
- cmd[0] = WRITE_6;
+ cmd[0] = WRITE_10;
break;
case READ :
- cmd[0] = READ_6;
+ cmd[0] = READ_10;
break;
default :
panic ("Unknown sd command %d\n", SCpnt->request.cmd);
@@ -1016,12 +1025,11 @@
this_count = this_count << 1;
}
- if (((this_count > 0xff) || (block > 0x1fffff)) && rscsi_disks[dev].ten)
+ if (rscsi_disks[dev].ten) /* Can handle ten-byte commands */
{
if (this_count > 0xffff)
this_count = 0xffff;
- cmd[0] += READ_10 - READ_6 ;
cmd[2] = (unsigned char) (block >> 24) & 0xff;
cmd[3] = (unsigned char) (block >> 16) & 0xff;
cmd[4] = (unsigned char) (block >> 8) & 0xff;
@@ -1030,11 +1038,12 @@
cmd[7] = (unsigned char) (this_count >> 8) & 0xff;
cmd[8] = (unsigned char) this_count & 0xff;
}
- else
+ else /* Can't handle ten-byte commands */
{
if (this_count > 0xff)
this_count = 0xff;
+ cmd[0] -= READ_10 - READ_6 ;
cmd[1] |= (unsigned char) ((block >> 16) & 0x1f);
cmd[2] = (unsigned char) ((block >> 8) & 0xff);
cmd[3] = (unsigned char) block & 0xff;
=============================================================================
File #3: scsi.c.patch-2.2.11-toshiba
=============================================================================
--- scsi.c.original Mon Aug 9 15:04:40 1999
+++ scsi.c Thu Aug 12 20:31:58 1999
@@ -654,6 +654,8 @@
struct Scsi_Device_Template *sdtpnt;
Scsi_Device * SDtail, *SDpnt=*SDpnt2;
int bflags, type=-1;
+ static int TOSH_DVD_RAM[2] = {-1,-1};
+ int org_lun = lun;
SDpnt->host = shpnt;
SDpnt->id = dev;
@@ -661,6 +663,16 @@
SDpnt->channel = channel;
SDpnt->online = TRUE;
+ /* Toshiba SD-W1101/SD-W1111 DVD-RAM adapted from the Panasonic model */
+ if (TOSH_DVD_RAM[0] == channel && TOSH_DVD_RAM[1] == dev && lun == 1) {
+ /* get CD-ROM type */
+ SDpnt->lun = lun = 0;
+ } else {
+ /* clear status */
+ TOSH_DVD_RAM[0] = -1;
+ TOSH_DVD_RAM[1] = -1;
+ }
+
/* Some low level driver could use device->type (DB) */
SDpnt->type = -1;
@@ -773,6 +785,22 @@
scsi_result[1] |= 0x80; /* removable */
}
+ if (!strncmp (scsi_result + 8, "TOSHIBA", 7) &&
+ (!strncmp (scsi_result + 16, "SD-W1101", 8) ||
+ !strncmp (scsi_result + 16, "SD-W1111", 8)) &&
+ scsi_result[0] == TYPE_ROM) {
+ if (TOSH_DVD_RAM[0] == channel && TOSH_DVD_RAM[1] == dev && org_lun == 1) {
+ /* Toshiba SD-W1101/SD-W1111 DVD-RAM treats as ROM */
+ lun = 1;
+ } else {
+ /* Toshiba SD-W1101/SD-W1111 DVD-RAM treats as MOD */
+ scsi_result[0] = TYPE_MOD;
+ scsi_result[1] |= 0x80; /* removable */
+ TOSH_DVD_RAM[0] = channel;
+ TOSH_DVD_RAM[1] = dev;
+ }
+ }
+
memcpy (SDpnt->vendor, scsi_result + 8, 8);
memcpy (SDpnt->model, scsi_result + 16, 16);
memcpy (SDpnt->rev, scsi_result + 32, 4);
@@ -969,6 +997,12 @@
*/
if (bflags & BLIST_MAX5LUN) {
*max_dev_lun = 5;
+ return 1;
+ }
+
+ /* Toshiba SD-W1101/SD-W1111 DVD-RAM */
+ if (TOSH_DVD_RAM[0] == channel && TOSH_DVD_RAM[1] == dev && org_lun == 1) {
+ *max_dev_lun = 2;
return 1;
}
=============================================================================
END OF FILES
=============================================================================
------------------------------
Subject: Re: Group ID maximum
From: [EMAIL PROTECTED] (Stephen Satchell)
Date: Fri, 13 Aug 1999 02:18:36 GMT
>On Wed, 11 Aug 1999 01:47:27 +0200, Ralph Geissler <[EMAIL PROTECTED]>
>wrote:
>
>>I have a user account on a Linux box (Intel) that has to be able to
>>read a hundert user's directories without the users reading the
>>directories of other users. I don't want my user account to be root.
I've been thinking about this requirement for quite some time, and there
are other ways to do the same thing. Here are a couple:
1) If the file base is small, you can write a setuid script that will
mirror the filesets of your hundred users into a tree belonging to your
supervising user. That script would need to: (a) copy the file, (b)
change the owner of the copies to the owner, and (c) log the event for
your review. To do this quickly and easily, consider using "tar" or
"cpio" to perform the collection and tree creation. This means that your
supervising user doesn't have to be running as root, and you can put all
sorts of authentication into the script. Watch out for how you handle
signals so you don't provide a means of gaining root access.
2) Set up the script described above as the "shell" for a login session.
Then you use the authentication system to control the execution of the
script. Program signal control appropriately!
3) Set up the script described above as a regularly run cron job.
4) If the file set is large, you can develop supervisory scripts to
perform common tasks such as listing directories and copying files on
demand. Watch out for how you handle signals so you don't provide a
means of gaining root access.
Just remember that your hundred users can use "chmod" to make any file
visible to others, simply by setting the world-readable bit...
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Stupid question re: sound config
Date: Fri, 13 Aug 1999 02:28:33 GMT
I'm a newbie, so to speak. Any help would be appreciated -- I can't
seem to get my sound card to work. It's a trident 4d PCI card. No
ideas. I tried Lothar - no help. Please help me, oh, the ignorant
one....
------------------------------
From: [EMAIL PROTECTED] (Edwin Lim)
Subject: Re: Linux hangs at reboot after recompiling kernel 2.2.10
Date: Fri, 13 Aug 1999 02:54:00 GMT
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On Tue, 10 Aug 1999 14:51:44 -0400, Guilhem Tardy <[EMAIL PROTECTED]> wrote:
>>Now I can boot (I previously forgot to update the bootsect.lnx in the
>>WinNT partition, which worked fine until some boot file moved within the
>>ext2 partition), BUT it hangs with the root fs:
>>NTFS version 990411
>>request_module[block-major-8]: Root fs is not mounted
>>VFS: Cannot open root device 08:07
>>Kernel panic: VFS: Unable to mount root fs on 08:07
>>
>>It is kernel 2.2.11 on a SCSI drive, I moved the SCSI drivers (AHA-7xxx)
>>to modules and created an initrd image, as described in the RH 6.0
We have lots of NT/Linux dual boot boxes here where I work (as a sys
admin). I always like to use LILO to boot NT and linux (although
almost every other admins here use the bootsect.lnx approach). That
way I never have to deal with the NT bootsect.lnx stuff.
What I do is make the linux partition bootable (or the extended
partition--yes, it is possible), and put LILO there. NT doesn't use
the MBR, and will not overwrite it. To boot NT (boot loader) using
LILO, just make an entry in lilo.conf that points to the NT partition,
just like if you were using DOS or Win9x. NT's boot loader resides in
the NT boot partition (or so it seems).
>I don't know whether this is relevant, but the drivers required to mount your
>root filesystem cannot be modules. You can't load modules if you haven't
>mounted any filesystem.
This is not strictly true. The work around with LILO is the initrd stuff.
Here's how it works:
1) Compile a generic kernel with as little stuff as possible, don't need
the SCSI driver even if your root partition is on the SCSI card, BUT
you need to have support for RAM disk and INITRD.
2) Compile your SCSI as a module, and make the initrd image. The initrd
image is really a very small file system in a compressed file, which you
can mount as a loop-back device. Say your initrd image is initrd.img,
you can do this:
# gunzip -c initrd.img > /tmp/initrd.loop
# mount -o loop /tmp/initrd.loop /mnt
# cd /mnt ; ls -l
3) Then you have to tell LILO that you have the initrd.img to load after
loading linux. After LILO loads the kernel, it loads the initrd.img
into RAM, tells the kernel where the initrd.img is, then the kernel
will mount initrd.img as a RAM disk, and execute the file /linuxrc
in that RAM disk.
LILO can load your initrd.img because it uses BIOS calls (so the 1024
cylinder limit applies to the initrd.img as well), and linux can mount
it because it is in RAM and linux doesn't have to deal with the SCSI
(or any other) device.
This linuxrc can do whatever you want, normally it just insmod your
SCSI driver. Now linux has your SCSI driver.
4) When it exits, then linux proceeds with the normal bootup, with your
insmod-ed SCSI driver, and can mount your root partition.
That's roughly it. I am not sure about who uncompresses the initrd.img,
LILO or linux or what. Hey! Here's what I found in
/usr/src/linux/Documentation/initrd.txt:
1) the boot loader loads the kernel and the initial RAM disk
2) the kernel converts initrd into a "normal" RAM disk and
frees the memory used by initrd
3) initrd is mounted read-write as root
4) /linuxrc is executed (this can be any valid executable, including
shell scripts; it is run with uid 0 and can do basically everything
init can do)
5) when linuxrc terminates, the "real" root file system is mounted
6) if a directory /initrd exists, the initrd is moved there
otherwise, initrd is unmounted
7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
on the root file system
>If your root partition is on a SCSI drive, the SCSI driver has to be statically
>compiled into the kernel. Ditto for the filesystem module that is used over the
>root partition (most likely ext2, which is rarely made as a module).
So with the help of LILO and initrd, it is not true that you have to
have your SCSI driver statically compiled into the kernel. This makes
it much easier for install process. Otherwise part of the install
process will be recompiling the kernel, or have a slew of kernels with
combinations of drivers, both having huge draw backs. Besides, I
doubt it very much we can compile everything into a single kernel
nowadays without making it 7.5MB and cause LILO to bitch... 8^)
Cheers,
e.
------------------------------
From: [EMAIL PROTECTED] (Matthias Kilian)
Subject: Re: Looking for a good utility...
Date: 12 Aug 1999 18:04:07 GMT
> >So he is saying, in obfuscated English, that he wants to look into
> >the deap dark depths of the code.
> When you've got all the source code, how much deeper can you
> expect to get.
You could throw away the sources and uncompress and disassemble /boot/zImage.
Kili
------------------------------
From: Greg White <[EMAIL PROTECTED]>
Subject: Re: Compile problem with kernel 2.2.11
Date: Fri, 13 Aug 1999 03:22:00 GMT
Erik de Castro Lopo wrote:
>
> Robert Krawitz wrote:
> <snip>
>
> > One of the early menu items is to choose your maximum memory size.
> > It's not set to anything by default; you have to pick something (1 GB
> > is the most common).
>
> Thanks, thats fixed it.
>
> It was my fault for just copying the .config files from the directory
> of 2.2.10 before compiling. The maximum memroy size option must be a new
> one.
>
> Erik
> --
> +-------------------------------------------------+
> Erik de Castro Lopo [EMAIL PROTECTED]
> +-------------------------------------------------+
> Will the last person leaving Redmond please turn off all the lights.
Actually, for a new kernel, I always copy the old .config file, and then
run 'make oldconfig'. It prompts you for any options new to your new
kernel. Hoping this helps you with 2.2.12,
GW
------------------------------
From: Greg White <[EMAIL PROTECTED]>
Subject: Re: Caldera kernel really 2.2.5??
Date: Fri, 13 Aug 1999 03:25:53 GMT
Alexander Viro wrote:
>
> In article <[EMAIL PROTECTED]>,
> Michael Kahl <[EMAIL PROTECTED]> wrote:
> [snip Caldera kernel is seriously different from the main tree]
> >altogether and start clean with an officially released kernel? Will my
> >system even still work if I do that (Caldera may have modified other
> >components of the system to match their hacked-up kernel)?
>
> IIRC they did - they used to include streams support <barf> into their tree
> so probably they are using it somewhere.
>
> >Do these problems exist with other distros as well? What's a poor kernel
> >hacker to do?
>
> Decide on which tree you are going to work? Debian, RedHat, Slackware
> and SuSE userlands seem to be OK with the main tree. Let's see... Debian keeps
> the patches in a separate file, so it should be the easiest to check... Aha.
> Vanilla 2.2.10 + bigphysarea. So unless it has problems with the supplied
> kernel it can't have any with the standard one. Checking the rest is left
> as an exercise to reader. If Caldera ships seriously non-standard kernel
> the basic decency would require to put the information on (in)compatibility
> issues. Look around, maybe they have it somewhere...
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
Mister Volkerding never messes with the sources in the Slackware tree.
(Some people are bothered by this, and prefer the modified trees
provided by distros like RH and COL... not me).
------------------------------
From: "bobrien" <[EMAIL PROTECTED]>
Subject: Kernel upgrades... why?
Date: Fri, 13 Aug 1999 00:35:38 -0300
I can understand making the jump from 1.x or 2.1 or 2.2 but it is really a
necessity or even useful to upgrade each release... 2.2.5-15, 2.2.5-20,
2.2.10, 2.2.11 ... etc... I'm still quite new to this and curious why
everyone seems to jump right into each tiny upgrade. I can't see a reason
to upgrade until my soundcard has built in support in the kernel. Or I can
plug in a module for it.
just curious,
Blake
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
