Linux-Development-Sys Digest #708, Volume #6 Thu, 13 May 99 18:14:37 EDT
Contents:
Re: what the ??!! happened to system headers in redhat 6?? (dave linenberg)
umount root file system ("new.ccu.edu.tw")
Compiling 0.01 kernel on DJGPP (Max Int)
Re: tcdrain(serial_fd) program (Etienne Lorrain)
Re: glibc-2.1 compiled broken (Andreas Jaeger)
Re: glibc-2.1 compiled broken (Xiphos Fuhr)
ISO9660 and kernel2.2.6+3com509B (Niclas Olsson)
Re: Who is keeping track of kernel patches (Michael Hirsch)
Re: Glibc rant ([EMAIL PROTECTED])
Re: How to make linux boot/shutdown rapidly (Michael Hirsch)
Re: umount root file system ("J�rgen Exner")
Re: Reading VideoCD? (Dr H. T. Leung)
Simple AVR (Atmel) programmer driver (Andrzej Radecki)
best distribution (octet)
Reading VideoCD? (Petter Reinholdtsen)
Re: Reading VideoCD? (Preston F. Crow)
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Insmod doesn't work (ellis)
Re: Glibc rant (Johan Kullstam)
----------------------------------------------------------------------------
From: dave linenberg <[EMAIL PROTECTED]>
Subject: Re: what the ??!! happened to system headers in redhat 6??
Date: Thu, 13 May 1999 04:34:05 GMT
problem solved...
OK, i found a glibc development rpm i had neglected to install, which then
filled in all the appropriate header files in /usr/include as expected.....
guess I've been conversing with myself... hope this helps anybody having the
same sort of problems...
dave
------------------------------
From: "new.ccu.edu.tw" <[EMAIL PROTECTED]>
Subject: umount root file system
Date: Thu, 13 May 1999 14:51:30 +0800
Hi,
I'm wondering when when umounting root file system of Linux,
it must be remount READO ONLY. Is there any security issue of
what ??
Thanks in advance !!
J.C. Chuang
------------------------------
From: Max Int <[EMAIL PROTECTED]>
Subject: Compiling 0.01 kernel on DJGPP
Date: Thu, 13 May 1999 18:39:11 +1000
Has anyone had any success compiling 0.01 kernel; or any other release,
using DJGPP (Windows version of gcc)?
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: tcdrain(serial_fd) program
Date: Thu, 13 May 1999 09:34:57 +0100
Reply-To: [EMAIL PROTECTED]
Kuang-chun Cheng wrote:
> That meant the tcdrain() doesn't work as I expected. Does anyone has
> similar experience or can tell me what's going on. Thanks.
Hi,
UARTs on PCs have a problem with tcdrain() : they do not say
(by setting a bit or generating an interrupt) that a char has been
completely sent; they just say that their serialisator is empty -
then there is still parity and stop bit to send... If all the 16550
were identical, Linux could have calculated when the char will
be finished - but it is not true.
You may even have this kind of UART which did not make any
difference between status bit "buffer empty" and "serialisator empty"
(the two bit are always read equal) - and that is on newer boards...
You may try your test on a real add on card with real NS16550A.
Etienne.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 compiled broken
Date: 13 May 1999 09:07:11 +0200
>>>>> Xiphos Fuhr writes:
Xiphos> Addendum: 2.1, not 2.1.1
Xiphos> woops :)
In that case reading the FAQ that comes with the prerelease of 2.1.1,
especially:
3.18. After upgrading to glibc 2.1, I receive errors about
unresolved symbols, like `_dl_initial_searchlist' and can not
execute any binaries. What went wrong?
Please note that 2.1.1 isn't released yet, you're using a prerelease
of it.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Xiphos Fuhr <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 compiled broken
Date: Thu, 13 May 1999 02:13:19 -0700
Andreas Jaeger wrote:
> >>>>> Xiphos Fuhr writes:
> Xiphos> Addendum: 2.1, not 2.1.1
> Xiphos> woops :)
> In that case reading the FAQ that comes with the prerelease of 2.1.1,
> especially:
> 3.18. After upgrading to glibc 2.1, I receive errors about
> unresolved symbols, like `_dl_initial_searchlist' and can not
> execute any binaries. What went wrong?
> Please note that 2.1.1 isn't released yet, you're using a prerelease
> of it.
Aha! That entry is not in my copy of the FAQ. To avoid any of that, I
shall opt for 2.0.whatever. Thankyou.
Now watch in amazement (or amusement) as I attempt to reverse the damage
without reinstalling from scratch!
--
xiphos <[EMAIL PROTECTED]>
------------------------------
From: Niclas Olsson <[EMAIL PROTECTED]>
Subject: ISO9660 and kernel2.2.6+3com509B
Date: Thu, 13 May 1999 16:24:38 +0200
Two questions:
===========
1) Problems with iso9660 filesystem under linux. I've burned a cd under
windows with Joliet (iso 9660) system.
The cd contains a html program with many links (on the cd). Under
windows everything works just fine. Under Linux (mount -t iso9660
/dev/cd /mnt/cd) when using the program most of the files on the cd
can't be found.
The problem is that short filenames is converted when mounting the cd to
UPPERCASE, and the html program
can't find them because of that. Read the man page for mount and read
about the Rock Ridge extension.
Does anyone know if the problem will disapper with the rock ridge
extenseion.
Willl I be able to use the cd under both windows and Linux with the rock
ridge extension??? Or, is there
a way to mount the cd (iso9660 without rock ridge ext.) with correct
filenames???
2) Problems with 3com509B when compiling the kernel 2.2.6 in RedHat 5.1.
The compiling works just fine and
I have included all that's needed for my networkcard 3com509B. After
rebooting the new kernel and looking
in /proc/interrupts etc, the networkcard is there. The strange thing is
that I can't even ping my own IPaddr...
I've met the same problem when trying to compiling the kernel 2.0.34
myself. What can be the problem?
I have tried and tried and finally included everything about networking
when compiling and ended up with
the same strange behavior. Why will the <DAM...> networkcard only work
with the precompiled kernel from
RedHat???
--
/Niclas Olsson
=====================================================
- ** ** **** Niclas Olsson -
- *** ** ****** Tunav�gen 39:B651 -
- **** ** ** ** 223 63 Lund -
- ** ** ** ** ** SWEDEN -
- ** **** ** ** -
- ** *** ****** email: [EMAIL PROTECTED] -
- ** ** **** phone: 046-211 67 19 -
=====================================================
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: Who is keeping track of kernel patches
Date: 13 May 1999 09:47:05 -0400
[EMAIL PROTECTED] (LEBLANC ERIC) writes:
> Michael Hirsch ([EMAIL PROTECTED]) wrote:
> : I have a very clear memory of a web site that kept track of kernel
> : patches that many people had released but were not in the kernel.
> : Does this still exist and where is it? I've been looking everywhere
> : and I can't find it anymore.
>
> http://www.linuxhq.com
>
> :
> : Was I dreaming?
>
> No. =)
Thanks for the pointer. I had checked there, but not thoroughly
enough, I guess. linuxhq has descriptions of the patches inthe
standard kernel, but it also has a link to
http://linux-patches.rock-projects.com/
which has what I was looking for. It has a collection of patches
which have not been incorporated into the Linux kernel along with
descriptions, etc.
Thanks a bunch,
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: gnu.misc.discuss
Subject: Re: Glibc rant
Date: 13 May 1999 09:24:44 +0100
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> - for the 2.1 release especially some programs had problems because
> they use undocumented *internal* interfaces. We simply had not
> the technology to prevent stupid people from using these functions
> and variables.
Once upon a time I used a system where, according to the manual, when
you invoked the system call to delete a file you had to specify the
process ID to use. It was a funny sort of requirement, but that's
what the manual said, so that's what I did.
Little did I know that in fact no version of the OS actually checked
this. Obviously some other people did know, though, as one of the
main compilers for the system simply didn't bother setting the
relevant register: they just passed any old nonsense there.
Eventually someone produced a version of the OS that enforced this
requirement. All the programs built using the compiler in question
broke when they tried to delete a file, of course. Actually they
broke several other more important ways too, again due to following
the current implementation rather than what the manual said.
The compiler writers said the OS developers were at fault, and vica
versa. I was astonished - clearly it was the fault of the compiler
writers for not reading the manual.
Personally I'm looking forward to the glibc 2.1 upgrade. If I've
understood the change right, it means that the linker will be able to
tell me where I've broken the rules, without my having to rely on
having read the manual correctly (which I try to do, but I'm only
human). I suspect in fact I'll be OK. l-)
--
http://www.greenend.org.uk/rjk/
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: How to make linux boot/shutdown rapidly
Date: 13 May 1999 09:59:11 -0400
Michael Hirsch <[EMAIL PROTECTED]> writes:
> I was thinking that one could write a kernel module that would imitate
> my ThinkPad. When loaded it would immediately write the contents of
> memory to a disk file, then shutdown the CPU. At boot time, you'd
> need a new boot loader that would load the file back into memory, then
> return execution to the appropriate place. Thus, shutdown would only
> take as long as it takes to write RAM to disk (and if you are clever
> you would only have to write the buffers that aren't just images of
> one on the disk). Start up would take as long as it takes to read
> them off disk.
Sorry to followup to my own post, but I've since found a kernel patch
that seems to do almost exactly what I was talking about:
http://falcon.sch.bme.hu/~seasons/linux/swsusp.html
Here's a quote from the homepage:
Enable the possibilty of suspendig machine. It doesn't need APM. You
may suspend your machine by either pressing Sysrq-d or with 'swsusp'
or 'shutdown -z (patch for sysvinit needed). It creates an image which
is saved in your active swaps. By the next booting the kernel detects
the saved image, restores the memory from it and then it continues to
run as before you've suspended. If you don't want the previous state
to continue use the 'noresume' kernel option.
I gotta try this.
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: "J�rgen Exner" <[EMAIL PROTECTED]>
Subject: Re: umount root file system
Date: Thu, 13 May 1999 10:59:27 -0700
Reply-To: "J�rgen Exner" <[EMAIL PROTECTED]>
new.ccu.edu.tw <[EMAIL PROTECTED]> wrote in message
news:7hdsdo$mnd$[EMAIL PROTECTED]...
> I'm wondering when when umounting root file system of Linux,
> it must be remount READO ONLY. Is there any security issue of
> what ??
Well, there is no point in unmounting the root filesystem in the first place
(how do you want to run any programs and even the last running shell will
loose it's CWD)?
However because some actions like file system checks should never be
performed on a mounted file system the closed acceptable scenario is a
read-only filesystem.
jue
--
J�rgen Exner
------------------------------
From: [EMAIL PROTECTED] (Dr H. T. Leung)
Subject: Re: Reading VideoCD?
Date: 13 May 1999 18:11:17 GMT
The error you are getting is the correct behaviour. the *.dat files on a VCD is not
real
files - it is just an entry point to the start of the data which is written on to the
disc in some special sector format (mode 2 form 2). To extra the mpeg stream from the
mode 2
form 2 sectors, you can either use "save as" in the "file" manu of mpegtv, or some
command line extraction tools like readvcd , xreadvcd, readxa, etc. (all of them are
detailed in the mpegtv website). I have done it a few times.
But then, I have a SCSI cdrom drive, and not sure about about the SCSI-emulation of the
ATAPI drive works, or is it transparent to mpegtv.
In article <7hf2f2$1ln$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Petter Reinholdtsen) writes:
|> When trying to read a VideCD mounted as iso9660, I get this in
|> /var/log/messages:
|>
|> May 13 19:29:12 lee kernel: hdc: command error: status=0x51 { DriveReady
|SeekComplete Error }
|> May 13 19:29:12 lee kernel: hdc: command error: error=0x54
|> May 13 19:29:12 lee kernel: end_request: I/O error, dev 16:00 (hdc), sector 1162228
|> May 13 19:29:12 lee kernel: ATAPI device hdc:
|> May 13 19:29:12 lee kernel: Error: Illegal request -- (Sense key=0x05)
|> May 13 19:29:12 lee kernel: Illegal mode for this track or incompatible medium --
|(asc=0x64, ascq=0x00)
|>
|> Are there any hopes to read the MPEG file directly from Linux? I know
|> MpegTV works, but I wanted to copy the MPEG file to local hard disk.
|> --
|> ##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
--
--------------------------------------------------
"What you don't care cannot hurt you." Chap. 7a, AMS-NS
------------------------------
From: Andrzej Radecki <[EMAIL PROTECTED]>
Subject: Simple AVR (Atmel) programmer driver
Date: 12 May 1999 21:20:24 GMT
I have written kernel module for AVR programmer. It works on lpt
port and require only 5 wires to connect to external cirquit. (It
utilize SPI - Serial Programming Interface). You can find this
driver on my www site [polish only :( ]
This is my first kernel module so I'd like to invite You to
correct it and tell me about bugs and mistake which I have made.
Best regards,
--
( /0/ Andrzej Radecki
==== \ mailto:[EMAIL PROTECTED]
/ | http://www.wpk.p.lodz.pl/~radecki
------------------------------
From: [EMAIL PROTECTED] (octet)
Subject: best distribution
Date: Thu, 13 May 1999 20:14:41 GMT
I'm pretty new to Linux and would like to get some opinions from you
folks. This is because I'm thinking about rolling out many Linux
workstations to replace Windows workstations.
1. Which distribution is the oldest?
2. Which one is the "technically" best distribution right now?
3. Which one is the best "over-all" distribution right now?
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Petter Reinholdtsen)
Subject: Reading VideoCD?
Date: 13 May 1999 17:34:26 GMT
When trying to read a VideCD mounted as iso9660, I get this in
/var/log/messages:
May 13 19:29:12 lee kernel: hdc: command error: status=0x51 { DriveReady SeekComplete
Error }
May 13 19:29:12 lee kernel: hdc: command error: error=0x54
May 13 19:29:12 lee kernel: end_request: I/O error, dev 16:00 (hdc), sector 1162228
May 13 19:29:12 lee kernel: ATAPI device hdc:
May 13 19:29:12 lee kernel: Error: Illegal request -- (Sense key=0x05)
May 13 19:29:12 lee kernel: Illegal mode for this track or incompatible medium --
(asc=0x64, ascq=0x00)
Are there any hopes to read the MPEG file directly from Linux? I know
MpegTV works, but I wanted to copy the MPEG file to local hard disk.
--
##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Preston F. Crow)
Subject: Re: Reading VideoCD?
Date: 13 May 1999 19:42:40 GMT
What you need is not iso9660fs but videocdfs.
Of course, you will have to write videocdfs. :)
Seriously, it shouldn't be too hard to do, at least for a read-only
fs, though I expect the other videocd tools that others mentioned are
easy enough to use that you don't really need a special file system.
--PC
--
=== "My 'tomorrow' is pretty flexible." ===
=== --Bob Gray, Dartmouth CS grad student ===
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Tue, 11 May 1999 13:07:46 GMT
In comp.os.linux.networking [EMAIL PROTECTED] wrote:
: In article <0EXY2.11020$[EMAIL PROTECTED]>,
: bryan <[EMAIL PROTECTED]> wrote:
: >my tulip card is totally unreliable. I can bring it down with an ftp
: >xfer (local lan) at 10 or 100, in a minute or less. network hangs and
: >will NOT be reset by software.
: Do you get a message in /var/log/messages when it gives up the ghost?
never saw one and I do usually look. I'll pay more attention next
time - tail -f and such.
: It's possible that a kernel oops in the driver's interrupt handler (or even in
: another interrupt handler shared on the same IRQ with your tulip) is causing
: the interrupt to be disabled, leaving you off-the-air. You should get log
: messages when this sort of thing happens.
: Other suggestions: try setting tulip_debug, or E-mailing the author of the
: driver. If it's really a driver problem, he'll want to know about it.
I did email the author but got no reply. that was before I heard of
the tulip mailing list. if I can reproduce that bug again, reliably,
I'll post it to that email list.
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: Insmod doesn't work
Date: 13 May 1999 18:00:41 GMT
In article <7hcudk$pt0$[EMAIL PROTECTED]>,
Marco Aurelio S. Mendes <[EMAIL PROTECTED]> wrote:
>The error message is: couldn't find the kernel version the module was
>compiled for.
Do you have all the proper includes (e.g. linux/module.h)? Is
MODULE defined before the includes?
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: 11 May 1999 08:43:46 -0400
"Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]> writes:
> >>>>> "Jan" == Jan Vroonhof <[EMAIL PROTECTED]> writes:
> > Moreover, recompiling is not always the easy solution. For instance if
> > you compile any current release of XEmacs under glibc 2.1 the
> > synchronous subprocesses break in a subtle way (they are no longer
> > interruptable).
>
> To me the main problem is more profound: the inability to have a single
> executable working with both glibc-2.1 and glibc-2.0 makes NFS sharing
> painful.
heterogenous is always painful. keep everything glibc-2.1 *or*
glibc-2.0. don't mix.
> Yes, there are workarounds, of course, but the libc5 to libc6 switch
> was much less painful from a syadmin point of view. Admittedly, the
> problems I've had so far with RedHat-6.0 are mostly due to the
> switch to egcs rather than to the switch to glibc-2.1.
nod. egcs has forced a number of incompatible libstdc++ revisions.
on the other hand, libstdc++ isn't used by nearly as much as libc, nor
are they critical to the system. egcs seems to be a better compiler
than gcc-2.[78].x so i prefer going with egcs.
--
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
******************************
