Linux-Development-Sys Digest #611
Linux-Development-Sys Digest #611, Volume #8 Wed, 4 Apr 01 20:13:12 EDT
Contents:
Re: signed vs unsigned ints discussion please (Juergen Heinzl)
Re: Kernel Panic in Network Interface
Re: We need Embedded Linux Developers in San Jose
Re: TCP/IP socket buffering (Grant Edwards)
Re: Need your recommendation for a full-featured text editor ("Aaron R. Kulkis")
kernel panic, killing interrupt handler ([EMAIL PROTECTED])
Conference on File and Storage Systems (FAST) Call for Papers (Becca Sibrack)
Re: TCP/IP socket buffering (Dave Platt)
Re: cpu scheduling problem (Robert Redelmeier)
Re: cpu scheduling problem ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: signed vs unsigned ints discussion please
Date: Wed, 04 Apr 2001 21:09:08 GMT
In article [EMAIL PROTECTED], Gene Heskett wrote:
Hi all;
I'm trying to clean up some c++ code but don't know a lot about c++. One
of the problems in this code is that there are many places in it where
the format is:
if var = 0
where the var is an int and isn't spec'd as an unsigned, and in fact
can't be or the compiler bails out totally since such a comparison is
always true. I actually tried that :(
So the real problem is that the casting of the numeral '0' must be an
unsigned value according to the warnings given.
[-]
Huh ?
The question then is: How can I specify, in c++, a globally available
signed int containing the value of zero, or 0x8000? Then all I have
to do is change all the '0's to 'zero'.
[-]
You had better check the code. Off the cuff I can think of two
reasons for any warnings ...
() the compiler can determine var is never going to be less than
zero.
() somewhere a value is being assigned to var which exceeds the range
on an int.
... and these two at least would mean the code is either not fully
thought through or possibly even buggy.
Sometimes it's better to trust your compiler more than yourself.
Cheers,
Juergen
--
\ Real name : Juergen Heinzl\ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
--
From: [EMAIL PROTECTED] ()
Subject: Re: Kernel Panic in Network Interface
Date: Wed, 04 Apr 2001 21:45:13 -
In article [EMAIL PROTECTED],
James Stephens [EMAIL PROTECTED] wrote:
Problem : when I attempt to use the route command, loopback works BUT
the route to the gateway MOST
(90%) often chokes... and crashes the entire box with the following
error...
Kernel Panic: skput: over: d0070fe4: 4096 put 4096 dev:tr0
In swapper task - not syncing
Details : I have a dual processor box running Linux kernel version
2.2.16 and a token ring adapter.
Sounds like either the token ring driver is broken or your adapter
is. You might want to check 2.2.19 for a new driver.
Hasn't IBM given up on token ring yet?
--
http://www.spinics.net/linux/
--
From: [EMAIL PROTECTED] ()
Subject: Re: We need Embedded Linux Developers in San Jose
Date: Wed, 04 Apr 2001 21:45:49 -
In article [EMAIL PROTECTED],
Warren Spencer [EMAIL PROTECTED] wrote:
Can't smoke cigarettes, either.
That's not a problem.
--
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.networking
Subject: Re: TCP/IP socket buffering
Date: Wed, 04 Apr 2001 22:02:20 GMT
In article [EMAIL PROTECTED], Joseph A. Knapka wrote:
In article [EMAIL PROTECTED], Lew Pitcher wrote:
I'm aware of that. The legacy stuff I'm supporting would be
unable to read a command sequence from a file: it depends on
each read() call to return exactly one command (of whatever
length). If commands get fragmented into mutple read()s it the
program doesn't work. If a read() returns multiple commands,
only the first is processed.
Ah, I see. In other words, your predecessor did *not* design a
datagram protocol atop TCP; rather he/she/it ignored the issue
entirely.
Exactly. They sort of went for the 90% solution. It works in
90% of the installations, and there were always other
higher-priority things that worrying about the last 10%.
The software I have to talk to is burned in ROMs in thousands
and thousands of boards scattered about the planet. I can not
change it.
Oh my. You'd think someone would have noticed this problem
earlier.
The problem only appears when poeple have a slow link in the
network and use routers that will concatenate packets when
they're queue for re-transmission. The temporary fix was
to add delays between write() operations, or to intersperse
write() operations that generate a response, then wait for the
resonse.
It would be nice to have the system provide a reliable datagram
service.
Agreed.
Sounds like a good MS project to me...
--
Grant Edwards grante Yow! .. my NO
Linux-Development-Sys Digest #611
Linux-Development-Sys Digest #611, Volume #6 Sat, 10 Apr 99 22:14:15 EDT
Contents:
nfsd and inode reuse (mlw)
Re: RH5.2, Solaris and NFS (John Murtari)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Joe Zeff)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) ([EMAIL PROTECTED])
Re: kernel_thread()'s become zombies (David Grothe)
Re: Linux task switching, schedule(), and do_timer() (Alexander Viro)
Where to get GCC latest for RH 5.1 ("Richard Copeman")
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Alexander Viro)
Writers wanted for zine articles. (Port Lord)
module-info (Svein K Svendsen)
ISR: Kernel-User space call (Milos Dedecek)
Linux NFS server, Solaris cient, bad news ... ([EMAIL PROTECTED])
Device drivers ("Hugo Halvorsen")
Re: kernel_thread()'s become zombies ("B. James Phillippe")
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 ("Dan M. Johnson
(bagzman)(LinuxBox1)")
Re: Writers wanted for zine articles. (Frank v Waveren)
Re: ISR: Kernel-User space call (Joe Pfeiffer)
Re: System development methodologies (Need Help) (Alexander Viro)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Andrew Comech)
From: mlw [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy
Subject: nfsd and inode reuse
Date: Sat, 10 Apr 1999 12:56:58 +
I have a strange problem with a Solaris machine connected to a Linux
server.
It seems that if, in rapid succession, a file is created, deleted, and a
new directory is created. In NFS the directory gets the same inode as
the previous file. For some reason, the Solaris box wants to think this
inode is a file until the nfs client refreshes. As you can imagine this
breaks a few scripts. Also, it does not happen 100% of the time (joy ;-(
).
I have a script:
resuse.sh
touch fubar
ls -i fubar
rm fubar
mkdir rabuf
ls -id rabuf
rmdir rabuf
When executed on a local disk, ext2 uses two different inodes. When
executed on an NFS volume, it uses the same "inode."
The questions are:
Is the reuse of the inode on the NFS mounted volume a problem? or, is it
some other level of cache coherency protocol that is breaking down?
If it is a Solaris client bug, is there a work around?
If it is a Linux server bug, is there a fix?
So, before I start hacking nfsd, maybe it is already fixed ;-)
Also, has anyone else seen this behavior?
If you, can, respond by e-mail. Thanks.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Take the Mohawk Software Computer Survey at: www.mohawksoft.com
--
From: John Murtari [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking
Subject: Re: RH5.2, Solaris and NFS
Date: Sun, 11 Apr 1999 00:25:03 -0400
Yes, we are experiencing NFS "hangs" between Solaris and Linux, fairly
busy systems we get problems 2-3 times/day will loss of one of the
mountd's.
Finally, we just put a monitor in place to make sure NFS daemons hadn't
stopped running, and to restart them if they had. Have seen no
corruption,
but most of our stuff is READ only.
Have seen other people noticing this, but have not seen any comments
from
anyone "in the know" from either Linux Folks or Sun on a solution.
John Murtari
http://www.thebook.com/
1. Rebuilt nfs-server-2.2beta40.
2. upgraded to kernel 2.2.5 with latest nfs-server-2.2beta40.
3. Contacted SunSolve. They had one ticket that referenced this
product. The customer closed it with mention of upgrading
Linux to 2.1.x kernel. Unable to find out who the customer is.
4. Calling for help from anybody.
Please also send any replies directly.
Marv Nachatelo
[EMAIL PROTECTED]
--
John
__
Customer Service Sofware Workshop Inc.
[EMAIL PROTECTED]"TheBook.Com" (TM)
315-635-1968, x-211
--
From: [EMAIL PROTECTED] (Joe Zeff)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Sat, 10 Apr 1999 19:12:04 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
There isn't any connection between what I wrote and notions
of "process improvement". There is a difference in goals
and available resources.
Sure there is, unless one stagnates a the lowest levels of technology.
OK, substitute "product evolution" and "keeping up with the times" then.
Emacs? How could anything be worse?? Guaranteed: if the tools were
better free UNIX would be a lot more accepted. There's still the problem
of obsolete monolithic design of the kernel offe
