Linux-Development-Sys Digest #793, Volume #8 Sun, 17 Jun 01 09:13:12 EDT
Contents:
Re: Module zombies (Clifford Kite)
Re: thread timing info, suspending threads (Kaz Kylheku)
Re: pause the bootup (Mike McDonald)
Re: "Locked Directory" for floppy & CDROM (Jose W. Shermanson)
Re: Hey Viro ("James T. Dennis")
Re: close or shutdown the tcp socket when it is in SYN_SEND ("James T. Dennis")
stat (Dekang Lin)
Re: Hey Viro (cLIeNUX user)
Protocol Switch Table protosw.h ([EMAIL PROTECTED])
Re: Supervising non-child processes w/wo procfs ("Guido Ostkamp")
Waking up a user thread from kernel code (galonius)
----------------------------------------------------------------------------
From: Clifford Kite <[EMAIL PROTECTED]>
Subject: Re: Module zombies
Date: Sat, 16 Jun 2001 09:54:33 -0500
Phil Ehrens <[EMAIL PROTECTED]> wrote:
> Clifford Kite wrote:
>> Linux kernel 2.4.5-ac9
>>
>> I have an HP 315 camera with a USB connector and can copy the pictures
>> on it's CompactFlash card from a directory using cp, after mounting
>> /dev/sda1 as a msdos filesystem. The connection to /dev/sda1 is created
>> by inserting the modules usb-uhci.o, usb-storage.o, and sd_mod.o with a
>> modprobe -a, turning on the camera, and, of course, mounting /dev/sda1.
>>
>> After copying the pictures and umounting /dev/sda1, a lsmod shows no
>> module being used, but then after removing the modules with modprobe -r
>> a ps auxw shows this:
>>
>> root 2985 0.0 0.0 0 0 ? Z 12:07 0:00 [usb-storage-0 <defunct>]
>> root 2986 0.0 0.0 0 0 ? Z 12:07 0:00 [scsi_eh_0 <defunct>]
>>
>> Is this normal?
> I found it necessary to do "rmmod usb-storage" after unmounting.
> modprobe -r seemed to rmmod in the wrong order, and these modules
> seem to be rmmod order sensitive. You don't need to rmmod any
> of the others explicitly.
Doing that here results in the other modules remaining in place and ps
auxw shows the same pair of zombies, which seems odd since the sd_mod
hasn't been removed. I've already tried several variations of the order
of removal of the modules too, and the same zombies appear. The most
likely thing is that I'm just doing something dumb, but I haven't been
able to find out what. (BTW kmod autoloading isn't used. Once the
camera is attached and turned on scripts are used to insert[remove]
the modules and mount[unmount] the CompactFlash card.)
There are also no dependences between these modules created in
/lib/modules/2.4.5-ac9 modules.dep after doing depmod -a.
However setting up dependences in modules.conf with
# hp315
alias hp315 usb-uhci
add below hp315 usb-storage sd_mod
does work for modprobe (modprobe -a hp315 and modprobe -ar hp315).
> This was with 2.2.19 and all the usb stuff as modules.
> Does usb-storage still cause a load with 2.4.5-ac9? It caused a
> continuous additional load of about 1 with 2.2.19, hence my desire
> to rmmod it!
No that doesn't happen, not while the camera card is mounted or after
it is dismounted. This top output shows there is very little load
after they are loaded, at least when there is no file transfer from
the camera card.
4487 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 usb-storage-0
4488 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 scsi_eh_0
I'm a little troubled to find out that these modules show up as
processes. I'd thought that modules were a part of the kernel once
they are inserted, not a process. That may just be a misconception
on my part, but nothing related to usb-uhci shows up as a process.
--
Clifford Kite <Email: [EMAIL PROTECTED] with X=kite, Y=inetport, Z=com>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: thread timing info, suspending threads
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 16:06:41 GMT
On Fri, 15 Jun 2001 12:09:58 -0700, Michael Harvey <[EMAIL PROTECTED]>
wrote:
>I am working on an application thread scheduler and need to be able to
>control how much time a given thread will spend working. To accomplish
>this I need to be able to find out how much time it has used (preferably
>with nanosecond resolution), and I also need to be able to suspend a
>thread and resume it later.
>
>In Win32 (yes this is cross platform) I use GetThreadTimes() to get
>kernel and user times, and SuspendThread()/ResumeThread() to turn it on
>and off.
This is wrong. You should not only avoid doing this on Linux, but fix your
Win32 program. There is no need for an ``application thread scheduler'' on
Win32, or in Linux. The threads already have a scheduler.
Stopping a thread with SuspendThread is dangerous, because you have
no clue what that thread is doing; you do not have its cooperation.
>Does similar functionality exist in pthreads, or if not, is there a
>LinuxThreads workaround that can do it?
You should be able to suspend a thread on Linux using pthread_kill with the
SIGSTOP and SIGCONT signals. That is not POSIX.
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Mike McDonald)
Subject: Re: pause the bootup
Date: Sat, 16 Jun 2001 17:37:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Aravindh) writes:
>> If your system has a serial port, try configuring your kernel for a serial
>> console. Also, change the printk buf to not be static so you can look to see
>
> Yes, my system has a serial port. But do you know what I need to
> modify in the kernel to get it configured as a serial port?
When doing 'make [x|menu]config', check the 'serial console' option. Then
recompile. There's docs in /usr/src/linux/Documentation/serial-console.txt
Mike McDonald
[EMAIL PROTECTED]
------------------------------
From: Jose W. Shermanson <[EMAIL PROTECTED]>
Subject: Re: "Locked Directory" for floppy & CDROM
Date: Sat, 16 Jun 2001 20:30:05 -0000
Kasper,
Sorry about the use of -1 vs. -l. The font I am using makes the difference
almost indestinguishable. I followed your suggestion to run the series of
commands immediatly after I rebooted (this was my 3rd reboot) and
everything works just fine. I don't understand what I did to fix the
problem but I don't know how I broke the system, either ;) Thanks ever so
much for your help. Jose
Kasper Dupont wrote:
>
> Jose W. Shermanson wrote:
> >
> > Kasper Dupont wrote:
> > >
> > > Jose W. Shermanson wrote:
> > > >
> > > > I'm not sure this is a kernal question or a file system one but I
> > cannot
> > > > access my CDROM nor my floppy. I recently loaded Mandrake Linux
v8.0.
> > All
> > > > went well for about 2 weeks and then, for some reason unknown to
me,
> > when I
> > > > attempt to access my CDROM or floppy, I get an error message "You
do
> > not
> > > > have enough permissions to read file:/mnt/floppy." The "file type"
> > column
> > > > displayed by konqueror says "locked directory." I suspect I
somehow
> > shut
> > > > down LINUX while these devices were busy and the condition hasn't
been
> > > > cleared. Any suggestions short of re-installing would be
appreciated.
> > I
> > > > am a total novice to LINUX but have 30+ years experience with
mainframe
> > > > OSs. Thanks. Jose
> > > >
> > > > --
> > > > Posted via CNET Help.com
> > > > http://www.help.com/
> > >
> > > What do you get when you type the
> > > following commands in a shell?
> > > cat /etc/fstab
> > > ls -l /mnt
> > > mount /mnt/floppy
> > > mount /mnt/cdrom
> > > ls -l /mnt
> > >
> > > Have you tried with different
> > > floppies and CDROMs?
> > >
> > > --
> > > Kasper Dupont
> > Kasper, Looks like the CDROM & the floppy are supermounted.
> >
> > $cat /etc/fstab
> > /dev/hdb5/ ext2 defaults 1 1
> > none /dev/pts devpts mode=0620 0 0
> > /mnt/cdrom /mnt cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0
> > /mnt/floppy /mnt/floppy supermount
exec,dev,suid,rw,fs=vfat 0
> > 0
> > <deleted>
> > $ls -1 /mnt
> > cdrom/
> > disk/
> > floppy/
> > win_c/
> > win_c2/
> > win_d/
> > $mount /mnt/floppy
> > mount: according to mtab, /mnt/floppy is already mounted on /mnt/floppy
> > mount failed
> >
> > Sorry but I'm too new to linux to know how to unmount the devices and
> > re-mount them. I tried the unmount command but bash says it can't fine
the
> > command.
> >
> > Any more suggestions?
> >
> > Jose
> >
> > --
> > Posted via CNET Help.com
> > http://www.help.com/
>
> Hmm, I don't know how this supermount filesystem works.
> Without supermount the lines would have looked like this:
> /dev/cdrom /mnt/cdrom iso9660 defaults 0 0
> /dev/fd0 /mnt/floppy vfat exec,suid,rw 0 0
> But I don't know if this is in any way related to your
> problem.
>
> The output from "ls -1 /mnt" doesn't help much, I asked
> you to type "ls -l /mnt". Notice the difference.
>
> There is no command named "unmount", it is named "umount".
> But maybe you are not suposed to use that with
> supermounted devices.
>
> I suggest you try these commands right after a boot:
> cat /proc/mounts
> ls -l /mnt
> ls -l /mnt/floppy
> ls -l /mnt/cdrom
> ls -l /mnt
> cat /proc/mounts
>
>
> BTW, Does anybody know what this supermount filesystem
> does, and what is the correct way to use it?
>
> --
> Kasper Dupont
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: "James T. Dennis" <[EMAIL PROTECTED]>
Subject: Re: Hey Viro
Date: 17 Jun 2001 02:26:50 GMT
cLIeNUX user <r@cLIeNUX.> wrote:
> man-pages 1.38, man 5 fs
> .B ext
> is an elaborate extension of the
> .B minix
> filesystem. It has been completely superseded by the second version
> of the extended filesystem
> .RB ( ext2 )
> and will eventually be removed from the kernel.
> .\"----------------------------------------------------------------------
> .TP
> .B ext2
> is the high performance disk filesystem used by Linux for fixed disks
> as well as removable media.
> .sp
> The second extended filesystem was designed as an extension of the
> extended file system
> .RB ( ext ).
> .B ext2
> offers the best performance (in terms of speed and CPU usage) of
> the filesystems supported under Linux.
> .\" Copyright 1996 Daniel Quinlan ([EMAIL PROTECTED])
Needs additions for ext3, reiserfs, xiafs, jfs (IBM), jffs
(Axi Comm.), XFS (SGI) and a few others.
ext2 might have to drop the claim regarding "best performance"
depending on your test criteria (particularly your mixture of
file and directory sizes).
Such a man page should also refer to the devfs, shmfs/tmpfs,
usbfs, proc, ramfs, cramfs, romfs, and other virtual filesystems
as well as the many network filesystems.
Even better it should refer to the current slough of network
filesystems.
------------------------------
From: "James T. Dennis" <[EMAIL PROTECTED]>
Subject: Re: close or shutdown the tcp socket when it is in SYN_SEND
Date: 17 Jun 2001 03:50:29 GMT
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, "HuYp" <[EMAIL PROTECTED]> wrote:
>> in fact it return the error
>> "no route to B" after several seconds, why?
> Because the ethernet ARP request did not produce an ARP response, which
> to Ethernet means `no route'. An ICMP destination-unreachable was
> generated.
Are you sure? Who would be generating this? I don't
see an ICMP host unreachable for a locally non-existent
IP address when I try this (while watching tcpdump -n
icmp logs).
I think that ICMP host unreachable is generated by remote
routers (and relayed back through your local router).
Localhost ARP timeouts seem to be handled locally (although
it seems that the local router will eventually start generating
ICMP host unreachable for the locally non-existent address
on stop of that).
------------------------------
From: Dekang Lin <[EMAIL PROTECTED]>
Subject: stat
Date: 16 Jun 2001 22:23:49 -0600
The stat(2) function should return zero on success. However, when the
file is larger than 2GB, it returns -1. Is this a known bug? (I am
using Red Hat Linux release 7.0, Kernel 2.2.18pre11-va1.1 on an
i686).
Dekang
------------------------------
From: r@cLIeNUX. (cLIeNUX user)
Subject: Re: Hey Viro
Date: Sun, 17 Jun 2001 06:24:56 -0000
[EMAIL PROTECTED]
>cLIeNUX user <r@cLIeNUX.> wrote:
>
>> man-pages 1.38, man 5 fs
>
>> .B ext
>> is an elaborate extension of the
>> .B minix
>> filesystem. It has been completely superseded by the second version
>> of the extended filesystem
>> .RB ( ext2 )
>> and will eventually be removed from the kernel.
>> .\"----------------------------------------------------------------------
>> .TP
>> .B ext2
>> is the high performance disk filesystem used by Linux for fixed disks
>> as well as removable media.
>> .sp
>> The second extended filesystem was designed as an extension of the
>> extended file system
>> .RB ( ext ).
>> .B ext2
>> offers the best performance (in terms of speed and CPU usage) of
>> the filesystems supported under Linux.
>
>
>> .\" Copyright 1996 Daniel Quinlan ([EMAIL PROTECTED])
>
> Needs additions for ext3, reiserfs, xiafs, jfs (IBM), jffs
> (Axi Comm.), XFS (SGI) and a few others.
>
> ext2 might have to drop the claim regarding "best performance"
> depending on your test criteria (particularly your mixture of
> file and directory sizes).
>
> Such a man page should also refer to the devfs, shmfs/tmpfs,
> usbfs, proc, ramfs, cramfs, romfs, and other virtual filesystems
> as well as the many network filesystems.
>
> Even better it should refer to the current slough of network
> filesystems.
>
>
>
True, but I'm just needling Al about his Minix roots.
Rick Hohensee
www.clienux.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Protocol Switch Table protosw.h
Date: 17 Jun 2001 09:36:54 GMT
Hi!
Is there a Linux equivalent of the protocol switch table in BSD???
Thanks!!
Jon
------------------------------
From: "Guido Ostkamp" <[EMAIL PROTECTED]>
Subject: Re: Supervising non-child processes w/wo procfs
Date: Sun, 17 Jun 2001 13:06:25 +0200
Jeremiah DeWitt Weiner <[EMAIL PROTECTED]> wrote:
> What exactly do you mean by "supervise"?
> [...]
> ...because it sounds like you mean "wait for it to die".
You are correct. The system is going to provide high-availability,
therefore one feature is that applications which exited, must be
restarted immediately. As it is possible that the supervising process
itself may fail (and will be restared) and processes can also be
restarted manually from outside and put themselves under control
of the supervising process by calling some libraray, there is no
parent-child relationship between them, thus signalling won't work.
> And it just
> so happens that I recently wrote a program to do this. Of course, my
> solution was "stat /proc/<pid> && sleep", so it's not quite the way you
> specify, but, as Linus said, it wins on points of being available now!
I cannot use such a solution because it uses active polling. If I do
this often enough to gurantee a certain reaction time, it would waste
too much CPU power. On the other hand I cannot sleep long time, because
restarting would be to slow. Therefore I need a blocking solution.
> I assume you have looked at the way some SysV systems do it - I just
> did a truss of pwait on a Solaris 7 system, and saw this
> [...]
> so it works the way you describe. The Linux and Solaris poll man
> pages make them look reasonably similar. You've tried it and it didn't
> work?
Yes. Of course, the poll() or select() library function API is the same,
but the underlying implementation of the poll in the proc filesystem
is different. On Linux, if you are listening for POLLPRI, POLLERR or
POLLHUP events (e.g. when using /proc/<pid>/status), they won't be
detected. When the process dies, nothing happens.
Therefore my question, if someone has implemented the procfs (poll)
the SysV way.
Regards,
Guido
------------------------------
From: [EMAIL PROTECTED] (galonius)
Subject: Waking up a user thread from kernel code
Date: 17 Jun 2001 06:05:09 -0700
I have the following problem :
I am writing a driver that needs, in some cases, to wake up
a user thread that is waiting on a semaphore.
Obviously, I can use neither a user-space semaphore nor a kernel-apce one.
Any ideas ?
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
