Linux-Development-Sys Digest #710, Volume #6 Fri, 14 May 99 02:14:25 EDT
Contents:
Re: Hostile Takeover of Linux (Frank v Waveren)
ifconfig and 10/100 speed/duplex (bryan)
Re: I want to learn to make drivers (Len Huppe)
Segfaults on Server after long uptime using 2.2.x (Tom Kyle)
A most peculiar bug! (Frampton Steve R)
ANN: x86emu project mailing list! (Kendall Bennett)
2.2.8 - Evil behavior (Kevin Turnquist)
Re: FireWire IEEE 1394b drivers? (Daniel Robert Franklin)
Re: Translation of linux to minor languages (Johan Kullstam)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: Hostile Takeover of Linux
Date: Fri, 14 May 1999 02:13:41 GMT
What, and have people think he _can_ use his mind?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alastair) writes:
> dan <[EMAIL PROTECTED]> wrote:
>>
>> snip ...
>
> Maybe if you started making sense ...
>
>
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: ifconfig and 10/100 speed/duplex
Crossposted-To: comp.os.linux.networking
Date: Fri, 14 May 1999 03:35:49 GMT
I've noticed that you can't manipulate the speed or duplex of ethernet
cards via ifconfig. in fact, I'm not aware of any card-independant
way to force-set the speed/duplex of ether cards under linux.
am I missing something? how are folks setting their cards today? I
know from personal experience that just letting it auto-sense isn't
always the most optimal solution.
--
Bryan
------------------------------
From: Len Huppe <[EMAIL PROTECTED]>
Subject: Re: I want to learn to make drivers
Date: Thu, 13 May 1999 23:14:04 -0500
There is a book called Linux Device Drivers on the market. One possible
project for you is to develop a device driver for DVD drives. I have
been seeing questions about how to get DVD drives working under Linux.
DVD seems to be what the industry is moving towards.
good luck
Enrique Cespedes wrote:
> Hi, I'd like to learn how to make drivers. Here can I found
> documentation. There is a site at the wed ? Or a good book ?
>
> Thanks
> Enrique Cespedes Sanchez.
------------------------------
From: Tom Kyle <[EMAIL PROTECTED]>
Subject: Segfaults on Server after long uptime using 2.2.x
Date: Wed, 12 May 1999 16:39:57 -0500
I have a dual P2 server that is experiencing segfaults if I try to use
fdisk or lilo after the server has been up for long periods of time.
Everything else seems to work fine, but then again this machine doesn't
see much action since it's just a test server for our department to see
how well Linux runs.
Anyway, the errors I receive are something like this:
May 11 14:36:18 empire kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000024
May 11 14:36:18 empire kernel: current->tss.cr3 = 0e50c000, `r3 =
0e50c000
May 11 14:36:18 empire kernel: *pde = 00000000
May 11 14:36:18 empire kernel: Oops: 0000
May 11 14:36:18 empire kernel: CPU: 0
May 11 14:36:18 empire kernel: EIP: 0010:[<c01380d6>]
May 11 14:36:18 empire kernel: EFLAGS: 00010286
May 11 14:36:18 empire kernel: eax: 00000004 ebx: cfa8ab60 ecx:
00000000 edx: 00000000
May 11 14:36:18 empire kernel: esi: cfa8ab00 edi: 0000ffff ebp:
00000000 esp: cd3d3f6c
May 11 14:36:18 empire kernel: ds: 0018 es: 0018 ss: 0018
May 11 14:36:18 empire kernel: Process fdisk (pid: 32599, process nr:
55, stackpage=cd3d3000)
May 11 14:36:18 empire kernel: Stack: 0000ffff 00000000 c01280ce
00000001 c0138366 cfa8ab60 00000000 00000000
May 11 14:36:18 empire kernel: 00000000 00000000 c01281e2
00000000 ffffffff 00000000 00000000 00000000
May 11 14:36:18 empire kernel: 00000000 cd3d2000 c0128213
00000000 cd3d2000 c0108c00 00000004 0000002c
May 11 14:36:18 empire kernel: Call Trace: [<c01280ce>] [<c0138366>]
[<c01281e2>] [<c0128213>] [<c0108c00>]
May 11 14:36:18 empire kernel: Code: 8b 74 91 24 f6 43 2c 01 74 09 53 e8
02 ff ff ff 83 c4 04 80
I've gotten these errors since 2.2.5, and I've since recompiled from a
fresh tar file, just in case a file or two got corrupted. Since the
problems seem to be related to SCSI disk access, here's a little info
about the SCSI setup on the system from dmesg:
(scsi0) <Adaptec AIC-7890/1 Ultra2 SCSI host adapter> found at PCI 6/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 407 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.10/3.2.4
<Adaptec AIC-7890/1 Ultra2 SCSI host adapter>
scsi : 1 host.
Vendor: TOSHIBA Model: CD-ROM XM-6401TA Rev: 1009
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
(scsi0:0:4:0) Synchronous at 20.0 Mbyte/sec, offset 16.
Vendor: HP Model: C1537A Rev: L706
Type: Sequential-Access ANSI SCSI revision: 02
Detected scsi tape st0 at scsi0, channel 0, id 5, lun 0
(scsi0:0:5:0) Synchronous at 10.0 Mbyte/sec, offset 32.
Vendor: QUANTUM Model: VIKING II 9.1WLS Rev: 5520
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 6, lun 0
(scsi0:0:6:0) Synchronous at 80.0 Mbyte/sec, offset 31.
Vendor: QUANTUM Model: VIKING II 9.1WLS Rev: 5520
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0
(scsi0:0:10:0) Synchronous at 80.0 Mbyte/sec, offset 31.
scsi : detected 1 SCSI tape 1 SCSI cdrom 2 SCSI disks total.
Uniform CDROM driver Revision: 2.54
SCSI device sda: hdwr sector= 512 bytes. Sectors= 17836668 [8709 MB]
[8.7 GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17836668 [8709 MB]
[8.7 GB]
I'm using the AIC/7xxx driver compiled into the kernel. The chipset
itself is onboard an Asus P2B-DS motherboard.
I'd be *very* interested in hearing from anyone who's run into the same
problems and/or understands these register/stack dumps...
Thanks,
Tom Kyle
Jr Unix Admin
Univ. of Missouri-St. Louis
[EMAIL PROTECTED]
------------------------------
From: Frampton Steve R <[EMAIL PROTECTED]>
Subject: A most peculiar bug!
Date: 14 May 1999 02:05:12 GMT
Hello:
I have a Red Hat 5.2-based server running kernel 2.2.4 (custom kernel
built from the kernel-source-2.2.4-4.i386.rpm file) on a P300 with an
Adaptec AHA-131 SCSI controller, (using the aic7xxx driver that came
with the 2.2.4 kernel package), driving four 9 Gb SCSI drives.
Because this server is in a remote location, I usually do remote
backups with tar to another disk partition, and then every so often
move these to tape. The backup command I am using is:
tar zcvpf /archive/backup-13-may-1999.tar.gz --exclude=archive
--exclude=mnt --exclude=proc --exclude=var/spool/squid .
This, in the past, has worked very well. However, the last couple
of times I have done this, the tar process itself has hung while
creating the archive. Even more strange, it is *impossible* to
terminate the tar process, whether by <ctrl><c>, kill, or even
with kill -9. Because I use "screen", I have to actually kill the
screen processes and then use "screen -wipe" to clear out the sessions
(note that this does *not* terminate the tar processes).
A process list shows both tar processes, as well as a zombie gzip
process (the first time, I tried it with the "z" (compress) parameter
to tar, while the second time, I tried it without compression). While
it looks like tar is still consuming some CPU time, the number gradually
shrinks to 0 (the first time, gzip was consuming massive amounts of CPU
time and took days to shrink to 0.00).
root 24956 0.0 0.2 1048 664 ? D Apr 29 0:32 tar zcvpf /archive/bac
root 30006 3.7 0.2 1048 660 a1 D 21:41 0:43 tar cvpf /archive/back
root 24957 0.0 0.0 0 0 ? Z Apr 29 13:32 (gzip <zombie>)
What is very strange is that tar hangs at the very same location
this time as it did last time!!! Here is a list of the last few
files that it managed to add to the archive before hanging:
usr/src/linux-2.2.4/Documentation/video4linux/radiotrack.txt
usr/src/linux-2.2.4/Documentation/watchdog.txt
usr/src/linux-2.2.4/Documentation/xterm-linux.xpm
usr/src/linux-2.2.4/MAINTAINERS
usr/src/linux-2.2.4/Makefile
usr/src/linux-2.2.4/README
usr/src/linux-2.2.4/Rules.make
usr/src/linux-2.2.4/arch/
usr/src/linux-2.2.4/arch/i386/
usr/src/linux-2.2.4/arch/i386/Makefile
usr/src/linux-2.2.4/arch/i386/boot/
usr/src/linux-2.2.4/arch/i386/boot/Makefile
usr/src/linux-2.2.4/arch/i386/boot/bootsect.S
usr/src/linux-2.2.4/arch/i386/boot/compressed/
usr/src/linux-2.2.4/arch/i386/boot/compressed/Makefile
usr/src/linux-2.2.4/arch/i386/boot/compressed/head.S
usr/src/linux-2.2.4/arch/i386/boot/compressed/misc.c
usr/src/linux-2.2.4/arch/i386/boot/compressed/piggy.o
I have never seen this behavior prior to kernel version 2.2.4 so I
am wondering if something may have changed in the aic7xxx driver (I
was using kernel version 2.0.36 before) that would cause this bug, or
else something about the kernel itself is causing this hang.
Obviously, I'm going to have to reboot to get rid of these processes
as they absolutely refuse to be killed! This is strange and bothersome
enough that I thought I'd mention it here.
Thanks...
==============< LINUX: The choice of a GNU generation. >==============
Steve Frampton <[EMAIL PROTECTED]> http://qlink.queensu.ca/~3srf
------------------------------
From: [EMAIL PROTECTED] (Kendall Bennett)
Subject: ANN: x86emu project mailing list!
Date: 11 May 1999 11:44:44 -0800
Date: Tue, 11 May 1999 11:39:57 -0500
Message-ID: <[EMAIL PROTECTED]>
Organization: SciTech Software, Inc.
X-Newsreader: MicroPlanet Gravity v2.11
Hi All,
What is x86emu?
===============
The x86emu project is an emulator for executing x86 real mode code on
any CPU platform, including the x86 CPU family. The emulator started
out as the free equivalent to the Digital Equipment x86 emulator in
the Linux MILO loader. Since then the emulator has been updated to
include support for 32-bit real mode instructions, and optimised for
better performance, and should be able to completely replace the
Digitial Equipment proprietry emulator in MILO.
This emulator has lots of different of uses on Linux and other
platforms. Some of those include:
. Ability to POST multi-head graphics controller configurations on
x86 using the existing adapter BIOS.
. Ability to POST the primary controller on non-x86 platforms to
bring it up into text mode for Linux.
. Ability to provide the Linux VBE framebuffer console driver with
the capabilities to call the BIOS on any number of controllers at
runtime. This will allow it to switch graphics modes on the fly,
program the hardware palette etc. On VBE/Core 3.0 adapters, this
also includes full refresh rate control out of the box!
The current maintainer of the x86emu project is Kendall Bennett
([EMAIL PROTECTED]). The emulator is licensed under the GNU
General Public License (GPL), with the library exception clause
included (ie: you can link the library with non-GPL'ed code).
How to subscribe?
=================
The x86emu mailing list is now active, and you can subscribe to the
mailing list by sending email to <[EMAIL PROTECTED]> with
subscribe [EMAIL PROTECTED]
in the subject. Of course replace [EMAIL PROTECTED] with your own
email address!
Regards,
--
+----------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+----------------------------------------------------------------------+
| Kendall Bennett | To reply via email, remove nospam from |
| Director of Engineering | the reply to email address. Do NOT send |
| SciTech Software, Inc. | unsolicited commercial email! |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+----------------------------------------------------------------------+
------------------------------
From: Kevin Turnquist <[EMAIL PROTECTED]>
Subject: 2.2.8 - Evil behavior
Date: 14 May 1999 05:20:02 GMT
I upgraded from 2.2.7 to 2.2.8, and removed the reference to update in
the rc.S file as directed from a couple sources.
Within 12 hours, all the servers that received this OS were dead from
"Divide Error (addresses) - Kernel Panic"
One machine I can see, but this hit 6 computers. Fortunately, I just
booted back into 2.2.7.
Has anyone else seen this behavior? I've never had this problem until
2.2.8, and I compiled it exactly as I did 2.2.7 and previous.
--
Kevin Turnquist
------------------------------
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Subject: Re: FireWire IEEE 1394b drivers?
Date: 14 May 99 05:08:16 GMT
[EMAIL PROTECTED] (Christopher Browne) writes:
>On Thu, 13 May 1999 20:56:21 +0000, Soeren Juelsgaard <[EMAIL PROTECTED]>
>wrote:
>>I have been looking for a firewire driver, but couldn't find any,
>>and before I run off and write one myself, I would like to know if
>>anyone is already working on a firewire driver, and if I can be of
>>any help?
>Sounds like something that will be of interest, in much the manner
>that USB hardware is now widely enough deployed that *that* has become
>of great interest...
Yes, there are a lot of high-end video cameras which now support FireWire,
and supposedly there are some fast HDDs which now use it too... I wish I
could afford some of this stuff :-)
>I'd not be shocked to hear that someone has already started work on a
>kernel driver; I'm sure that assistance in testing, debugging, and
>even specifying would be welcome.
Such a project already exists. Check out
http://eclipt.uni-klu.ac.at/ieee1394
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: Translation of linux to minor languages
Date: 13 May 1999 11:11:03 -0400
"Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]> writes:
> >>>>> "Johan" == Johan Kullstam <[EMAIL PROTECTED]> writes:
> > yes. except that the #! mechanism isn't very good.
> > 1) what if your interpreter doesn't use # as a comment marker?
>
> Many interpreters that suffer from this problem have an exception for
> the first line for this very purpose.
> Of course, on Linux you can also use binfmt_misc to work around that problem
> by using some other magic cookie.
>
> > 2) what if two applications want first line specials? how can you
> > have both #!/bin/sh and -*- sh -*- on the same first line?
>
> You put the -*- sh -*- on the second line (as Emacs does) ?
> Or you add a parameter to /bin/sh since the kernel ignores anything
> past the first parameter.
>
> Now, don't get me wrong: #! is far from perfect, but it's a really
> cheap hack that covers 95% of what you need and the remaining 5%
> can usually/always be recovered without too much trouble.
this is a problem. 95% solutions stacked upon other 95% solutions.
after a while 0.95 * 0.95 * 0.95 ... becomes an unacceptibly small
number.
> > 3) there's more than just this i'd like to affix to the file without
> > it being of the file. documentation strings, prefered editor,
> > where you were when you save in that editor &c.
>
> Be extra careful here:
> 1 - what do you mean exactly by "documentation string" ?
something like a sentence or paragraph of commentary. you do not
always want huge file names. it'd be especially useful for annotating
binary data files. one could even go so far as to put man pages in
the meta data. it has a rather tenous linkage to the executable now.
granted, some man pages cover multiple files and some man pages cover
non file items. but for a lot of executables, i'd be nice if there
were some compact synopsis of their usage bundled right there with the
binary itself.
> 2 - preferred editor is not really a per-file info but a per-type-of-file
> and per-user info. This requires a type-info attached to the file
> (available in Unix in a very ad-hoc manner via file(1) using magic
> cookies, or via /etc/mime.types using filename extensions).
> 3 - "where you were when you saved in that editor" is a per-file and per-user
> info. The usefulness of such info looks rather dubious to me.
> So 2&3 belong at least as much to the user as to the file.
> Attaching such meta-data to the file is stupid.
agreed. i was wrong in thinking this would work over multiple users.
> To solve this right,
> it seems that you'd need a fancier mechanism that allows to attach info
> between several objects. Like a relational database, for example.
>
> > i think having an out-of-band signaling mechanism would be
> > beneficial. for example in serial lines, hardware flow control is
> > much better than ^S/^Q (xon/xoff) signaling.
>
> Indeed, a RDB would be quite out-of-band.
>
> > i think filenames stored in a directory would do better in UTF-16.
> > filenames do not themselves take that much space. and operations such
> > as shell globing would be quicker without any translation from UTF-8
> > directory string to UTF-16 for regexp handling.
>
> Regexp matching can be done on UTF-8 just fine (no conversion
> needed).
you *do* need conversion. what does "." mean for a multi-byte char?
> Better yet: regexp code need usually zero changes to work on UTF-8.
> Regexp engines often use tables indexed by chars. To deal with 16bit
> chars, they often switch to a two-step (twice 8-bit) lookup.
> > the files could be in either UTF-8 or UTF-16 depending on what was
> > appropriate (speed vs space should be a userland tradeoff). that is
> > where some kind of header to mark the contents would be useful.
>
> This discussion is moot anyway: Linux's filenames are already
> UTF-8.
yes.
however, the file themselves could still be in one of several formats
- us-ascii, iso8859-x, koi-8r, utf-8, utf-16 &c. one would choose
whatever is appropriate. it'd be nice if there was a decent way to
keep track of the particular encoding used by the file instead of
resorting to guessing every time you open.
the text processing programs would use an internal superset of all the
formats and translation would be done at a read/write time.
then there's the old lf vs cr/lf issue. i prefer the unix solution,
but this keeps causing headaches when used with other systems. this
could be rolled into the encoding stuff.
> > i think you are dead wrong in this assessment. moving to UTF-16 would
> > basically entail doing a global search and replace from `char' to
> > `short' on all your string oriented functions. internal processing of
> > UTF-8 would involve all sorts of stunts to keep track of how many
> > bytes you have for each char.
>
> Don't forget that in UTF-16 chars are not necessarily 16bits (most are,
> but not all).
ack. that makes it less attractive.
--
johan kullstam
------------------------------
** 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
******************************
