Linux-Development-Sys Digest #366, Volume #8 Wed, 20 Dec 00 20:13:15 EST
Contents:
LVM and JReiserfs crash 2.2.14 and 2.2.16 (Johannes Nix)
Re: sys_close & fd's ??? (byteme)
Re: How to make a BIOS call in Linux (Johannes Nix)
Re: Intel Easy PC camera - cannot be supported in Linux! ([EMAIL PROTECTED])
Re: How to make a BIOS call in Linux (Andi Kleen)
Re: LVM and JReiserfs crash 2.2.14 and 2.2.16 (Andi Kleen)
Re: IEEE standards (HomerWelch)
Re: Do "Lions' Commentary on UNIX" good for knowing unix kernal? (Daniel Rall)
Re: IEEE standards (Kaz Kylheku)
ip_masq_ftp.c ([EMAIL PROTECTED])
ip_masq_ftp.c ([EMAIL PROTECTED])
Char device drivers and mknod (Petric Frank)
Re: semaphore problem (David Schwartz)
Re: Intel Easy PC camera - cannot be supported in Linux! (Russ Lyttle)
Re: how to use "pthread_rwlock_t" in linux? (David Schwartz)
Re: Char device drivers and mknod (Kaz Kylheku)
----------------------------------------------------------------------------
From: Johannes Nix <[EMAIL PROTECTED]>
Subject: LVM and JReiserfs crash 2.2.14 and 2.2.16
Date: 20 Dec 2000 21:07:53 +0100
Hi there,
We are running a small academic workgroup server. It runs Linux 2.2.16
(SuSE patches), Journaling ReiserFS, and has an 700 MHz Athlon CPU,
512 MB Memory and a 96 G SCSI Volume (ATA disk array with RAID
controller, operating at RAID level 5). Has worked flawless for about
six months (We had to turn on the "notails" option for the FS, because
file modification times changed sometimes shortly after writing
files). All in all a supercheap reliable system which I would
recommend to everybody.
Because our group members are good at generating data ;-), we tried to
upgrade the thing with another 280 G RAID array (also SCSI connected).
We didn't want to split up the file hierarchy, therefore we tried to
use LVM. The number of physical extends (PE) was too large for the
default physical extend size, for this reason we increased the size
from 4 MB to 32 MB. This resulted in about 9000 physical extends.
Then, we created a logical volume and put a Reiser filesystem on it.
It seemed to work, but the machine slowed down a bit (it runs only
samba and NFS server processes). We then started a copy command of the
old partition. The effect was that the system nearly stopped and
couldn't be controlled any more. It was like swapping. We tried
crtl-alt-del and read the first response from init about five minutes
later, after ten minutes more of waiting we hit the power key.
We tried then to boot the box using a 2.2.14 kernel (which was proved
to work for a long time), and mounted the logical volume another
time. It turned out that only a few dozen MB had been copied. We
started the copy another time, but the machine went like trashing
again; the kswapd process was quite active. However it remained
controllable. After un-mounting the logical volume, everything went
normal.
So anybody has heard about this problem before ? Could it be related
to problems handling lots of memory?
Are there any additional resources on LVM (I couldn't find even a
EMail address in the LVM HOWTO)?
Of the experienced people out there, does anybody think it's
appropriate to post it to linux-kernel? What kind of additional
information would be needed then? (Perhaps even anybody would be so
nice and scan the posting before?)
kind regards,
Johannes Nix
[EMAIL PROTECTED]
(Note: I am reading the group, but due to the crappiness of our local
news server I would really prefer to get CC'ed any postings. Thanks.)
------------------------------
From: [EMAIL PROTECTED] (byteme)
Subject: Re: sys_close & fd's ???
Date: Wed, 20 Dec 2000 20:09:32 GMT
On Fri, 15 Dec 2000 10:14:16 +0100, Kasper Dupont
<[EMAIL PROTECTED]> wrote:
Thank you for the info . I've since figured out a way by maintaining
my own linked list when the files are opened and destroying the entry
when they are closed. Seems to work well.
I'll take a look at you sug. maybe I can do the same usiing native
funcs
kevin
>Erik Hensema wrote:
>>
>> byteme ([EMAIL PROTECTED]) wrote:
>> >Does anyone know how to assoc. a fd to a file name ??
>>
>> Can't be done.
>>
>
>You are mistaken, it is posible. The kernel
>present the information to userspace programs
>in /proc/<pid>/fd.
>
>If you want to use the information inside the
>kernel you should probably use the function:
>char * d_path(struct dentry *dentry,
> char *buffer,
> int buflen)
>The struct file contains a pointer to a struct
>dentry.
>
>--
>Kasper Dupont
------------------------------
From: Johannes Nix <[EMAIL PROTECTED]>
Subject: Re: How to make a BIOS call in Linux
Date: 20 Dec 2000 21:38:12 +0100
[EMAIL PROTECTED] (bill davidsen) writes:
> Thanks, I will have to look at this, since the 2.4 kernel series does
> not interface to APM (in spite of notes in the Change log saying that
> power down does work, even with SMP). When my UPS says the party's over,
> I want to shut the system off, not run the UPS dead supporting a halted
> system. There's no real hope of getting this in the kernel, so I want to
It seems wiser to me to do an umount -a and switch off the UPS - many
UPS seem to support this. Why? Because it is safer if power comes back
and fails again. You don't have UPS protection the second time, as the
battery is empty.
Johannes
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Wed, 20 Dec 2000 21:16:08 GMT
mlw <[EMAIL PROTECTED]> writes:
> Jonathan Buzzard wrote:
>>In article <[EMAIL PROTECTED]>,
>> mlw <[EMAIL PROTECTED]>writes:
>>>The price indicates that the actual camera is trivial and all the
>>>important product development was in the software. If Intel makes
>>>the hardware API public, then it is clear how the camera
>>>works. Competitors would be able to clone the hardware and just
>>>instruct users to download the camera software from Intel.
>>I don't think that this would work, few users would be happy not
>>getting the driver with the device, and it would probably be a
>>breach of the license for the software. If Intel was to put some
>>device ID in the device which the driver was to check, then this
>>would effectively lock out the clonners, unless they want to find
>>themselves in court.
>But, and I have seen this with older video cards based on S3 chips,
>video capture cards, FAX modems, etc. If vendor A puts a lot of work
>in their driver to make it better, and vendor B puts very little work
>in their driver, but it is common knowledge that vendors A's driver
>will work with vendor B's hardware, the more savvy people will buy
>the device by vendor B and download drivers from vendor A.
.. And when this is the case, the problem is _not_ with Vendor B, but
rather with the fact that both A _and B_ are selling the same hardware
produced by S3.
A is pretending that they have a better product, when really they are
selling the same hardware.
By and large, both vendors are making their money from selling the
hardware, not from selling software. Which is why such situations
persist.
>>>I worked at Polaroid as a contractor and did some work on their
>>>electronic still camera. There is a lot of image processing
>>>involved in this sort of product. Obviously, the el-cheapo cameras
>>>must do this in host software, not on the camera to keep the costs
>>>down. The competitor only has to invest in hardware, while Intel
>>>has to recoup cost the larger cost of software development.
>>>It is a tough problem, and one of those gray areas in which a pure
>>>GPL approach is a very tough sell. To differentiate yourself and be
>>>competitive with a hardware product, you must make it good and make
>>>it competitively priced. The answer to this is proprietary software
>>>to control mass-produced trivial hardware.
>>Not in a pure GPL approach, as Intel would have only a small expense
>>in the software development as would all the other camera
>>manuafactures.
>But how would Intel make a case for its camera over some low priced
>clone? Why would someone pay $10 dollars more for an Intel camera?
>They wouldn't, and that would not be acceptable for someone like
>Intel.
Intel's _strength_ is in building and selling sophisticated integrated
circuits. They produce sell the CPUs that are bundled into computer
systems sold by innumerable vendors. They produce all the StrongARM
chips integrated into "settop boxes" and PDAs. They produce video
cards [albeit not the _noted_ ones]. They produce all sorts of the
hardware that gets integrated onto motherboards.
It is no great leap for them to produce the internal circuitry for
digital cameras, and then resell that to other vendors that might
package it under their own name.
>Intel has a brand name, as dubious as it is, they have to make sure
>that there camera is better than a "Snap!" super el-cheapo. If they
>can't, they won't enter the market. If they release something that
>makes their camera better than the "Snap!" then, "Snap!" would be
>able to copy their image processing techniques and steal the market
>with price.
For the most part, Intel's "brand name" is associated with being The
Integrated Circuit Vendor Of Choice. ["Choice for What" is a whole
other question :-).]
If someone else markets a camera that uses the same chipset, it may be
that the Intel "Retail Camera" division would be unhappy at the loss
of _their_ sales. Intel as a whole may be entirely pleased, as the
result of such a deal is that they can do more of What Intel Is Known
For, namely selling electronic components. If there were only _one_
such deal, this might indeed be a "loss" for Intel.
If it leads to _more_ deals, that allow Intel to ramp up circuit
production, they might be quite pleased to have a Camera Division that
represents little more than a conduit of "espionage information" so
that Canon, Olympia, and a host of others could readily get the
engineering specs they need to build cameras that _sell Intel chips_.
>GPL can not apply to hardware, because hardware is limited by finite
>numbers. Production has a proportional unit cost for the
>producer. While the software associated with a digital camera may be
>free, making it so would affect the ability to produce the camera
>competitively. The software is part of the camera.
Hardware itself is something to which one cannot readily apply the GPL
as it is not readily duplicable in the way software is. Nonetheless,
there is potential room for there to be GPL-like licensing of hardware
_designs_.
There certainly hasn't been the popularization of hardware components
thus licensed; it is not entirely clear why this is.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
"My mom said she learned how to swim. Someone took her out in the lake
and threw her off the boat. That's how she learned how to swim. I
said, 'Mom, they weren't trying to teach you how to swim.' "
-- Paula Poundstone
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: How to make a BIOS call in Linux
Date: 20 Dec 2000 22:35:48 +0100
[EMAIL PROTECTED] (bill davidsen) writes:
>
> There's even an option to use a real mode APM BIOS call to power down
> in the kernel, but the SMP stuff doesn't use use it. One of my clients
> wrote code to use the "-R" option in lilo to reboot into Windows just
> so the APC code there can do the shutdown Linux can't. To quote my
> youngest, "Yuckie-Poo!"
The SMP poweroff works fine when you specify apm=power-off on the kernel
command line. Next time please check facts before flaming.
-Andi
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: LVM and JReiserfs crash 2.2.14 and 2.2.16
Date: 20 Dec 2000 22:41:01 +0100
Johannes Nix <[EMAIL PROTECTED]> writes:
>
> Then, we created a logical volume and put a Reiser filesystem on it.
> It seemed to work, but the machine slowed down a bit (it runs only
> samba and NFS server processes). We then started a copy command of the
> old partition. The effect was that the system nearly stopped and
> couldn't be controlled any more. It was like swapping. We tried
> crtl-alt-del and read the first response from init about five minutes
> later, after ten minutes more of waiting we hit the power key.
You should probably update to a newer SuSE kernel. One of the kernel updates
(no on CD kernel) had a memory balancing problem that caused such effects on
very heavy writes.
> Of the experienced people out there, does anybody think it's
> appropriate to post it to linux-kernel? What kind of additional
> information would be needed then? (Perhaps even anybody would be so
> nice and scan the posting before?)
linux-kernel is appropiate when you're using mostly unpatched kernels
(i.e not the SuSE kernel)
-Andi
------------------------------
From: HomerWelch <[EMAIL PROTECTED]>
Subject: Re: IEEE standards
Date: Wed, 20 Dec 2000 22:23:22 GMT
Matthew Palmer wrote:
>
> Bart De Schuymer is of the opinion:
> >I've been looking at the IEEE homepage (www.ieee.com).
> >I would like to read the standard called:
> >IEEE 802.1 Spanning-Tree Protocol
> >but it seems I have to pay to read a standard ??
>
> Yup - it's how IEEE recoups the money spent in actually producing the
> standard. The alternative is a patent, I guess. I know which one I prefer.
>
I doubt whether it is patentable, but it is copyrighted. I
remember reading a magazine article by a guy who was on the
committee to standardize the C Programming Language. He
wanted a copy of the released standard. IEEE wouldn't give
him one. He had to pay for it. So much for volunteering on
IEEE committees.
--
Homer J. Welch [EMAIL PROTECTED]
Troy, Michigan
------------------------------
Crossposted-To: comp.unix.programmer,comp.os.linux.development
Subject: Re: Do "Lions' Commentary on UNIX" good for knowing unix kernal?
From: Daniel Rall <[EMAIL PROTECTED]>
Date: Wed, 20 Dec 2000 23:03:39 GMT
Josef Moellers <[EMAIL PROTECTED]> writes:
> Carfield Yim wrote:
> >
> > From many classic review, the book "Lions' Commentary on UNIX 6th
> > edition : with source code " is the most excellent point of learn unix
> > system. So I borrow it from my library, and then I find out that it is
> > the source code with comment, as it state, but nothing more. Seen to me
> > that it is a bit harder to read because I am a java programmer. Only
> > learn C, ASM and Unix programming at college, with really less
> > experience of these stuff. Do this book still suitable for me? or is
> > there are better choice to learn more about Unix kernal?
>
> Although it is a tad outdated, yes, it is a good introduction to UN*X
> kernel internals. OTOH I have also seen a book much like the Lion's,
> based on Linux: "Linux Core Kernel Commentary" by Scott Maxwell
> (CoriolisOpen Press, ISBN 1-57610-469-9). I have inherited the book from
> a colleague who has left the department but, so far, I have not looked
> through it, so I can't judge whether it is of any use.
>
> Of course, Joe Humrickhouse's recommendations are good books, too.
The "Linux Core Kernel Commentary" is interesting, but already sorely
out of date.
Daniel Rall
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: IEEE standards
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Dec 2000 23:25:05 GMT
On Wed, 20 Dec 2000 22:23:22 GMT, HomerWelch <[EMAIL PROTECTED]> wrote:
>Matthew Palmer wrote:
>>
>> Bart De Schuymer is of the opinion:
>> >I've been looking at the IEEE homepage (www.ieee.com).
>> >I would like to read the standard called:
>> >IEEE 802.1 Spanning-Tree Protocol
>> >but it seems I have to pay to read a standard ??
>>
>> Yup - it's how IEEE recoups the money spent in actually producing the
>> standard. The alternative is a patent, I guess. I know which one I prefer.
>>
>
>I doubt whether it is patentable, but it is copyrighted. I
>remember reading a magazine article by a guy who was on the
>committee to standardize the C Programming Language. He
>wanted a copy of the released standard. IEEE wouldn't give
>him one. He had to pay for it. So much for volunteering on
>IEEE committees.
All that means is that as an organization, they they don't have a formal
process for giving away a copy. :)
That shouldn't stop an individual who works for them from doing so.
------------------------------
From: [EMAIL PROTECTED]
Subject: ip_masq_ftp.c
Date: Wed, 20 Dec 2000 23:53:10 GMT
I've recently found a (very) small bug in the IP
MASQ FTP module, and I've already gone ahead and
changed the code on my machine to fix it.
However, I cannot find out who to send this
information to so it can be worked into the
kernel!
Anyone know? If anyone else wants the info, feel
free to email me.
Thanks!
Pat
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: ip_masq_ftp.c
Date: Wed, 20 Dec 2000 23:53:08 GMT
I've recently found a (very) small bug in the IP
MASQ FTP module, and I've already gone ahead and
changed the code on my machine to fix it.
However, I cannot find out who to send this
information to so it can be worked into the
kernel!
Anyone know? If anyone else wants the info, feel
free to email me.
Thanks!
Pat
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Petric Frank <[EMAIL PROTECTED]>
Subject: Char device drivers and mknod
Date: Thu, 21 Dec 2000 00:56:19 +0100
Hello,
i am actually designing a character device driver (under kernel 2.2.17).
Instead of hardcoding the major device number in the file i decided to
let the linux kernel to assign me one dynamically. This is working fine.
Next i have to create the device node in /dev. All papers i've seen are
suggesting using the mknod command. This assumes you know the major
device number (either hardcoded or by scanning /proc/devices). This
requires an additional action if the driver is loaded automatically
(when specified in modules.conf) and the major device number is assigned
by the kernel automatically.
Isn't there a possibility to create this device node in /dev at loading
time by the character device driver himself ?
Thinking about a 'mknod' in the init_module function of the device
driver. Is such a thing possible ?
If yes, how it have to be coded ?
regards
Petric
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: semaphore problem
Date: Wed, 20 Dec 2000 16:16:56 -0800
Marty wrote:
> I am concurrently using semaphore in C for doing synchronization.
> Though it is non-blocking, I found that my call to sem_post sometimes
> costs several tens to hundred of milliseconds to return.
> That lot of time will be very critical to my program.
> Can anyone explain to me what 's happening ??? and how can make it
> return immediately ?
If your code is time critical, you must inform the scheduler of this.
Otherwise, it will feel free to schedule other processes.
DS
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Thu, 21 Dec 2000 00:23:23 GMT
"Aaron R. Kulkis" wrote:
>
> jtnews wrote:
> >
> > If I reverse engineer the camera protocol through the USB interface,
> > develop a Linux driver, distribute the driver under the GPL
> > over the Internet, can I be sued by Intel for violating their
> > intellectual property?
> >
>
> NOPE!
>
Unfortunately, the correct answer is YEP. You might win, Intel might
loose, but in the meantime, who has money to pay for lawyers? I would
suggest contacting Intel and clearing it with them first. Otherwise post
the code as "anonymous coward" somewhere from a cybercafe.
> > Kasper Dupont wrote:
> > >
> > > jtnews wrote:
> > > >
> > > > The Intel Easy PC camera is not supported in Linux!
> > > > You can't even write a driver for it!
> > > >
> > > > I got it as a "free" add-on with my new Dell Dimension
> > > > L600cx, but now it seems I made the wrong choice!
> > > >
> > > > Why does a $40 cheapo camera have to be proprietary for
> > > > Intel? I thought Intel made all their money because they make
> > > > huge volumes of flash memory chips over their competitors.
> > > >
> > > > I better choose the Lexmark color printer as a free add on next
> > > > time!
> > > >
> > >
> > > Of course it is posible to write a driver for that
> > > camera, but you would have to reverse engineer the
> > > protocols.
> > >
> > > Depending on how it is connected you could hook in
> > > a piece of hardware or software to watch the
> > > communication.
> > >
> > > I don't understand Intel's policy, a Linux driver
> > > would allow more people to use the camera and then
> > > they could expect to sell more cameras. But
> > > perhaps they have some secret agreement with MS.
> > >
> > > --
> > > Kasper Dupont
>
> --
> Aaron R. Kulkis
> Unix Systems Engineer
> DNRC Minister of all I survey
> ICQ # 3056642
>
> H: "Having found not one single carbon monoxide leak on the entire
> premises, it is my belief, and Willard concurs, that the reason
> you folks feel listless and disoriented is simply because
> you are lazy, stupid people"
>
> I: Loren Petrich's 2-week stubborn refusal to respond to the
> challenge to describe even one philosophical difference
> between himself and the communists demonstrates that, in fact,
> Loren Petrich is a COMMUNIST ***hole
>
> J: Other knee_jerk reactionaries: billh, david casey, redc1c4,
> The retarded sisters: Raunchy (rauni) and Anencephielle (Enielle),
> also known as old hags who've hit the wall....
>
> A: The wise man is mocked by fools.
>
> B: Jet Silverman plays the fool and spews out nonsense as a
> method of sidetracking discussions which are headed in a
> direction that she doesn't like.
>
> C: Jet Silverman claims to have killfiled me.
>
> D: Jet Silverman now follows me from newgroup to newsgroup
> ...despite (C) above.
>
> E: Jet is not worthy of the time to compose a response until
> her behavior improves.
>
> F: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
> adultery while concurrently committing adultery with Tammy Hahn.
>
> G: Knackos...you're a retard.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: how to use "pthread_rwlock_t" in linux?
Date: Wed, 20 Dec 2000 16:26:52 -0800
Victor wrote:
>
> I want to use Process_shared "pthread_rwlock_t" in my program.
>
> But it seems that my Linux(Redhat 6.1) doesn't support it and always report
> compiling error "aggregate `struct pthread_rwlock_t rw_lock' has incomplete
> type and cannot be initialized".
>
> I found its definition in the "/usr/include/bits/pthreadtypes.h", but it
> fellows
> a switch "__USE_UNIX98". Maybe it was not opened yet.
>
> How can I use it? Need I re-compile my Linux and how to open
> "__USE_UNIX98"?
Compile with -D_XOPEN_SOURCE=500
DS
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Char device drivers and mknod
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Dec 2000 00:52:00 GMT
On Thu, 21 Dec 2000 00:56:19 +0100, Petric Frank <[EMAIL PROTECTED]> wrote:
>Isn't there a possibility to create this device node in /dev at loading
>time by the character device driver himself ?
Yes! You need to have a kernel which supports something called devfs: a virtual
/dev filesystem exported by the kernel, similar to /proc. It provides a
solution to the problem of dynamic device numbers, as well as to the problems
of disk space wasted by /dev hierarchies that have much more entries than
the list of devices actually available, and the problems of access speed;
having to hit a real filesystem just to determine what major and minor number
to hook into.
>Thinking about a 'mknod' in the init_module function of the device
>driver. Is such a thing possible ?
>If yes, how it have to be coded ?
It's possible, but there must be a reason why it's a bad idea, because you
don't see it done. :)
------------------------------
** 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
******************************
