Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[H. Peter Anvin]

"Albert D. Cahalan" wrote:
> 
> H. Peter Anvin writes:
> 
> > This means you don't have to configure two levels (scancodes ->
> > keycodes and keycodes -> keymap); since currently the keycodes are
> > keyboard-specific anyway there is no benefit to the two levels.
> 
> The medium-raw level ought to be what the X11R6 protocol uses.
> Then the keyboard-specific stuff can be removed from XFree86,
> and there would be one less mapping to configure.
> 

Uhm, doesn't work that way.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ext2 Directory Index - File Structure

[Andreas Dilger]

Daniel, you write (re indexed directories):
> Superblock Feature Flag
> ---
> 
> This is now incorporated.  I use the following code:
> 
>   if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
>   {
>   lock_kernel();
>   ext2_update_dynamic_rev(sb);
>   EXT2_SET_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX);
>   unlock_kernel();
>   ext2_write_super(sb);
>   }
>   new->u.ext2_i.i_flags |= EXT2_INDEX_FL;

Why lock_kernel() calls and not lock_super()?  I would _think_ that
file creation within the VFS was already protected with BKL, but you
need to do lock_super(), because lock_kernel() can be dropped on
context switch.  A typo in the email maybe?

> It looks like there is a common factor in there that should be used
> throughout the ext2 code.

Yes, may be worthwhile to have a little helper function do this.

> This is only done on the deferred-creation path since the other path
> will be gone by beta time.

Yes, it only makes sense to do this at initial dx root creation.

> Delete Performance
> --
> 
> As we both noticed, delete performance for rm -rf is running
> considerably behind create performance by a factor of 4 or so - worse,
> it's running behind non-indexed Ext2 :-O 
> 
> There is no valid reason for this in the index code.  The indexed delete
> dirties the same things as a non-indexed delete, so it's not clear to me
> why we see a lot of extra disk activity with the indexed code. 

Possibilities:
- extra cache footprint for code (unlikely cause)
- extra block reads because of index blocks
- 

> Redundant Existence Test
> 
> 
> The inner loop of add_ext2_entry has traditionally included a test for
> an existing entry with the same name as the new entry, in which case an
> error exit is taken:
> 
>   err = -EEXIST;
>   if (ext2_match (namelen, name, de))
>   goto err_out;
> 
> This test is entirely redundant as can be seen from this code snippet
> from fs/namei.c, open_namei:
> 
> 980 dentry = lookup_hash(&nd->last, nd->dentry);
> [...]
> 989 /* Negative dentry, just create the file */
> 990 if (!dentry->d_inode) {
> 991 error = vfs_create(dir->d_inode, dentry, mode);
> [...]
> 1000goto ok;
> 1001 }
> 1002 
> 1003 /*
> 1004  * It already exists.
> 1005  */
> 
> There is always an explicit search for the entry before creating it
> (except in the case where we find a deleted entry in the dcache - then
> the search can be safely skipped)  Thus, ext2's create never gets called
> when the name already exists.  Worse, the ext2 existence test is not
> reliable.  If there is a hole in the directory big enough for the new
> entry then add_ext2_entry will stop there and not check the rest of 
> the directory.   So the test in add_ext2_entry adds no extra protection,
> except perhaps helping verify that the code is correct.  In this case,
> an assertion would capture the intent better.  On the other hand, it
> does cost a lot of CPU cycles. 

Possibly it is a holdout from (or extra check for) some sort of locking
race condition?  ISTR that the dentry cache _should_ protect us from a
dirent being created twice (that would also corrupt the dentry cache).

However, if it _was_ some sort of race avoidance, the existence check
_would_ be enough.  Reasoning is that if we had two processes trying
to create the same dirent then one of them would find "the spot" big
enough to hold the new entry first, and the second process would _have_
to pass this spot in order to find another place to put the dentry
(assuming no other dentry was deleted in the meantime).  The check
would be equally valid (if it is needed at all, mind you) in the index
code because we would always search the same hash bucket to find the
new home of the dentry.  In fact, in the indexed code we would be much
more likely to find duplicate dentries because the hashing would always
place the duplicate dentries into the same hash bucket.

> With the directory index it becomes attractive to combine the existence
> test with the entry creation and this would come almost for free: after
> a suitable place has been found for the new entry the rest of the block
> has to be searched for an entry of the same name, and if the name's hash
> value continues in the next block(s) those blocks have to be checked
> too, the latter test being needed very infrequently.  So in exchange for
> 20-30 new lines of code we get a significant performance boost.   A
> similar argument applies to unlink.  The only difficulty is, there is
> currently no internal interface to support this, so I'll just note that
> it's possible.

Yes, I have thought about this as well.  If it is possible (I'm not sure
how, maybe a hashed per-super cache?) you could keep a pointer to the first
free entry in a directory, along with the dentry

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Albert D. Cahalan]

H. Peter Anvin writes:

> This means you don't have to configure two levels (scancodes ->
> keycodes and keycodes -> keymap); since currently the keycodes are
> keyboard-specific anyway there is no benefit to the two levels.

The medium-raw level ought to be what the X11R6 protocol uses.
Then the keyboard-specific stuff can be removed from XFree86,
and there would be one less mapping to configure.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Data-corruption bug in VIA chipsets

[Eric W. Biederman]

Alan Cox <[EMAIL PROTECTED]> writes:

> > Here might be one of the resons for the trouble with VIA chipsets:
> > 
> > http://www.theregister.co.uk/content/3/18267.html
> > 
> > Some DMA error corrupting data, sounds like a really nasty bug. The
> > information is minimal on that page.
> 
> What annoys me is that we've known about the problem for _ages_. If you look
> the 2.4 kernel has experimental workarounds for this problem. VIA never once
> even returned an email to say 'we are looking into this'. Instead people sat
> there flashing multiple BIOS images and seeing what made the difference.
> 
> > I just bought one of these babies and I should probably return it
> > directly. I have seven days to return it and get my money back. I have not
> > even opened the box yet.
> 
> Disabling pci master read caching is likely to reduce the performance of the 
> board.
> 
> > They seems to think they can correct it by some bios updates, but who
> > knows what that fix might be. Maybe they turn of DMA alltogether
> > (hopefully not).
> 
> The -ac kernel does this on the KT7 series boards which seemed the worst
> affected. 
> 
> Hopefully now someone in VIA will have the decency to tell the community 
> how to detect setups that need a BIOS upgrade so we can warn them before the
> chipset bug turns there file systems into sludge.

I wonder if someone at VIA even knows what is going on.  In working
with linuxBIOS Ron Minnich was worked with VIA to get it up on some of
their chipsets. He ran into a few cases where his code wouldn't work,
he'd show it to the engineers at VIA and they also wouldn't have a
clue why his code was failing.  And that it looked like only Award
knew how the chipset really worked.  This is northbridge code not
southbridge code so it may be an entirely different ball game but...

Anyway Alan you might want to bounce off Ron.  He might have a clue
how to help you get get VIA's attention...

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Files not linking/replacing.

[Jeff Garzik]

"Eric W. Biederman" wrote:
> Normally /usr/src/linux on a redhat system contains a kernel with a
> known good set of kernel headers.  /usr/include/linux and
> /usr/include/asm are symlinks that point into the known good kernel
> headers.  It looks like you removed your known good 2.2.14 known good
> kernel headers, or the symlinks to them.

Modern glibc systems have their own copies of headers for
/usr/include/{asm,linux}, and those locations should not be pointing to
kernel space...

-- 
Jeff Garzik   | "Give a man a fish, and he eats for a day. Teach a
Building 1024 |  man to fish, and a US Navy submarine will make sure
MandrakeSoft  |  he's never hungry again." -- Chris Neufeld
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in EZ-Drive remapping code (ide.c)

[Albert D. Cahalan]

Andries.Brouwer writes:

> What one wants is to remap access to sector 0 to sector 1,
> and leave all other sectors alone. Thus, if someone asks
> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.

No, because then you can't write to the real first sector.
Assuming translation is good, 1 0 2 3 4 is a better order.
Then "dd if=/dev/zero of=/dev/hda bs=1k count=999" will get
rid of all this crap. Otherwise, killing it is difficult.

> So yes, the problem is known, but I do not see a clean solution,
> unless the solution is to rip out all this EZ drive nonsense.

Linux should still be able to read the partition table.
The translation can go.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Files not linking/replacing.

[Eric W. Biederman]

Patrick Shirkey <[EMAIL PROTECTED]> writes:

> Hi.
> 
> I hope this is the correct place to report to.
> 
> I have installed kernel 2.4.3 but my system is having a few problems
> compiling things. Not all software is having problems it just seems to
> be the most important ones. like mozilla or alsa-driver, I would like to
> try others to test this but it's kind of frustrating and time consuming.
> 
> I installed the kernel in /usr/local/src because the install file says
> not to do it in /usr/src anymore because of kernel header dependencies.
> 
> The system is booting and obviously I can use the net but the main
> problem seems toi be that a lot of important files have not benn updated
> or relinked to the right dir.
> 
> I installed the new kernel onto Mandrake 7.0 which ships with 2.2.14.
> 
> I'm using a PIII
> and have verified that my software is upto the minimal requirements
> according to the /documentation/changes file. All except mkinitrd which
> I can't install becuse I have an old version of rpm and cannot find the
> tar.gz file on the net.
> 
> An example of what my system is doing:
> 
> I compile the latest stable mozilla.
> First off it complains that /usr/include/bits/errno.h doesn't point to
> the right place.
> So I remove it and link /usr/local/src/linux/include/asm/errno.h to
> /usr/include/bits/errno.h and recompile.
> It gets past that point then complains about /usr/include/bits/socket.h
> so I repeat the process.
> 
> The futility of doing this occurs to me. So I write in to this list in
> the hope that someone may know what I have done wrong or can offer me
> some help to debug.
> 
> Any ideas?

Normally /usr/src/linux on a redhat system contains a kernel with a
known good set of kernel headers.  /usr/include/linux and 
/usr/include/asm are symlinks that point into the known good kernel
headers.  It looks like you removed your known good 2.2.14 known good
kernel headers, or the symlinks to them.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Eric W. Biederman]

"H. Peter Anvin" <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> of
> linux.dev.kernel, you write:
> > On Fri, Apr 13, 2001 at 03:02:19PM +0200, Jan Dvorak wrote:
> > 
> > > i recently met with a new (Unisys) keyboard, which have (among 'normal'
> > > windows keys) 3 more keys on top of arrows, labeled by pictures as
> > > halfsun, halfmoon, and power switch. Following patch adds 'support' for them
> 
> > 
> > > +#define E0_MSPOWER   128
> > > +#define E0_MSHALFMOON129
> > > +#define E0_MSHALFSUN 130
> > 
> > No, these codes cannot be larger than 127 today.
> > You can use the utility setkeycodes to assign keycodes to these keys.
> > 
> > [One of the things for 2.5 is 15- or 31-bit keycodes.
> > The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]

If we can try to keycodes in 8-bits it would be nice.  The difficulty
is that X cannot handle more than 8-bits without telling it you have
multiple keyboards.  The keycode (at least in X) is exported to
X applications.  This is certainly something to coordinate with the
XFree folks about.  If you really need more then 8-bits. 

> By the way, it's for things like this that I suggested using a keycode
> which can be algorithmically mapped from scan codes once we go to a
> larger keycode space.  For example, if your key generates E0 63, it
> would *always* have keycode 0x00E3 (227).  For PC keyboards, I believe
> the following mapping algorithm should work onto a 15-bit keycode
> space (all numbers in hex):
> 
>   xx -> 00xx
>   E0 xx  -> 00xx | 0080
>   E1 xx yy   -> yyxx
> 
> (I can't remember which one of the E1 bytes that has the make/break
> bit, it should obviously go at the top.)
> 
> This assumes that there isn't a null byte form of E1, in which case it
> really can't be made to fit, but I don't think so.
> 
> This means you don't have to configure two levels (scancodes ->
> keycodes and keycodes -> keymap); since currently the keycodes are
> keyboard-specific anyway there is no benefit to the two levels.

Hmm.  I'd love to see how a mapping that takes everything into account
works.  In a classic pc compatible keyboard E1 is only used for the
Pause key.  And you need to special case Print-Screen/SysRq
Pause/Break, anyway to collapse then into one keycode to really get
your keycodes correct.   So I'm not certain that after special case
the two totally hosed keys if you need to handle more than the E0
prefix in which case you really only need one more bit.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.1, wiuth experimental fast mode

[Eric S. Raymond]

Albert D. Cahalan <[EMAIL PROTECTED]>:
> > * Added fast-mode command to suppress side-effect computation 
> >   on slow machines.
> 
> You could put the computation in a low-priority thread, so that it
> still gets done but doesn't mess up responsiveness.

Yes, I've thought about doing exactly this.  It's a huge nasty can of
worms, though, because it would mean that the side effects from
setting a symbol could manifest some unpredictable amount of time
after they were triggered.  And what if the user has taken actions
that set variables during that window?  What if the side-effects
conflict?

Clearly, that way lies madness.  I think my effort would be better spent
speed-tuning the deduction algorithms so fastmode can go away.  
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.1, wiuth experimental fast mode

[Albert D. Cahalan]

>   * Added fast-mode command to suppress side-effect computation 
> on slow machines.

You could put the computation in a low-priority thread, so that it
still gets done but doesn't mess up responsiveness.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.2 is available

[Eric S. Raymond]

Anton Altaparmakov <[EMAIL PROTECTED]>:
> When .config is missing and error is emitted when running make menuconfig 
> (or any other I guess) for the first time. Should this be the case? It's 
> ignored so ok but still would be nice not to have an error.

Yes, that is the expected behavior.  It will go away eventually; this is
part of the transition while the old .config format is still valid.
 
> In ttyconfig: If type 'a' then enter then 'a' then enter then 'v' then 
> enter it crashes out... Might be specific to where you are at the time. 
> Sorry don't remember.

Just the (undocumented) v command would have done it.  It was expecting a 
numeric debug level argument.  I've fixed it to treat "v' alone as a command
to increment the debug level.
 
> Good performance going up/down in menuconfig now. Even on my Pentium 133S! 
> Excellent work! (fastmode on)

We aim to please...
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction.  Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
-- Colin Greenwood, in the study "Firearms Control", 1972
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lilo + raid + kernel-2.4.x failure to boot

[Linas Vepstas]

Hi,

another zinger that I am sending to LKML because I don't know where else to send it ...

I've discovered a deadly combination of kernel & lilo (and raid).  This may be a pure
lilo bug, but I assume that the kernel+raid aids & abets the problem...:


I am running kernel-2.4.x.  Two ide hard drives, with partitions 1,5,6,7,8 in use.
The partitions on the two drives are mirrored using RAID-1 to create /dev/md1, 
/dev/md5,
/dev/md6, etc.  The root fs is on /dev/md1.  Thus, lilo.conf looks like:


boot=/dev/md1
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linux

image=/boot/vmlinuz-2.4.2
label=linux
read-only
root=/dev/md1

For nearly a year, this combo has worked just fine (running 2.3.99 back then).   

Just fine, that is, using the redhat-6.2 rpm for LILO, i.e. version 
lilo-0.21-15.i386.rpm  which reports itself to be: 

% /sbin/lilo -V
LILO version 21

Recently, this machine went over to debian-unstable from redhat: 

% dpkg -s lilo
Package: lilo
Status: install ok installed
Priority: important
Section: base
Installed-Size: 271
Maintainer: Russell Coker <[EMAIL PROTECTED]>
Version: 1:21.7-3
Depends: libc6 (>= 2.2.1-2), debconf (>= 0.2.26), logrotate

The debian version of lilo writes a boot sector that hangs hard for the above
kernel+raid+lilo.conf configuration: specifically: 

LIL- after a reboot.   Needless to say, recovery was painful.  But I was able to 
verify
that the redhat lilo rpm always functioned correctly, and the debian-unstable dpkg 
always
hung in this way.  Although at one point, during my twisting & turning, I got the 
debian lilo
to get to only LI  before hanging.  I have no idea of what I did different to get to 
that as
opposed to LIL- 


BTW, I noticed that oddly, every time I ran lilo, and then ran lilo -q -v -v, it 
reported
different sector numbers for the kernel images.  This freaked me out at first, but I 
came to
accept it as normal: doesn't affect bootability.  But is this really w.a.d?  (I was
assuming, appearently erroneously, that lilo -q -v -v was reporting the physical 
location
of the kernel image on the disk; but since the numbers bounce around, that can't be 
right.
Or is this just weird bios head/cyl/sect math flakiness?)


--linas

 




 PGP signature

Re: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Is this a pathological case because of the way fsck does business, or does the RAID 
>re-sync affect any disk-bound process that severely?

i gues the seeks are the problem. fsck will quite heavyly reposition, so does
the rebuild, most likely on different ends of the disk.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <01041521302600.15046@tabby> you wrote:
>>a) stop rebuild until fsck is fixed

> And let fsck read bad data because the raid doesn't yet recognize the correct
> one

a degraded raid will not deliver broken data. and even if it does, one more
reason not to check a degraded raid.

> There is nothing to fix in fsck. It should NOT know about the low level
> block storage devices. If it does, then fsck for EACH filesystem will
> have to know about ALL different raid hardware/software implementations.

fsck does not neet to be changed, yoi can have a shell script loop and check
the raid state before caling the fsck.

>>b) wait with fsck until rebuild is fixed

> Depends on your definition of "fixed"

fixed as in rebuild, thats what we where tlking about, no?

. The most I can see to fix is
> reduce the amount of continued update in favor of updating those blocks
> being read (by fsck or anything else). This really ought to be a runtime
> configuration option. If it is set to 0, then no automatic repair would
> be done.

yes would be a nice feature if rebuild can be made to only to io which is
required by the kernel anyway. since fsck will reach a lot of meta data this
is a fairly good start for a slow rebuild.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer!

[Jamie Lokier]

Ben Greear wrote:
> > Note that jumping around the array thrashes no more cache than
> > traversing a tree (it touches the same number of elements).  I prefer
> > heap-ordered trees though because fixed size is always a bad idea.
> 
> With a tree, you will be allocating and de-allocating for every
> insert/delete right?

No, there is no memory allocation.

> On cache-coherency issues, wouldn't it be more likely to have a cache
> hit when you are accessing one contigious (ie the array) piece of
> memory?  A 4-k page will hold a lot of indexes!!

No, because when traversing an array-heap, you don't access contiguous
entries.  You might get one or two more cache hits near the root of the
heap.

> To get around the fixed size thing..could have
> the array grow itself when needed (and probably never shrink again).

You could to that, but then you'd have to deal with memory allocation
failures and memory deadlocks, making add_timer rather complicated.
It's not acceptable for add_timer to fail or require kmalloc().

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsck, raid reconstruction & bad bad 2.4.3

[Jonathan Lundell]

At 9:23 PM -0500 2001-04-15, Jesse Pollard wrote:
> >b) wait with fsck until rebuild is fixed
>
>Depends on your definition of "fixed". The most I can see to fix is
>reduce the amount of continued update in favor of updating those blocks
>being read (by fsck or anything else). This really ought to be a runtime
>configuration option. If it is set to 0, then no automatic repair would
>be done.

The original post was referring to RAID 1; there's no repair necessary at the RAID 
level to give fsck the correct data. Seems to me the basic problem here is that the 
RAID re-sync is supposed to be throttling back to allow other activity to run, but 
that in the case of fsck the other activity is still slower by a large factor 
(compared to no RAID re-sync).

Is this a pathological case because of the way fsck does business, or does the RAID 
re-sync affect any disk-bound process that severely?
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[Dax Kelson]

David Findlay said once upon a time (Tue, 17 Apr 2001):

> I am using the kernel IP Accounting in Linux to record the amount of data
> transfered via my Linux internet gateway from individual IP addresses. This
> currently requires me to set up an accounting rule for each IP address that I
> want to record accounting info for. If I had 200 machines to individually log
> this would require me to set 200 rules.

In 1999 I setup a Linux kernel 2.2 box to monitor traffic for about 2500
hosts.  I created two rules for each host (to monitor inbound and
outbound).  I had over 5000 total rules on a Pentium II 300 Mhz box.  I
wrote some perl glue so I could accounts on a per customer basis (each
customer had one or more IPs, not necessarily contiguous) and graph the
results in MRTG.

There was ZERO performance problems on the box.  The box is still
runningly happily today.  I don't there is a "problem" to fix.

Dax

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer!

[Ben Greear]

Jamie Lokier wrote:
> 
> george anzinger wrote:
> > Horst von Brand wrote:
> > >
> > > Ben Greear <[EMAIL PROTECTED]> said:
> > >
> > > [...]
> > >
> > > > Wouldn't a heap be a good data structure for a list of timers?  Insertion
> > > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > > front  It can be implemented in an array which should help cache
> > > > coherency and all those other things they talked about in school :)
> > >
> > > Insertion and deleting the first are both O(log N). Plus the array is fixed
> > > size (bad idea) and the jumping around in the array thrashes the caches.
> > > --
> > And your solution is?
> 
> Note that jumping around the array thrashes no more cache than
> traversing a tree (it touches the same number of elements).  I prefer
> heap-ordered trees though because fixed size is always a bad idea.

With a tree, you will be allocating and de-allocating for every
insert/delete right?  That seems like a reasonable performance
hit that an array-based approach might not have... 

On cache-coherency issues, wouldn't it be more likely to have a cache hit when you are
accessing one contigious (ie the array) piece of memory?  A 4-k page
will hold a lot of indexes!!

To get around the fixed size thing..could have
the array grow itself when needed (and probably never shrink again).
This would suck if you did it often, but I'm assuming that it would
quickly grow to needed size and then stabalize...

> 
> Insertion is O(1) if entries can be predicted to be near
> enough some place in the list, be that the beginning, the end, or some
> marked places in the middle.
> 
> By the way, the current timer implementation only appears to be O(1) if
> you ignore the overhead of having to do a check on every tick, and the
> extra processing on table rollover.  For random timer usage patterns,
> that overhead adds up to O(log n), the same as a heap.
> 
> However for skewed usage patterns (likely in the kernel), the current
> table method avoids the O(log n) sorting overhead because long-delay
> timers are often removed before percolating down to the smallest tables.
> It is possible to produce a general purpose heap which also has this
> property.
> 
> -- Jamie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsck, raid reconstruction & bad bad 2.4.3

[Jesse Pollard]

On Sun, 15 Apr 2001, Bernd Eckenfels wrote:
>In article <[EMAIL PROTECTED]> you wrote:
>>>(There is no config file to disable/alter this .. no work-around that I
>>>know of ..)
>
>> You can't be serious.  Go sit down and think about what's going on.
>
>Well, there are two potential solutions:
>
>a) stop rebuild until fsck is fixed

And let fsck read bad data because the raid doesn't yet recognize the correct
one

There is nothing to fix in fsck. It should NOT know about the low level
block storage devices. If it does, then fsck for EACH filesystem will
have to know about ALL different raid hardware/software implementations.

>b) wait with fsck until rebuild is fixed

Depends on your definition of "fixed". The most I can see to fix is
reduce the amount of continued update in favor of updating those blocks
being read (by fsck or anything else). This really ought to be a runtime
configuration option. If it is set to 0, then no automatic repair would
be done.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer!

[Ben Greear]

george anzinger wrote:
> 
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers?  Insertion
> > > is log(n) and finding the one with the least time is O(1), ie pop off the
> > > front  It can be implemented in an array which should help cache
> > > coherency and all those other things they talked about in school :)
> >
> > Insertion and deleting the first are both O(log N). Plus the array is fixed
> > size (bad idea) and the jumping around in the array thrashes the caches.

Jumping around an array can't be much worse than jumping around
a linked list, can it?

It does not have to be fixed length, though it wouldn't be log(n) to
grow the array, it can still be done...and once you reach maximal
size, you won't be growing it any more...

I had forgotten about the log(n) to delete, though log(n) is
still pretty good.  As others have suggested, it might be good
to have a linked list for very-soon-to-expire timers.  However,
they would have to be few enough that your linear insert was
not worse than a log(n) instert and a log(n) delete...

> > --
> And your solution is?


> 
> George

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[Manfred Bartz]

David Findlay <[EMAIL PROTECTED]> writes:

> On Monday 16 April 2001 10:40, you wrote:

> > Perhaps I misunderstand what it is exactly you are trying to do,
> > but I would think that this could be done entirely in userland by
> > software that just adds rules for you instead of you having to do
> > it manually.
> 
> I suppose, but it would be so much easier if the kernel did it
> automatically. 

Yes, but by what criteria?  You want to log on a per host basis.
Someone else wants to log by service (www, ftp, mail, news), or
any number of other criteria.

> Having a rule to go through for each IP address to be logged would
> be slower than implementing one rule that would log all of
> them. Doing this in the kernel would improve preformance.

If there really is a performance issue with a few hundred rules, then
it can be overcome by grouping rules in separate custom chains.  F.e.
if you have 1024 rules create 32 custom chains with 32 rules each.
Then have 32 rules in your main table which jump to the appropriate
custom chain --> maximum rules traversed by each packet = 64.

There is another issue with logging in general:

*COUNTERS MUST NOT BE RESETABLE!!!*

Resetable counters guarantee that no two programs can co-exists if
they happen to reset the same counters.

All logging counters should be implemented with 32bit or 64bit
unsigned integers.  Any software using correct unsigned integer
arithmetic can then simply subtract a previous value from the current
value to get the difference.  This works reliably across counter
wrap-arounds.  There is absolutely *no need for reset* !

-- 
Manfred Bartz
---
ipchainsLogAnalyzer, NetCalc, whois at: 
 NEW: 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[swds . mlowe]

No, one rule would be MUCH faster. What's do you think would be faster of the two:

if ((ipaddr>=3232235521)&&(ipaddr<=3232235774))
return 1;
else
return 0;

or

for (a=0;a<(3232235774-3232235521);a++)
if (ipaddr==a)
return 1;
return 0;

Obviously it compares the 192.168.0.1 - 192.168.0.255 range, but I think we both
know which one will be faster. Not to mention countless other redundant checks
will be added in on both, but on the second one the time of the checks is
multiplied by the number of times you have too loop.

But, I'm just a newbie so I don't really know :P Just taking up bandwith :(

L8ers,
Matt

"Mike A. Harris" wrote:

> On Tue, 17 Apr 2001, David Findlay wrote:
>
> >> Perhaps I misunderstand what it is exactly you are trying to do,
> >> but I would think that this could be done entirely in userland by
> >> software that just adds rules for you instead of you having to do
> >> it manually.
> >
> >I suppose, but it would be so much easier if the kernel did it automatically.
> >Having a rule to go through for each IP address to be logged would be slower
> >than implementing one rule that would log all of them. Doing this in the
> >kernel would improve preformance.
>
> I don't think it would, but then only benchmarking it both ways
> would know for sure.  Even with incredibly large rulesets,
> ipchains &&/|| netfilter works admirably well.  Rusty?
>
> --
> Mike A. Harris  -  Linux advocate  -  Free Software advocate
>   This message is copyright 2001, all rights reserved.
>   Views expressed are my own, not necessarily shared by my employer.
> --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

devfs weirdnesses in 2.4.3 (-ac5)

[Andreas Ferber]

Hi,

I recently noticed some weird behaviour in devfs.

- some symlinks not showing up in directory listings, although they
  are surely existing. I noticed this with symlinks created by devfsd
  for IDE devices (/dev/hda{9,10,11} showing in normal ls, other hda
  entries are hidden). If I explicitly give the name of one of the
  hidden symlinks (for example "ls -l /dev/hda"), it shows the
  symlink, and I can see that the symlink is absolutely correct (as
  far as ls output goes...). Sadly I'm not able to reproduce this
  behaviour now, but read on.
- same thing with ippp*. Some ippp symlinks are now hidden. If I do a
  "rm ippp*" in /dev, the visible symlinks are removed, and
  the hidden entries become visible. With a second "rm ippp*", the
  originally hidden symlinks are also removed.

The kernel version used is 2.4.3-ac5, but as the ac patches only
change one line in devfs code, related to devfsd notification, I think
the problem should exist in non-ac kernel also.

Andreas
-- 
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
-- Kirk, "The Squire of Gothos", stardate 2124.5

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Files not linking/replacing.

[Patrick Shirkey]

Hi.

I hope this is the correct place to report to.

I have installed kernel 2.4.3 but my system is having a few problems
compiling things. Not all software is having problems it just seems to
be the most important ones. like mozilla or alsa-driver, I would like to
try others to test this but it's kind of frustrating and time consuming.

I installed the kernel in /usr/local/src because the install file says
not to do it in /usr/src anymore because of kernel header dependencies.

The system is booting and obviously I can use the net but the main
problem seems toi be that a lot of important files have not benn updated
or relinked to the right dir.

I installed the new kernel onto Mandrake 7.0 which ships with 2.2.14.

I'm using a PIII
and have verified that my software is upto the minimal requirements
according to the /documentation/changes file. All except mkinitrd which
I can't install becuse I have an old version of rpm and cannot find the
tar.gz file on the net.

An example of what my system is doing:

I compile the latest stable mozilla.
First off it complains that /usr/include/bits/errno.h doesn't point to
the right place.
So I remove it and link /usr/local/src/linux/include/asm/errno.h to
/usr/include/bits/errno.h and recompile.
It gets past that point then complains about /usr/include/bits/socket.h
so I repeat the process.

The futility of doing this occurs to me. So I write in to this list in
the hope that someone may know what I have done wrong or can offer me
some help to debug.

Any ideas?

Patrick Shirkey.

-- 
Boost Hardware.
Importing Korean Computer Hardware to New Zealand.

Http://www.boosthardware.com for latest stock and prices.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't free the ramdisk (initrd, pivot_root)

[Scott Murray]

On 15 Apr 2001, H. Peter Anvin wrote:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Amit D Chaudhary <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > On the same topic, I have not found any change in free memory
> > reported before and after the ioctl call. Though umount /initrd does
> > free around 2 MB.
> >
>
> With Scott's patch applied, I get substantially better performance on
> low-memory machines, so I'm guessing it's doing its job.  Also, just
> umount /initrd for me made it still possible to mount it, so it
> clearly did not go away.

I can't take credit for the patch, just the (mis)fortune of having to
track down its existence. :)  All mentions of it in Alan's older change
logs have it uncredited, so I'm unsure if he or someone else fixed it.

Scott


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ext2 Directory Index - File Structure

[Andreas Dilger]

Daniel, you write:
> Andreas, you wrote:
> > We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> > because the on-disk layout is 100% compatible with older kernels, so
> > no reason to force read-only for those systems.  I'm guessing Ted had
> > put RO_COMPAT_BTREE_DIR in there in anticipation, but it was never used.
> 
> By the way, did you mean:
> 
>   #define EXT2_FEATURE_COMPAT_DIR_INDEX 0x0002
> 
> since there is only one other COMPAT feature currently defined?

Quick note - you need to use 0x0008 or higher (Ted is the authority on
this).  The kernel ext2_fs.h is out of date compared to the one in e2fsprogs.
The EXT3_FEATURE_COMPAT_HAS_JOURNAL and EXT2_FEATURE_COMPAT_IMAGIC_INODES
is missing from the kernel header.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sun, 15 Apr 2001, Arthur Pedyczak wrote:

> On Sat, 14 Apr 2001, Jeff Garzik wrote:
>
> > Can you try 2.4.4-pre3?
> > ftp://ftp.us.kernel.org/pub/linux/kernel/testing/
> >


...the same thing happens in 2.4.3...



> I am testing loop behaviour in 2.4.3 and 3.4.4p3. I have noticed something
> disturbing:
>
> I can mount the same file on the same mountpoint more than once. If I
> mount a file twice (same file on the same mount point)
> both mounts (identical) show when I do df or cat /proc/mounts. If I issue
> unmount (once), both mounts disappear from df output, but one of them
> remains in /proc/mounts. If I issue umount again, the second mount
> disappers from cat /proc/mounts output, but the module 'loop' shows as
> busy and cannot be removed even though there are no more loop mounts.
> lsmod shows loop being used by 1 process.
> If I repeat this whole procedure again, loop will be used by 2 processess
> in the end. I guess something is wrong here.
> This experiment has been done under 2.4.4pre3. I will try the same under
> 2.4.3.
>
> cheers,
> Arthur
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't free the ramdisk (initrd, pivot_root)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Amit D Chaudhary <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> On the same topic, I have not found any change in free memory
> reported before and after the ioctl call. Though umount /initrd does
> free around 2 MB.
> 

With Scott's patch applied, I get substantially better performance on
low-memory machines, so I'm guessing it's doing its job.  Also, just
umount /initrd for me made it still possible to mount it, so it
clearly did not go away.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't free the ramdisk (initrd, pivot_root)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Scott Murray <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Indeed it is.  This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):
> 

This did the trick.  I bounced the patch to Linus, too.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[Matti Aarnio]

On Tue, Apr 17, 2001 at 08:46:12AM +1000, David Findlay wrote:
> On Monday 16 April 2001 10:40, you wrote:
> > Perhaps I misunderstand what it is exactly you are trying to do,
> > but I would think that this could be done entirely in userland by
> > software that just adds rules for you instead of you having to do
> > it manually.
> 
> I suppose, but it would be so much easier if the kernel did it automatically. 
> Having a rule to go through for each IP address to be logged would be slower 
> than implementing one rule that would log all of them. Doing this in the 
> kernel would improve preformance.

Perhaps "netflow" would be an answer ?

It is cisco idea for collecting accounting data for
network flows.   System has a cache of flows for
which it collects data, and once the cache overflows
(or flow times out), data is sent to designated flow
collection server(s).

http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm

> David

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>>(There is no config file to disable/alter this .. no work-around that I
>>know of ..)

> You can't be serious.  Go sit down and think about what's going on.

Well, there are two potential solutions:

a) stop rebuild until fsck is fixed
b) wait with fsck until rebuild is fixed

Both of them are valid. The first one is valid in a scenario where you want to
decrease downtimes in favor of insecure operation/or multiple redundancy

The second one is good if you prefer data consitency over small down times. It
might actually speed up the bootup process, one has to measure this.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sat, 14 Apr 2001, Jeff Garzik wrote:

> Can you try 2.4.4-pre3?
> ftp://ftp.us.kernel.org/pub/linux/kernel/testing/
>
I am testing loop behaviour in 2.4.3 and 3.4.4p3. I have noticed something
disturbing:

I can mount the same file on the same mountpoint more than once. If I
mount a file twice (same file on the same mount point)
both mounts (identical) show when I do df or cat /proc/mounts. If I issue
unmount (once), both mounts disappear from df output, but one of them
remains in /proc/mounts. If I issue umount again, the second mount
disappers from cat /proc/mounts output, but the module 'loop' shows as
busy and cannot be removed even though there are no more loop mounts.
lsmod shows loop being used by 1 process.
If I repeat this whole procedure again, loop will be used by 2 processess
in the end. I guess something is wrong here.
This experiment has been done under 2.4.4pre3. I will try the same under
2.4.3.

cheers,
Arthur

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[Mike A. Harris]

On Tue, 17 Apr 2001, David Findlay wrote:

>> Perhaps I misunderstand what it is exactly you are trying to do,
>> but I would think that this could be done entirely in userland by
>> software that just adds rules for you instead of you having to do
>> it manually.
>
>I suppose, but it would be so much easier if the kernel did it automatically.
>Having a rule to go through for each IP address to be logged would be slower
>than implementing one rule that would log all of them. Doing this in the
>kernel would improve preformance.

I don't think it would, but then only benchmarking it both ways
would know for sure.  Even with incredibly large rulesets,
ipchains &&/|| netfilter works admirably well.  Rusty?


--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[David Findlay]

On Monday 16 April 2001 10:40, you wrote:
> Perhaps I misunderstand what it is exactly you are trying to do,
> but I would think that this could be done entirely in userland by
> software that just adds rules for you instead of you having to do
> it manually.

I suppose, but it would be so much easier if the kernel did it automatically. 
Having a rule to go through for each IP address to be logged would be slower 
than implementing one rule that would log all of them. Doing this in the 
kernel would improve preformance.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IP Acounting Idea for 2.5

[Mike A. Harris]

On Tue, 17 Apr 2001, David Findlay wrote:

>I am using the kernel IP Accounting in Linux to record the amount of data
>transfered via my Linux internet gateway from individual IP addresses. This
>currently requires me to set up an accounting rule for each IP address that I
>want to record accounting info for. If I had 200 machines to individually log
>this would require me to set 200 rules.
>
>In the 2.5 series of kernels, working towards 2.6, could you please make the
>IP Accounting so that I can set a single rule that will make it watch all IP
>traffic going from the local network, through the masquerading service to the
>internet, and log local IP Addresses using it? This would allow me to set 1
>rule, but have the information I want on a per IP address system.
>
>One other person I have talked to would like to see this too, and he
>basically says we need a software version of the Cisco IP Accounting
>server/router.
>
>Could you please add this to the next kernel? Please CC me your responses as
>I am not a member of the kernel mailing list. Thanks,

Perhaps I misunderstand what it is exactly you are trying to do,
but I would think that this could be done entirely in userland by
software that just adds rules for you instead of you having to do
it manually.

Just a thought.

--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--
There are two major products that come out of Berkeley: LSD and BSD.
We don't believe this to be a coincidence. -- Jeremy S. Anderson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: IP Acounting Idea for 2.5

[Michael Clark]

> In the 2.5 series of kernels, working towards 2.6, could you please make the
> IP Accounting so that I can set a single rule that will make it watch all IP
> traffic going from the local network, through the masquerading service to the
> internet, and log local IP Addresses using it? This would allow me to set 1
> rule, but have the information I want on a per IP address system.

You could try using a mature userspace traffic meter like 'NeTraMet' (uses
libpcap).

ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/

> One other person I have talked to would like to see this too, and he
> basically says we need a software version of the Cisco IP Accounting
> server/router.

NeTraMet can also account using Cisco Netflow accounting records.

> Could you please add this to the next kernel? Please CC me your responses as
> I am not a member of the kernel mailing list. Thanks,
>
> David
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Alan Cox]

> If you have the diffs ready then it would be great if you could do that. 
> (Did the maxbytes stuff enter the mainstream kernel yet? Are you going to 
> feed them together? Or will that be dropped for now?)

maxbytes got to Linus. The checks using it are not all there, but maxbytes
went in early to avoid fs differences being hard to maintain. I've fed him
bits of the fs checking this time. There is some negotiation to be done over
truncate yet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.2 is available

[Anton Altaparmakov]

At 19:33 15/04/2001, Eric S. Raymond wrote:
>The latest version is always available at http://www.tuxedo.org/~esr/cml2/
>Release 1.1.2: Sun Apr 15 14:26:07 EDT 2001
> * Synchronized with 2.4.4-pre3.
> * Screen flicker in menuconfig is gone.
> * KEY_HOME and KEY_END now go to top or bottom of menu.
> * Zack Weinberg's patch reorganizing the block devices menus.
>The screen flicker fix should also speed up general responsiveness.

Few comments:

When .config is missing and error is emitted when running make menuconfig 
(or any other I guess) for the first time. Should this be the case? It's 
ignored so ok but still would be nice not to have an error.

In ttyconfig: If type 'a' then enter then 'a' then enter then 'v' then 
enter it crashes out... Might be specific to where you are at the time. 
Sorry don't remember.

Good performance going up/down in menuconfig now. Even on my Pentium 133S! 
Excellent work! (fastmode on)

Best regards,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Anton Altaparmakov]

At 23:11 15/04/2001, Alan Cox wrote:
> > Can the numerous ntfs fixes in the -ac series be applied to the mainstream
> > kernel instead? Thanks.
>
>Want me to feed them to Linus or will you do it ?

If you have the diffs ready then it would be great if you could do that. 
(Did the maxbytes stuff enter the mainstream kernel yet? Are you going to 
feed them together? Or will that be dropped for now?)

Cheers,

 Anton

PS. If you are too busy let me know and I will do it as soon as I have my 
normal net connection back...


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.0 bug and snailspeed

[Anton Altaparmakov]

At 18:59 15/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <[EMAIL PROTECTED]>:
> > At 18:56 14/04/2001, Eric S. Raymond wrote:
> > >Anton Altaparmakov <[EMAIL PROTECTED]>:
> > > > I found a bug: In "Intel and compatible 80x86 processor options", 
> "Intel
> > > > and compatible 80x86 processor types" I press "y" on "Pentium Classic"
> > > > option and it activates Penitum-III as well as Pentium Classic 
> options at
> > > > the same time!?! Tried to play around switching to something else 
> and then
> > > > onto Pentium Classic again and it enabled Pentium Classic and Pentium
> > > > Pro/Celeron/Pentium II (NEW) this time! Something is very wrong here.
> > >
> > >Rules file bug, probably.  I'll investigate this afternoon.
> >
> > Just to say that this bug still exists in CML2 1.1.1 but it is sometimes
> > hidden, i.e. you only see a "Y" on one of the options but when you select
> > another option, it sometimes says that TWO other options were set to "n"
> > implying that two options were Y before... I also still see random two
> > options being Y when playing with Pentium Classic selection (right now I
> > see Pentium Classic and Pentium-4 at the same time being Y on my screen)...
>
>I can't reproduce this in 1.1.2.  Here's a ttyconfig run, after "v 2" to set
>the verbose flag.

I can't reproduce it with ttyconfig either. But here is how to reproduce it 
reliably with menuconfig:

make mrproper
rm .config
rm config.out
make menuconfig
down
down
right
right
[Now in cpu selection have a Y next to M686.]
down to M586TSC
y
msg: M686=n (deduced from M586TSC)
enter to dismis msg
up
[now at M586]
y
msg: M586TSC=n (deduced from M586)
enter to dismis msg
down
[now back at M586TSC]
y
msg: M586=n (deduced from M586TSC)
enter to dismis msg
[now have a Y for both M586TSC and M686]
y
[nothing happens, as it is already 'y' it's expected]
down
[now notice colouring: M586TSC is green while M686 is grey like the rest]
down
[now at M686 which has the second y but is grey]
y
[nothing happens, as it is 'y' it's expected, but it shouldn't be 'y']
down
[now at MPENTIUMIII]
y
msg: M586TSC=n (deduced from MPENTIUMIII)
  M686=n (deduced from MPENTIUMIII)
enter to dismis msg
[only one Y left at expected position MPENTIUMIII]

I cannot reproduce any of this using make ttyconfig I am afraid...

The above in/output was with CML2 1.1.2.

There must be something... Can you reproduce this? I gave you all 
keypresses I used. I can reproduce it every time.

If I press 'x' after the two 'Y' have appeared at the same time and look at 
the generated .config it says:

# Intel and compatible 80x86 processor types
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set

And config.out contains:

# Intel and compatible 80x86 processor types
#
CONFIG_M386=n
CONFIG_M486=n
CONFIG_M586=n
CONFIG_M586TSC=y
CONFIG_M586MMX=n
CONFIG_M686=y
CONFIG_MPENTIUMIII=n
CONFIG_MPENTIUM4=n
CONFIG_MK6=n
CONFIG_MK7=n
CONFIG_MCRUSOE=n
CONFIG_MWINCHIPC6=n
CONFIG_MWINCHIP2=n
CONFIG_MWINCHIP3D=n
CONFIG_MCYRIXIII=n

This shows quite cleary that the state really is messed up indeed.

Let me know if you cannot reproduce this stil...

If there is anything I can help to narrow this down let me know (I don't 
know any Python I am afraid). Once I have my permanent netconnection back 
to home (will take a few days) I can give you a ssh shell account on this 
system if it would be helpful. At the moment the only interaction with the 
world is using a floppy disk or my Windows box and the modem in my Nokia 
7110... )-:

Best regards,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

IP Acounting Idea for 2.5

[David Findlay]

I am using the kernel IP Accounting in Linux to record the amount of data 
transfered via my Linux internet gateway from individual IP addresses. This 
currently requires me to set up an accounting rule for each IP address that I 
want to record accounting info for. If I had 200 machines to individually log 
this would require me to set 200 rules.

In the 2.5 series of kernels, working towards 2.6, could you please make the 
IP Accounting so that I can set a single rule that will make it watch all IP 
traffic going from the local network, through the masquerading service to the 
internet, and log local IP Addresses using it? This would allow me to set 1 
rule, but have the information I want on a per IP address system.

One other person I have talked to would like to see this too, and he 
basically says we need a software version of the Cisco IP Accounting 
server/router.

Could you please add this to the next kernel? Please CC me your responses as 
I am not a member of the kernel mailing list. Thanks,

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3dfx framebuffer problems with 2.4.4-pre[1-3]

[Stefan Frank]

Hello,

I have a problem with the 3dfx framebuffer since 2.4.4-pre1.
I have the following append line in my lilo.conf:
append = "video=tdfx:1280x1024-8@76"

This setting works fine for the 2.4.[0-3] kernels.

When I boot the box, the little penguin on the top left side is unrecognizable.

When I exit X, the console is just black with a blinking cursor. I can type
commands "blind" but nothing appears on the screen. The system seems to work
normal because the commands are executed, the only problem is that the screen
is black.

Using fbset or resetting the console doesn't help.

fbtv (from the xawtv-package) works fine, also on the "black and
blinking" console.

My card is a 3dfx Voodoo3 2000 PCI (16MB).

gcc2.95.2
make   2.79.1
binutils   2.9.5.0.24
util-linux 2.10q
modutils   2.4.5
e2fsprogs  1.19
PPP2.4.0

Let me know, if I can provide more information.
Perhaps I have a configuration failure?
(I'm not a linux guru and a good programmer)

Thanks a lot,
Steff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Alan Cox]

> Can the numerous ntfs fixes in the -ac series be applied to the mainstream
> kernel instead? Thanks.

Want me to feed them to Linus or will you do it ?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [new PATCH] Re: 8139too: defunct threads

[Rod Stewart]

On Sun, 15 Apr 2001, Manfred Spraul wrote:

> Alan, which fix would you prefer:
> * init could use wait3 and set __WALL.
> * all kernel thread users could set SIGCHLD. Some already do that
> (__call_usermodehelper).
> * the kernel_thread implementations could force the exit signal to
> SIGCHLD.
>
> I'd prefer the last version.
> The attached patch is tested with i386. The alpha, parisc and ppc
> assember changes are guessed.

This patch fixed my problem.

Thanks,
-Rms

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.3.4 Module Problems UPDATED

[Matthew W. Lowe]

Ok, I've gotten both NICs to work thanks to the help from you guys.
Basically, what you have to do is disable all the packet filtering stuff
with exception to the minimal requirements to select ipchains. And also
I disabled modular install and built in install for every nic card but
the ones I had. (aka, clicking a bunch of options, rebooting and linux
loading.)

Note: Just in case anyone else comes around asking about 2000 smbfs
mounting, it works with 2.4.3. Before (or in version 2.2.16 and
earlier... Not sure when it was fixed) there use to be this bug with
mounting 2000 shares. Changes to the drive and files wouldn't be
updated, just reloaded from the cache.

Thanks for the help,
   Matt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.1, wiuth experimental fast mode

[Olaf Titz]

[Warning: historical reference ahead.]

> > I'd appreciate it if some of you with slow machines would try running
> > with fast mode on and seeing if that addresses the sluggishness.
>
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode.  Right?  :)

Perhaps not, if fast mode won't display on the screen while running,
or such things... ;-)

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML1 cleanup patch

[Olaf Titz]

> And the problem is that this hits a fast path in the classical news spool
> layout article create path. The code for this assumes that you have
> articles in the range X to Y, and you just got a new article, so you write
> a file called /var/spool/news/group/name/Y+1. You really do not want to
> cope with the possibility of a directory Y+1 existing in that place.

C News did this, actually: if creat(.../name/Y+1) fails, it tries
creat(.../name/Y+2), etc. (IIRC up to 1000 times). This does not really
hurt a fast path: either you do
  sprintf(a, "...", artno);
  if (creat(a, ...)<0) {
syslog(...);
return FAILED;
  }
or
  while (sprintf(a, "...", artno),
 creat(a, ...)<0) {
++artno;
if (++count>MAX) {
  syslog(...);
  return FAILED;
}
  }

it's just one compare in the fast path which you need anyway.
(Initializing the counter does not _have_ to happen for each article.)

What would hurt is a stat() here, but that is not necessary. It could
be necessary in expire and/or maintenance tools, but these are not as
time-critical. The all-numerics mess up things like "find the lowest
article number" (makeactive/renumber/however it is called), in these
cases a stat is really necessary.

However I think the point is moot because the traditional spool layout
has been proven by experience to be inadequate for the job, even in
the face of more sophisticated filesystems - modern news systems need
other storage mechanisms to cope with the load anyway.

> And then, it's an ugly user interface: the classical spool layout does
> assume that you look at that scpool with Unix tools (like find and grep),
> not only via NNTP and the server.

INN needs a "storage manager grep", but that's even more off topic
here :-)

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks

[Kurt Roeckx]

On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
> While running 2.4.3, I saw the following message a few times:
> 
> KERNEL: assertion (tp->lost_out == 0) failed at
> tcp_input.c(1202):tcp_remove_reno_sacks

Nobody seems to be intrested in fixing this bug?

Anyway, I was looking at some statistics of the box, which I
think might be related to this problem.

netstat -s shows this under TCP:

Tcp:
11681 active connections openings
0 passive connection openings
84689 failed connection attempts
0 connection resets received
94 connections established
10963047 segments received
11476087 segments send out
392891 segments retransmited
772 bad segments received.
24083 resets sent

It seems it has to retransmit 3.4% of the TCP segments, which is
rather high.

The box is just up for 10 days, this means it has to retransmit
about .45 segments / second, and the rate seems to be going up.

I hope this helps.

If there is anything else I can do, please ask.


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't free the ramdisk (initrd, pivot_root)

[Amit D Chaudhary]

On the same topic, I have not found any change in free memory reported before 
and after the ioctl call. Though umount /initrd does free around 2 MB.


Amit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Anton Altaparmakov]

On Sun, 15 Apr 2001, Rogier Wolff wrote:
> Anton Altaparmakov wrote:
> > >Also, the "start" value that is read from the record, could be much 
> > larger than expected, which could lead to accessing random data. The
> > fixup should fail then, and this is also patched below.
> > 
> > No it can't (in theory). The volume would be corrupt if it was. That kind
> > of check belongs in ntfs fsck utility but not in kernel code.
> > 
> > In any case, the correct check, if you want one, would be:
> > 
> > if (start + (count * 2) > size)
> > return 0;
> 
> Of course this is the better check. I was being sloppy. 
> 
> I disagree with your "this belongs in an fsck-program". If this
> condition triggers, then indeed, the filesystem is corrupt. But if the
> "start" pointer is dereferenced, the kernel could be accessing an area
> that you don't want touched (e.g. if the buffer happens to be near 
> enough to the "end-of-memory", you could "Ooops" .
> 
> The kernel should validate all user-input as much as possible, and an
> ntfs-formatted-floppy should count as such.

Ok. I see your point. But you have to admitt that if it is possible for a
malicious person to gain physicall access to the machine your security is
already zero whatever you do. And I wouldn't expect any sane admin to want
to trash their mashine.

[According to MS of course, NTFS cannot be put on floppies but let's not
get into this discussion.]

> The "fixup" routine has a bunch of "return 0" conditions. These are
> similar to mine: If they trigger, the filesystem must be corrupt.
> It's a sanity check, which is neccesary to keep Linux stable.

Yes, but if you wanted to check for one and every single possibility of
how a filesystem could be trying to kill your fs driver then you driver
will end up with 90% of code being checks in the driver and this
resulting in the driver being slow as hell. If you can't trust your
fs, what can you trust? - That's what the dirty flag is for. If dirty on
mount run fsck to fix corruptions, after that assume that fs is not
corrupt...

But, point taken. I guess we want to safe guard all places where
corruption would result in dereferencing memory outside the buffer (here
ntfs record). It should be safe to ignore all other corruption, from 
this aspect of security.

I will be sending out all my fixes which are in -ac kernels to
Linus soon, myself, and I will include a patch to do a full bounds check
at this point.

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amiga affs support broken in 2.4.x kernels??

[Roman Zippel]

Hi,

Mark Hounschell wrote:

>  I'm not a list member so IF you respond to this mail please CC me.
> I've been looking at the archives and see some problems with the 2.3.x
> kernel versions and affs support.

I've put a new version at
http://www.xs4all.nl/~zippel/affs.010414.tar.gz

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fsck, raid reconstruction & bad bad 2.4.3

[Colonel]

In list.kernel, linas wrote:
>
>First problem:  In kernel-2.4.2 and earlier, if the machine is not cleanly
>shut down, then upon reboot, RAID reconstruction is automatically started.
>(For RAID-1, this more-or-less ammounts to copying the entire contents
>of one disk partition on one disk to another).   The reconstruction
>code seems to be clever: it will try to use the full bandwidth when
>the system is idle, and it will throttle back when busy.  It will
>only throttle back so far: it tries to maintain at least a minimum amount
>of work going, in order to gaurentee forward progress even on a busy system.

And it works great!

>The problem:  this dramatically slows fsck after an unclean shut-down.
>You can hear the drives machine-gunning.  I haven't stop-watch timed it,
>but its on the order of 5x slower to fsck a raid partition when there's
>reconstruction going on, then when the raid thinks its clean.  This
>makes unclean reboots quite painful.

Since the alternative is to sit there and do NOTHING until the
reconstruction is complete, ala Solaris 2.5, it's WONDERFUL the way it
is.  This change was extensively discussed on the raid mailing list a
couple of years ago.  You can look it up for review.

>(There is no config file to disable/alter this .. no work-around that I
>know of ..)

You can't be serious.  Go sit down and think about what's going on.


>
>The second problem: oparallelizing fsck doesn't realize that different
>/dev/md raid volumes are on the same physical disks, and thus tries
>to parallelize  again slowing things down.   There is a work-around,
>modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
>really gets into this   it would be nice to get fsck to 'do the
>right thing'.

You probably have your fstab incorrectly setup.


#> In particular, how does fsck deal with md devices? It parallelizes
#> itself for multiple disks, but if the volumes are all actually striped 
#> over the same disks, fsck will perform better if it's serial.
#
#The "pass" field in /etc/fstab is for exactly this: fsck -a will
#serialise devices with different pass numbers.  Pass==1 is for root,
#pass==2 is for normal devices which fsck knows how to serialise.  If you
#want to force serialisation on md devices, use larger pass numbers.


Do a little work, it won't hurt you.  Fsck should not (and may not be
able to) decode metadevice structures.


Your third part was ignored, given the above.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ext2 Directory Index - File Structure

[Daniel Phillips]

Andreas, you wrote:
> Daniel, you write:
> > So then, the obvious candidate would be:
> >
> > #define EXT2_FEATURE_RO_COMPAT_DIR_INDEX0x0004
> >
> > which was formerly EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
>
> Actually not.  We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> because the on-disk layout is 100% compatible with older kernels, so
> no reason to force read-only for those systems.  I'm guessing Ted had
> put RO_COMPAT_BTREE_DIR in there in anticipation, but it was never used.

Whoops, my mind came to one conclusion and my mouse to another: I cut
and pasted Ted's original define without noticing the RO in it.  Yes,
it would have been RO as Ted  conceived it due to the addition
of a new class of filesystem metadata (btree nodes).  He suggested
keeping the normal file index blocks as well, which would have given it
RO compatibility, which is what got me thinking about this design.  As
it turns out, the page cache erases the advantage of absolute indexing
in terms of access time, and even with the buffer cache the overhead is
not large compared to the savings.

That reminds me, putting this code back into the page cache is gradually
working its way back up my to-do list.  My first attempt to do that was
not very satisfying.  The problems I ran into were:

  - Locking issues.  The page cache locks in units of pages; the
directory index works in units of blocks that do not group nicely
into pages.  We do not lock buffers at all when we read/write them,
but in the current page cache regime we are supposed to with pages.
Since I operate on up to 4 non-contiguous blocks simultaneously this
turns into a major hassle, and at least one problem is quite
difficult: suppose you are splitting a leaf.  You have a lock on the
page the original lives on and you allocate a new block at the end
of the file for the new one.  Is that new block on the same page as
the original or not?  If it is, you'd better not try to lock again
or you will deadlock.  So you skip the lock, and now you have to
remember that you skipped the lock so you don't unlock the page
twice.  This is just a simple example, when you throw index blocks
in with the leaf blocks it can get quite a lot messier.

  - The "prepare/commit bracket".  In the current regime you prepare a
page for writing by calling a VFS function that maps the page to
file blocks and reads some of them if necessary.  With buffers, you
use the same function (bread) to prepare the buffer for writing as
you do for reading.  Often, you will have read the buffer anyway, so
there's nothing more to do there.  This doesn't sound like a huge
difference, but actually it is.  In the case of mark_buffer_dirty
you are acting on the buffer at one point in its lifetime; with
prepare/commit you have to worry about a linear span of a page's
life.  This can get especially messy if the span crosses a few
conditionals, which it often does.

  - Extra parameters.  Because you are typically operating on a piece of
a page you have to keep not only a pointer to the struct page, but
something to tell you which part of the page you were working on,
so instead of having one data item to pass around you have 2-3, and
the chance of them getting out of sync increases from "0" to
"probable".  If you examine directory code you'll see I'm keeping a
pointer not only to each buffer, but to its b_data as well, which
would normally be a stupid thing to do - I kept this extra cruft in
there when I converted the code back from the page cache to the
buffer cache, in order to ease the pain of the next try at page
cache conversion.  Combined with the prepare/commit bracket, you now
have to track 4-6 data items over a span of code fs 1 data item at
one point.  The combinatorics are starting to kick in here.  Sure,
it's all doable, but at what cost to readability?

  - Granularity.  Besides the locking issue, it is just extra work to
keep track of which logical block lives on which page.

  - Interface definition issues.  Nobody has written down a definition
of the page cache interface in terms of operations, states, locking
rules, etc.  There are fragments of information here and there but
you really have to dig for them and it's a practical certainty that
you will miss some.  You pretty much just have to read the code on
this one, and even then there are a lot of subtleties that can be
easily missed.

All these problems could have been solved, but the fact is, I put quite
a lot of work into the code and the result was distressingly unstable,
the reasons for this being not at all obvious.  On top of that, I found
that the code was getting quite tied to all the little bookkeeping
issues that came up, to the point where I wasn't making a lot of
progress developing the features I wanted.  And to add insult to injury,
I just wasn't very

Ide performance (was RAID0 Performance problems)

[Andreas Peter]

Hi,
I've posted about performance problems with my RAID0 setup.
RAID works fine, but it's too slow.
But now it seems not to be a problem with the md code, it's an ide problem.
There are two HDs in my PC: /dev/hda and /dev/hdc. No other devices are 
attached to the ide-bus.
PC is a SMP-System, 2 Celeron 533, Gigabyte 6BXDS with Intel BX-Chipset, 
66MHz FSB.
The hdparm settings: 

bash-2.04# hdparm /dev/hda /dev/hdc
 
/dev/hda:
 multcount=  0 (off)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq=  1 (on)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  0 (off)
 geometry = 59556/16/63, sectors = 60032448, start = 0
 
/dev/hdc:
 multcount=  0 (off)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq=  1 (on)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  0 (off)
 geometry = 59556/16/63, sectors = 60032448, start = 0

I've tested a lot of variations of this settings (multcount=16, 
unmaskirq=0...) without succes. 
The performance of the RAID doesn't increase :-(
hdparm -tT on a single HD (dev/hda3 is the RAID-partition) reports a very 
good performance:

bash-2.04# hdparm -tT /dev/hda3
 
/dev/hda3:
 Timing buffer-cache reads:   128 MB in  1.42 seconds = 90.14 MB/sec
 Timing buffered disk reads:  64 MB in  2.27 seconds = 28.19 MB/sec

But if I start 2 hdparms simultanous (one on /dev/hda3 the other on 
/dev/hdc3) the performance on the HDs decreases to 1/2 of the original speed:

bash-2.04# hdparm -tT /dev/hda3
 
/dev/hda3:
 Timing buffer-cache reads:   128 MB in  2.27 seconds = 56.39 MB/sec
 Timing buffered disk reads:  64 MB in  4.56 seconds = 14.04 MB/sec

bash-2.04# hdparm -tT /dev/hdc3
 
/dev/hdc3:
 Timing buffer-cache reads:   128 MB in  2.25 seconds = 56.89 MB/sec
 Timing buffered disk reads:  64 MB in  4.49 seconds = 14.25 MB/sec

The performance of the RAID0:

bash-2.04# hdparm -tT /dev/md0
 
/dev/md0:
 Timing buffer-cache reads:   128 MB in  1.35 seconds = 94.81 MB/sec
 Timing buffered disk reads:  64 MB in  3.11 seconds = 20.58 MB/sec

Tests with bonnie or iozone have the same reuslts, RAID is slower then a 
single HD :-(

Does anybody has an idea what's wrong with my setup??

Thx,
Andreas
-- 
Andreas Peter *** [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] CML2 1.1.2 is available

[Steven Cole]

On Sunday 15 April 2001 12:33, Eric S. Raymond wrote:
> The latest version is always available at http://www.tuxedo.org/~esr/cml2/
>
> Release 1.1.2: Sun Apr 15 14:26:07 EDT 2001
>   * Synchronized with 2.4.4-pre3.
>   * Screen flicker in menuconfig is gone.
>   * KEY_HOME and KEY_END now go to top or bottom of menu.
>   * Zack Weinberg's patch reorganizing the block devices menus.
>
> The screen flicker fix should also speed up general responsiveness.

Good,  and many thanks for changing bright green to dark green for make 
xconfig. That's much better!

However, the label "Processor type (X86)" is still in cyan, and makes
my poor old tired eyes even more tired.  A nice dark blue would be much 
appreciated.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CML2 1.1.2 is available

[Eric S. Raymond]

The latest version is always available at http://www.tuxedo.org/~esr/cml2/

Release 1.1.2: Sun Apr 15 14:26:07 EDT 2001
* Synchronized with 2.4.4-pre3.
* Screen flicker in menuconfig is gone.
* KEY_HOME and KEY_END now go to top or bottom of menu.
* Zack Weinberg's patch reorganizing the block devices menus.

The screen flicker fix should also speed up general responsiveness.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

...the Federal Judiciary...an irresponsible body, working like gravity
by night and by day, gaining a little today and a little tomorrow, and
advancing its noiseless step like a thief over the field of
jurisdiction until all shall be usurped from the States; and the
government of all be consolidated into one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't free the ramdisk (initrd, pivot_root)

[Scott Murray]

On 14 Apr 2001, H. Peter Anvin wrote:

> Hello friends,
>
> I am trying the following setup, and it works beautifully, *except*
> that I don't seem to be able to free the ramdisk memory at the end.

Heh, sounds familiar, I was in exactly the same situation a month ago.
I meant to post something about it, but kept forgetting.

> This successfully runs init, and I can umount /initrd in the new
> setup, but I cannot then destroy the ramdisk contents by calling
> ioctl([/dev/ram0], BLKFLSBUF, 0) -- it always returns EBUSY.  What is
> holding this ramdisk busy, especially since I could successfully
> umount the filesystem?  Seems like a bug to me.

Indeed it is.  This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):

@@ -690,6 +690,7 @@
 done:
if (infile.f_op->release)
infile.f_op->release(inode, &infile);
+   blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
 free_inodes: /* free inodes on error */

has been in Alan's tree since some time in November (it first appeared
in the 2.4.0test11ac1 Change Log).

Another ramdisk gotcha that also still exists is that cramfs still seems to
be hosing the ramdisk superblock if it's compiled into the kernel.  I had to
not only switch to romfs for my initrd, but also compile cramfs support out
of the kernel.  There was a big discussion about this exact problem back in
January, but none of the suggested fixes seem to have been incorporated.

Scott


-- 
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

fsck, raid reconstruction & bad bad 2.4.3

[Linas Vepstas]

Hi,
I want to report a trio of raid-related problems.  The third one is 
very serious, and effectively prevents 2.4.3 from being usable (by me).

First problem:  In kernel-2.4.2 and earlier, if the machine is not cleanly
shut down, then upon reboot, RAID reconstruction is automatically started.
(For RAID-1, this more-or-less ammounts to copying the entire contents
of one disk partition on one disk to another).   The reconstruction
code seems to be clever: it will try to use the full bandwidth when
the system is idle, and it will throttle back when busy.  It will
only throttle back so far: it tries to maintain at least a minimum amount
of work going, in order to gaurentee forward progress even on a busy system.

The problem:  this dramatically slows fsck after an unclean shut-down.
You can hear the drives machine-gunning.  I haven't stop-watch timed it,
but its on the order of 5x slower to fsck a raid partition when there's
reconstruction going on, then when the raid thinks its clean.  This
makes unclean reboots quite painful.

(There is no config file to disable/alter this .. no work-around that I
know of ..)


The second problem: oparallelizing fsck doesn't realize that different
/dev/md raid volumes are on the same physical disks, and thus tries
to parallelize  again slowing things down.   There is a work-around,
modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
really gets into this   it would be nice to get fsck to 'do the
right thing'.

--

Third problem:

I just tried boot 2.4.3 today.  (after an unclean shutdown)  fsck runs 
at a crawl on my RAID-1 volume.  It would take all day (!! literally) 
to fsck.  The disk-drive activity light flashes about once a second,
maybe once every two seconds.  (with a corresponding click from the
drive).

On 2.4.2 kernels, the disk activity light is constantly on... and the
fsck proceeds apace. 

Whatever it is that changed in 2.4.3, it makes unclean reboots
impossible ...


--linas




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Rogier Wolff]

Anton Altaparmakov wrote:
> >Also, the "start" value that is read from the record, could be much 
> larger than expected, which could lead to accessing random data. The
> fixup should fail then, and this is also patched below.
> 
> No it can't (in theory). The volume would be corrupt if it was. That kind
> of check belongs in ntfs fsck utility but not in kernel code.
> 
> In any case, the correct check, if you want one, would be:
> 
> if (start + (count * 2) > size)
>   return 0;

Hi Anton, 

Of course this is the better check. I was being sloppy. 

I disagree with your "this belongs in an fsck-program". If this
condition triggers, then indeed, the filesystem is corrupt. But if the
"start" pointer is dereferenced, the kernel could be accessing an area
that you don't want touched (e.g. if the buffer happens to be near 
enough to the "end-of-memory", you could "Ooops" .

The kernel should validate all user-input as much as possible, and an
ntfs-formatted-floppy should count as such. 

The "fixup" routine has a bunch of "return 0" conditions. These are
similar to mine: If they trigger, the filesystem must be corrupt.
It's a sanity check, which is neccesary to keep Linux stable.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.0 bug and snailspeed

[Eric S. Raymond]

Anton Altaparmakov <[EMAIL PROTECTED]>:
> At 18:56 14/04/2001, Eric S. Raymond wrote:
> >Anton Altaparmakov <[EMAIL PROTECTED]>:
> > > I found a bug: In "Intel and compatible 80x86 processor options", "Intel
> > > and compatible 80x86 processor types" I press "y" on "Pentium Classic"
> > > option and it activates Penitum-III as well as Pentium Classic options at
> > > the same time!?! Tried to play around switching to something else and then
> > > onto Pentium Classic again and it enabled Pentium Classic and Pentium
> > > Pro/Celeron/Pentium II (NEW) this time! Something is very wrong here.
> >
> >Rules file bug, probably.  I'll investigate this afternoon.
> 
> Just to say that this bug still exists in CML2 1.1.1 but it is sometimes 
> hidden, i.e. you only see a "Y" on one of the options but when you select 
> another option, it sometimes says that TWO other options were set to "n" 
> implying that two options were Y before... I also still see random two 
> options being Y when playing with Pentium Classic selection (right now I 
> see Pentium Classic and Pentium-4 at the same time being Y on my screen)...

I can't reproduce this in 1.1.2.  Here's a ttyconfig run, after "v 2" to set
the verbose flag.

Skip-to-query arrived at x86type
Intel and compatible 80x86 processor types may have these values:
 1: M386386
 2: M486486
 3: M586586/K5/5x86/6x86/6x86MX
 4: M586TSC Pentium Classic
 5: M586MMX Pentium MMX
 6: M686Pentium Pro/Celeron/Pentium II
 7: MPENTIUMIII Pentium-III
 8: MPENTIUM4   Pentium-4
 9: MK6 K6/K6-II/K6-III
10: MK7 Athlon/Duron/K7
11: MCRUSOE Crusoe
12: MWINCHIPC6  Winchip-C6
13: MWINCHIP2   Winchip-2
14: MWINCHIP3D  Winchip-2A/Winchip-3
15: MCYRIXIII   CyrixIII/C3
x86type: Intel and compatible 80x86 processor types (M686): 4
User action on M586TSC.
set_symbol_internal(M586TSC, y, None)
bindsymbol(M586TSC, y, M586TSC)
M586TSC=y
set_symbol_internal(M386, n, M586TSC)
Symbol M386 unchanged
set_symbol_internal(M486, n, M586TSC)
Symbol M486 unchanged
set_symbol_internal(M586, n, M586TSC)
Symbol M586 unchanged
set_symbol_internal(M586MMX, n, M586TSC)
Symbol M586MMX unchanged
set_symbol_internal(M686, n, M586TSC)
bindsymbol(M686, n, M586TSC)
M686=n (deduced from M586TSC)
set_symbol_internal(MPENTIUMIII, n, M586TSC)
Symbol MPENTIUMIII unchanged
set_symbol_internal(MPENTIUM4, n, M586TSC)
Symbol MPENTIUM4 unchanged
set_symbol_internal(MK6, n, M586TSC)
Symbol MK6 unchanged
set_symbol_internal(MK7, n, M586TSC)
Symbol MK7 unchanged
set_symbol_internal(MCRUSOE, n, M586TSC)
Symbol MCRUSOE unchanged
set_symbol_internal(MWINCHIPC6, n, M586TSC)
Symbol MWINCHIPC6 unchanged
set_symbol_internal(MWINCHIP2, n, M586TSC)
Symbol MWINCHIP2 unchanged
set_symbol_internal(MWINCHIP3D, n, M586TSC)
Symbol MWINCHIP3D unchanged
set_symbol_internal(MCYRIXIII, n, M586TSC)
Symbol MCYRIXIII unchanged
Unchilling...
M686=n (deduced from M586TSC)
Committing new bindings.
Trit flag is now y
Skip-to-query called from x86type
is_visible(MICROCODE) called
MICROCODE not visible, MICROCODE guard M686 is false
is_visible(TOSHIBA) called
Query of TOSHIBA *not* elided
Skip-to-query arrived at TOSHIBA
TOSHIBA: Toshiba Laptop support < > (NEW)?: 

I'm going to ship 1.1.2 in a few hours.  Would you see if you can reproduce
it in your environment?  Perhaps it's some effect of reading in your
existing config.out.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

...the Federal Judiciary...an irresponsible body, working like gravity
by night and by day, gaining a little today and a little tomorrow, and
advancing its noiseless step like a thief over the field of
jurisdiction until all shall be usurped from the States; and the
government of all be consolidated into one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.3 - Module problems?

[Jeff Garzik]

Francois Cami wrote:
> 
> hi Matthew and everyone
> 
> I use a 3COM Etherlink III ISA and a 3C905C PCI in my firewall
> box (i440BX mobo). (distro is slackware 7.1, kernels are either
> 2.2.19 or 2.4.3, modutils 2.3.1 (slackware 7.1 default) ).
> 
> The 3C905C was never a problem (and i guess your R8029 isn't either),
> however to make the 3C509 ISA work, I had to disable PnP in the
> card's firmware, with 3COM tools : see
> 
> 
>http://www.3com.com/products/html/prodlist.html?family=570&cat=20&pathtype=download&tab=cat&selcat=Network%20Interface%20Cards%20%26%20Adapters
> 
> to download the DOS tools to configure your card without PnP, i.e.
> manually
> assigning an IRQ and address to it.
> 
> You'll have to declare to your BIOS that this particular IRQ is taken
> by a non-PNP ISA card too.

You can also use the Linux program
ftp://www.scyld.com/pub/diag/3c5x9setup.c

-- 
Jeff Garzik   | "Give a man a fish, and he eats for a day. Teach a
Building 1024 |  man to fish, and a US Navy submarine will make sure
MandrakeSoft  |  he's never hungry again." -- Chris Neufeld
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Data-corruption bug in VIA chipsets

[Thomas Molina]

On Sat, 14 Apr 2001, Dan Podeanu wrote:

> On 13 Apr 2001, Doug McNaught wrote:
>
> > Alan Cox <[EMAIL PROTECTED]> writes:
> >
> > > > Here might be one of the resons for the trouble with VIA chipsets:
> > > >
> > > > http://www.theregister.co.uk/content/3/18267.html
> > > >
> > > > Some DMA error corrupting data, sounds like a really nasty bug. The
> > > > information is minimal on that page.
> > >
> > > What annoys me is that we've known about the problem for _ages_. If you look
> > > the 2.4 kernel has experimental workarounds for this problem. VIA never once
> > > even returned an email to say 'we are looking into this'. Instead people sat
> > > there flashing multiple BIOS images and seeing what made the difference.
> >
> > Is this problem likely to affect 2.2.X?  I have a VIA-based board on
> > order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon
> > (it's upgrading a stock RH6.2 box).
> >
>
> We've had HUGE problems with 2.4.x kernels and VIA based boards. We have
> here 3 VIA boards with Athlon/850 and Duron/900 CPUs. The problem goes
> like this:
>
> Compile 2.4.3 with VIA and Athlon support.
> Reboot.
> Ooopses (between 1 and continuously scrolling of them) occur at random
> periods of time, between mounting the root filesystem and 2-3 minutes of
> functionality.
>

Interesting.  I have an ASUS A7V board I'm running an Athlon 900 on with
none of the problems noted here.  Are there specific hardware
correlations that people have noted?  It does have the 686B southbridge
noted in the article as causing problems.

The BIOS thing is interesting though.  I work part time in a computer
repair shop.  With the A7V boards you never know which BIOS version will
be on the board.  The A7V is one of the most popular ones we have for
AMD chips.  We sell a ton of them, so if there are problems I'd sure
like to be kept up to date.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.3 - Module problems?

[Francois Cami]

hi Matthew and everyone

I use a 3COM Etherlink III ISA and a 3C905C PCI in my firewall
box (i440BX mobo). (distro is slackware 7.1, kernels are either
2.2.19 or 2.4.3, modutils 2.3.1 (slackware 7.1 default) ).

The 3C905C was never a problem (and i guess your R8029 isn't either), 
however to make the 3C509 ISA work, I had to disable PnP in the 
card's firmware, with 3COM tools : see

http://www.3com.com/products/html/prodlist.html?family=570&cat=20&pathtype=download&tab=cat&selcat=Network%20Interface%20Cards%20%26%20Adapters

to download the DOS tools to configure your card without PnP, i.e.
manually
assigning an IRQ and address to it.

You'll have to declare to your BIOS that this particular IRQ is taken
by a non-PNP ISA card too.

Now it works well, whether i use a separate module or build the
module into the kernel.

I hope that helps.

François CAMI (new to the list)
[EMAIL PROTECTED]


"Matthew W. Lowe" wrote:
> 
> Hey, Thanks for all the help everyone. So far this is my exact
> configuration:
> Two NICs, 3COM Etherlink III ISA, Realtek 8029 PCI (Covered by the
> NE2000 PCI module). Both cards are setup for PnP, the modules have been
> built into the kernel. (It worked in my old version with them build into
> the kernel.)
> 
> I have upgraded to the latest modutils, and it appeared to fix the
> problem with the 3COM Etherlink III card.
> 
> Alan Cox:
> You mentioned turning PnP off if I was building the modules into the
> kernel? Is there something in the later versions of the kernel that is
> setup like that, or ?? (** didn't quite understand what you meant **)
> 
> Thanks,
>Matt
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: "uname -p" prints unknown for Athlon K7 optimized kernel?

[Andreas Schwab]

"Mr. Shannon Aldinger" <[EMAIL PROTECTED]> writes:

|> On Sun, 15 Apr 2001, it was written:
|> 
|> > elfie:~ # uname -p
|> > unknown
|> >
|> > elfie:~ # uname -a
|> > Linux elfie 2.4.3 #1 Fri Apr 13 21:08:29 CEST 2001 i586 unknown
|> >
|> I get the same on my Sun Ultra 1, and various x86 boxes. I'm sure this is
|> normal, I'm just not sure how you would change that label. I know gcc
|> compiles everything with a target of gcc-linux-unkown on my machines, so
|> the uknown may be coming from there...

The two things are completely unrelated.

Andreas.

-- 
Andreas Schwab  "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Lse-tech] Bug in sys_sched_yield

[Kanoj Sarcar]

> 
> 
> George, while this is needed as pointed out in a previous message,
> due to non-contiguous physical IDs, I think the current usage is
> pretty bad (at least looking from a x86 perspective). Maybe somebody
> can chime in from a different architecture.
> 
> I think that all data accesses particularly to __aligned_data
> should be performed through logical ids. There's a lot of remapping
> going on, due to the mix of logical and physical IDs.
>

I _think_ cpu_logical_map() can be deleted from the kernel, and all
places that use it can just use the [0 ... (smp_num_cpus-1)] number.
This is for the generic kernel code. The only place that should need
to convert from this number space to a "physical" space would be the
intercpu interrupt code (arch specific code). 

Only a handful of architectures (mips64, sparc*, alpha) do array
lookups for cpu_logical_map() anyway, those probably can be changed 
to the x86 definition of cpu_logical_map().

Kanoj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NTFS comment expanded, small fix.

[Anton Altaparmakov]

Linus, Alan,

Please do not apply this patch as both the comment and the code are wrong
and unnecessary, respectively.

Can the numerous ntfs fixes in the -ac series be applied to the mainstream
kernel instead? Thanks.

Rogier and everyone doing any NTFS work, please use -ac series kernels as
ntfs has had major updates which are now proven to be a Good Thing
(TM)... - I get bug reports for mainstream kernel ntfs several times a
month while I haven't received a single one for the -ac series (perhaps
due to smaller userbase admittedly, but all bugs reported are fixed in the
-ac patches).

Also, if you need info about ntfs read the ntfs docs at:
http://linux-ntfs.sourceforge.net/ntfs

For example the fixups are explained at:
http://linux-ntfs.sourceforge.net/ntfs/concepts/fixup.html

And if the docs don't suffice (they are work in progress), look at the
linux-ntfs project source code.  Especially at the doc directory and the
include directory (and sometimes the libntfs directory). Either the header
files or the library files contain extensive documentation about the
meaning of each and every field in the ntfs structures. For example, the
fixup mechanism is described in: 
linux-ntfs/include/layout.h, lines 84 to 110.
You can find the most current code in CVS on sourceforge. The project page
is:
http://sourceforge.net/projects/linux-ntfs/

You can browse the cvs cvs on the web or download the lot. (don't use the
now out of date packaged linux-ntfs-0.0.1 distribution as it is out of
date...)

At 13:53 15/04/2001, Rogier Wolff wrote:
>I am studying an NTFS problem, and came across the NTFS fixup mechanism. 

Care to elaborate? - We could save you some time perhaps...

>It took me much too long to understand the fixup mechanism, even though
a comment tried to explain it. So I rewrote the comment. 

If you read what I referenced above you will want to revise your own
comment

>Also, the "start" value that is read from the record, could be much 
larger than expected, which could lead to accessing random data. The
fixup should fail then, and this is also patched below.

No it can't (in theory). The volume would be corrupt if it was. That kind
of check belongs in ntfs fsck utility but not in kernel code.

In any case, the correct check, if you want one, would be:

if (start + (count * 2) > size)
return 0;

And it has to happen before the:

count--;

Hope this helps,

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: can't use printk in linux 2.4.2 module

[James Simmons]

Try the following patch to linux/kernel/Makefile. If it works fine let me
know and we can get it into the standard tree.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

--- Makefile.orig   Sun Apr 15 10:06:40 2001
+++ MakefileSun Apr 15 10:06:51 2001
@@ -9,7 +9,7 @@

 O_TARGET := kernel.o

-export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o
+export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o printk.o

 obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
module.o exit.o itimer.o info.o time.o softirq.o resource.o \

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[James Simmons]

> [One of the things for 2.5 is 15- or 31-bit keycodes.
> The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]

Or for 2.5.X you could use EVIOCGKEYCODE or EVIOCSKEYCODE using
/dev/eventX. Also the input api supports up to 220 different keys and
could support up to 255. If you app needs to use a large keycode space
then use this instead. Its better to use this interface especially
for embedded systems that have only a serial console, but sometimes
we need to use a regular keyboard. Consider for example a hand held iPAQ.
Usually their is no keyboard attached. Here you have a graphical interface
(using framebuffer) and a touch screen. So here I like to have a kernel
that uses fbdev without the VT console system and input drivers to
interface with the device. Debugging can be done by the serial console.
If I attach a keyboard I like to be able to use it without having to have
a console system needing to be built in. Remember every byte of space
counts. Getting keycode via the console layer should eventually be
replaced by this approach.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SCSI tape corruption problem

[Olaf Titz]

>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k

I have a tool which compresses individual files in a tar archive
instead of the whole archive[1]. That one tries hard to write only in
standard 10kb blocks to emulate tar's behavior towards the drive.
I'll try in a few days (when I'm back from holidays) if I have this
error on my scsi tape too (bad) and if the compression program affects
it.

Olaf

[1] http://sites.inka.de/bigred/sw/tarmill-0.22.tar.gz>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Ext2 Directory Index - File Structure

[Daniel Phillips]

>Daniel Phillips wrote:
> > Jamie Lokier wrote:
> > > Daniel Phillips wrote:
> > > > ls already can't handle the directories I'm working with on a regular
> > > > basis.  It's broken and needs to be fixed.  A merge sort using log n
> > > > temporary files is not hard to write.
> > >
> > > ls -U | sort
> > >
> > > should do the trick.
> >
> > Um, yep.  Now ls should do that itself instead of giving up with an error.
>
> Sorting 1 million 30-character strings does not require temporary files
> on a machine with > 35 MB anyway, and that can be virtual, so if anyone
> cares about ls sorting huge directories I suggest improving the
> in-memory sort.

I got this today:

ls -U  
ls: Memory exhausted

Since this occured while nothing else was active, it's probably a MM bug
and I will chase it further.  However, it also shows that ls is well and
truly borked.  If anybody is going to work on it I'd suggest not only
improving the in-memory sort but adding a custom file-based sort or exec
sort as a fallback.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-pre3: lvm.c patch results in "hanging" mount or swapon

[Arjan Filius]

Hello,

On Sun, 15 Apr 2001, Jens Axboe wrote:

> On Sun, Apr 15 2001, Arjan Filius wrote:
> > Hello,
> >
> > While trying kernel 2.4.4-pre3 i found a "hanging" swapon (my swap is on
> > LVM), same effect for "mount -a". 2.4.3 works properly.
> >
> > I found ./drivers/md/lvm.c is patched, and restoring the lvm.c from 2.4.3
> > resulted in normal operation.
> >
> > I Found LVM/0.9.1_beta7 makes some notes about the patch, so i tried that
> > (beta7), but no luck, only 2.4.3:lvm.c worked ok.
>
> Small buglet in the buffer_IO_error out path, I maybe that's it...

Dunno, i did som 'strace'ing and found it is waiting in read():
open("/dev/vg_4/lv_images", O_RDONLY)   = 4
lseek(4, 1024, SEEK_SET)= 1024
read(4,
  (killed with SAK)


Greatings,



-- 
Arjan Filius
mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4.3 - Module problems?

[Matthew W. Lowe]

Hey, Thanks for all the help everyone. So far this is my exact
configuration:
Two NICs, 3COM Etherlink III ISA, Realtek 8029 PCI (Covered by the
NE2000 PCI module). Both cards are setup for PnP, the modules have been
built into the kernel. (It worked in my old version with them build into
the kernel.)

I have upgraded to the latest modutils, and it appeared to fix the
problem with the 3COM Etherlink III card.

Alan Cox:
You mentioned turning PnP off if I was building the modules into the
kernel? Is there something in the later versions of the kernel that is
setup like that, or ?? (** didn't quite understand what you meant **)

Thanks,
   Matt


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.1, wiuth experimental fast mode

[Eric S. Raymond]

Anton Altaparmakov <[EMAIL PROTECTED]>:
> Much better now! make xconfig still seems to be the old way (hadn't tried 
> it before)? - At least I get two shades of green. The lighter one is 
> completely unreadable on the silver background. Could I suggest to get rid 
> of the light/dark green distinction altogether, do it like the new 
> menuconfig colors, they are much improved now.

Yeah, that was a typo.  It will work this way in 1.1.2.

> On my Pentium 133S with fastmode I get a more than 2 fold increase in speed 
> and  it feels a lot more usable. Still have to wait between key presses but 
> it is better than before.

Uh oh.  

If you still have to wait I'd better make fastmode disable more stuff :-(.
 
> One general note: scrolling between entries (up/down arrow) seems slower 
> than it should be.

That should be fixed now.  I found a way to recode menuconfig's screen refresh
that will be faster and eliminate the screen flicker.

> Keep up the good work. You are on the right track. (-:

Thanks!
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"Rightful liberty is unobstructed action, according to our will, within limits
drawn around us by the equal rights of others."
-- Thomas Jefferson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

v2.4.3 networking problem other than tcp_ecn?

[jeff millar]

Several web sites have stoped working recently about the time I upgraded to
2.4.2 - 2.4.3.  Some testing at one site showed it doesn't respond to pings
except for an occasional reply reported as "admin prohibited filter" by
tcpdump or as "packet filtered" by ping.  The kernel doesn't have tcp_ecn
compiled in, access is via ppp and dialup, everything possible compiled as
modules, iptables firewall setup.  This problem applies to machine on the
local net and to the firewall itself.

ideas?

jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: "uname -p" prints unknown for Athlon K7 optimized kernel?

[Mr. Shannon Aldinger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 15 Apr 2001, it was written:

> elfie:~ # uname -p
> unknown
>
> elfie:~ # uname -a
> Linux elfie 2.4.3 #1 Fri Apr 13 21:08:29 CEST 2001 i586 unknown
>
I get the same on my Sun Ultra 1, and various x86 boxes. I'm sure this is
normal, I'm just not sure how you would change that label. I know gcc
compiles everything with a target of gcc-linux-unkown on my machines, so
the uknown may be coming from there...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Made with pgp4pine 1.75

iEYEARECAAYFAjrZxI0ACgkQwtU6L/A4vVCO6wCdGoot4MMYmrdW4N2ankreoHXn
t1UAoJLpUTlsEY+jQCcSrz6ezId2oUqM
=sCuV
-END PGP SIGNATURE-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4 stable when?

[George Bonser]

>
> > Is there any information that would be helpful to the kernel
> > developers that I might be able to provide or is this a known issue
> > that is currently being worked out?
>
> I never heard about this problem.  What would be helpful is to
> send a few minutes' (a full 'load cycle'?) worth of output from
> 'vmstat 5' and some information about the configuration of the
> machine.
>
> It's possible I'll want more information later, but just the
> vmstat output would be a good start.
>
> If the data isn't too big, I'd appreciate it if you could also
> CC [EMAIL PROTECTED]
>
> regards,

Sounds good. I think I can do this.  Also, it appears that the problem is
related to how busy the farm is.  The machines are load balanced in a "least
connections" mode. There are 5 servers in the farm. Suppose I have 300
connections to each machine and reboot one to load the new kernel.

When that server comes back up it is handed 300 connections all at once. It
seems (and this is subjective ... does it handle things differently with
more than 256 processes?) that when I give the machine much more than 200
connections, it is very slow to clear them.  It seems to have trouble at
that point clearing connections as fast as it is getting them. If I have
less than 200 connections initially, it seems to handle things OK.

I tried to collect some data last night but it appeared to work ok. I will
wait for the load to come up later today and try it during its peak time.
While I could put the balancer into a "slow start" mode, 2.2 always seemed
to handle the burst of new connections just fine so I didn't bother.

The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian
Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR
motherboard. This uses the ServerWorks ServerSet III LE chipset and Adaptec
AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using
eth0).

I have cut the configuration pretty much to the bone, no NetFilter support,
no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my
first step when having problems).

I was able to run 2.4.0-test12 in this application and did for quite some
time. I don't recall trying 2.4.1 but I know I had severe problems with
2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as
busy back when I put 2.4.0 on it or that I ever rebooted during my peak
period. This might have been a problem all along but I just never saw it. It
seems to have to do with handing the machine a large number of connections
at once and then a stream of them at a pretty good clip. It is getting about
40 connections/second right this minute but that should come up a bit in the
next couple of hours.

To be quite honest, I could run this on 2.2 forever, it is just a webserver.
My only reason for using 2.4 would be to see if I can go SMP on these things
when my load gets higher and I get some benefit of the finer granularity of
2.4 in SMP to serve a higher load with fewer machines than would be possible
with 2.2. That, and just to beat on a 2.4 kernel and report any problems to
you guys.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: "uname -p" prints unknown for Athlon K7 optimized kernel?

[Heinz Diehl]

On Sun Apr 15 2001, joker wrote:

> i have this problem using intel 850mhz and 333mhz
> any know where to get update version of uname ?

http://www.tuxfinder.com

Btw:

elfie:~ # uname --version
uname (GNU sh-utils) 2.0.11
Written by David MacKenzie.

Copyright (C) 2000 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
elfie:~ # uname -p
unknown

elfie:~ # uname -a
Linux elfie 2.4.3 #1 Fri Apr 13 21:08:29 CEST 2001 i586 unknown

elfie:~ # cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 9
model name  : AMD-K6(tm) 3D+ Processor
stepping: 1
cpu MHz : 400.917
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
k6_mtrr
bogomips: 799.53

-- 
# Heinz Diehl, 68259 Mannheim, Germany
# Groovebox Roland MC-303, Digitech RP-1 and Fender Stratocaster for sale,
# all in mint condition! Further information via e-mail.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 stable when?

[Rik van Riel]

On Sat, 14 Apr 2001, George Bonser wrote:

> 2.4.4pre3 works, sorta, but is very "pumpy". The load avg will go up to
> about 60, then drop, then climb again, then drop. It will vary from very
> sluggish performance to snappy and back again to sluggish.

So it's stable ;))

> With 2.2 kernels I see something like this:
> 
>  00:48:00 up  4:51,  1 user,  load average: 0.00, 0.02, 0.06

*nod*

> Is there any information that would be helpful to the kernel
> developers that I might be able to provide or is this a known issue
> that is currently being worked out?

I never heard about this problem.  What would be helpful is to
send a few minutes' (a full 'load cycle'?) worth of output from
'vmstat 5' and some information about the configuration of the
machine.

It's possible I'll want more information later, but just the
vmstat output would be a good start.

If the data isn't too big, I'd appreciate it if you could also
CC [EMAIL PROTECTED]

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...

[James Simmons]

>Agreed.  The only thing I was thinking, was if the kernel is doing the
>right thing now, it shouldn't be forced to work around a bug in XFree.
>By not "fixing" the kernel, the XFree team would be forced to do the
>right thing.

Ha Ha Ha. That is funny. Okay it does get fixed many many months later.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-pre3: lvm.c patch results in "hanging" mount or swapon

[Jens Axboe]

On Sun, Apr 15 2001, Arjan Filius wrote:
> Hello,
> 
> While trying kernel 2.4.4-pre3 i found a "hanging" swapon (my swap is on
> LVM), same effect for "mount -a". 2.4.3 works properly.
> 
> I found ./drivers/md/lvm.c is patched, and restoring the lvm.c from 2.4.3
> resulted in normal operation.
> 
> I Found LVM/0.9.1_beta7 makes some notes about the patch, so i tried that
> (beta7), but no luck, only 2.4.3:lvm.c worked ok.

Small buglet in the buffer_IO_error out path, I maybe that's it...

-- 
Jens Axboe



--- /opt/kernel/linux-2.4.4-pre3/drivers/md/lvm.c   Sun Apr 15 16:24:13 2001
+++ drivers/md/lvm.cSun Apr 15 16:23:36 2001
@@ -1675,8 +1675,10 @@
   struct buffer_head *bh)
 {
int ret = lvm_map(bh, rw);
-   if (ret < 0)
+   if (ret < 0) {
+   ret = 0;
buffer_IO_error(bh);
+   }
return ret;
 }
 

Re: Writing to Pana DVD-RAM

[Jens Axboe]

On Sun, Apr 15 2001, [EMAIL PROTECTED] wrote:
> DOH!  You're right.
> 
> I can now write to it, but only get one chance.  Copy a file to
> DVDRAM, read, print, etc, but when I try to rm or mv, segfault.
> Foreverafter the DVDRAM is 'busy'.  Cannot umount.  Must reboot then
> umount.  Remount, get another write, but on subsequent write,
> segfault.

Please decode that oops and send it along, see REPORTING-BUGS

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How can I add a function to the kernel initialization

[James Simmons]

Is this a HD44780 LCD? Geert wrote a console driver sometime ago for this.
He had a driver for it. If he still doesn't I have a copy of the code.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Writing to Pana DVD-RAM

[cacook]

DOH!  You're right.

I can now write to it, but only get one chance.  Copy a file to DVDRAM, read, print, 
etc, but when I try to rm or mv, segfault.  Foreverafter the DVDRAM is 'busy'.  Cannot 
umount.  Must reboot then umount.  Remount, get another write, but on subsequent 
write, segfault.

I am using UDF2. (UDF2.1 won't mount)  Would I be better off with UDF1.2, or FAT32?  
How can I get details of the driver's capabilities?
--
C.

The best way out is always through.
  - Robert Frost  A Servant to Servants, 1914



Jeremy Jackson wrote:

> [EMAIL PROTECTED] wrote:
>
> > Hello,
> >
> > I am running RedHat Wolverine (beta) with kernel 2.4.2.  I have a SCSI subsystem 
>(AHA2740) with a Panasonic LF-D101 DVDRAM on it.
> >
> > I read that the CDROM driver is built to recognize DVDRAMs and allow writes; well 
>I can mount and read the UDF file system fine, but am not allowed writes.  I have 
>UDF2.0 on the disk, because it didn't recognize UDF2.1.
> >
> > Also, when I  make xconfig,  it includes UDF support, but read-only. 
>(Write-Experimental is grayed-out)
> >
> > In fstab: /dev/scd1 is mounted to /mnt/dvdram  udf  default 0 0. (paraphrasing)
> >
> > I need the DVDRAM for backups and file transfers.  Is the problem the driver, the 
>UDF filesystem, my setup, or what?
> > --
> > C.
> >
> > The best way out is always through.
> >   - Robert Frost  A Servant to Servants, 1914
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> Check that "Experimental " is enabled under "Code Maturity level options",
> if you can't find it try using "make menuconfig" instead of "make xconfig"
> Note that the UDF-write support option is listed as "Dangerous"... possibly
> making things difficult, but then again if you have a DVD-RAM,
> how bad can things be :)
>
> Cheers,
>
> Jeremy




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: comments on CML 1.1.0

[Daniel Stone]

On Sat, Apr 14, 2001 at 11:58:41AM -0400, jeff millar wrote:
> Selecting IP_NF_COMPAT_IPCHAINS turns off IP_NF_CONNTRACK and friends.  But,
> I think CML1, allowed both support to the new iptables and compatibility
> modes to allow old ipchains scripts to work with the new kernel.

Only as modules: conntrack/queueing/iptables, ipchains compat, and ipfwadm
compat, are all mutually exclusive. The only way that this was at all
possible in 2.4.x was via modules, but even then, they were still mutually
exclusive.

-- 
Daniel Stone
Linux Kernel Developer
[EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o
K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ 
D+ G e->++ h!(+) r+(%) y? UF++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[new PATCH] Re: 8139too: defunct threads

[Manfred Spraul]

I found the problem:

* init uses waitpid(-1,,), thus the __WALL flag is not set
* without __WALL, only processes with exit_signal == SIGCHLD are reaped
* it's impossible for user space processes to die with another
exit_signal, forget_original_parent changes the exit_signal back to
SIGCHLD ("We dont want people slaying init"), and init itself doesn't
use clone.
* kernel threads can die with an arbitrary exit_signal.

Alan, which fix would you prefer:
* init could use wait3 and set __WALL.
* all kernel thread users could set SIGCHLD. Some already do that
(__call_usermodehelper).
* the kernel_thread implementations could force the exit signal to
SIGCHLD.

I'd prefer the last version. 
The attached patch is tested with i386. The alpha, parisc and ppc
assember changes are guessed.

--
Manfred

diff -ur 2.4/arch/alpha/kernel/entry.S build-2.4/arch/alpha/kernel/entry.S
--- 2.4/arch/alpha/kernel/entry.S   Sun Sep  3 20:36:45 2000
+++ build-2.4/arch/alpha/kernel/entry.S Sun Apr 15 14:58:01 2001
@@ -242,12 +242,12 @@
subq$30,4*8,$30
stq $10,16($30)
stq $9,8($30)
-   lda $0,CLONE_VM
+   lda $0,CLONE_VM|SIGCHLD
stq $26,0($30)
.prologue 1
mov $16,$9  /* save fn */   
mov $17,$10 /* save arg */
-   or  $18,$0,$16  /* shuffle flags to front; add CLONE_VM.  */
+   or  $18,$0,$16  /* shuffle flags to front; add CLONE_VM|SIGCHLD. */
bsr $26,kernel_clone
bne $20,1f  /* $20 is non-zero in child */
ldq $26,0($30)
diff -ur 2.4/arch/arm/kernel/process.c build-2.4/arch/arm/kernel/process.c
--- 2.4/arch/arm/kernel/process.c   Thu Feb 22 22:28:51 2001
+++ build-2.4/arch/arm/kernel/process.c Sun Apr 15 14:51:08 2001
@@ -368,6 +368,8 @@
 {
pid_t __ret;
 
+   flags |= SIGCHLD;
+
__asm__ __volatile__(
"orrr0, %1, %2  @ kernel_thread sys_clone
mov r1, #0
diff -ur 2.4/arch/cris/kernel/process.c build-2.4/arch/cris/kernel/process.c
--- 2.4/arch/cris/kernel/process.c  Sat Apr  7 22:01:49 2001
+++ build-2.4/arch/cris/kernel/process.cSun Apr 15 14:51:16 2001
@@ -127,6 +127,8 @@
 int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
register long __a __asm__ ("r10");
+
+   flags |= SIGCHLD;

__asm__ __volatile__
("movu.w %1,r9\n\t" /* r9 contains syscall number, to sys_clone */
diff -ur 2.4/arch/i386/kernel/process.c build-2.4/arch/i386/kernel/process.c
--- 2.4/arch/i386/kernel/process.c  Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cSun Apr 15 14:40:43 2001
@@ -440,6 +440,8 @@
 {
long retval, d0;
 
+   flags |= SIGCHLD;
+
__asm__ __volatile__(
"movl %%esp,%%esi\n\t"
"int $0x80\n\t" /* Linux/i386 system call */
diff -ur 2.4/arch/ia64/kernel/process.c build-2.4/arch/ia64/kernel/process.c
--- 2.4/arch/ia64/kernel/process.c  Thu Jan  4 21:50:17 2001
+++ build-2.4/arch/ia64/kernel/process.cSun Apr 15 14:51:44 2001
@@ -500,7 +500,7 @@
struct task_struct *parent = current;
int result, tid;
 
-   tid = clone(flags | CLONE_VM, 0);
+   tid = clone(flags | CLONE_VM | SIGCHLD, 0);
if (parent != current) {
result = (*fn)(arg);
_exit(result);
diff -ur 2.4/arch/m68k/kernel/process.c build-2.4/arch/m68k/kernel/process.c
--- 2.4/arch/m68k/kernel/process.c  Thu Feb 22 22:28:54 2001
+++ build-2.4/arch/m68k/kernel/process.cSun Apr 15 14:51:58 2001
@@ -135,7 +135,7 @@
 
{
register long retval __asm__ ("d0");
-   register long clone_arg __asm__ ("d1") = flags | CLONE_VM;
+   register long clone_arg __asm__ ("d1") = flags | CLONE_VM | SIGCHLD;
 
__asm__ __volatile__
  ("clrl %%d2\n\t"
diff -ur 2.4/arch/mips/kernel/process.c build-2.4/arch/mips/kernel/process.c
--- 2.4/arch/mips/kernel/process.c  Sat Apr  7 22:01:56 2001
+++ build-2.4/arch/mips/kernel/process.cSun Apr 15 14:52:12 2001
@@ -161,6 +161,8 @@
 {
long retval;
 
+   flags |= SIGCHLD;
+
__asm__ __volatile__(
".set\tnoreorder\n\t"
"move\t$6,$sp\n\t"
diff -ur 2.4/arch/mips64/kernel/process.c build-2.4/arch/mips64/kernel/process.c
--- 2.4/arch/mips64/kernel/process.cThu Feb 22 22:28:55 2001
+++ build-2.4/arch/mips64/kernel/process.c  Sun Apr 15 14:52:21 2001
@@ -154,6 +154,8 @@
 {
int retval;
 
+   flags |= SIGCHLD;
+
__asm__ __volatile__(
"move\t$6, $sp\n\t"
"move\t$4, %5\n\t"
diff -ur 2.4/arch/parisc/kernel/entry.S build-2.4/arch/parisc/kernel/entry.S
--- 2.4/arch/parisc/kernel/entry.S  Sat Apr  7 22:01:58 2001
+++ build-2.4/arch/parisc/kernel/entry.SSun Apr 15 14:56:58 2001
@@ -497,7 +497,7 @@
 #endif
STREG   %r26, PT_GR26

Re: CML2 1.1.1, wiuth experimental fast mode

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode.  Right?  :)

That's an interesting question to which I do not yet know the answer.
I am continuing to speed-tune.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The Constitution is not neutral. It was designed to take the
government off the backs of the people.
-- Justice William O. Douglas 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] NTFS comment expanded, small fix.

[Rogier Wolff]

Hi all,

I am studying an NTFS problem, and came across the NTFS fixup mechanism. 

It took me much too long to understand the fixup mechanism, even though
a comment tried to explain it. So I rewrote the comment. 

Also, the "start" value that is read from the record, could be much 
larger than expected, which could lead to accessing random data. The
fixup should fail then, and this is also patched below. 

Patch attached. 

Roger. 



diff -ur linux-2.4.3.clean/fs/ntfs/super.c linux-2.4.3.ntfs_fix/fs/ntfs/super.c
--- linux-2.4.3.clean/fs/ntfs/super.c   Sun Apr 15 14:48:05 2001
+++ linux-2.4.3.ntfs_fix/fs/ntfs/super.cSun Apr 15 14:47:48 2001
@@ -30,6 +30,22 @@
  * . the magic identifier is wrong
  * . the size is given and does not match the number of sectors
  * . a fixup is invalid
+ **
+ * Somehow that comment may sound usable to the person who wrote it, but 
+ * in fact it took me over an hour to figure it out. That's not what 
+ * comments are for. So let me try to explain it: 
+ *
+ * A record contains a fixup-area. The size of this area is S+1 words,
+ * with S the number of sectors in the record. 
+ *
+ * The first word of the fixup area is a random word. 
+ * The last word of every sector should contain this random word. 
+ * The rest of the fixup area contains the original contents of that
+ * last word of each sector of the record. 
+ * the position and length of the fixup area are stored at offset 4 
+ * and 6 in the record.  
+ *
+ * Hope this helps. -- REW
  */
 int ntfs_fixup_record(ntfs_volume *vol, char *record, char *magic, int size)
 {
@@ -42,6 +58,8 @@
count=NTFS_GETU16(record+6);
count--;
if(size && vol->blocksize*count != size)
+   return 0;
+   if (start >= size) 
return 0;
fixup = NTFS_GETU16(record+start);
start+=2;
Only in linux-2.4.3.ntfs_fix/fs/ntfs: super.c.orig


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML1 cleanup patch

[Kai Henningsen]

Warning: No kernel related stuff inside.

[EMAIL PROTECTED] (Rik van Riel)  wrote on 26.03.01 in 
<[EMAIL PROTECTED]>:

> On Mon, 26 Mar 2001, John Cowan wrote:

> > In fact this has come up before: in Usenet software, which has to
> > differentiate between an article and a sub-newsgroup.  An article has
> > to have an all-numeric name, and It Would Have Been Nice if all
> > newsgroup names began with non-digits, but then there was
> > comp.bugs.4bsd.
>
> What's wrong with using the _file type_ for these things ?

Wrong problem description, really. The problem is not components starting  
with digits, the problem is all-numeric components as in alt.2600.

And the problem is that this hits a fast path in the classical news spool  
layout article create path. The code for this assumes that you have  
articles in the range X to Y, and you just got a new article, so you write  
a file called /var/spool/news/group/name/Y+1. You really do not want to  
cope with the possibility of a directory Y+1 existing in that place.

I think there are some other things that also get impacted on their fast  
path, but this is probably the most important.

And then, it's an ugly user interface: the classical spool layout does  
assume that you look at that scpool with Unix tools (like find and grep),  
not only via NNTP and the server.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.3 - Module problems?

[Alan Cox]

> as I did the previous kernel. They were the NE2000 PCI module and the
> 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> at the end.

Make sure you use either the kernel or the usermode PnP and not both. (You
probably want to turn kernel PnP off)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: shmem_getpage_locked() / swapin_readahead() race in 2.4.4-pre3

[Christoph Rohland]

Hi,

On Sat, 14 Apr 2001, Marcelo Tosatti wrote:
> There is a nasty race between shmem_getpage_locked() and
> swapin_readahead() with the new shmem code (introduced in 2.4.3-ac3
> and merged in the main tree in 2.4.4-pre3):
> 
> shmem_getpage_locked() finds a page in the swapcache and moves it to
> the pagecache as an shmem page, freeing the swapcache and the swap
> map entry for this page. (which causes a BUG() in mm/shmem.c:353
> since the swap map entry is being used)
> 
> In the meanwhile, swapin_readahead() is allocating a page and adding
> it to the swapcache.

Oh, I was just chasing this also. 

> I don't see any clean fix for this one.

I think the actual check for swap_count is not necessary: If
swapin_readahead allocates a new swap_cache page for the entry, that's
not a real bug. On memory pressure this page will be reclaimed.

Actually we have to make shmem much more unfriendly to the swap cache
to make it correct: I think we have to drop the whole drop swap cache
pages on truncate logic since it uses lookup_swap_cache and
delete_from_swap_cache which both lock the page, while holding a
spinlock :-(

The appended patch implements both changes and relies on the page
stealer to shrink the swap cache. 

It also integrates fixes which Marcelo did send earlier.

Greetings
Christoph



--- 2.4.4-pre3/mm/shmem.c   Sat Apr 14 11:12:54 2001
+++ u2.4.3/mm/shmem.c   Sun Apr 15 13:45:58 2001
@@ -123,10 +123,19 @@
entry = *ptr;
*ptr = (swp_entry_t){0};
freed++;
+#if 0
+/*
+* This does not work since it may sleep while holding
+* a spinlock 
+*
+* We rely on the page stealer to free up the
+* allocated swap space later
+*/
if ((page = lookup_swap_cache(entry)) != NULL) {
delete_from_swap_cache(page);
page_cache_release(page);   
}
+#endif
swap_free (entry);
}
return freed;
@@ -236,8 +245,10 @@

/* Only move to the swap cache if there are no other users of
 * the page. */
-   if (atomic_read(&page->count) > 2)
-   goto out;
+   if (atomic_read(&page->count) > 2){
+   set_page_dirty(page);
+   goto out;
+   }

inode = page->mapping->host;
info = &inode->u.shmem_i;
@@ -348,9 +359,6 @@
if (TryLockPage(page)) 
goto wait_retry;
 
-   if (swap_count(page) > 2)
-   BUG();
-   
swap_free(*entry);
*entry = (swp_entry_t) {0};
delete_from_swap_cache_nolock(page);
@@ -432,6 +440,7 @@
*ptr = NOPAGE_SIGBUS;
return error;
 sigbus:
+   up (&inode->i_sem);
*ptr = NOPAGE_SIGBUS;
return -EFAULT;
 }

Re: usb-uhci.c problems in latest kernels?

[Joseph Carter]

On Sat, Apr 14, 2001 at 09:35:46PM -0400, Pete Zaitcev wrote:
> > usb-uhci.c: interrupt, status 3, frame# 1876 
> 
> This is a known problem, here is the discussion that I initiated
> on linux-usb-devel:
> 
>  http://marc.theaimsgroup.com/?t=9860950851&w=2&r=1
> 
> The right fix is to comment that printout out.
> In fact, that is what I commited for Red Hat 7.1 release.

I'm not sure of that.  Sometimes keys get "stuck" in the down position
with my USB keyboard (mechanical switches, so the keys themselves are not
sticking) and usually when that happens I can find a line like the one
quoted above in the logs.  Also, occasionally my mouse goes black (one of
the optical Logitech's) with a similar line and must be disconnected and
reconnected to work again.  Again, similar line in the logs.

Nothing fatal happens.  Pressing another key fixes the keyboard and my old
fashioned USB ball mouse ;) works fine.


> Some people suggest to switch to uhci instead of usb-uhci,
> which helps precisely because it does not have a corresponding
> printk.

I've seen similar suggestions for people with AMD-based systems.

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

Change the Social Contract?  BWAHAHAHAHAHAHAHAHAHAHAHA.
-- Branden Robinson


 PGP signature

2.4.4-pre3: lvm.c patch results in "hanging" mount or swapon

[Arjan Filius]

Hello,

While trying kernel 2.4.4-pre3 i found a "hanging" swapon (my swap is on
LVM), same effect for "mount -a". 2.4.3 works properly.

I found ./drivers/md/lvm.c is patched, and restoring the lvm.c from 2.4.3
resulted in normal operation.

I Found LVM/0.9.1_beta7 makes some notes about the patch, so i tried that
(beta7), but no luck, only 2.4.3:lvm.c worked ok.

Greatings,

-- 
Arjan Filius
mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.0 bug and snailspeed

[Anton Altaparmakov]

At 18:56 14/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <[EMAIL PROTECTED]>:
> > I found a bug: In "Intel and compatible 80x86 processor options", "Intel
> > and compatible 80x86 processor types" I press "y" on "Pentium Classic"
> > option and it activates Penitum-III as well as Pentium Classic options at
> > the same time!?! Tried to play around switching to something else and then
> > onto Pentium Classic again and it enabled Pentium Classic and Pentium
> > Pro/Celeron/Pentium II (NEW) this time! Something is very wrong here.
>
>Rules file bug, probably.  I'll investigate this afternoon.

Just to say that this bug still exists in CML2 1.1.1 but it is sometimes 
hidden, i.e. you only see a "Y" on one of the options but when you select 
another option, it sometimes says that TWO other options were set to "n" 
implying that two options were Y before... I also still see random two 
options being Y when playing with Pentium Classic selection (right now I 
see Pentium Classic and Pentium-4 at the same time being Y on my screen)...

Hope this helps,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.1.1, wiuth experimental fast mode

[Anton Altaparmakov]

At 04:45 15/04/2001, Eric S. Raymond wrote:
>Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001
> * The old menuconfig shortcut that 'm' in a boolean entry field
>   sets 'y' is now implemented.
> * Simplified color scheme.

Much better now! make xconfig still seems to be the old way (hadn't tried 
it before)? - At least I get two shades of green. The lighter one is 
completely unreadable on the silver background. Could I suggest to get rid 
of the light/dark green distinction altogether, do it like the new 
menuconfig colors, they are much improved now. - Also removing the N and 
replacing M by m has improved readability  by a long way. (-:

> * Added fast-mode command to suppress side-effect computation
>   on slow machines.
>
>I'd appreciate it if some of you with slow machines would try running
>with fast mode on and seeing if that addresses the sluggishness.

On my Pentium 133S with fastmode I get a more than 2 fold increase in speed 
and  it feels a lot more usable. Still have to wait between key presses but 
it is better than before.

I also tried this on a Dual Celeron 450. Speed is fine but you can still 
feel that something is happening in between the key press and it taking 
effect. fastmode doesn't make much difference that I could feel there.

One general note: scrolling between entries (up/down arrow) seems slower 
than it should be. It is noticeable when you want to scroll several entries 
at once and hit an arrow key quickly several times in succession. Perhaps 
the action taken after reaching an entry could be delayed until the next 
key press and only then when it is not one of the move to next/prev option 
ones? That should make moving up/down instantaneous like in the old (cml1) 
menuconfig. But then I have no idea how cml2 works so maybe my suggestion 
is bogus...

Keep up the good work. You are on the right track. (-:

Best regards,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Process (mozilla) in 'D' state (down_w)

[Athanasius]

On Fri, Apr 13, 2001 at 07:52:44AM +0100, Athanasius wrote:
>Seems like anytime I first startup mozilla I end up with something
> like:
[snip]
>I'll sometime if I can remember to run mozilla with a strace -f -ff
> -o file to see if it gives any more useful info.  I'll be updating to
> 2.4.3-ac5 in the next hour or so anyway (currently on plain vanilla
> 2.4.3).

   Ok, this seems to be gone in 2.4.3-ac5.  Three reboots, first two I
ran mozilla as strace -f -ff -o mozilla-strace mozilla and got no
D-state process, this third one I just ran it as normal from my fvwm2
menus and it's also working fine.

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
  Finger athan(at)fysh.org for PGP key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH 2.4.4.3: 3rdparty driver support for kbuild

[Jeff Garzik]

The attached patch, against kernel 2.4.4-pre3, adds a feature I call
"3rd-party support."

When vendors put additional kernel modules and drivers in their kernel
package, typically they do so via a patch.  For the case where totally
new file(s) are added to a kernel, this results in patch conflicts time
and again, because all these patches are updating central files: 
drivers/foo/Config.in and drivers/foo/Makefile.

The attached patch allows the addition of new kernel features without
patching.

A vendor can simply have their kernel package build process untar a
tarball inside the 3rdparty directory, or 'cp' a .c file into the
3rdparty directory.  You simply run the "mkbuild.pl" script to make the
kernel build and configuration system aware of the new kernel module,
and then rebuild with your normal kernel build process.  Additional
details are included in Documentation/3rdparty.txt, in the patch.

-- 
Jeff Garzik   | "Give a man a fish, and he eats for a day. Teach a
Building 1024 |  man to fish, and a US Navy submarine will make sure
MandrakeSoft  |  he's never hungry again." -- Chris Neufeld

Index: linux_2_4/Makefile
diff -u linux_2_4/Makefile:1.1.1.85 linux_2_4/Makefile:1.1.1.85.2.1
--- linux_2_4/Makefile:1.1.1.85 Fri Apr 13 17:13:43 2001
+++ linux_2_4/Makefile  Fri Apr 13 18:16:59 2001
@@ -124,7 +124,7 @@
 drivers/net/net.o \
 drivers/media/media.o
 LIBS   =$(TOPDIR)/lib/lib.a
-SUBDIRS=kernel drivers mm fs net ipc lib
+SUBDIRS=kernel drivers mm fs net ipc lib 3rdparty
 
 DRIVERS-n :=
 DRIVERS-y :=
@@ -180,6 +180,7 @@
 
 DRIVERS += $(DRIVERS-y)
 
+include 3rdparty/Makefile.drivers
 
 # files removed with 'make clean'
 CLEAN_FILES = \
@@ -219,7 +220,8 @@
.menuconfig.log \
include/asm \
.hdepend scripts/mkdep scripts/split-include scripts/docproc \
-   $(TOPDIR)/include/linux/modversions.h
+   $(TOPDIR)/include/linux/modversions.h \
+   3rdparty/Makefile.meta
 # directories removed with 'make mrproper'
 MRPROPER_DIRS = \
include/config \
@@ -407,7 +409,19 @@
rm -rf $(CLEAN_DIRS)
$(MAKE) -C Documentation/DocBook clean
 
-mrproper: clean archmrproper
+3rdpartyproper:
+   @echo "#" > 3rdparty/Config.in
+   @echo "# THIS IS AN AUTOMATICALLY GENERATED FILE. DO NOT EDIT." >> 
+3rdparty/Config.in
+   @echo "#" >> 3rdparty/Config.in
+   @echo "#" > 3rdparty/Makefile
+   @echo "# THIS IS AN AUTOMATICALLY GENERATED FILE. DO NOT EDIT." >> 
+3rdparty/Makefile
+   @echo "#" >> 3rdparty/Makefile
+   @echo 'include $$(TOPDIR)/Rules.make' >> 3rdparty/Makefile
+   @echo "#" > 3rdparty/Makefile.drivers
+   @echo "# THIS IS AN AUTOMATICALLY GENERATED FILE. DO NOT EDIT." >> 
+3rdparty/Makefile.drivers
+   @echo "#" >> 3rdparty/Makefile.drivers
+
+mrproper: clean archmrproper 3rdpartyproper
find . \( -size 0 -o -name .depend \) -type f -print | xargs rm -f
rm -f $(MRPROPER_FILES)
rm -rf $(MRPROPER_DIRS)
Index: linux_2_4/3rdparty/Makefile.drivers
diff -u /dev/null linux_2_4/3rdparty/Makefile.drivers:1.1.4.1
--- /dev/null   Sun Apr 15 02:15:05 2001
+++ linux_2_4/3rdparty/Makefile.drivers Sun Apr 15 02:14:41 2001
@@ -0,0 +1,3 @@
+#
+# THIS IS AN AUTOMATICALLY GENERATED FILE. DO NOT EDIT.
+#
Index: linux_2_4/3rdparty/mkbuild.pl
diff -u /dev/null linux_2_4/3rdparty/mkbuild.pl:1.1.6.1
--- /dev/null   Sun Apr 15 02:15:05 2001
+++ linux_2_4/3rdparty/mkbuild.pl   Fri Apr 13 18:16:59 2001
@@ -0,0 +1,366 @@
+#!/usr/bin/perl -w
+#
+# Copyright 2001 Jeff Garzik <[EMAIL PROTECTED]>
+#
+# This software may be used and distributed according to the terms
+# of the GNU General Public License, incorporated herein by reference.
+#
+#
+# Run "mkbuild.pl -h" for a usage summary.
+#
+# Makefile.meta datafile format:
+# 2D table with columns separated by formfeeds,
+# and rows separated by newlines.  Columns 1-N meanings
+# differ based on column 0 value.
+#
+# Column 0: 'D' or 'F' character -- directory or file
+# Column 1(D): sub-directory containing kernel module
+# Column 2(D): Config.in CONFIG_xxx symbol for this sub-directory
+# Column 3(D): Config.in line, verbatim, for this sub-directory
+# Column 4(D): Filename of target, from [LO]_TARGET in subdir/Makefile
+# Column 1(F): Base name of kernel module
+# Column 2(F): Config.in CONFIG_xxx symbol for this module
+# Column 3(F): Config.in line, verbatim, for this module
+# Column 4(F): Export symbols flag: 'Y' or 'N'
+
+
+use strict;
+use Getopt::Std;
+
+my $MetadataFile = "Makefile.meta";
+
+my (%opts, $InstDir, $InstFile);
+my ($FileDesc, $ConfigIn, $ExportSyms, $ConfigSym, @db);
+
+
+&parse_cmd_line;
+
+if ($opts{'c'}) {
+   print STDERR "Creating new database (ignoring any existing one).\n";
+} else {
+   &read_database;
+}
+
+if ($opts{'r'}) {
+   # do nothing
+} elsif ($InstDir) {
+   &update_from_dir;
+} else {
+   &update_from_file;
+}
+
+&update_database;

can't use printk in linux 2.4.2 module

[vivid_liou]

Dear All :
I wrote a small module to print "hello world " . when I comiple it under kernel
2.2 , everything works fine.
 the output " printk unsolve " appear under 2.4.2 .
with kernel 2.2. , I can find "printk " in the /proc/ksyms , but
with kernel 2.4.2  , only "printk_Rsmp" symbol .
Does anyone know how to solve the problem ?  Thanks you a lot.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH 2.4.4.3: pci_enable/disable_device stuff

[Jeff Garzik]

The attached patch does two things:

1) Take PCI devices to D0 state before enabling them.  We both think
this is the right thing to do, but there is always the crazy chance this
change will break something.  So, think twice before applying, but IMHO
apply :)

2) Adds pci_disable_device.  Right now is just disables busmastering. 
When suspending devices, the last task that should occur is to disable
busmastering, before ceding control to ACPI.  Also its a good idea in
general to disable busmastering when its not in use; it's friendlier to
the bus.  When unloading drivers too, we should be more "green" about
disabling devices.

I wonder if we should disable IO and MEM decoding too, and I also like
to ack PCI_STATUS.  I didn't add those things because I'm not yet sure
we want to do that unconditionally.  Comments welcome.

-- 
Jeff Garzik   | "Give a man a fish, and he eats for a day. Teach a
Building 1024 |  man to fish, and a US Navy submarine will make sure
MandrakeSoft  |  he's never hungry again." -- Chris Neufeld

diff -urN linux.vanilla/drivers/pci/pci.c linux/drivers/pci/pci.c
--- linux.vanilla/drivers/pci/pci.c Wed Mar  7 01:44:15 2001
+++ linux/drivers/pci/pci.c Sun Apr 15 04:32:41 2001
@@ -286,12 +286,33 @@
 {
int err;
 
+   pci_set_power_state(dev, 0);
if ((err = pcibios_enable_device(dev)) < 0)
return err;
-   pci_set_power_state(dev, 0);
return 0;
 }
 
+/**
+ * pci_disable_device - Disable PCI device after use
+ * @dev: PCI device to be disabled
+ *
+ * Signal to the system that the PCI device is not in use by the system
+ * anymore.  Currently this only involves disabling PCI busmastering,
+ * if active.
+ */
+
+void
+pci_disable_device(struct pci_dev *dev)
+{
+   u16 pci_command;
+
+   pci_read_config_word(dev, PCI_COMMAND, &pci_command);
+   if (pci_command & PCI_COMMAND_MASTER) {
+   pci_command &= ~PCI_COMMAND_MASTER;
+   pci_write_config_word(dev, PCI_COMMAND, pci_command);
+   }
+}
+
 int
 pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge)
 {
@@ -1381,6 +1402,7 @@
 EXPORT_SYMBOL(pci_devices);
 EXPORT_SYMBOL(pci_root_buses);
 EXPORT_SYMBOL(pci_enable_device);
+EXPORT_SYMBOL(pci_disable_device);
 EXPORT_SYMBOL(pci_find_capability);
 EXPORT_SYMBOL(pci_release_regions);
 EXPORT_SYMBOL(pci_request_regions);
diff -urN linux.vanilla/include/linux/pci.h linux/include/linux/pci.h
--- linux.vanilla/include/linux/pci.h   Mon Mar 26 18:48:46 2001
+++ linux/include/linux/pci.h   Sun Apr 15 04:27:28 2001
@@ -525,7 +525,9 @@
 int pci_write_config_word(struct pci_dev *dev, int where, u16 val);
 int pci_write_config_dword(struct pci_dev *dev, int where, u32 val);
 
+#define HAVE_PCI_DISABLE_DEVICE
 int pci_enable_device(struct pci_dev *dev);
+void pci_disable_device(struct pci_dev *dev);
 void pci_set_master(struct pci_dev *dev);
 int pci_set_dma_mask(struct pci_dev *dev, dma_addr_t mask);
 int pci_set_power_state(struct pci_dev *dev, int state);
@@ -594,6 +596,7 @@
 
 static inline void pci_set_master(struct pci_dev *dev) { }
 static inline int pci_enable_device(struct pci_dev *dev) { return -EIO; }
+static inline void pci_disable_device(struct pci_dev *dev) { }
 static inline int pci_module_init(struct pci_driver *drv) { return -ENODEV; }
 static inline int pci_assign_resource(struct pci_dev *dev, int i) { return -EBUSY;}
 static inline int pci_register_driver(struct pci_driver *drv) { return 0;}

Re: small bug/oversight found in 2.4.3

[Alexander Viro]

On Sun, 15 Apr 2001, Jeff Garzik wrote:

> Swivel wrote:
> > 
> > drivers/char/char.c, line 247
> > create_proc_read_entry() is called regardless of the definition of
> > CONFIG_PROC_FS, simply wrap call with #ifdef CONFIG_PROC_FS and #endif.
> 
> create_proc_read_entry exists, as a static inline no-op, without
> CONFIG_PROC_FS.

... while drivers/char/char.c doesn't exist at all.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: small bug/oversight found in 2.4.3

[Jeff Garzik]

Swivel wrote:
> 
> drivers/char/char.c, line 247
> create_proc_read_entry() is called regardless of the definition of
> CONFIG_PROC_FS, simply wrap call with #ifdef CONFIG_PROC_FS and #endif.

create_proc_read_entry exists, as a static inline no-op, without
CONFIG_PROC_FS.

Typically you want to change the driver-local function passed to
create_proc_read_entry to be a static inline no-op for the
!CONFIG_PROC_FS case.

-- 
Jeff Garzik   | "Give a man a fish, and he eats for a day. Teach a
Building 1024 |  man to fish, and a US Navy submarine will make sure
MandrakeSoft  |  he's never hungry again." -- Chris Neufeld
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/