OK to mount multiple FS in one dir?

[Michael D. Crawford]

I was groping around my FAT/NTFS directories from Linux, mounting and 
unmounting them into
/mnt, and was suprised at some point that I got the message "/dev/sda5 
already mounted or
/mnt busy".  (I'm using a SCSI disk, use hda* for IDE).

Upon further examination, I found that I'd accidentally mounted 
/dev/sda1 (VFAT) on /mnt
while /dev/sda5 (NTFS) was still mounted there.  The NTFS files remained 
invisible until
I'd unmounted /dev/sda1 and then I could see them again.

This is with the 2.4.1 kernel on a Pentium III machine with an Adaptec 
29160 SCSI
controller.

I found I could mount three partitions on /mnt, and they'd all show up 
as mounted at
/mnt in the "mount" command, but if I unmounted one of them (only tried 
with the currently
visible one), then it appeared that there were no filesystems mounted 
there, but I could
continue umounting until the other two were gone.

I'm suprised this works.  Note that the kernel rejected an attempt to 
mount a filesystem
that was already mounted, but not to mount a filesystem at a point that 
was already in use.
It looks like there is a stack of mounts on the mount point.

Looking at Documentation/Changes, I see that I need util-linux 2.10o.  I 
had 2.10l.  But I
had the 2.10r util-linux sources on my machine and installed mount and 
umount from it, and
I find that it gets it right mostly when I mount and unmount multiple 
things, with the
exception that if /dev/sda5 was mounted before /dev/sda1, then if I give 
the command
"umount /dev/sda5", sda1 is the one that gets unmounted rather than 
sda5, so it takes the
most recently mounted filesystem rather than the one you specify.

Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.


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

RE: system call sched_yield() doesn't work on Linux 2.2

[Mohit Aron]

Thanks for a reasonable/thoughtful reply.

>   to expect perfect alternation is not reasonable. the scheduler
> (or one of its subsidiary and/or supporting functions) decides what
> should run and what shouldn't. the linux scheduler did have problems
> in 2.2 (and still does in some places). however last i checked
> sched_yield() is at best a hint to the scheduler not a command. the
> man page even suggests this. it says that if the process (or thread)
> yields and if it is the highest priority task at the time it will be
> re-run. so you can not guarantee that it will not re-run. this i think
> was the point david was trying to make (albiet with some possibly
> misplaced "fervour").

It looks like what you're saying above is that the scheduling 
priority of a thread might be changed dynamically by the scheduler. 
Hence, even though it called sched_yield(), its resulting priority might 
still be higher than the other thread and hence there may not be 
perfect alternation. This makes sense.

However, I just had a chance to run my program on a Linux 2.4 kernel. 
I got almost perfect alternation every time I ran it. The output was:

Thread1
Thread1
Thread2
Thread1
Thread2
Thread1
Thread2
Thread1
Thread2
Thread2

Basically, the first thread prints twice in the beginning but after
that there's perfect alternation. This might however be because of
startup delays in Thread2.

I might add that I've tested my program on two other operating systems - 
Solaris 2.7 and DUNIX V4.0D. In both I got perfect alternation every
time I ran the program. And with Linux 2.4 there was "almost" perfect
alternation.


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

Re: [PATCH] devfsd, compiling on glibc22x

[Richard Gooch]

Ulrich Drepper writes:
> Richard Gooch <[EMAIL PROTECTED]> writes:
> 
> > So why do old binaries (compiled with glibc 2.1.3) segfault when they
> > call dlsym() with RTLD_NEXT?  Even newly compiled binaries (with glibc
> > 2.2) still segfault.
> 
> What do you ask me?  You wrote the code.

But you wrote dlsym(), right I have a debug trace from someone which
shows that the call to dlsym() segfaults. It's being called thusly:
dlsym (RTLD_NEXT, "symlink");

This doesn't fail with libc 5 nor with glibc 2.1.3. But it does with
glibc 2.2.

Regards,

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

Re: [patch] make tmpfs_statfs more user friendly

[Christoph Rohland]

Christoph Rohland <[EMAIL PROTECTED]> writes:

> The following patch make shmem_statfs report some sensible size
> estimates in the case that the user does not give a size limit.
> 
> This should make it more error prone when used as /tmp
  
Oh well, Lars pointed out that I was apparently in outer space
when typing this mail ;-)

So: s/more/less/

Christoph

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

Re: [PATCH] Hot swap CPU support for 2.4.1

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write
:
> Hello,
>Which archs still need to implement it? I briefly looked over the patch an
d noticed that it had i386, ppc, mips64, and s390 already there.

PPC is there (kinda hackish, but proof of concept).  For the rest, I
don't consider:

return -ENOSYS;

an implementation.  Someone who understands the interrupt controllers
and vagarities for each platform needs to implement them...

Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] tidy up 2.2.19pre8 APM

[Stephen Rothwell]

Hi Alan,

This just brings 2.2.19pre8 into line with the DPMI and APM
from 2.4.  It also only cripples /proc/apm for the actually
buggy Dell BIOS.

Cheers,
Stephen
-- 
Stephen Rothwell, Open Source Researcher
Linuxcare, Inc. +61-2-62628990 tel, +61-2-62628991 fax 
[EMAIL PROTECTED], http://www.linuxcare.com/ 
Linuxcare. Putting open source to work.

diff -ruN 2.2.19pre8/CREDITS 2.2.19pre8-APM.1/CREDITS
--- 2.2.19pre8/CREDITS  Mon Feb  5 13:45:59 2001
+++ 2.2.19pre8-APM.1/CREDITSMon Feb  5 13:58:28 2001
@@ -1869,7 +1869,7 @@
 S: Germany
 
 N: Stephen Rothwell
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
 W: http://linuxcare.com.au/sfr
 P: 1024/BD8C7805 CD A4 9D 01 10 6E 7E 3B  91 88 FA D9 C8 40 AA 02
 D: Boot/setup/build work for setup > 2K
diff -ruN 2.2.19pre8/arch/i386/kernel/apm.c 2.2.19pre8-APM.1/arch/i386/kernel/apm.c
--- 2.2.19pre8/arch/i386/kernel/apm.c   Mon Dec 11 12:24:58 2000
+++ 2.2.19pre8-APM.1/arch/i386/kernel/apm.c Mon Feb  5 17:04:15 2001
@@ -36,6 +36,7 @@
  * Oct 1999, Version 1.10
  * Nov 1999, Version 1.11
  * Jan 2000, Version 1.12
+ * Feb 2000, Version 1.13
  *
  * History:
  *0.6b: first version in official kernel, Linux 1.3.46
@@ -55,7 +56,7 @@
  * The new replacment for it is, but Linux doesn't yet support this.
  * Alan Cox Linux 2.1.55
  *1.3: Set up a valid data descriptor 0x40 for buggy BIOS's
- *1.4: Upgraded to support APM 1.2. Integrated ThinkPad suspend patch by 
+ *1.4: Upgraded to support APM 1.2. Integrated ThinkPad suspend patch by
  * Dean Gaudet <[EMAIL PROTECTED]>.
  * C. Scott Ananian <[EMAIL PROTECTED]> Linux 2.1.87
  *1.5: Fix segment register reloading (in case of bad segments saved
@@ -127,7 +128,7 @@
  * scripts that check for it before doing power off
  * work (Jim Avera <[EMAIL PROTECTED]>).
  *   1.13: Fix the Thinkpad (again) :-( (CONFIG_APM_IGNORE_MULTIPLE_SUSPENDS
- * is now the way life works). 
+ * is now the way life works).
  * Fix thinko in suspend() (wrong return).
  *   1.13ac: Added apm_battery_horked() for Compal boards (Dell 5000e etc)
  *
@@ -242,8 +243,8 @@
 
 /*
  * Define to re-initialize the interrupt 0 timer to 100 Hz after a suspend.
- * This patched by Chad Miller <[EMAIL PROTECTED]>, orig code by David 
- * Chen <[EMAIL PROTECTED]>
+ * This patched by Chad Miller <[EMAIL PROTECTED]>, original code by
+ * David Chen <[EMAIL PROTECTED]>
  */
 #undef INIT_TIMER_AFTER_SUSPEND
 
@@ -326,7 +327,6 @@
 #else
 static int power_off_enabled = 1;
 #endif
-static int dell_crap = 0;  /*Set if we find a 5000e */
 
 static DECLARE_WAIT_QUEUE_HEAD(apm_waitqueue);
 static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
@@ -522,7 +522,7 @@
&dummy, &dummy))
return (eax >> 8) & 0xff;
*event = ebx;
-   if (apm_bios_info.version < 0x0102)
+   if (apm_info.connection_version < 0x0102)
*info = ~0; /* indicate info not valid */
else
*info = ecx;
@@ -554,7 +554,7 @@
 #ifdef ALWAYS_CALL_BUSY
clock_slowed = 1;
 #else
-   clock_slowed = (apm_bios_info.flags & APM_IDLE_SLOWS_CLOCK) != 0;
+   clock_slowed = (apm_info.bios.flags & APM_IDLE_SLOWS_CLOCK) != 0;
 #endif
return 1;
 }
@@ -620,7 +620,7 @@
 * This may be called on an SMP machine.
 */
 #ifdef CONFIG_SMP
-   /* Many bioses don't like being called from CPU != 0 */
+   /* Some bioses don't like being called from CPU != 0 */
while (cpu_number_map[smp_processor_id()] != 0) {
kernel_thread(apm_magic, NULL,
CLONE_FS | CLONE_FILES | CLONE_SIGHAND | SIGCHLD);
@@ -638,15 +638,15 @@
 {
u32 eax;
 
-   if ((enable == 0) && (apm_bios_info.flags & APM_BIOS_DISENGAGED))
+   if ((enable == 0) && (apm_info.bios.flags & APM_BIOS_DISENGAGED))
return APM_NOT_ENGAGED;
if (apm_bios_call_simple(APM_FUNC_ENABLE_PM, APM_DEVICE_BALL,
enable, &eax))
return (eax >> 8) & 0xff;
if (enable)
-   apm_bios_info.flags &= ~APM_BIOS_DISABLED;
+   apm_info.bios.flags &= ~APM_BIOS_DISABLED;
else
-   apm_bios_info.flags |= APM_BIOS_DISABLED;
+   apm_info.bios.flags |= APM_BIOS_DISABLED;
return APM_SUCCESS;
 }
 
@@ -658,6 +658,8 @@
u32 edx;
u32 dummy;
 
+   if (apm_info.get_power_status_broken)
+   return APM_32_UNSUPPORTED;
if (apm_bios_call(APM_FUNC_GET_STATUS, APM_DEVICE_ALL, 0,
&eax, &ebx, &ecx, &edx, &dummy))
return (eax >> 8) & 0xff;
@@ -677,7 +679,7 @@
u32 edx;
u32 esi;
 
-   if (apm_bios_info.version < 0x0102) {
+   if (apm_info.connection_version < 0x0102) {
/* p

Re: [PATCH] devfsd, compiling on glibc22x

[Ulrich Drepper]

Richard Gooch <[EMAIL PROTECTED]> writes:

> So why do old binaries (compiled with glibc 2.1.3) segfault when they
> call dlsym() with RTLD_NEXT?  Even newly compiled binaries (with glibc
> 2.2) still segfault.

What do you ask me?  You wrote the code.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.x Shared memory question

[LA Walsh]

Another oddity -- I notice things taking alot more memory
in 2.4.  This coincides with 'top' consistently showing I have 0 shared
memory.  These two observations would have me wondering if I
have somehow misconfigured my system to disallow sharing.  Note
that /proc/meminfo also shows 0 shared memory:

total:used:free:  shared: buffers:  cached:
Mem:  525897728 465264640 606330880 82145280 287862784
Swap: 2709094400 270909440
MemTotal:   513572 kB
MemFree: 59212 kB
MemShared:   0 kB
Buffers: 80220 kB
Cached: 281116 kB
Active:  22340 kB
Inact_dirty:338996 kB
Inact_clean: 0 kB
Inact_target:0 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   513572 kB
LowFree: 59212 kB
SwapTotal:  264560 kB
SwapFree:   264560 kB 

Not that it seems unrelated, but I do have filesystem type shm 
mounted on /dev/shm as suggested for POSIX shared memory.


-- 
Linda A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338



-- 
Linda A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] devfsd, compiling on glibc22x

[Richard Gooch]

Ulrich Drepper writes:
> Pierre Rousselet <[EMAIL PROTECTED]> writes:
> 
> > for me :
> > make CFLAGS='-O2 -I. -D_GNU_SOURCE' 
> > compiles without any patch. is it correct ?
> 
> Yes.  RTLD_NEXT is not in any standard, it's an extension available
> via -D_GNU_SOURCE.

So why do old binaries (compiled with glibc 2.1.3) segfault when they
call dlsym() with RTLD_NEXT?  Even newly compiled binaries (with glibc
2.2) still segfault.

Regards,

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

2.4.2-test1 better on disk lock/freezups

[LA Walsh]

In trying to apply Jens's patch I upgraded to 2.4.2-pre1.  The figures on it(242-p1) 
look
better at this point: a vmstat dump, same data...notice this time it only took maybe 45
seconds to write out the data.  I also got better interactive performance.
So write speed is up to about 3.5Mb/s.  Fastest reads using 'hdparm' are in the 
12-14Mb/s
range.  Sooo...IDE hdparm block dev read vs. file writes...3-4:1 ratio?

I honestly have little clue as to what would be considered 'good' numbers.

Note the maximum 'system freeze' seems under 10 seconds now -- alot more 
tolerable.  

Note also, this was without my applying Jens's patch -- as I could not figure out how
to get it to apply cleanly  :-(.


 0  0  0  0  77564  80220 280164   0   0 0   348  287  1367  10   7  83
 0  0  1  0  77560  80220 280164   0   0 0   304  193   225   0   1  99
 0  1  1  0  77572  80220 280156   0   0 0   162  241   354   4   2  95
 0  1  1  0  77572  80220 280156   0   0 0   156  218   182   0   1  99
 1  1  1  0  77560  80220 280164   0   0 0   165  217   218   0   1  99
 0  1  1  0  77328  80220 280164   0   0 0   134  213   215   1   1  97
 0  1  1  0  77328  80220 280164   0   0 0   138  217   177   0   1  98
 0  1  1  0  77328  80220 280164   0   0 0   206  215   178   0   1  99
 0  1  1  0  77332  80220 280164   0   0 0   166  219   206   1   1  98
 0  0  0  0  85632  80220 280172   0   01412  192   360   1   1  98
 
-- 
Linda A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Hot swap CPU support for 2.4.1

[Anton Blanchard]

 
> Rusty, what would be needed to "hot-add" CPUs ?

The PPC version at the moment simply locks a cpu in the idle loop
with __cli(); while(1); for cpu down and jumps out of it for cpu up.
Good for testing but not very useful. After talking to paulus we
will use the RTAS cpu stop and cpu start.

In order to bring a new cpu up you will need to duplicate a lot of
the stuff in smp_boot_cpus or else just set up all NR_CPUS of these
structures (eg NR_CPUS idle threads etc) at boot time.

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

Re: system call sched_yield() doesn't work on Linux 2.2

[Davide Libenzi]

On Sunday 04 February 2001 21:50, Matt wrote:
> in this case you will see that in 2.2.18 a SCHED_YIELD process will
> get a "goodness" value of 0, however in 2.4.1-ac1 you will find that
> it gets a value of -1 (and hence a lower scheduling priority). i dont
> have a machine handy that is running 2.2.18 that i can patch and
> reboot, how ever you may wish to change the return value on line 119
> of kernel/sched.c in 2.2.18 to -1 and you may find that it might give
> the behaviour you are looking for. it may also cause other
> problems. caveat emptor and all that..

I don't have a copy of POSIX 1003.1 (Realtime Extensions) with me now but if 
I remember well this states that sched_yield() should release the CPU to 
other threads with the same priority and never schedule task with lower ones.
Now, if for priority We mean static priority the current behaviour of 2.4.x 
is correct, but if We mean dynamic priority the current implementation does 
not respect the standard.
This coz the goodness() for that task will return -1, and this will make this 
process a loser even compared to ones with lower ( dynamic ) priority.
If the POSIX standard concept of priority is nearest to the dynamic one, 
probably a better solution would be a move_last_runqueue + clean_yield_flag.
Not that this will change the universe anyway ...



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

Re: [PATCH] Hot swap CPU support for 2.4.1

[Lars Marowsky-Bree]

On 2001-02-05T15:00:40,
   Rusty Russell <[EMAIL PROTECTED]> said:

> I did the infrastructure, Anton did the bugfinding and PPC support,
> aka. the hard stuff.  Other architectures need to implement
> __cpu_disable, __cpu_die and __cpu_up for them to work.  Volunteers
> appreciated.

Rusty, what would be needed to "hot-add" CPUs ?

Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
SuSE Linux AG at the SAP LinuxLab - [EMAIL PROTECTED]

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

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

RE: system call sched_yield() doesn't work on Linux 2.2

[Matt]

mohit,
to expect perfect alternation is not reasonable. the scheduler
(or one of its subsidiary and/or supporting functions) decides what
should run and what shouldn't. the linux scheduler did have problems
in 2.2 (and still does in some places). however last i checked
sched_yield() is at best a hint to the scheduler not a command. the
man page even suggests this. it says that if the process (or thread)
yields and if it is the highest priority task at the time it will be
re-run. so you can not guarantee that it will not re-run. this i think
was the point david was trying to make (albiet with some possibly
misplaced "fervour").

however i did notice one small change wrt to SCHED_YIELD
semantics from 2.2.18 and 2.4.1-ac1 (one would assume that this change
happened during the schedule() re-writes during 2.3.x).

xref line 119 of kernel/sched.c in 2.2.18

 and

xref line 148 of kernel/sched.c in 2.4.1-ac1

in this case you will see that in 2.2.18 a SCHED_YIELD process will
get a "goodness" value of 0, however in 2.4.1-ac1 you will find that
it gets a value of -1 (and hence a lower scheduling priority). i dont
have a machine handy that is running 2.2.18 that i can patch and
reboot, how ever you may wish to change the return value on line 119
of kernel/sched.c in 2.2.18 to -1 and you may find that it might give
the behaviour you are looking for. it may also cause other
problems. caveat emptor and all that..

matt

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

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Gregory Maxwell]

On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
>   From the debate raging here is what I gathered is acceptable
> 
> make it blow up fataly and immediatly if it detects Red Hat + gcc 
>2.96-red_hat_broken(forgot version num)
> make it provide a URL to get the patch to remove this safeguard if you really want 
>this.
> 
>   The fatal crash should be VERY carefull to only trigger on a redhat system 
>with the broken compiler. And to satisfy your agument that people may need to be able 
>to use it, provide a reverse patch to remove this safeguard in one easy cat file | 
>patch.

No. There are *many* other compilers out there which are much *more* broken
then anything RedHat has recently shipped. Unfortunatly, there is no easy
way to accuratly test for such bugs (because once they can be boiled down to
a simple test they are very rapidly fixed, what's left is voodoo).

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

Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todowith ECN)

[David S. Miller]

jamal writes:
 > > So, now you have to ask how well any given NIC follows chains of
 > > buffers. At what number of buffers is the overhead in the NIC of
 > > following the chains enough to keep it from achieving link-rate?
 > >
 > 
 > hmmm... not sure how you would enforce this today or why you would
 > want that. Alexey, Dave?
 > The kernel should be able to break it into two buffers(with netperf,
 > for example -- header + data).
 > Ok, probably with tux-http 3 (header, data, trailler).

First, just to make sure Jamal understands what Rick Jones is
trying to make note of.  He is trying to say that the cost of
dealing with extra TX descriptor ring entries can begin to
nullify the gains of zerocopy, depending upon HW implementation (both
at the NIC and the PCI controller).

Back to today, it is possible that this is an issue if your machine
is near PCI bandwidth saturation before zerocopy for these tests.
I think this may be one of the factors causing Jamal to see results
Alexey cannot reproduce.  Get two people with identical PCI host
bridges, Acenic in identical PCI slot, I bet the numbers begin to
jive.

Currently, you get "1 + ((MTU + PAGE_SIZE - 1) / PAGE_SIZE)" buffers
per packet when going over a zerocopy device using TCP.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: "kaweth" usb ethernet driver in 2.4?

[Dunlap, Randy]

It was posted on linux-usb-devel on 28-jan-2001.
Find some email archive for it, or I can forward it
to you...

~Randy

> -Original Message-
> From: Michael Rothwell [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, February 04, 2001 6:17 PM
> To: Eric Sandeen
> Cc: [EMAIL PROTECTED]
> Subject: Re: "kaweth" usb ethernet driver in 2.4?
> 
> 
> Thanks. Has Brad Hards made his version available somewhere?
> -M
> 
> - Original Message -
> From: "Eric Sandeen" <[EMAIL PROTECTED]>
> To: "Michael Rothwell" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, February 04, 2001 9:30 AM
> Subject: Re: "kaweth" usb ethernet driver in 2.4?
> 
> 
> > Michael Rothwell wrote:
> >
> > > > It also doesn't seem to work in 2.2.  :)  The original 
> development of
> > > > this driver was going on at 
> http://drivers.rd.ilan.net/kaweth/ but
> there
> > > > have been no updates for quite some time.
> > >
> > > Well, it doesn't work you _you_ on 2.2, obviously. But it 
> works for us
> > > and other people. Can you provide any information to diagnose the
> > > problem you're having?
> >
> > I'm sorry, I should have provided that info.  I searched 
> the 'net, and
> > saw many people with problems on several mailing lists, and saw no
> > solutions, or reports of success, so I assumed that it was 
> a widespread,
> > possibly even known, problem with the driver.
> >
> > I'll preface this by saying that Brad Hards sent me an 
> updated version
> > that works much better, at least as long as the module is 
> loaded before
> > the device is plugged in.
> >
> > But here's what I get with a 2.2 kernel and the stock driver:
> >
> > Kawasaki USB->Ethernet Driver loading...
> > usb.c: registered new driver kaweth
> > usb.c: USB new device connect, assigned device number 2
> > Kawasaki Device Probe (Device number:2): 0x0846:0x1001
> > Device at c2192600
> > Descriptor length: 12 type: 1
> > NetGear EA-101 connected...
> > Reading kaweth configuration
> > Request type: c0  Request: 0  Value: 0 Index: 0 Length: 12
> > usb-uhci.c: interrupt, status 2, frame# 1929
> > kaweth control message failed (urb addr: c2c05ca0)
> > usb_control/bulk_msg: timeout
> > usb-uhci.c: interrupt, status 2, frame# 851
> > Actual length: 0, length 18
> > Resetting...
> > usb-uhci.c: interrupt, status 2, frame# 854
> > Downloading firmware at c48abb6c to kaweth device at c31be000...
> > Firmware length: 3838
> > Request type: 40  Request: ff  Value: 0 Index: 0 Length: efe
> > usb-uhci.c: interrupt, status 2, frame# 871
> > kaweth control message failed (urb addr: c213ab60)
> > usb-uhci.c: interrupt, status 2, frame# 877
> > usb-uhci.c: interrupt, status 2, frame# 882
> > Actual length: 0, length 3838
> > Error downloading firmware (-110), no net device created
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Hot swap CPU support for 2.4.1

[Frank Davis]

Hello,
   Which archs still need to implement it? I briefly looked over the patch and noticed 
that it had i386, ppc, mips64, and s390 already there.
Regards,
Frank

>Hi all,
>
>I did the infrastructure, Anton did the bugfinding and PPC >support,
>aka. the hard stuff.  Other architectures need to implement
>__cpu_disable, __cpu_die and __cpu_up for them to work.  >Volunteers
>appreciated.


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

nvidia fb 0.9.0

[Louis Garcia]

I gave upgraded to 2.4.2pre on my RH7 box and while using riva-128 fb 
noticed when in X all the white parts of my desktop are to dark, it is 
almost unreadable. I think it might have to do with video timing, is 
there a way to fix this?

Lou

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

RE: system call sched_yield() doesn't work on Linux 2.2

[Robert Guerra]

David,
please try to reply courteously to queries by other people. And specially
when you're the one who's wrong. Mohit is right - Linux had a 
long standing problem where sched_yield() system call didn't work. It 
was only fixed in Linux 2.4. 

> > Also, it is NOT unrealistic to expect perfect alternation.
>
>   Find one pthreads expert who agrees with this claim. Post it to
> comp.programming.threads and let the guys who created the standard 
> laugh at you. Scheduling is not a substitute for synchronization, ever.

I don't claim mastery over threads. But I have been programming with threads
for a very long time and am well aware of the way OS schedulers
work. In the example that Mohit posted, it is reasonable to expect 
perfect alternation once both threads have started. And it certainly isn't
something to laugh at (even if it were wrong).


- Robert Guerra





Get free email and a permanent address at http://www.netaddress.com/?N=1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Wavelan IEEE driver

[Eric Molitor]

I dropped a patch to 2.4.1 with the updated wavelan driver at the
following locations. It should work with the new firmware. (Its the 1.06
wavelan driver)

http://www.molitor.org/wavelan/
http://omega.uta.edu/~emm7993/wavelan/

- Eric Molitor
  Please CC me on the reply as I'm not on the kernel mailing list...

On Wed, 31 Jan 2001, Tobias Ringstrom wrote:

> On Tue, 30 Jan 2001, Jurgen Botz wrote:
> > and appears to work.  I did observe a problem with iwconfig dumping
> > core, but it seems to do its job before it dies, so this may be non-
> > critical.
> 
> Make sure you compile wireless-tools using the right headers.  You must
> manually insert -I/path/to/running-linux-version/include in the Makefile.
> 
> This is due to a bad (non-existing) ioctl backward and forward
> compatibility, and is being worked on.  Basically, you cannot use the
> tools compiled with one version of the wireless extension headers on a
> kernel with another version of the wireless extensions.  The symptom is at
> best a SEGV, but you may also get strange values.
> 
> /Tobias
> 
> 
> 
> 



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

Re: Dual Promise Ultra66 PCI Cards

[Adrian Chung]

On Mon, Feb 05, 2001 at 02:11:03AM -0200, Carlos Carvalho wrote:
> Adrian Chung ([EMAIL PROTECTED]) wrote on 4 February 2001 15:53:
>  >I've been attempting to get two Promise Ultra66 controllers working
>  >with an Asus P2B-F motherboard.  I've got one controller successfully
>  >working, but as soon as I stick the second controller in the computer,
>  >the system refuses to boot.
>  >
>  >With 2.2.18 and the linux-ide patches (Uniform E-IDE 6.30), the
>  >computer refuses to boot if there are no bootable drives on the
>  >motherboard's IDE controllers.
> 
> The same happens with a P2B-DS. It has nothing to do with the kernel,
> the bios doesn't try to boot (from floppy in my case).

The BIOS doesn't try to boot, but if I switch my bootable linux drive
from the Ultra66 to the motherboard's controller, it boots just fine.
Up until it detects ide devices and tries to scan the hard drives.

Then linux just hangs...

--
Adrian Chung - [EMAIL PROTECTED]

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

Re: Dual Promise Ultra66 PCI Cards

[Carlos Carvalho]

Adrian Chung ([EMAIL PROTECTED]) wrote on 4 February 2001 15:53:
 >I've been attempting to get two Promise Ultra66 controllers working
 >with an Asus P2B-F motherboard.  I've got one controller successfully
 >working, but as soon as I stick the second controller in the computer,
 >the system refuses to boot.
 >
 >With 2.2.18 and the linux-ide patches (Uniform E-IDE 6.30), the
 >computer refuses to boot if there are no bootable drives on the
 >motherboard's IDE controllers.

The same happens with a P2B-DS. It has nothing to do with the kernel,
the bios doesn't try to boot (from floppy in my case).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Albert D. Cahalan]

Brian Wolfe writes:

> I hate to say it but I think Hans might have the right answer here.
> As an administrator that has worked in large multi hundred million
> dollar companies where 1 hour of downtime == $75,000 in lost income
...
> From the debate raging here is what I gathered is acceptable
> 
> make it blow up fataly and immediatly if it detects Red Hat +
> gcc 2.96-red_hat_broken(forgot version num) make it provide a URL
> to get the patch to remove this safeguard if you really want this.
>
> The fatal crash should be VERY carefull to only trigger on a redhat
> system with the broken compiler. And to satisfy your agument that
> people may need to be able to use it, provide a reverse patch to
> remove this safeguard in one easy cat file | patch.

There is another way: directly test for the bug.

In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: system call sched_yield() doesn't work on Linux 2.2

[Mohit Aron]

>   I'm using 2.4.1-pre10, glibc 2.1.3.

And I'm using Linux 2.2. And the sched_yield bug exists in Linux 2.2. I
found 
a huge number of posted bug reports on linux-kernel regarding this issue. 
Check http://boudicca.tux.org/hypermail/linux-kernel/2000week21/0858.html
for one.


>   Thread1
>   Thread1
>   Thread1
>   Thread1
>   Thread1
>   Thread2
>   Thread2
>   Thread2
>   Thread2
>   Thread2
>
>   That's totally reasonable, although you probably just forgot to
fflush.

Maybe to you. Not to anyone else who knows anything about systems. FYI,
stdout
is line buffered - so a printf ending in a "\n" is an automatic flush.


>   It's also possible Thread1 did all its work, yields and all, before
Thread2
> even got started. Thus Thread1 had no 'ready to run' thread to yield to.
> (The main thread may not have been ready to run, it may still have been
> waiting to synchronize to the new thread it created.)

What synchronization ? Even if thread1 started before main thread has a
chance to
create thread2, the first sched_yield would give main thread a chance to
create 
thread2. 


>   Find one pthreads expert who agrees with this claim. Post it to
> comp.programming.threads and let the guys who created the standard laugh
at
> you. Scheduling is not a substitute for synchronization, ever.

I for one am one. And I find your statement about laughable. Try posting
your
stuff on comp.programming.threads and see if you don't get the laughter that

you're expecting is lying in wait for me. Here is simple 
logic for you to figure out - if you have one run queue, and two threads
calling sched_yield() (and hence theoretically putting themselves at the end
of run queue), perfect alternation should be seen. Also, who's said I'm
trying to
synchronize based on scheduling - sched_yield() just isn't working, that's
all.


>   Your reasoning is totally invalid and ignores so many possible other
>factors. For example, who says that the writes that your threads are doing
> don't block?

If the printfs are blocking, then there's even more reason that the other
thread should run. And print its stuff. Put some pressure on your brain and
it might come to you.

>   I'm not sure I understand what this has to do with anything. If you
think
>so, then I don't think you appreciate with a standard actually is. Perfect
>alternation is reasonable, expecting perfect alternation is not. Probably
>the reason you got perfect alternation in Solaris is because you only had
>one kernel execution vehicle. Try it with system contention scope threads.


My Linux system is also idle. Even if one assumes that a sched_yield causes 
some other process to run on the CPU, the thread that caused sched_yield is
theoretically the last on the run queue. Hence no matter what other system
process is run first, the other thread should always run before the thread
that called sched_queue. Again my point of putting some pressure on your
brain ...

Also, I won't reply any further to anything you post. If you don't
understand
systems, kindly stay out of this discussion.


- Mohit

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

[PATCH] Hot swap CPU support for 2.4.1

[Rusty Russell]

Hi all,

I did the infrastructure, Anton did the bugfinding and PPC support,
aka. the hard stuff.  Other architectures need to implement
__cpu_disable, __cpu_die and __cpu_up for them to work.  Volunteers
appreciated.

This patch allows you to down & up CPUs as follows:
# echo 0 > /proc/sys/cpu/0/online
# echo 1 > /proc/sys/cpu/0/online

The relatively trivial patch works as follows:

1) Implements synchronize_kernel() (thanks Andi Kleen for forwarding
   Paul McKenney's quiescent-state ideas) which waits for a schedule
   on all CPUs.
2) All CPU numbers are now physical: removes cpu_number_map,
   cpu_logical_map and smp_num_cpus.
3) Adds cpu_online(cpu) and cpu_num_online() macros.
4) Adds cpu_down() and cpu_up() calls, which call arch-specific
   __cpu_disable(cpu), __cpu_die(cpu) and __cpu_up(cpu).
5) Fixes schedule() to check allowed_cpus even if rescheduling same
   task.

Since it's 60k long, mime attached bzip2.

Go hack!
Rusty Russell & Anton Blanchard
--

 hotswap CPU patch

Re: raid-1 with raid-0 and normal disk -> performance and autostart?

[Neil Brown]

On Thursday February 1, [EMAIL PROTECTED] wrote:
> hi,
> i using kernel 2.4.1. mkraid version 0.90.0
> i build /dev/md0 raid-0 with hda5 and sda1. then i build /dev/md1 raid-1 
> with /dev/md0 and sdb1.
> it works fine.
> BUT the resync takes a long time. i have a performance from 253K/sec. 
> whats there wrong?

The resync code tries to detect other (non-resync) IO on the devices
and throttle back the resync process if there is any other IO.
Because you can build a RAID array from partitions, and because it is
IO to the device rather than the partition that md wants to meausure,
md needs to figure out what actual device the IO is on, and keep track
of that.

When one of the underlying devices is a raid0 array, md fails to guess
properly and I suspect that this is causing the problem.  It is
concluding that there is always IO to that device, and constantly
throttling.

You can control the throttling with
   /proc/sys/dev/raid/speed_limit_min
and
   /proc/sys/dev/raid/speed_limit_max

If you put a nice big number in speed_limit_min, it should rebuild
more quickly for you, at the cost of interfering with any other IO to
the device.

NeilBrown

> [root@mendocino  /root]# cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid5]
> read_ahead 1024 sectors
> md0 : active raid1 md1[1] sdb1[0]
>   8891712 blocks [2/2] [UU]
>   [>]  resync =  0.0% (5572/8891712) 
> finish=581.8min speed=253K/sec
> md1 : active raid0 sda1[1] hda5[0]
>   8891776 blocks 4k chunks
> 
> unused devices: 
> 
> if i build a raid-1 with sdb1 and hda5 i get:
> 
> Personalities : [linear] [raid0] [raid1] [raid5]
> read_ahead 1024 sectors
> md0 : active raid1 sdb1[1] hda5[0]
>   4449920 blocks [2/2] [UU]
>   [>]  resync =  0.4% (21952/4449920) 
> finish=10.0min speed=7317K/sec
> unused devices: 
> 
> i get the same speer also with sda1 and sdb1.
> any ideas?
> 
> i will mount the raid-10 (or 01???) as "/". but the autodetection 
> doesn't work corect. the partitions are all "Linux raid autodetect". the 
> raid-0 starts fine. if he tries to start the raid-1 the dev md0 will not 
> integrated in the array. must i start a ramdisk, and starting there 
> manuell the raid-1? if i change md1 and md0 it's the same.
> 
> THNX
> CU
> daniel
> 
> 
> raidtab:
> 
> raiddev /dev/md0
> raid-level0
> nr-raid-disks 2
> persistent-superblock 1
> chunk-size4
> 
> device/dev/hda5
> raid-disk 0
> device/dev/sda1
> raid-disk 1
> 
> raiddev /dev/md1
> raid-level1
> nr-raid-disks 2
>persistent-superblock 1 # i tried also 0 here
> chunk-size4
> 
> device/dev/sdb1
> raid-disk 0
> device/dev/md0
> raid-disk 1
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]

Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)

[Rogerio Brito]

On Feb 05 2001, Jens Axboe wrote:
> On Sat, Feb 03 2001, [EMAIL PROTECTED] wrote:
> > Feb  3 22:08:25 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
> > Feb  3 22:08:25 Line kernel: hdb: DMA disabled
> > Feb  3 22:08:55 Line kernel: hdb: ATAPI reset timed-out, status=0x90
> > Feb  3 22:08:55 Line kernel: hda: DMA disabled
> 
> Try disabling DMA on the drive before accessing it. 

Well, this has nothing to do with the above, but is there any
utility or /proc entry that lets me say to my CD drive that it
should not work at full speed?

Basically, some drives make way too much noise when they're
operating at full speed. When I'd like to listen to some MP3s
from a burned CD-R, what I'm currently doing is copying the
files that I want to /tmp and listening from there, but this
is obviously a dirty solution. :-(


Thanks in advance for any hints, Roger...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[Patch] 3Com 3c523: Can't load module in kernel 2.4.1

[Tom Sightler]

Ok all, here's a patch that attempts to make the 3c523 driver work again in 2.4.1.  It 
includes the following changes:


- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets

It passed basic stress testing with multiple, simultaneous ftp transfers.

Know bugs:

- Multicast still doesn't work at all (I have patches that seem to fix this but they 
have other problems)
- Still drops packets under heavy traffic (can be reduced further by lowering MTU on 
interface)
- Sometimes requires host to send a packet before it starts receiving (I can't 
reproduce this on my equipment anymore, but needs more testing)

Anyone with this card please test and report back.

Later,
Tom


--- 3c523.c.241 Fri Feb  2 21:09:20 2001
+++ 3c523.c Sun Feb  4 21:02:18 2001
@@ -148,9 +148,9 @@

  #define RECV_BUFF_SIZE 1524   /* slightly oversized */
  #define XMIT_BUFF_SIZE 1524   /* slightly oversized */
-#define NUM_XMIT_BUFFS 4   /* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8  1/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1   /* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8  4/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9/* config for 16K shared mem */

  #if (NUM_XMIT_BUFFS == 1)
  #define NO_NOPCOMMANDS/* only possible with NUM_XMIT_BUFFS=1 */
@@ -303,13 +303,13 @@
char *iscp_addrs[2];
int i = 0;

- 
p->base = where + size - 0x0100;
- 
p->memtop = phys_to_virt(where) + size;
- 
p->scp = (struct scp_struct *)phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
+ 
p->base = (unsigned long) bus_to_virt((unsigned long)where) + size - 0x0100;
+ 
p->memtop = bus_to_virt((unsigned long)where) + size;
+ 
p->scp = (struct scp_struct *)(p->base + SCP_DEFAULT_ADDRESS);
memset((char *) p->scp, 0, sizeof(struct scp_struct));
p->scp->sysbus = SYSBUSVAL; /* 1 = 8Bit-Bus, 0 = 16 Bit */

- 
iscp_addrs[0] = phys_to_virt(where);
+ 
iscp_addrs[0] = bus_to_virt((unsigned long)where);
iscp_addrs[1] = (char *) p->scp - sizeof(struct iscp_struct);

for (i = 0; i < 2; i++) {
@@ -325,6 +325,7 @@

/* apparently, you sometimes have to kick the 82586 twice... */
elmc_id_attn586();
+ 
DELAY(1);

if (p->iscp->busy) {/* i82586 clears 'busy' after successful init 
*/
 
return 0;
@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);

- 
p->scp = (struct scp_struct *) phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
- 
p->scb = (struct scb_struct *) phys_to_virt(dev->mem_start);
+ 
p->scp = (struct scp_struct *) (p->base + SCP_DEFAULT_ADDRESS);
+ 
p->scb = (struct scb_struct *) bus_to_virt(dev->mem_start);
p->iscp = (struct iscp_struct *) ((char *) p->scp - sizeof(struct 
iscp_struct));

memset((char *) p->iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev->mem_end = dev->mem_start + size;   /* set mem_end showed by 'ifconfig' */

- 
((struct priv *) (dev->priv))->base = dev->mem_start + size - 0x0100;
+ 
((struct priv *) (dev->priv))->memtop = bus_to_virt(dev->mem_start) + size;
+ 
((struct priv *) (dev->priv))->base = (unsigned long) bus_to_virt(dev->mem_start) + 
size - 0x0100;
alloc586(dev);

elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@
 
if (skb != NULL) {
 
skb->dev = dev;
 
skb_reserve(skb, 2);/* 16 byte alignment */
- 
memcpy(skb_put(skb, totlen), (u8 
*)phys_to_virt(p->base) + (unsigned long) rbd->buffer, totlen);
+ 
skb_put(skb,totlen);
+ 
eth_copy_and_sum(skb, (char *) p->base+(unsigned long) 
rbd->buffer,totlen,0);
 
skb->protocol = eth_type_trans(skb, dev);
 
netif_rx(skb);
 
p->stats.rx_packets++;
@@ -1086,6 +1089,7 @@
  static int elmc_send_packet(struct sk_buff *skb, struct net_device *dev)
  {
int len;
+ 
int i;
  #ifndef NO_NOPCOMMANDS
int next_nop;
  #endif

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

Re: 2.4.2-pre1 won't boot on my SMP P-II

[Bryan W. Headley]

Mikael Pettersson wrote:

> Bryan W. Headley writes:
> > Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
> > where the issue is at, so I attach a log of the system booting up.
> >
> > It's an ASUS P2B-DS with dual Deschutes PII-450s.
>
> > Linux version 2.4.2-pre1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 
>(Red Hat Linux 7.0)) #1 SMP Sun Feb 4 15:57:05 CST 2001
>
> gcc 2.96 -- is this the vanilla RH7.0 gcc or the updated one? The vanilla one
> is known to miscompile stuff. Use kgcc, 2.95.2, or the updated RH7.0 gcc.
>

The updated one. On suggestion, I upgraded the BIOS which seems to have fixed the 
issue.

>
> > md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
> > md.c: sizeof(mdp_super_t) = 4096
> > autodetecting RAID arrays
> > autorun ...
> > ... autorun DONE.
> > ACPI: Core Subsystem version [20010125]
> > LNMI Watchdog detected LOCKUP on CPU0, registers:
> > CPU:0
> > EIP:0010:[]
> > EFLAGS: 0086
> > eax:    ebx: 000f8040   ecx: 0001   edx: c0272b42
> > esi: cfd6ff70   edi: cfd6e331   ebp:    esp: cfd6ff48
> > ds: 0018   es: 0018   ss: 0018
> > Process kacpid (pid: 7, stackpage=cfd6f000)
> > Stack: 0286 0007 00c7 c01c10c1 000f8040 cfd6ff70 cfd6e331 
> >c01d47fa c0272b42 003c cfd6ffa0 000f8040   
> >  cfd6e000  0001 cfd6e000 20010125 0003
> > Call Trace: [] [] [] [] []
> >
> > Code: 80 3d 20 50 29 c0 00 f3 90 7e f5 e9 93 5c ee ff 80 3d 20 50
> > console shuts up ...
>
> The NMI watchdog detected an apparent lockup (interrupts masked
> for too long) during boot. This is fatal. Note that the last message
> before the oops mentioned "ACPI" and the process killed is "kacpid".
> Hmm, I don't know how well ACPI works on SMP (or at all), but you
> should try a new kernel built with ACPI disabled.
>
> /Mikael

--
   .:. 
Bryan W. Headley - [EMAIL PROTECTED]


N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ zÚ&j:+v‰¨¾«‘êçzZ+€ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i

Re: More on the VIA KT133 chipset misbehaving in Linux

[Rogerio Brito]

On Feb 02 2001, Dunlap, Randy wrote:
> > From: Rogerio Brito [mailto:[EMAIL PROTECTED]]
> > 
> > While I don't have problems with the Duron above, I do have a
> > 486 here with 8MB of memory that I intend to use as a router
> > for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18
> > recognizes all 8MB.
> 
> Fixed in 2.4.1 and its pre-patches.

Thank you very much, Randy. I'll compile 2.4.1 or anything
newer than this and I'll report back my results.


Thank you very much again, Roger...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.2-pre1 won't boot on my SMP P-II

[Mikael Pettersson]

Bryan W. Headley writes:
> Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
> where the issue is at, so I attach a log of the system booting up.
> 
> It's an ASUS P2B-DS with dual Deschutes PII-450s.

> Linux version 2.4.2-pre1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 
>(Red Hat Linux 7.0)) #1 SMP Sun Feb 4 15:57:05 CST 2001

gcc 2.96 -- is this the vanilla RH7.0 gcc or the updated one? The vanilla one
is known to miscompile stuff. Use kgcc, 2.95.2, or the updated RH7.0 gcc.

> md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
> md.c: sizeof(mdp_super_t) = 4096
> autodetecting RAID arrays
> autorun ...
> ... autorun DONE.
> ACPI: Core Subsystem version [20010125]
> LNMI Watchdog detected LOCKUP on CPU0, registers:
> CPU:0
> EIP:0010:[]
> EFLAGS: 0086
> eax:    ebx: 000f8040   ecx: 0001   edx: c0272b42
> esi: cfd6ff70   edi: cfd6e331   ebp:    esp: cfd6ff48
> ds: 0018   es: 0018   ss: 0018
> Process kacpid (pid: 7, stackpage=cfd6f000)
> Stack: 0286 0007 00c7 c01c10c1 000f8040 cfd6ff70 cfd6e331  
>c01d47fa c0272b42 003c cfd6ffa0 000f8040    
>  cfd6e000  0001 cfd6e000 20010125 0003 
> Call Trace: [] [] [] [] [] 
> 
> Code: 80 3d 20 50 29 c0 00 f3 90 7e f5 e9 93 5c ee ff 80 3d 20 50 
> console shuts up ...

The NMI watchdog detected an apparent lockup (interrupts masked
for too long) during boot. This is fatal. Note that the last message
before the oops mentioned "ACPI" and the process killed is "kacpid".
Hmm, I don't know how well ACPI works on SMP (or at all), but you
should try a new kernel built with ACPI disabled.

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

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Brian Wolfe]

I hate to say it but I think Hans might have the right answer here. As an 
administrator that has worked in large multi hundred million dollar companies where 1 
hour of downtime == $75,000 in lost income proactive prevention IS the right answer. 
If the gcc people need to compile with the .96 rh version then they can apply a 
removal patch hans provides in the crash message. This makes it easy to remove the 
safeguard and blow yourself up at will after being suitibly called a dumbass.

I do understand your desire to keep things simple and not put a safetynet out 
for every single moron out there. Personaly I despise them. But I also understand the 
evil necessity of doign this for somet hings that are this serious of a risk.

From the debate raging here is what I gathered is acceptable

make it blow up fataly and immediatly if it detects Red Hat + gcc 
2.96-red_hat_broken(forgot version num)
make it provide a URL to get the patch to remove this safeguard if you really want 
this.

The fatal crash should be VERY carefull to only trigger on a redhat system 
with the broken compiler. And to satisfy your agument that people may need to be able 
to use it, provide a reverse patch to remove this safeguard in one easy cat file | 
patch.

Brian Wolfe

On Sat, Feb 03, 2001 at 01:06:52AM +0300, Hans Reiser wrote:
> Alan Cox wrote:
> > 
> > > As it stands, there is no way to determine programatically whether
> > > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > > version -- which, needless to say, is a bit difficult to do from the
> > > C code about to be compiled. So I can't really blame Hans if he decides
> > > to outlaw gcc-2.96[.0] for reiserfs compiles.
> > 
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #warning in nobody will
> > read it and if you dont put anything in you get the odd bug report anyway.
> > 
> > Basically you can't win and unfortunately a shrink wrap forcing the user
> > to read the README file for the kernel violates the GPL ..
> > 
> > Jaded, me ?
> > 
> > Alan
> 
> I fear that you are speaking from experience about the complaints it doesn't
> build, and that there is a strong element of truth in what you say.
> 
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
> 
> Hans

 PGP signature

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Miles Lane]

As we look into developing PCMCIA support in the
2.4/2.5 kernel trees, in addition to reading the
pcmcia-cs code to learn about problems with specific
devices that need to be handled, David Hinds also
a reference page that lists some a bunch of issues
that are in varying degrees of resolution:

http://pcmcia-cs.sourceforge.net/ftp/BUGS

This may be a useful resource.  I'll see whether
David has time to update this page with a bit more
detailed explanations of the problems.  Some of the
items are pretty vague.  For example,

the Asix AX88190 chipset, which has
several serious bugs and incompatibilities
that render the regular pcnet_cs driver
unusable

It would be nice to know exactly what those bugs
and incompatibilities are.  :-)

Anyhow, I hope this helps,

Miles

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

[PATCH] [BUGFIX] [RESEND, goddammit!] important fixes for ieee1394 subsystem

[Andreas Bombe]

I have sent the following patch three times to you during 2.4.1 prepatch
time and you seem to have missed all of them (Jan 15, 19 and 25).  I
hope we can manage that for 2.4.2 and get the known bugs with fixes out
of the ieee1394 subsystem.  Finally.

Please, either show some sign of life by replying or making a 2.4.2-pre
patch with this included this week.  Thanks to the subsystem not being
modified the same patch from 2.4.0 times applies to 2.4.2-pre1.

* It completes the adaption to the new task queue structure.  Instead of
  plain INIT_LIST_HEAD internal macros are used to make backporting to
  2.2 easy (fixes 1 oops, the rest makes initialization just clean).   

* PCILynx bus reset handling was modified to make it much more robust
  with multiple bus resets in quick succession (fixes possible driver
  hangs).

* The definition of ohci_csr_rom was moved from ohci1394.h to
  ohci1394.c.  The header file is also included in video1394.c (fixes
  build failure when neither ohci1394 nor video1394 are configured as
  module or not built).  There is apparantly a different patch for this
  in Alan's tree.

* Five symbols in pcilynx.h were renamed to something more descriptive.
  Not a bug fix, but it's so small...



diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c 
linux-2.4.linus/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c  Mon Jan  1 23:17:36 2001
+++ linux-2.4.linus/drivers/ieee1394/guid.c Mon Feb  5 02:59:17 2001
@@ -163,7 +163,7 @@
 return;
 }
 
-INIT_LIST_HEAD(&greq->tq.list);
+INIT_TQ_LINK(greq->tq);
 greq->tq.sync = 0;
 greq->tq.routine = (void (*)(void*))pkt_complete;
 greq->tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c 
linux-2.4.linus/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan  1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/hosts.cMon Feb  5 02:59:17 2001
@@ -106,6 +106,7 @@
 sema_init(&h->tlabel_count, 64);
 spin_lock_init(&h->tlabel_lock);
 
+INIT_TQ_LINK(h->timeout_tq);
 h->timeout_tq.routine = (void (*)(void*))abort_timedouts;
 h->timeout_tq.data = h;
 
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c 
linux-2.4.linus/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan  1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_core.cMon Feb  5 02:59:17 2001
@@ -98,6 +98,7 @@
 packet->data_size = data_size;
 }
 
+INIT_TQ_HEAD(packet->complete_tq);
 INIT_LIST_HEAD(&packet->list);
 sema_init(&packet->state_change, 0);
 packet->state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h 
linux-2.4.linus/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan  2 05:53:39 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_types.h   Mon Feb  5 02:59:17 2001
@@ -15,6 +15,9 @@
 #define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
 #define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
 #define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD(&(tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD(&(tq))
 #endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c 
linux-2.4.linus/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c  Thu Jan 11 01:34:32 2001
+++ linux-2.4.linus/drivers/ieee1394/ohci1394.c Mon Feb  5 02:59:17 2001
@@ -97,6 +97,81 @@
 #include "ieee1394_core.h"
 #include "ohci1394.h"
 
+
+/* This structure is not properly initialized ... it is taken from
+   the lynx_csr_rom written by Andreas ... Some fields in the root
+   directory and the module dependent info needs to be modified
+   I do not have the proper doc */
+quadlet_t ohci_csr_rom[] = {
+/* bus info block */
+0x0404, /* info/CRC length, CRC */
+0x31333934, /* 1394 magic number */
+0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
+0x, /* vendor ID, chip ID high (written from card info) */
+0x, /* chip ID low (written from card info) */
+/* root directory - FIXME */
+0x0009, /* CRC length, CRC */
+0x03080028, /* vendor ID (Texas Instr.) */
+0x8109, /* offset to textual ID */
+0x0c000200, /* node capabilities */
+0x8d0e, /* offset to unique ID */
+0xc710, /* offset to module independent info */
+0x0400, /* module hardware version */
+0x8126, /* offset to textual ID */
+0x0900, /* node hardware version */
+0x8126, /* offset to textual ID */
+/* module vendor ID textual */
+0x0008, /* CRC length, CRC */
+0x,
+0x,
+0x54455841, /* "Texas Instruments" */
+ 

Re: [OT] Major Clock Drift

[Michael B. Trausch]

On Sun, 4 Feb 2001, Tom Eastep wrote:

> Thus spoke Michael B. Trausch:
> 
> > On Sat, 3 Feb 2001, Josh Myer wrote:
> >
> > > Hello all,
> > >
> > > I know this _really_ isn't the forum for this, but a friend of mine has
> > > noticed major, persistent clock drift over time. After several weeks, the
> > > clock is several minutes slow (always slow). Any thoughts on the
> > > cause? (Google didn't show up anything worthwhile in the first couple of
> > > pages, so i gave up).
> > >
> >
> > I'm having the same problem here.  AMD K6-II, 450 MHz, VIA Chipset, Kernel
> > 2.4.1.
> >
> 
> 
> The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
> rather than atyfb because the latter screws up X.
> 

I'm not using any framebuffer on my machine (I have an ATI 3D Rage 128
Pro, myself).  I use the standard 80x50 console, and X when I need
it.  I'm about to put Debian on the system and see how that works and if I
like it, I just got the .ISO of disc 1 downloaded (after about a week) and
now it's burning.  (I hate having a 33.6 connection!)

However the clock drift didn't happen as much, if at all, with 2.2.xx
kernels.  It's kept itself pretty well sane.  But now I'm losing something
on the order of a half hour a week - that didn't happen before.

- Mike

===
Michael B. Trausch[EMAIL PROTECTED]
Avid Linux User since April, '96!   AIM:  ML100Smkr

  Contactable via IRC (DALNet) or AIM as ML100Smkr
===

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

Re: Adding PCMCIA support to the kernel tree -- developers needed.

[Jeff Garzik]

Miles Lane wrote:
> 
> Jeff Garzik wrote:
> >
> > On Fri, 2 Feb 2001, Miles Lane wrote:
> > > I asked David Hinds to write up an outline of the things that
> > > will be needed to get PCMCIA support cleanly and completely
> > > integrated into the kernel tree.
> > >
> > > David has expressed that he'll not be able to participate in
> > > this work.  He has his hands full with his day job and his
> > > role as maintainer/developer of the pcmcia-cs package.
> > [...]
> > > Anyone willing to sign up for some of this effort?
> >
> > I'll convert all the network drivers once a design is agreed upon.
> 
> Would you write up a proposal for this design that we could work
> from to come to a agreed design?  You are probably the best person
> to start this process.

I'm going to finish my current projects first :)

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ATAPI CDRW which doesn't work

[Jens Axboe]

On Sat, Feb 03 2001, [EMAIL PROTECTED] wrote:
> Feb  3 22:08:25 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
> Feb  3 22:08:25 Line kernel: hdb: DMA disabled
> Feb  3 22:08:55 Line kernel: hdb: ATAPI reset timed-out, status=0x90
> Feb  3 22:08:55 Line kernel: hda: DMA disabled

Try disabling DMA on the drive before accessing it. 

-- 
Jens Axboe

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

Re: System unresponsitive when copying HD/HD

[Jens Axboe]

On Sun, Feb 04 2001, LA Walsh wrote:
>   Seems to have gotten a bit worse.  Vmstat output after 'vmware' had completed
> write -- but system unresponsive and writing out a 155M file...

Your numbers seem way too much off to have much to do with i/o scheduling
fairness, but there is a slight bug due to the merge and insertion scan
being done at once now. So you could try with attached patch and see
if it makes any difference whatsoever.

>   Those columns are output from a 'vmstat 5'.  Meaning it took about 70 seconds
> to write out 158M.  Or about 2.2M/s.  That's probably not bad.  It still locks
> up the system for over a minute though -- which is really undesirable performance
> for interactive use.  I'm guessing the vmstat output numbers are showing 4K? 8K? 
> blocks?  8K would about make sense for the 2.2M average.

Most likely 4kB blocks. I'd say the numbers are pretty bad...

-- 
Jens Axboe



--- /opt/kernel/linux-2.4.2-pre1/drivers/block/elevator.c   Tue Jan 30 13:32:10 
2001
+++ drivers/block/elevator.cMon Feb  5 01:26:49 2001
@@ -35,6 +35,7 @@
struct list_head *entry = &q->queue_head;
unsigned int count = bh->b_size >> 9, ret = ELEVATOR_NO_MERGE;
 
+   *req = NULL;
while ((entry = entry->prev) != head) {
struct request *__rq = blkdev_entry_to_request(entry);
 
@@ -46,10 +47,13 @@
break;
}
 
+
if (__rq->sem)
continue;
if (__rq->cmd != rw)
continue;
+   if (!*req && BHRQ_IN_ORDER(bh, __rq))
+   *req = __rq;
if (__rq->rq_dev != bh->b_rdev)
continue;
if (__rq->nr_sectors + count > max_sectors)
@@ -65,8 +69,7 @@
__rq->elevator_sequence -= count;
*req = __rq;
break;
-   } else if (!*req && BHRQ_IN_ORDER(bh, __rq))
-   *req = __rq;
+   }
}
 
return ret;
--- /opt/kernel/linux-2.4.2-pre1/drivers/block/ll_rw_blk.c  Tue Jan 30 13:32:10 
2001
+++ drivers/block/ll_rw_blk.c   Mon Feb  5 02:02:22 2001
@@ -628,11 +628,19 @@
&& atomic_read(&queued_sectors) < low_queued_sectors)
wake_up(&blk_buffers_wait);
 
+   if (!list_empty(&q->request_freelist[rw])) {
+   blk_refill_freelist(q, rw);
+   list_add(&req->table, &q->request_freelist[rw]);
+   if (waitqueue_active(&q->wait_for_request))
+   wake_up_nr(&q->wait_for_request, 2);
+   return;
+   }
+
/*
-* Add to pending free list and batch wakeups
+* free list is empty, add to pending free list and
+* batch wakeups
 */
list_add(&req->table, &q->pending_freelist[rw]);
-
if (++q->pending_free[rw] >= batch_requests) {
int wake_up = q->pending_free[rw];
blk_refill_freelist(q, rw);
@@ -705,7 +713,7 @@
 {
unsigned int sector, count;
int max_segments = MAX_SEGMENTS;
-   struct request * req = NULL, *freereq = NULL;
+   struct request *req, *freereq = NULL;
int rw_ahead, max_sectors, el_ret;
struct list_head *head, *insert_here;
int latency;
@@ -767,6 +775,10 @@
 
el_ret = elevator->elevator_merge_fn(q, &req, head, bh, rw,
 max_sectors, max_segments);
+   if (el_ret && q->head_active && !q->plugged
+   && req->queue.prev == &q->queue_head)
+   BUG();
+
switch (el_ret) {
 
case ELEVATOR_BACK_MERGE:

RE: accept

[David Schwartz]

> Ok, but fd 0 cant be a valid socket since its the stdin

Wrong. fd 0 can be a valid socket. Read the man page to 'accept' again.
Remember again that zero is a non-negative integer.

> I posted that on this mailing list coz I thought that this might
> be a scaling
> problem since it happens when theres already several clients
> connected to the
> server

If your code called 'perror' in response to getting a zero from 'accept',
your code is broken.

DS

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

RE: system call sched_yield() doesn't work on Linux 2.2

[David Schwartz]

> What version of Linux are you using ? What I see is the following:

I'm using 2.4.1-pre10, glibc 2.1.3.

>   Thread1
>   Thread1
>   Thread1
>   Thread1
>   Thread1
>   Thread2
>   Thread2
>   Thread2
>   Thread2
>   Thread2

That's totally reasonable, although you probably just forgot to fflush.

It's also possible Thread1 did all its work, yields and all, before Thread2
even got started. Thus Thread1 had no 'ready to run' thread to yield to.
(The main thread may not have been ready to run, it may still have been
waiting to synchronize to the new thread it created.)

> Also, it is NOT unrealistic to expect perfect alternation.

Find one pthreads expert who agrees with this claim. Post it to
comp.programming.threads and let the guys who created the standard laugh at
you. Scheduling is not a substitute for synchronization, ever.

> The definition
> of sched_yield in the manpage says that sched_yield() puts the
> thread under
> question last in the run queue. So perfect alternation should
> have occurred.

Your reasoning is totally invalid and ignores so many possible other
factors. For example, who says that the writes that your threads are doing
don't block?

> I've also tested the code on Solaris - there is perfect alternation there.

I'm not sure I understand what this has to do with anything. If you think
so, then I don't think you appreciate with a standard actually is. Perfect
alternation is reasonable, expecting perfect alternation is not. Probably
the reason you got perfect alternation in Solaris is because you only had
one kernel execution vehicle. Try it with system contention scope threads.

DS


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

[BUG] Shutting down PCMCIA driver in Linux 2.4.1, "Trying to free nonexistent resource <000003e0-000003e1>"

[Thomas Hood]

I get this message when shutting down Linux with 2.4.1 kernel,
kernel PCMCIA support compiled as a module.

-

$ cat /proc/ioports
...
03e0-03e1 : i82365
...
$ sudo reboot
(reboot)
$ grep 3e0 /var/log/messages
Feb  4 18:13:44 thanatos kernel: Trying to free nonexistent resource 
<03e0-03e1>

--

IIRC, during the shutdown sequences the "Trying ..." message appears just
after the words "Shutting down PCMCIA card services: cardmgr modules".

T. Hood
jdthood_AT_mail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: modversions.h source pollution in 2.4

[Jeff Garzik]

Keith Owens wrote:
> Maintainers: please fix these sources by removing modversions.h.
[...]
> drivers/net/epic100.c
> drivers/net/starfire.c

Fixed.

Jeff



-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

modversions.h source pollution in 2.4

[Keith Owens]

The following files explicitly include linux/modversions.h.  They
should not do this, the Makefiles are responsible for automatically
including modversions.h.  Since modversions.h will disappear in 2.5,
consider this advance warning that the offending sources can expect
problems.

Maintainers: please fix these sources by removing modversions.h.

arch/ia64/kernel/palinfo.c
drivers/char/amiserial.c
drivers/char/dtlk.c
drivers/char/ip2.c
drivers/char/ip2main.c
drivers/char/rocket.c
drivers/char/serial.c
drivers/md/lvm.c
drivers/net/eepro100.c
drivers/net/epic100.c
drivers/net/starfire.c
drivers/net/wan/lmc/lmc_main.c

The presence of symbols like foo__ver_foo is not a reason to explicitly
include modversions.h, see http://www.tux.org/lkml/#s8-8.

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

Re: d-link dfe-530 tx (bug-report)

[Thomas Stewart]

On 4 Feb 2001, at 23:31, Urban Widmark wrote:

> On Sun, 4 Feb 2001, Manfred wrote:
> 
> > Ok, I've attached a patch that performs an unconditional reset in
> > tx_timeout().
> > 
> > I don't have the hardware, could you test it?
> 
> The changed startup code doesn't break anything for me.
> 
> > I also found newer via documentation on via's ftp site:
> > ftp.via.com.tw/public/lan/Products/NIC/VT86C100A, from Sept 98
> 
> You've done even better than that:
> ftp.via.com.tw/public/lan/Products/NIC/VT6102
> :)
> 
> 
> For those of you with vt6102s that don't like being rebooted from
> win98 I have modified Manfred's patch to try and really reset the card
> at startup.
> 
> CmdReset is not instant, it may need a delay. There is also a "force
> software reset" operation that sounds good, I assume that one also
> could use a delay so I gave it 6ms.
> 
> This will probably not fix things, but it would be nice if you could
> test it as well as Manfred's variant. (I know it's painful to reboot
> into win98 all the time :)
> 
> You shouldn't have to reboot between testing each of the patches
> (assumes via-rhine.o as a module). Just make sure the module is
> unloaded and reloaded. So a single win98 trip would allow testing both
> of them.
> 
> The via-diag.c program has a bug when looking at vt6102's. They have
> 256 bytes of registers, not just 128. The attached patch fixes this
> (no need to use the -Ii switches). Checking the output again when the
> card is working and not working could give some clue. There are some
> power save states in the higher registers that look suspicious.
> 
> 0x96 contains "PHY address at suspend well"
> 0x94-0x95 contains "MII address at suspend well"
> (at suspend well == in power save mode?)
> 
> Finally, MII PHYs can be reset by setting bit15 in MII register 0.
> During the search for the PHY it could try resetting each address.
> 
> /Urban
> 

Right, i patched the via-diag and its showing more regs.

I applyed Manfred's patch but that changed nothing.
Then I applyed your patch and still changed nothing as you suspected.
But there are regs that are different.

Not working:-
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
 Station address 00:00:00:00:00:00.
 Tx disabled, Rx disabled, half-duplex (0x0004).
  Receive  mode is 0x6c: Normal unicast and hashed multicast.
  Transmit mode is 0x21: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
 0x000:  216c 0004    
07c62000 07c62120
 0x020: 0400 0600 07c61010 07c62010  0600 
07c61810 07c62020
 0x040: c000 00e0824e 07c80402 07c62120   
 feff
 0x060:    0006131f 8100 0880 
0247 
 0x080: 03012000    0680  
 
 0x0A0:       
 
 0x0C0:       
 
 0x0E0:       
 
 No interrupt sources are pending ().
  Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x110:  00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73
 ***WARNING***: No MII transceivers found!

Working:-
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
 Station address 00:50:ba:6e:d8:55.
 Tx disabled, Rx disabled, half-duplex (0x0004).
  Receive  mode is 0x6c: Normal unicast and hashed multicast.
  Transmit mode is 0x21: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
 0x000: 6eba5000 216c55d8 0004  8000  
07c620e0 07c62180
 0x020: 0400 0600 07c85010 07c620f0  0600 
07c85810 07c62000
 0x040:  00e08000  07c62190   
 fefd
 0x060:    00061108 9f00 0880 
0247 
 0x080: 00012000    0680 0008 
 
 0x0A0: 0101 0101     
 
 0x0C0:       
 
 0x0E0:       
 
 No interrupt sources are pending ().
  Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100:  00 50 ba 6e d8 55 00 00 00 00 00 00 00 00 00 00
0x110:  00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73
 MII PHY found at address 8, status 0x782d.
 MII PHY #8 transceiver registers:
   3000 782d 0016 

IDE CD writer fails on 2.4.x

[Frank van de Pol]

Though I was successfull using my cdwriter under the pre series and win98 it
fails using 2.4.x (i tested it with 2.4.0 and 2.4.2-pre1).


cd writer software in use:
Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling


caps according to hdparm:
/dev/hdd:

 Model=PHILIPS CDD3610 CD-R/RW, FwRev=V:003.01,
SerialNo=4VO22985121772100210
 Config={ Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=3900kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=yes, tPIO={min:208,w/IORDY:127}, tDMA={min:127,rec:127}
 PIO modes: pio0 pio1 pio2 pio3 
 DMA modes: sdma0 sdma1 sdma2 mdma0 *mdma1 



scsi1 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: E-IDE Model: CD-ROM 36X/AKURev: U21I
  Type:   CD-ROM ANSI SCSI revision: 02
  Vendor: PHILIPS   Model: CDD3610 CD-R/RW   Rev: 3.01
  Type:   CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 0x/36x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 2x/6x writer cd/rw xa/form2 cdda tray
VFS: Disk change detected on device sr(11,1)
attempt to access beyond end of device
0b:01: rw=0, want=34, limit=2
isofs_read_super: bread failed, dev=0b:01, iso_blknum=16, block=16
Uniform CD-ROM driver unloaded
hdb: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
scsi : aborting command due to timeout : pid 0, scsi1, channel 0, id 1, lun
0 Write (10) 00 00 00 04 5c 00 00 1f 00 
hdd: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdd: irq timeout: status=0xd0 { Busy }
hdd: DMA disabled
hdd: ATAPI reset complete
hdd: irq timeout: status=0xd0 { Busy }
hdd: ATAPI reset complete
hdd: irq timeout: status=0xd0 { Busy }
hdd: status timeout: status=0xd0 { Busy }
hdd: drive not ready for command
hdd: ATAPI reset complete
scsi1 : channel 0 target 1 lun 0 request sense failed, performing reset.
SCSI bus is being reset for host 1 channel 0.


/proc/ide/ide1/hdd/settings:

namevalue   min max mode
-   --- --- 
bios_cyl0   0   1023rw
bios_head   0   0   255 rw
bios_sect   0   0   63  rw
current_speed   33  0   69  rw
ide_scsi0   0   1   rw
init_speed  33  0   69  rw
io_32bit0   0   3   rw
keepsettings0   0   1   rw
log 0   0   1   rw
nice1   1   0   1   rw
number  3   0   3   rw
pio_modewrite-only  0   255 w
slow0   0   1   rw
transform   1   0   3   rw
unmaskirq   0   0   1   rw
using_dma   0   0   1   rw


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.2-pre1 won't boot on my SMP P-II

[Bryan W. Headley]

Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
where the issue is at, so I attach a log of the system booting up.

It's an ASUS P2B-DS with dual Deschutes PII-450s.

Anybody with a clue as to where to look, please advise. (Have other boot
logs)

--
   .:. 
Bryan W. Headley - [EMAIL PROTECTED]



 bootup-2.4.2-pre1.log

Re: [OT] Major Clock Drift

[Alan Chandler]

On Sun, 04 Feb 2001 10:31:35 -0500, you wrote:

>Technical explanations aside, some sort of clock drift exists in all 
>computers. My experience with Sun hardware, for instance, was that the 
>hardware and software clocks rarely agreed.
>
>You should set up your machines to use some sort of time synchronization 
>software, such as ntp or rdate. When I didn't have a 24/7 net presence, I had 
>my ppp script run ntpdate when the connection was complete.
>
>See http://www.eecis.udel.edu/~ntp/
>

If you don't have 24/7 net presence then chrony does a nice job of
sorting out your clock.


http://www.rrbcurnow.freeuk.com/freeuk.com/r/r/b/rrbcurnow/webspace/chrony




Alan

[EMAIL PROTECTED]
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

3 more traces, 2.4.1 this time.

[Dan Merillat]

Managed to get 2.4.1 to Oops without locking up entirely:

I have no idea what's causing this... I just mkfs'ed all the drives fresh, so there
shouldn't be any filesystem corruption.

Ideas?

Unable to handle kernel paging request at virtual address d8958100
c0130704
*pde = 
Oops: 
CPU:0
EIP:0010:[__block_prepare_write+224/584]
EFLAGS: 00010283
eax: 04f0   ebx: 0322   ecx:    edx: d89580e8
esi: 0800   edi: ce01a322   ebp: c25c5ef8   esp: c25c5ec8
ds: 0018   es: 0018   ss: 0018
Process innd (pid: 585, stackpage=c25c5000)
Stack: 0322 c13b86f8 c331c360 04f0 0400 0f3b c25c5ef8 ce044980 
   ce01a000 0400 00035221 d89580e8 000fc340 c013e3b0 c0130ea2 c39fc2c0 
   c13b86f8 0322 04f0 c014ccbc c13b86f8 fff4 c014d425 c13b86f8 
Call Trace: [] [posix_lock_file+1344/1360] [block_prepare_write+34/60] 
[ext2_get_block+0/1332] [ext2_prepare_write+25/32] [ext2_get_block+0/1332] 
[generic_file_write+812/1204] 
Code: f6 42 18 10 0f 85 b2 00 00 00 6a 01 52 8b 5c 24 30 53 8b 44 
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; d89580e8 
Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   f6 42 18 10   testb  $0x10,0x18(%edx)
Code;  0004 Before first symbol
   4:   0f 85 b2 00 00 00 jnebc <_EIP+0xbc> 00bc Before first symbol
Code;  000a Before first symbol
   a:   6a 01 push   $0x1
Code;  000c Before first symbol
   c:   52push   %edx
Code;  000d Before first symbol
   d:   8b 5c 24 30   mov0x30(%esp,1),%ebx
Code;  0011 Before first symbol
  11:   53push   %ebx
Code;  0012 Before first symbol
  12:   8b 44 00 00   mov0x0(%eax,%eax,1),%eax

Unable to handle kernel paging request at virtual address d89580ec
c012fd64
*pde = 
Oops: 
CPU:0
EIP:0010:[getblk+128/296]
EFLAGS: 00010286
eax: c145   ebx: 0002   ecx: 0004c11a   edx: d89580e8
esi: 0008   edi: 0801   ebp: 0026   esp: c1bd1e1c
ds: 0018   es: 0018   ss: 0018
Process innfeed (pid: 588, stackpage=c1bd1000)
Stack: c1bd1f00 c3a64de0 c3a64de0 c3a64e50 0801 1f6e c014d253 0801 
   0004c11a 0400 cfb5cd40 0001 c3a64de0 c33293a0 0004c11a c354a3c0 
   c3320801 c354a3c0 00030002 0010 c1bd1e94 c1bd1e78 c1bd1e7c c198a2a0 
Call Trace: [ext2_getblk+99/204] [ext2_find_entry+177/944] [error_code+52/64] 
[file_read_actor+51/104] [ext2_unlink+39/204] [vfs_unlink+231/300] 
[sys_unlink+165/284] 
Code: 39 4a 04 75 12 31 c0 66 8b 42 08 3b 44 24 24 75 06 66 39 7a 

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   39 4a 04  cmp%ecx,0x4(%edx)
Code;  0003 Before first symbol
   3:   75 12 jne17 <_EIP+0x17> 0017 Before first symbol
Code;  0005 Before first symbol
   5:   31 c0 xor%eax,%eax
Code;  0007 Before first symbol
   7:   66 8b 42 08   mov0x8(%edx),%ax
Code;  000b Before first symbol
   b:   3b 44 24 24   cmp0x24(%esp,1),%eax
Code;  000f Before first symbol
   f:   75 06 jne17 <_EIP+0x17> 0017 Before first symbol
Code;  0011 Before first symbol
  11:   66 39 7a 00   cmp%di,0x0(%edx)

Unable to handle kernel paging request at virtual address d89580ec
c012fd64
*pde = 
Oops: 
CPU:0
EIP:0010:[getblk+128/296]
EFLAGS: 00010286
eax: c145   ebx: 0002   ecx: 0004a014   edx: d89580e8
esi: 0008   edi: 0801   ebp: 0025   esp: c15e9f38
ds: 0018   es: 0018   ss: 0018
Process kupdate (pid: 6, stackpage=c15e9000)
Stack: 0004a014 00a0 2280 c1b25c20 0801 1555 c012fffe 0801 
   0004a014 0400 0801 c014e1f6 0801 0004a014 0400 0001 
   c1b25c20 cff68238 cff68200 c7707ab4 0286 0001 cff68200 0801 
Call Trace: [bread+26/112] [ext2_update_inode+302/952] [ext2_write_inode+15/20] 
[sync_inodes+296/388] [sync_old_buffers+14/56] [kupdate+222/232] [kernel_thread+35/48] 
Code: 39 4a 04 75 12 31 c0 66 8b 42 08 3b 44 24 24 75 06 66 39 7a 

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   39 4a 04  cmp%ecx,0x4(%edx)
Code;  0003 Before first symbol
   3:   75 12 jne17 <_EIP+0x17> 0017 Before first symbol
Code;  0005 Before first symbol
   5:   31 c0 xor%eax,%eax
Code;  0007 Before first symbol
   7:   66 8b 42 08   mov0x8(%edx),%ax
Code;  000b Before first symbol
   b:   3b 44 24 24   cmp0x24(%esp,1),%eax
Code;  000f Before first symbol
   f:   75 06 jne17 <_EIP+0x17> 0017 Before first symbol
Code;  0011 Before first symbol
  11:   66 39 7a 00   cmp%d

Re: "kaweth" usb ethernet driver in 2.4?

[Michael Rothwell]

Thanks. Has Brad Hards made his version available somewhere?
-M

- Original Message -
From: "Eric Sandeen" <[EMAIL PROTECTED]>
To: "Michael Rothwell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 9:30 AM
Subject: Re: "kaweth" usb ethernet driver in 2.4?


> Michael Rothwell wrote:
>
> > > It also doesn't seem to work in 2.2.  :)  The original development of
> > > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but
there
> > > have been no updates for quite some time.
> >
> > Well, it doesn't work you _you_ on 2.2, obviously. But it works for us
> > and other people. Can you provide any information to diagnose the
> > problem you're having?
>
> I'm sorry, I should have provided that info.  I searched the 'net, and
> saw many people with problems on several mailing lists, and saw no
> solutions, or reports of success, so I assumed that it was a widespread,
> possibly even known, problem with the driver.
>
> I'll preface this by saying that Brad Hards sent me an updated version
> that works much better, at least as long as the module is loaded before
> the device is plugged in.
>
> But here's what I get with a 2.2 kernel and the stock driver:
>
> Kawasaki USB->Ethernet Driver loading...
> usb.c: registered new driver kaweth
> usb.c: USB new device connect, assigned device number 2
> Kawasaki Device Probe (Device number:2): 0x0846:0x1001
> Device at c2192600
> Descriptor length: 12 type: 1
> NetGear EA-101 connected...
> Reading kaweth configuration
> Request type: c0  Request: 0  Value: 0 Index: 0 Length: 12
> usb-uhci.c: interrupt, status 2, frame# 1929
> kaweth control message failed (urb addr: c2c05ca0)
> usb_control/bulk_msg: timeout
> usb-uhci.c: interrupt, status 2, frame# 851
> Actual length: 0, length 18
> Resetting...
> usb-uhci.c: interrupt, status 2, frame# 854
> Downloading firmware at c48abb6c to kaweth device at c31be000...
> Firmware length: 3838
> Request type: 40  Request: ff  Value: 0 Index: 0 Length: efe
> usb-uhci.c: interrupt, status 2, frame# 871
> kaweth control message failed (urb addr: c213ab60)
> usb-uhci.c: interrupt, status 2, frame# 877
> usb-uhci.c: interrupt, status 2, frame# 882
> Actual length: 0, length 3838
> Error downloading firmware (-110), no net device created
>

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

Re: Better battery info/status files

[Ben Ford]

David Woodhouse wrote:

> On Sun, 4 Feb 2001, James Sutherland wrote:
> > On Sun, 4 Feb 2001, Ben Ford wrote:
> > > David Woodhouse wrote:

> On Sun, 4 Feb 2001, James Sutherland wrote:
>
> > For the end-user, the ability to see readings in other units would be
> > useful - how many people on this list work in litres/metres/kilometres,
> > and how many in gallons/feet/miles? Probably enough in both groups that
> > neither could count as universal...
>

>
> > > > Yeah. We can have this as part of the locale settings, changeable by
> > > > echoing the desired locale string to /proc/sys/kernel/lc_all.
> > >
> > > Just an idea, . .  but isn't this something better done in userland?
> >
> > That's what I'd do, anyway
>
> STOP!
>
> I'll repeat myself, in the en_US locale this time...
>
> 
> Yeah. We can have this as part of the locale settings, changeable by
> echoing the desired locale string to /proc/sys/kernel/lc_all.
> 
> Go away and troll elsewhere
>
> --
> dwmw2

You have an odd definition of troll.  Tell me, who is trolling, the guy who
posts something trying to help or the guy who posts sarcastic responses to
things?  You appear to have a major case of little-dick syndrome.

-b


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

Re: Motherboard Misdetect

[David Woodhouse]

[EMAIL PROTECTED] said:
>   I own a M-Technology M-668DS motherboard.  Linux 2.4.1
>   identifies my board as a Soyo SY-6KD.  They're not really
>   the same board, and they each have features the other doesn't
>   have. (The 668DS has onboard SCSI, where as the 6KD doesn't.
>   The 6KD can be upgraded for I20 compatibiliy, whereas the 668DS
>   can't.)

Linux is only reporting the information contained within the BIOS. It's not
going to cause you a problem. Other than printing it, the only thing Linux
uses the information for is to ensure that we don't lock up the machine by
trying to use certain APM functinos on certain laptops which have
known-buggy BIOSes. (You can blame Dell for this particular piece of 
incompetence).


--
dwmw2


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

Motherboard Misdetect

[Steve 'Denali' McKnelly]

Howdy everyone,

I own a M-Technology M-668DS motherboard.  Linux 2.4.1
identifies my board as a Soyo SY-6KD.  They're not really
the same board, and they each have features the other doesn't
have. (The 668DS has onboard SCSI, where as the 6KD doesn't.
The 6KD can be upgraded for I20 compatibiliy, whereas the 668DS
can't.)

Is this going to be a problem for me?  I will admit to knowing
nothing about kernel programming, but I'm willing to help
in any way.  Below is a copy of my dmesg output.

Thanks,
Steve

[root@shadowforge denali]: dmesg
achine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183fbff   
CPU: After generic, caps: 0183fbff   
CPU: Common caps: 0183fbff   
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0183fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183fbff   
CPU: After generic, caps: 0183fbff   
CPU: Common caps: 0183fbff   
CPU0: Intel Pentium II (Deschutes) stepping 02
per-CPU timeslice cutoff: 1463.01 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 0
Getting ID: f00
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 0004
ESR value after enabling vector: 
CPU present map: 1
Before bogomips.
Error: only one processor found.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-18, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=49 pin1=2 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
. (found pin 0) ...works.
activating NMI Watchdog ... done.
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC...

IO APIC #2..
 register #00: 0200
...: physical APIC id: 02
 register #01: 00170011
... : max redirection entries: 0017
... : IO APIC version: 0011
 register #02: 
... : arbitration: 00
 IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 001 01  000   0   01131
 01 001 01  000   0   01139
 02 000 00  100   0   00000
 03 001 01  000   0   01141
 04 001 01  000   0   01149
 05 001 01  000   0   01151
 06 001 01  000   0   01159
 07 001 01  000   0   01161
 08 001 01  000   0   01169
 09 001 01  000   0   01171
 0a 001 01  000   0   01179
 0b 001 01  000   0   01181
 0c 001 01  000   0   01189
 0d 000 00  100   0   00000
 0e 001 01  000   0   01191
 0f 001 01  000   0   01199
 10 001 01  110   1   011A1
 11 001 01  110   1   011A9
 12 000 00  100   0   00000
 13 001 01  110   1   011B1
 14 000 00  100   0   00000
 15 000 00  100   0   00000
 16 000 00  100   0   00000
 17 000 00  100   0   00000
IRQ to pin mappings:
IRQ0 -> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 5
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ10 -> 10
IRQ11 -> 11
IRQ12 -> 12
IRQ13 -> 13
IRQ14 -> 14
IRQ15 -> 15
IRQ16 -> 16
IRQ17 -> 17
IRQ19 -> 19
 done.
calibrating APIC timer ...
. CPU clock speed is 300.6844 MHz.
. host bus clock speed is 66.8185 MHz.
cpu: 0, clocks: 668185, slice: 334092
CPU0
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfdba1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
PCI->APIC IRQ transform: (B0,I11,P0) -> 16
PCI->APIC IRQ transform: (B0,I13,P0) -> 17
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.0 present.
34 structures occupying 820 bytes.
DMI table at 0x000F748B.
BIOS Vendor: American Megatrends, Inc.
BIOS Version: 0627
BIOS Release: 07/15/95
Board Vendor: SOYO Computer Inc

Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)

[Mark Cooke]

On Mon, 29 Jan 2001, Jamie Lokier wrote:

> Unfortunately getting the same IP is rare now, so I've been toying with
> running a PPP tunnel through a fixed host out on the net.  The tunnel
> would be dropped and recreated with each new connection.  My local link
> IP would change, but the tunnel IP would not so connections to other
> places, ssh etc. would all be from the tunnel IP.

ciped is great for this.  I use it to tunnel ssh from my home dialup
to work.  Very stable, and with cipe's shared keys, there's nothing
too taxing about setting it up.

I just have a call to /etc/init.d/ciped restart in my ppp up script.

freeswan was another way I looked at , but ip/sec was horrible at
the time and didn't (maybe still doesn't) deal with dynamic ip
assignment nicely.

Cheers,

Mark

-- 
+-+
Mark Cooke  The views expressed above are mine and are not
Systems Programmer  necessarily representative of university policy
University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/
+-+

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

APM screen blanking

[Joseph Pingenot]

Greetings.

Does anyone know what would cause a lockup when (2.4.x):
  * supsending to disk
  * changing from X to a virtual console
with APM enabled?  Changing from X to a VC functions when APM is
  compiled out.
Essentially, the screen blanks once and the machine locks up.
  Usually while suspending, the screen blanks at least twice.
  The 2.2.1[78] kernels work fine.
Has anyone else seen this behaviour?  I'm seeing this on a Toshiba 
  Satellite 1605CDS.
Thanks!

  -Joseph

-- 
[EMAIL PROTECTED]
"I felt a great disturbance in the force.  As if a significant plot
  line suddenly cried out in terror... and was suddenly silenced."
-Torg in "Sluggy Freelance" www.sluggy.com.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0/2.4.1 crashes in ext2

[Dan Merillat]

Ok, here's the crash I'm getting in 2.4.0.  Same thing is happening in 2.4.1,
but It's dying harder so getting syslog info out is tougher.

Looks like it's trying to write WAY past the end of a drive (from some messages
that unfortunatly did not get logged, but were scrolling on the screen) but I'm
not sure if that's the cause or result of the oops.

The only thing different on this machine from my others running 2.4.1 is that
this one is actually using large files.  lots of them, all the time.  So that'd
be my first guess.

I made sure to compile 2.4.1 with 2.91.2, no change.

I get about 5-10 minutes of runtime on a full-feed newsserver before it
crashes.   Need to figure this out quickly, please.

--Dan


Unable to handle kernel paging request at virtual address d8958100
c012e253
*pde = 
Oops: 
CPU:0
EIP:0010:[__block_write_full_page+123/372]
EFLAGS: 00010206
eax:    ebx: d89580e8   ecx: 3057   edx: 
esi:    edi: 0c4c   ebp: c3886f60   esp: c15ebf5c
ds: 0018   es: 0018   ss: 0018
Process kupdate (pid: 6, stackpage=c15eb000)
Stack: c10f2388 c4ff6620 c4ff66c4 c4ff6620  c012eda1 c4ff6620 c10f2388 
   c0148e78 c10f2388 c4ff6620 c4ff66c4 c01494ec c4bd2d60 c01494fa c10f2388 
   c0148e78 c011fe6a c10f2388 0004 c4ff6620 cffca638 cffca600 c013db9b 
Call Trace: [block_write_full_page+49/328] [ext2_get_block+0/1168] 
[ext2_writepage+0/20] [ext2_writepage+14/20] [ext2_get_block+0/1168] 
[filemap_fdatasync+90/188] [sync_inodes+239/364] 
Code: 8b 73 18 83 e6 10 75 29 6a 01 53 57 8b 54 24 24 52 8b 54 24 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 73 18  mov0x18(%ebx),%esi
Code;  0003 Before first symbol
   3:   83 e6 10  and$0x10,%esi
Code;  0006 Before first symbol
   6:   75 29 jne31 <_EIP+0x31> 0031 Before first symbol
Code;  0008 Before first symbol
   8:   6a 01 push   $0x1
Code;  000a Before first symbol
   a:   53push   %ebx
Code;  000b Before first symbol
   b:   57push   %edi
Code;  000c Before first symbol
   c:   8b 54 24 24   mov0x24(%esp,1),%edx
Code;  0010 Before first symbol
  10:   52push   %edx
Code;  0011 Before first symbol
  11:   8b 54 24 00   mov0x0(%esp,1),%edx


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

Re: Configure.help typo fix

[Jeremy M. Dolan]

On Mon, 05 Feb 2001 02:22:11 +, Keitaro Yosimura wrote:
> Hi. Axel Boldt, Alan Cox, Linus Torvalds.

This might be a good time to mention Axel has passed maintainership of
Configure.help to myself. I'm currently working to combine Axel's fork
against Linux 2.4.1's Configure.help, which is requiring hand merging
a 260 kbyte diff, so it may be a week or two off.

Anyway, I thought it might be a good idea to update the MAINTAINERS
file to cut the flow of patches to Axel.

/jmd

--- linux-2.4.1/MAINTAINERS Thu Feb  1 22:56:14 2001
+++ jmd-241/MAINTAINERS Sun Feb  4 14:43:05 2001
@@ -273,8 +273,8 @@
 S: Maintained
 
 CONFIGURE.HELP
-P: Axel Boldt
-M: [EMAIL PROTECTED]
+P: Jeremy M. Dolan
+M: [EMAIL PROTECTED]
 S: Maintained
 
 COSA/SRP SYNC SERIAL DRIVER
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID autodetect and 2.4.1

[Jakob Østergaard]

On Sun, Feb 04, 2001 at 12:28:30AM +0100, Jean-Eric Cuendet wrote:
> 
> Hi,
> I have a server with RAID1 partitions with linux 2.4.1 (stock,
> self-compiled) installed.
> It was easy to create the RAID partitions but when booting, no
> auto-detection is successful.
> The kernel says that autodetect is running, then done, but nothing is
> auto-detected.
> My devices are IDE devices (hda + hdc) and all drivers are bult-ins (no
> initrd nor modules).
> After the boot, making a raidstart works like a charm...
> Any advice?
> Help welcomed.

From http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-4.html#ss4.10

-
4.10 Autodetection

Autodetection allows the RAID devices to be automatically recognized by the kernel at 
boot-time, right after the ordinary partition detection is done. 

This requires several things:
* You need autodetection support in the kernel. Check this
* You must have created the RAID devices using persistent-superblock
* The partition-types of the devices used in the RAID must be set to 0xFD (use fdisk 
and set the type to ``fd'')
-

I guess you forgot to mark the partitions as type 0xfd.   I have a similar box
here with 2.4.1 and autodetect works like a charm.

Cheers,

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Dual Promise Ultra66 PCI Cards

[Adrian Chung]

I've been attempting to get two Promise Ultra66 controllers working
with an Asus P2B-F motherboard.  I've got one controller successfully
working, but as soon as I stick the second controller in the computer,
the system refuses to boot.

With 2.2.18 and the linux-ide patches (Uniform E-IDE 6.30), the
computer refuses to boot if there are no bootable drives on the
motherboard's IDE controllers.  I have 4 hard drives on the promise
ultra66, and a cdrom drive on the motherboard's controller.  I've
tried setting the BIOS IDE/SCSI first option to SCSI, and it still
doesn't work.

I moved my boot drive to the motherboard's controller, and then linux
boots, but after detecting IDE devices, it hangs just after printing:

ide1 at ...
ide2 at ...
ide3 at ...

I don't have the exact messages at hand, but can produce them...

Any ideas?  Can this work?  I've read on the Promise site that
flashing the second controller with their "dummy" BIOS may make a
difference, but I'm not sure.

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

Re: PS hanging in 2.4.1 - More interesting things

[Shawn Starr]

Well, i found something in my logs:

This really is weird :)

Shawn.

Alan Cox wrote:

> > Well, strangely, it stopped as it started?
> > I don't know what caused it to go loopy but then it just stopped. Im using:
> > syslogd -ver
> > syslogd 1.4-0
> >
> > klogd -v
> > klogd 1.4-0
> >
> > I thought this only affected older versions?
>
> Yep. So something else happened in this case. I don't know what but that
> would appear to be a different bug
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


Feb  3 18:11:35 coredump syslogd 1.4-0: restart.
Feb  3 18:11:35 coredump syslogd: select: Bad file descriptor
Feb  3 18:12:06 coredump last message repeated 214069 times
Feb  3 18:14:48 coredump syslogd 1.4-0: restart.
Feb  3 18:14:48 coredump syslogd: select: Bad file descriptor
Feb  3 18:21:08 coredump syslogd 1.4-0: restart.
Feb  3 18:21:08 coredump syslogd: select: Bad file descriptor
Feb  3 18:21:34 coredump last message repeated 168154 times
Feb  3 18:24:08 coredump syslogd 1.4-0: restart.
Feb  3 18:24:08 coredump syslogd: select: Bad file descriptor
Feb  3 18:24:39 coredump last message repeated 231290 times
Feb  3 18:26:07 coredump syslogd 1.4-0: restart.
Feb  3 18:27:24 coredump init: Switching to runlevel: 6
Feb  3 18:27:31 coredump exiting on signal 15
Feb  3 18:34:44 coredump syslogd 1.4-0: restart.

Re: AW: ATAPI CDRW which doesn't work -> devfs problems

[Douglas Gilbert]

Friedrich Lindenberg wrote:
> I was trying to burn cds under linux-2.4.1 with 
> devFS enabled. But x-cd-roast (and also cdrecord)
> do not find any scsi drives. I guess they have been
> renamed or something like that, I cannot find them 
> in /dev, nor anywhere in /dev/scsi ...

xcdroast expects to find a whole swag of sg device
filenames (/dev/sg[0-16], /dev/sg[a-q]) and scsi
cdrom names (/dev/sr[0-15]) when it starts. The
xcdroast tarball comes with a MAKEDEVICES.sh script to
create them. If they are not all there it seems to
get upset.

This is not very devfs friendly since its policy
is only to show /dev entries for devices that you
actually have connected and that a driver is 
controlling.

So the hack solution is to edit out of MAKEDEVICES.sh
those file names that you actually have then execute
it. IMO this is not a devfs problem, xcdroast needs an 
improved device scanning algorithm.

BTW the /dev/sga,b,c style of sg device names are
deprecated in favour of the numeric style.

Doug Gilbert

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

RE: accept

[J . A . Magallon]

On 02.04 Mathieu Dube wrote:
> Ok, but fd 0 cant be a valid socket since its the stdin
> 
> I posted that on this mailing list coz I thought that this might be a scaling
> problem since it happens when theres already several clients connected to the
> server
> 

It just mean that your stdin was closed some time in the past...
As the prog is a daemon, probably it closed its std{in,out,err} and its
controlling tty.

I do not know if Linux follows the rule that the first fd you get is the
first available. That means that after 'daemonize' you should get the 0
in the first connection. If fd reuse is delayed, you can get the 0 any time
after...

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.2-pre1 #1 SMP Sun Feb 4 13:04:30 CET 2001 i686

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

Re: PS hanging in 2.4.1 - More interesting things

[Alan Cox]

> Well, strangely, it stopped as it started?
> I don't know what caused it to go loopy but then it just stopped. Im using:
> syslogd -ver
> syslogd 1.4-0
> 
> klogd -v
> klogd 1.4-0
> 
> I thought this only affected older versions?

Yep. So something else happened in this case. I don't know what but that
would appear to be a different bug

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

Re: PS hanging in 2.4.1 - More interesting things

[Shawn Starr]

Well, strangely, it stopped as it started?

I don't know what caused it to go loopy but then it just stopped. Im using:

syslogd -ver
syslogd 1.4-0

klogd -v
klogd 1.4-0

I thought this only affected older versions?

Shawn.

Alan Cox wrote:

> > Ok, I rebooted the system, then syslogd was using 100% cpu?
> > it seems like perhaps reiserfs is causing this problem??
>
> Typically it means your syslogd (klogd actually) is too old and has a bug that
> a 0 length printk causes it to spin.

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

Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todowith ECN)

[jamal]

On Tue, 30 Jan 2001, Rick Jones wrote:

> > > How does ZC/SG change the nature of the packets presented to the NIC?
> >
> > what do you mean? I am _sure_ you know how SG/ZC work. So i am suspecting
> > more than socratic view on life here. Could be influence from Aristotle;->
>
> Well, I don't know  the specifics of Linux, but I gather from what I've
> read on the list thusfar, that prior to implementing SG support, Linux
> NIC drivers would copy packets into single contiguous buffers that were
> then sent to the NIC yes?
>

yes.

> If so, the implication is with SG going, that copy no longer takes
> place, and so a chain of buffers is given to the NIC.
>

yes.

> Also, if one is fully ZC :) pesky things like protocol headers can
> naturally end-up in separate buffers.
>

yes.

> So, now you have to ask how well any given NIC follows chains of
> buffers. At what number of buffers is the overhead in the NIC of
> following the chains enough to keep it from achieving link-rate?
>

hmmm... not sure how you would enforce this today or why you would
want that. Alexey, Dave?
The kernel should be able to break it into two buffers(with netperf,
for example -- header + data).
Ok, probably with tux-http 3 (header, data, trailler).

> One way to try and deduce that would be to meld some of the SG and preSG
> behaviours and copy packets into varying numbers of buffers per packet
> and measure the resulting impact on throughput through the NIC.
>

If only time were on my hands i'd love to do this. Alas.
NOTE also, that effect would also be an effect of the specif NIC.

> rick jones
>
> As time marches on, the orders of magnitude of the constants may change,
> but basic concepts still remain, and the "lessons" learned in the past
> by one generation tend to get relearned in the next :) for example -
> there is no such a thing as a free lunch... :)

;->
BTW, i am reading one of your papers (circa 1993 ;->, "we go fast with a
little help from your apps")  in which you make an interesting
observation. That (figure 2) there is "a considerable increase in
efficiency but not a considerable increase in throughput"  I "scanned"
to the end of the paper and dont see an explanation.
I've made a somehow similar observation with the current zc patches and
infact observed that throughput goes down with the linux zc patches.
[This is being contested but no-one else is testing at gigE, so my word is
the only truth].
Of course your paper doesnt talk about sendfile rather the page pinning +
COW tricks (which are considered taboo in Linux) but i do sense a
relationship.

cheers,
jamal

PS:- I dont have "my" machines yet and i have a feeling it will be a while
before i re-run the tests; however, i have created a patch for
linux-sendfile with netperf. Please take a look at it at:
http://www.cyberus.ca/~hadi/patch-nperf-sfile-linux.gz
tell me if is missing anything and if it is ok, could you please merge in
your tree?



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

Re: System unresponsitive when copying HD/HD

[LA Walsh]

Alan Cox wrote:
> But try 2.4.1 before worrying too much. That fixed a lot of the block
> performance problems I was seeing (2.4.1 ruins the VM performance under paging
> loads but the I/O speed is fixed ;))

---
Seems to have gotten a bit worse.  Vmstat output after 'vmware' had completed
write -- but system unresponsive and writing out a 155M file...

 1  0  0  0 113960  47528 277152   0   0 0 0  397   861   1  24  75
 1  0  0  0 114060  47560 277152   0   0 4   350  432  1435   4  17  79
 0  0  1  0 127380  47560 266196   0   0 0   516  216   435   7   3  90
 1  0  1  0 127380  47560 266196   0   0 0   240  203   173   0   1  99
 0  0  1  0 127380  47560 266196   0   0 0   434  275   180   0   2  98
 1  0  1  0 127376  47560 266196   0   0 0   218  204   173   0   2  98
 0  0  1  0 127376  47560 266196   0   0 0   288  203   174   0   0 100
 0  0  1  0 127376  47560 266196   0   0 0   337  230   176   0   1  99
 0  0  1  0 127376  47560 266196   0   0 0   267  241   177   0   1  99
 0  0  1  0 127376  47560 266196   0   0 0   210  204   173   0   1  99
 0  0  1  0 127376  47560 266196   0   0 0   204  203   173   0   1  99
 0  0  1  0 127376  47560 266196   0   0 0   216  212   250   0   1  99
 0  0  1  0 127376  47560 266196   0   0 0   208  205   172   0   2  98
 0  0  1  0 127372  47560 266196   0   0 0   225  203   160   0   2  98
 0  0  1  0 127372  47560 266196   0   0 0   316  214   212   0   1  99
 1  0  1  0 127144  47560 266196   0   0 0   281  218   304   1   2  96
 0  0  0  0 127144  47560 266196   0   0 0 1  161   240   1   0  99
 0  0  0  0 127144  47560 266196   0   0 0 0  101   232   0   1  99 
---
What is the meaning of having a process in the 'w' column?  On other
systems, I was used to that meaning an executable had been *swapped* out completely
(as opposed to no pages mapped in) and that it meant your system vm was 'thrashing'.
But that obviously isn't the case here.

Those columns are output from a 'vmstat 5'.  Meaning it took about 70 seconds
to write out 158M.  Or about 2.2M/s.  That's probably not bad.  It still locks
up the system for over a minute though -- which is really undesirable performance
for interactive use.  I'm guessing the vmstat output numbers are showing 4K? 8K? 
blocks?  8K would about make sense for the 2.2M average.

-- 
Linda A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel memory allocations alignment

[Johannes Erdfelt]

On Sun, Feb 04, 2001, Andi Kleen <[EMAIL PROTECTED]> wrote:
> "Hen, Shmulik" <[EMAIL PROTECTED]> writes:
> 
> > Actually yes. We were warned that on IA64 architecture the system will halt
> > when accessing any type of variable via a pointer if the pointer does not
> > contain an aligned address matching that type. Until now we were using a
> 
> That will need to be fixed with a handler anyways, the network stack requires 
> unaligned accesses. If the IA64 port doesn't handle that it it's buggy and 
> trivially remotely crashable.

That ia64 port now supports unaligned accesses in kernel mode. (via the
latest patch)

It was more a debugging aid in the beginning than inability to do.

> Of course it'll always be much faster to use aligned accesses that do not
> need an exception.

Absolutely.

JE

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

Re: [OT] Major Clock Drift

[Tom Eastep]

Thus spoke Hacksaw:

> >I've discovered that heavy use of vesafb can be a major source of clock
> >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
>
> This is extremely interesting. What version of ntp are you using?
>

The RH7 rpm -- ntp-4.0.99k-5

-Tom
-- 
Tom Eastep \ Alt Email: [EMAIL PROTECTED]
ICQ #60745924   \ Websites: http://seawall.sourceforge.net
[EMAIL PROTECTED]   \  http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___

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

Re: [OT] Major Clock Drift

[Hacksaw]

>I've discovered that heavy use of vesafb can be a major source of clock
>drift on my system, especially if I don't specify "ypan" or "ywrap". On my

This is extremely interesting. What version of ntp are you using?



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

Re: accept

[W1012]

In article <01020411401700.00110@grndctrl> you wrote:
> Ok, but fd 0 cant be a valid socket since its the stdin
if you have closed stdin (like all daemons usually do) you will get fd 0 on
next open. There is nothing magical about fd0 or fd1.

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

Re: 2.4.2-pre1

[Linus Torvalds]

[ Linux-kernel added to the cc, as others probably also wonder ]

On Sat, 3 Feb 2001, David D.W. Downey wrote:
>
>   How often does Alan's patches get rolled into your main line? I'm
> having difficulty following the divergence here. I'm trying to run THE
> latest release(s) of your kernel with applicaple patches. I'm just trying
> to figure out if everything that is in the ac## line is ALWAYS rolled into
> your pre## line or not. Which patch sequence am I supposed to follow to
> have THE most current release of all fixes et. al.?

Alan tends to have much more experimental patches than I do - and we don't
sync up more often than maybe once a month or so. And even then, the
sync-up won't be complete, exactly because I don't take the experimental
parts (or more accurately, Alan mostly doesn't even try to send them to me
and we tend to agree pretty well on what is appropriate and what is not).

We're nearing another sync-point right now - I actually have a lot of
Alans patches in my mail-box, and -pre2 will probably contain a lot of the
-ac stuff. But don't expect a complete sync, as explained above.

Linus

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

RE: system call sched_yield() doesn't work on Linux 2.2

[Mohit Aron]

What version of Linux are you using ? What I see is the following:
Thread1
Thread1
Thread1
Thread1
Thread1
Thread2
Thread2
Thread2
Thread2
Thread2

Also, it is NOT unrealistic to expect perfect alternation. The definition
of sched_yield in the manpage says that sched_yield() puts the thread under
question last in the run queue. So perfect alternation should have occurred.
I've also tested the code on Solaris - there is perfect alternation there.


- Mohit


-Original Message-
From: David Schwartz [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 04, 2001 3:09 AM
To: Mohit Aron; [EMAIL PROTECTED]
Subject: RE: system call sched_yield() doesn't work on Linux 2.2



The program you attached worked perfectly for me. You need to
'fflush(stdout);' after each 'printf'. You didn't expect perfect alternation
did you? That's totally unrealistic. You cannot use the scheduler as a
synchronization mechanism.

--

Thread1
Thread1
Thread2
Thread1
Thread1
Thread2
Thread1
Thread2
Thread2
Thread2

--

DS

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mohit Aron
> Sent: Saturday, February 03, 2001 2:53 PM
> To: [EMAIL PROTECTED]
> Subject: system call sched_yield() doesn't work on Linux 2.2
>
>
> Hi,
>   the system call sched_yield() doesn't seem to work on Linux
> 2.2. Does
> anyone know of a kernel patch that fixes this ?
>
> Attached below is a small program that uses pthreads and demonstrates that
> sched_yield() doesn't work. Basically, the program creates two
> threads that
> alternatively try to yield CPU to each other.
>
>
> - Mohit
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI broken in 2.4.1

[Alan Cox]

> I waited out the boot so I could login and experiment, but it was
> painfully slow.
> 
> Compiling with just APM in and no ACPI, results in a correctly-running
> machine with rh7 gcc-2.96-69.

Lots of people are seeing this. Stick to APM for now until the acpi folks fix
it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI broken in 2.4.1

[Benson Chow]

I waited out the boot so I could login and experiment, but it was
painfully slow.

Compiling with just APM in and no ACPI, results in a correctly-running
machine with rh7 gcc-2.96-69.

I got lucky this time that with APM worked, else I'd be stuck with slowly
fscking, since this last boot I had to fsck two of my partitions (maximum
mount count exceeded...)  I don't even want to know how long it'd take to
fsck my almost 60GB worth of disks on this machine...  If that were the
case, I guess I'd be better off fscking with 2.4.0 and then coming back
in... ouch.

-bc

On Sun, 4 Feb 2001, Tony Hoyle wrote:

> Date: Sun, 04 Feb 2001 15:26:04 +
> From: Tony Hoyle <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: ACPI broken in 2.4.1
>
> In my wifes' machine 2.4.1 (both vanilla and -ac2) enabling ACPI causes
> the machine to run so slowly it's unusable.  On my machine it's OK.
> 2.4.0 worked fine, so something has changed between 2.4.0 and 2.4.1 that
> broke it.  I couldn't find anything in dmesg that looked any different,
> though.  However since that machine has never successfully booted with
> ACPI on the kern.log hasn't been written so it's unlikely I'd find anything.
>
> Tony


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

Re: 2.4.1 segfault when doing "ls /dev/"

[Pierre Rousselet]

Pierfrancesco Caci wrote:

> Yes I know this. Actually, booting with "devfs=nomount s" is the only
> way to update the boot record with lilo and my existing lilo.conf.

i can't do that on my box, /dev is only a mount point for devfs.

assuming your /dev directory is dirty from something else than devfsd,
could you try this while devfsd is running :
#mkdir /devtest
#mount none -t devfs /devtest
#ls /devtest

-- 

 Pierre Rousselet <[EMAIL PROTECTED]>

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

Re: "kaweth" usb ethernet driver in 2.4?

[Eric Sandeen]

Michael Rothwell wrote:

> > It also doesn't seem to work in 2.2.  :)  The original development of
> > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there
> > have been no updates for quite some time.
> 
> Well, it doesn't work you _you_ on 2.2, obviously. But it works for us
> and other people. Can you provide any information to diagnose the
> problem you're having?

I'm sorry, I should have provided that info.  I searched the 'net, and
saw many people with problems on several mailing lists, and saw no
solutions, or reports of success, so I assumed that it was a widespread,
possibly even known, problem with the driver.

I'll preface this by saying that Brad Hards sent me an updated version
that works much better, at least as long as the module is loaded before
the device is plugged in.

But here's what I get with a 2.2 kernel and the stock driver:

Kawasaki USB->Ethernet Driver loading... 
usb.c: registered new driver kaweth 
usb.c: USB new device connect, assigned device number 2 
Kawasaki Device Probe (Device number:2): 0x0846:0x1001 
Device at c2192600 
Descriptor length: 12 type: 1 
NetGear EA-101 connected... 
Reading kaweth configuration 
Request type: c0  Request: 0  Value: 0 Index: 0 Length: 12 
usb-uhci.c: interrupt, status 2, frame# 1929 
kaweth control message failed (urb addr: c2c05ca0) 
usb_control/bulk_msg: timeout 
usb-uhci.c: interrupt, status 2, frame# 851 
Actual length: 0, length 18 
Resetting... 
usb-uhci.c: interrupt, status 2, frame# 854 
Downloading firmware at c48abb6c to kaweth device at c31be000... 
Firmware length: 3838 
Request type: 40  Request: ff  Value: 0 Index: 0 Length: efe 
usb-uhci.c: interrupt, status 2, frame# 871 
kaweth control message failed (urb addr: c213ab60) 
usb-uhci.c: interrupt, status 2, frame# 877 
usb-uhci.c: interrupt, status 2, frame# 882 
Actual length: 0, length 3838 
Error downloading firmware (-110), no net device created
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Configure.help typo fix

[Keitaro Yosimura]

Hi. Axel Boldt, Alan Cox, Linus Torvalds.

We found Configure.help typo. please fix it.

 for 2.2.X
--- linux.orig/Documentation/Configure.help Mon Feb  5 02:07:04 2001
+++ linux/Documentation/Configure.help  Mon Feb  5 02:07:52 2001
@@ -1530,7 +1530,7 @@
   inserted in and removed from the running kernel whenever you want).
   If you want to compile it as a module, say M here and read
   Documentation/modules.txt. You will get modules called i2o_core.o
-  and i20_config.o. 
+  and i2o_config.o. 
 
   If unsure, say N.
 
 for 2.4.X
--- linux.orig/Documentation/Configure.help Mon Feb  5 02:09:05 2001
+++ linux/Documentation/Configure.help  Mon Feb  5 02:09:50 2001
@@ -2572,7 +2572,7 @@
   inserted in and removed from the running kernel whenever you want).
   If you want to compile it as a module, say M here and read
   Documentation/modules.txt. You will get modules called i2o_core.o
-  and i20_config.o. 
+  and i2o_config.o. 
 
   If unsure, say N.
 


<|> YOSHIMURA 'ramsy' Keitaro / Japan Linux Association
<|> mailto:[EMAIL PROTECTED]
<|> http://jla.linux.or.jp/index.html

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

Re: [OT] Major Clock Drift

[Tom Eastep]

Thus spoke Michael B. Trausch:

> On Sat, 3 Feb 2001, Josh Myer wrote:
>
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any thoughts on the
> > cause? (Google didn't show up anything worthwhile in the first couple of
> > pages, so i gave up).
> >
>
> I'm having the same problem here.  AMD K6-II, 450 MHz, VIA Chipset, Kernel
> 2.4.1.
>

I've discovered that heavy use of vesafb can be a major source of clock
drift on my system, especially if I don't specify "ypan" or "ywrap". On my
system (similar Hw/Sw configuration to yours), a 2.4 kernel "make dep"
from a vesafb console will cause the system clock to drift 10-12 seconds.
With "ywrap", I can do an entire kernel build and only loose 5 seconds or
so. Even with "ywrap", the drift causes ntpd to loose synchronization. If
I build the kernel from an xterm window, ntpd does not loose sync and
there is no apparent clock drift.

The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
rather than atyfb because the latter screws up X.

-Tom
-- 
Tom Eastep \ Alt Email: [EMAIL PROTECTED]
ICQ #60745924   \ Websites: http://seawall.sourceforge.net
[EMAIL PROTECTED]   \  http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___

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

Re: Better battery info/status files

[Alan Cox]

> > Yeah. We can have this as part of the locale settings, changable by
> > echoing the desired locale string to /proc/sys/kernel/lc_all.
> 
> Just an idea, . .  but isn't this something better done in userland?

Please remember this is an international list. For the benefit of certain
users please mark all sarcasm with the word NOT or a simply face

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

Re: ATAPI CDRW which doesn't work

[patrick . mourlhon]

> > I've got those kind of message now :
> > 
> > Feb  4 07:18:35 Line kernel: scsi : aborting command due to timeout : pid 0, 
>scsi0, channel 0, id 0, lun 0 Read (10) 00 00 00 00 2e 00 00 01 00 
> 
> If this is a correct ISO9660 cd you should not see those
> messages.  It is either hardware problem (eg IDE cable is badly
> conencted or CDRW is broken/dusty) or this CD is simply
> scratched.  Does it work with another CD?
> 
> Also try to put it on separate IDE channel than your main HD.

Cable looks ok, removed and reinstalled, used it before with 
a second hard disk. CDRW may be broken. don't know, but at
least nothing appear broken all around the device.
CD was read with an other CDROM reader.
Never seen CDRW working reliably till now. But never used it
through Windows, don't have it since 4 years. I might at least
check if it could work on Windows.

Whatever thanks a lot for your time, was greatly appreciated,

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

Re: kernel memory allocations alignment

[Andi Kleen]

"Hen, Shmulik" <[EMAIL PROTECTED]> writes:

> Actually yes. We were warned that on IA64 architecture the system will halt
> when accessing any type of variable via a pointer if the pointer does not
> contain an aligned address matching that type. Until now we were using a

That will need to be fixed with a handler anyways, the network stack requires 
unaligned accesses. If the IA64 port doesn't handle that it it's buggy and 
trivially remotely crashable.

Of course it'll always be much faster to use aligned accesses that do not
need an exception.

> method of receiving a pointer to an array, casting it to a pointer of a
> struct (packed with #pragma pack(1) ) ,and retrieving fields directly from
> it with pointers.
> It seems we cannot do that any more and were wondering what are the
> alternatives.

get_unaligned() or a memcpy to a local variable is the standard method.
get_unaligned is normally slightly faster than relying on an unalignment
exception handler.

> One way we could think of is forget the packing and rearrange the fields in
> the struct in descending order so they all come out aligned, but we didn't
> know for sure if the first one will be aligned too.
> 
> Will that work ?

Yes, it's the best solution.

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

Re: Better battery info/status files

[James Sutherland]

On Mon, 5 Feb 2001, Steve Underwood wrote:
> James Sutherland wrote:
> > On Sun, 4 Feb 2001, Ben Ford wrote:
> > > David Woodhouse wrote:
> > > > On Sun, 4 Feb 2001, James Sutherland wrote:
> > > >
> > > > > For the end-user, the ability to see readings in other units would be
> > > > > useful - how many people on this list work in litres/metres/kilometres,
> > > > > and how many in gallons/feet/miles? Probably enough in both groups that
> > > > > neither could count as universal...
> > > >
> > > > Yeah. We can have this as part of the locale settings, changable by
> > > > echoing the desired locale string to /proc/sys/kernel/lc_all.
> > >
> > > Just an idea, . .  but isn't this something better done in userland?
> > >
> > > (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> > > $ date  +%s
> > > 981298161
> > > (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> > > $ date  +%c
> > > Sun Feb  4 06:49:24 2001
> > 
> > That's what I'd do, anyway - /dev/pieceofstring would return the length of
> > said piece of string in some units, explicityly stated. (e.g. "5m" or
> > "15ft").
> > 
> > "uname -s" ("how long's a piece of string on this system") would then
> > convert the length into feet, metres or fathoms, depending on what the
> > user prefers.
> 
> Don't get carried away. In the present context we are only talking about
> time and electrical measurements. Whilst most of the human race can't
> read the English labels in /proc, they all use the same measurements for
> electrical units and time (unless the time exceeds 24 hours, where dates
> get a bit screwed up). In this case even the US in in line with the rest
> of humanity. or would you like to be able to express battery
> capacity in BTUs?

Personally, I'd prefer a percentage and/or estimated time remaining
anyway... However, from the kernel's PoV, the rule is just "KISS". Print
in something consistent, let userspace do any conversions you
want. Probably seconds for time (simplest - scripts can compare "if
est_batterylife_remaining < 300 do something", UI things can convert to
H:M:S or whatever), watts for power.

What is measured, BTW - battery voltage, presumably, and drain
current?


James.

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

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Alan Cox]

> It appears that we are coming across 2 kinds of requirements for kiobuf
> vectors - and quite a bit of debate centering around that.
> 
> 1. In the block device i/o world, where large i/os may be involved, we'd
> 2. In the networking world, we deal with smaller fragments (for protocol

Its probably worth commenting at this point that the I2O message passing layers
do indeed have both #1 and #2 type descriptor chains to optimise performance
for different tasks. We arent the only people to hit this.

I2O supports 
offset, pagelist, length

where the middle pages in the list are entirely copied

And sets of
addr, len

tuples.



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

Re: accept

[Mathieu Dube]

On Sat, 03 Feb 2001, you wrote:
> > What does it typically mean when accept returns 0
> > and that the perror outputs "Interupted system call"??
> 
> During the call, your process received a signal.
> Most system calls are affected in this way, so that
> you may break out of what you are doing by sending
> a signal to yourself with alarm().
> 
> It sucks too, since you have to wrap nearly every
> system call in a while loop. You can avoid some of
> the trouble with careful use of sigaction() to make
> the OS restart system calls in some conditions.
Could it be the SIG32 signal that pthreads use ??
-- 
Mathieu Dube
Mondo-Live
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1 segfault when doing "ls /dev/"

[Pierfrancesco Caci]

:-> "Pierre" == Pierre Rousselet <[EMAIL PROTECTED]> writes:


> /dev is mounted at boot time by the kernel (CONFIG_DEVFS_MOUNT=y).
> The system boots and runs without devfsd. You just can't start any 
> process calling for non-existing device under /dev and not created
> by devfsd. For instance pppd or mc won't start by lack of pseudo-tty 
> esd needs /dev/dsp ...

Yes I know this. Actually, booting with "devfs=nomount s" is the only
way to update the boot record with lilo and my existing lilo.conf.
If I boot with devfs=nomount, I *can* ls /dev, without segfaulting.
I don't want to access or use any device in /dev, I just want to stat
/dev and see what's inside. There's something wrong with (I suspect)
devfsd and the way it populates /dev with symlinks, whick make /dev
un-listable but still usable, somewhat.


> i was thinking the trouble may come from some programme launched by
> your boot scripts before devfsd is running.

I have no idea. Any other debian users reporting this ?

> is your version of fileutils > 4.0.28 (ls --version) ?

root@penny:/usr/src/linux # ls --version
ls (fileutils) 4.0.37


Pf


-- 

---
 Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED]  -  http://gusp.dyndns.org
  Firenze - Italia  | Office for the Complication of Otherwise Simple Affairs 
 Linux penny 2.4.1 #1 Sat Feb 3 20:43:54 CET 2001 i686 unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: accept

[Mathieu Dube]

Ok, but fd 0 cant be a valid socket since its the stdin

I posted that on this mailing list coz I thought that this might be a scaling
problem since it happens when theres already several clients connected to the
server

On Sun, 04 Feb 2001, David Schwartz wrote:
> > What does it typically mean when accept returns 0
> > and that the perror outputs "Interupted system call"??
> 
>   Since 'accept' returning zero is not an error, the results of 'perror' are
> meaningless. Please read the manual page for 'accept' and notice that it
> says, "The call returns -1 on error". Continue reading to understand what a
> return value of zero means. Remember that zero is a non-negative integer.
> 
>   DS
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-- 
Mathieu Dube
Mondo-Live
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Better battery info/status files

[David Woodhouse]

On Sun, 4 Feb 2001, James Sutherland wrote:
> On Sun, 4 Feb 2001, Ben Ford wrote:
> > David Woodhouse wrote:
> > > Yeah. We can have this as part of the locale settings, changeable by
> > > echoing the desired locale string to /proc/sys/kernel/lc_all.
> > 
> > Just an idea, . .  but isn't this something better done in userland?
> 
> That's what I'd do, anyway

STOP!

I'll repeat myself, in the en_US locale this time...


Yeah. We can have this as part of the locale settings, changeable by
echoing the desired locale string to /proc/sys/kernel/lc_all.

Go away and troll elsewhere

-- 
dwmw2



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

Re: Better battery info/status files

[Steve Underwood]

James Sutherland wrote:
> 
> On Sun, 4 Feb 2001, Ben Ford wrote:
> 
> > David Woodhouse wrote:
> >
> > > On Sun, 4 Feb 2001, James Sutherland wrote:
> > >
> > > > For the end-user, the ability to see readings in other units would be
> > > > useful - how many people on this list work in litres/metres/kilometres,
> > > > and how many in gallons/feet/miles? Probably enough in both groups that
> > > > neither could count as universal...
> > >
> > > Yeah. We can have this as part of the locale settings, changable by
> > > echoing the desired locale string to /proc/sys/kernel/lc_all.
> > >
> > > -
> >
> > Just an idea, . .  but isn't this something better done in userland?
> >
> > (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> > $ date  +%s
> > 981298161
> > (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> > $ date  +%c
> > Sun Feb  4 06:49:24 2001
> 
> That's what I'd do, anyway - /dev/pieceofstring would return the length of
> said piece of string in some units, explicityly stated. (e.g. "5m" or
> "15ft").
> 
> "uname -s" ("how long's a piece of string on this system") would then
> convert the length into feet, metres or fathoms, depending on what the
> user prefers.
> 
> James.

Don't get carried away. In the present context we are only talking about
time and electrical measurements. Whilst most of the human race can't
read the English labels in /proc, they all use the same measurements for
electrical units and time (unless the time exceeds 24 hours, where dates
get a bit screwed up). In this case even the US in in line with the rest
of humanity. or would you like to be able to express battery
capacity in BTUs?

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

RE: kernel memory allocations alignment

[Hen, Shmulik]

Actually yes. We were warned that on IA64 architecture the system will halt
when accessing any type of variable via a pointer if the pointer does not
contain an aligned address matching that type. Until now we were using a
method of receiving a pointer to an array, casting it to a pointer of a
struct (packed with #pragma pack(1) ) ,and retrieving fields directly from
it with pointers.
It seems we cannot do that any more and were wondering what are the
alternatives.
One way we could think of is forget the packing and rearrange the fields in
the struct in descending order so they all come out aligned, but we didn't
know for sure if the first one will be aligned too.

Will that work ?


Thanks,
Shmulik Hen  
  Software Engineer
Linux Advanced Networking Services
Intel Network Communications Group
Jerusalem, Israel

-Original Message-
From: Manfred [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 04, 2001 5:56 PM
To: Hen, Shmulik
Cc: 'LKML'
Subject: Re: kernel memory allocations alignment


"Hen, Shmulik" wrote:
> 
> When using kmalloc(size_t size), do I get a guaranty that the memory
region
> allocated is aligned according to the size specified ?
> More to the point, if I call kmalloc for type int on an IA64 architecture
is
> the pointer going to be 8 bytes aligned ?
>

Yes, kmalloc results are always 'sizeof(void*)' aligned.

Do you have stricter alignment requirements?

--
Manfred

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

Re: 2.4.1 segfault when doing "ls /dev/"

[Pierre Rousselet]

Pierfrancesco Caci wrote:

> I can't see how this can affect performance/funtionality of
> devfsd. Can you try to stop the daemon and restart it to see if
> continues to work as before ?

/dev is mounted at boot time by the kernel (CONFIG_DEVFS_MOUNT=y).
The system boots and runs without devfsd. You just can't start any 
process calling for non-existing device under /dev and not created
by devfsd. For instance pppd or mc won't start by lack of pseudo-tty 
esd needs /dev/dsp ...

i was thinking the trouble may come from some programme launched by
your boot scripts before devfsd is running.

is your version of fileutils > 4.0.28 (ls --version) ?

-- 

 Pierre Rousselet <[EMAIL PROTECTED]>

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

Re: kernel memory allocations alignment

[Manfred]

"Hen, Shmulik" wrote:
> 
> When using kmalloc(size_t size), do I get a guaranty that the memory region
> allocated is aligned according to the size specified ?
> More to the point, if I call kmalloc for type int on an IA64 architecture is
> the pointer going to be 8 bytes aligned ?
>

Yes, kmalloc results are always 'sizeof(void*)' aligned.

Do you have stricter alignment requirements?

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

Re: Better battery info/status files

[James Sutherland]

On Sun, 4 Feb 2001, Ben Ford wrote:

> David Woodhouse wrote:
> 
> > On Sun, 4 Feb 2001, James Sutherland wrote:
> >
> > > For the end-user, the ability to see readings in other units would be
> > > useful - how many people on this list work in litres/metres/kilometres,
> > > and how many in gallons/feet/miles? Probably enough in both groups that
> > > neither could count as universal...
> >
> > Yeah. We can have this as part of the locale settings, changable by
> > echoing the desired locale string to /proc/sys/kernel/lc_all.
> >
> > -
> 
> Just an idea, . .  but isn't this something better done in userland?
> 
> (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> $ date  +%s
> 981298161
> (ben@Deacon)-(06:49am Sun Feb  4)-(ben)
> $ date  +%c
> Sun Feb  4 06:49:24 2001

That's what I'd do, anyway - /dev/pieceofstring would return the length of
said piece of string in some units, explicityly stated. (e.g. "5m" or
"15ft").

"uname -s" ("how long's a piece of string on this system") would then
convert the length into feet, metres or fathoms, depending on what the
user prefers.


James.

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

Re: d-link dfe-530 tx (bug-report)

[Manfred]

Urban Widmark wrote:
> 
> On Sun, 4 Feb 2001, Manfred Spraul wrote:
> 
> > > Oh, that's known already. They haven't released any info on the older
> > > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
> > > preliminary version.
> > >
> > Where can I find that file?
> > I'll try to implement tx_timeout()
> 
> http://www.via.com.tw/pdf/productinfo/vt86c100a.pdf
>

Ok, I've attached a patch that performs an unconditional reset in
tx_timeout().

I don't have the hardware, could you test it?

I also found newer via documentation on via's ftp site:
ftp.via.com.tw/public/lan/Products/NIC/VT86C100A, from Sept 98

--
Manfred

--- 2.4/drivers/net/via-rhine.c Sat Feb  3 14:02:54 2001
+++ build-2.4/drivers/net/via-rhine.c   Sun Feb  4 15:58:38 2001
@@ -380,6 +380,7 @@
CmdNoTxPoll=0x0800, CmdReset=0x8000,
 };
 
+#define MAX_MII_CNT4
 struct netdev_private {
/* Descriptor rings */
struct rx_desc *rx_ring;
@@ -421,7 +422,8 @@
 
/* MII transceiver section. */
u16 advertising;/* NWay media 
advertisement */
-   unsigned char phys[2];  /* MII device addresses. */
+   unsigned char phys[MAX_MII_CNT];/* MII device 
+addresses. */
+   unsigned int mii_cnt;   /* number of MIIs found, but only the 
+first one is used */
u16 mii_status; /* last read MII 
status */
 };
 
@@ -431,7 +433,6 @@
 static void via_rhine_check_duplex(struct net_device *dev);
 static void via_rhine_timer(unsigned long data);
 static void via_rhine_tx_timeout(struct net_device *dev);
-static void via_rhine_init_ring(struct net_device *dev);
 static int  via_rhine_start_tx(struct sk_buff *skb, struct net_device *dev);
 static void via_rhine_interrupt(int irq, void *dev_instance, struct pt_regs *regs);
 static void via_rhine_tx(struct net_device *dev);
@@ -451,14 +452,11 @@
struct netdev_private *np;
int i, option;
int chip_id = (int) ent->driver_data;
-   int irq = pdev->irq;
static int card_idx = -1;
static int did_version = 0;
long ioaddr;
int io_size;
int pci_flags;
-   void *ring;
-   dma_addr_t ring_dma;

/* print version once and once only */
if (! did_version++) {
@@ -471,6 +469,10 @@
io_size = via_rhine_chip_info[chip_id].io_size;
pci_flags = via_rhine_chip_info[chip_id].pci_flags;
 
+   if (pci_enable_device (pdev))
+   goto err_out;
+
+
/* this should always be supported */
if (!pci_dma_supported(pdev, 0x)) {
printk(KERN_ERR "32-bit PCI DMA addresses not supported by the 
card!?\n");
@@ -484,20 +486,7 @@
goto err_out;
}
 
-   /* allocate pci dma space for rx and tx descriptor rings */
-   ring = pci_alloc_consistent(pdev, 
-   RX_RING_SIZE * sizeof(struct rx_desc) +
-   TX_RING_SIZE * sizeof(struct tx_desc),
-   &ring_dma);
-   if (!ring) {
-   printk(KERN_ERR "Could not allocate DMA memory.\n");
-   goto err_out;
-   }
-
ioaddr = pci_resource_start (pdev, pci_flags & PCI_ADDR0 ? 0 : 1);
-
-   if (pci_enable_device (pdev))
-   goto err_out_free_dma;

if (pci_flags & PCI_USES_MASTER)
pci_set_master (pdev);
@@ -506,7 +495,7 @@
if (dev == NULL) {
printk (KERN_ERR "init_ethernet failed for card #%d\n",
card_idx);
-   goto err_out_free_dma;
+   goto err_out;
}
SET_MODULE_OWNER(dev);

@@ -545,23 +534,18 @@
dev->dev_addr[i] = readb(ioaddr + StationAddr + i);
for (i = 0; i < 5; i++)
printk("%2.2x:", dev->dev_addr[i]);
-   printk("%2.2x, IRQ %d.\n", dev->dev_addr[i], irq);
+   printk("%2.2x, IRQ %d.\n", dev->dev_addr[i], pdev->irq);
 
/* Reset the chip to erase previous misconfiguration. */
writew(CmdReset, ioaddr + ChipCmd);
 
dev->base_addr = ioaddr;
-   dev->irq = irq;
 
np = dev->priv;
spin_lock_init (&np->lock);
np->chip_id = chip_id;
np->drv_flags = via_rhine_chip_info[chip_id].drv_flags;
np->pdev = pdev;
-   np->rx_ring = ring;
-   np->tx_ring = ring + RX_RING_SIZE * sizeof(struct rx_desc);
-   np->rx_ring_dma = ring_dma;
-   np->tx_ring_dma = ring_dma + RX_RING_SIZE * sizeof(struct rx_desc);
 
if (dev->mem_start)
option = dev->mem_start;
@@ -593,7 +577,7 @@
if (np->drv_flags & CanHaveMII) {
int phy, phy_idx = 0;
np->phys[0] = 1;/* Standard for this chip. */
-   for (phy = 1; phy < 32 && phy_idx < 4; phy++) {
+   

Re: [OT] Major Clock Drift

[Hacksaw]

Technical explanations aside, some sort of clock drift exists in all 
computers. My experience with Sun hardware, for instance, was that the 
hardware and software clocks rarely agreed.

You should set up your machines to use some sort of time synchronization 
software, such as ntp or rdate. When I didn't have a 24/7 net presence, I had 
my ppp script run ntpdate when the connection was complete.

See http://www.eecis.udel.edu/~ntp/



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

[patch] 2.4.1-tmpfs-2

[Christoph Rohland]

Hi,

this is my second version of tmpfs against 2.4.1. It adds more
resonable reporting on statfs when there is no size limit given.

Have fun
Christoph


diff -uNr 2.4.1/Documentation/Changes 2.4.1-tmpfs-fstat/Documentation/Changes
--- 2.4.1/Documentation/Changes Tue Jan 30 11:06:59 2001
+++ 2.4.1-tmpfs-fstat/Documentation/Changes Thu Feb  1 22:04:13 2001
@@ -114,20 +114,6 @@
 DevFS is now in the kernel.  See Documentation/filesystems/devfs/* in
 the kernel source tree for all the gory details.
 
-System V shared memory is now implemented via a virtual filesystem.
-You do not have to mount it to use it. SYSV shared memory limits are
-set via /proc/sys/kernel/shm{max,all,mni}.  You should mount the
-filesystem under /dev/shm to be able to use POSIX shared
-memory. Adding the following line to /etc/fstab should take care of
-things:
-
-none   /dev/shmshm defaults0 0
-
-Remember to create the directory that you intend to mount shm on if
-necessary (The entry is automagically created if you use devfs). You
-can set limits for the number of blocks and inodes used by the
-filesystem with the mount options nr_blocks and nr_inodes.
-
 The Logical Volume Manager (LVM) is now in the kernel.  If you want to
 use this, you'll need to install the necessary LVM toolset.
 
diff -uNr 2.4.1/Documentation/Configure.help 
2.4.1-tmpfs-fstat/Documentation/Configure.help
--- 2.4.1/Documentation/Configure.help  Tue Jan 30 11:06:59 2001
+++ 2.4.1-tmpfs-fstat/Documentation/Configure.help  Thu Feb  1 22:06:30 2001
@@ -2739,14 +2739,6 @@
   section 6.4 of the Linux Programmer's Guide, available from
   http://www.linuxdoc.org/docs.html#guide .
 
-  Shared memory is now implemented using a new (minimal) virtual file
-  system. To mount it automatically at system startup just add the
-  following line to your /etc/fstab:
-
-  none /dev/shmshm defaults0 0
-
-  Saying Y here enlarges your kernel by about 18 KB. Just say Y.
-
 BSD Process Accounting
 CONFIG_BSD_PROCESS_ACCT
   If you say Y here, a user level program will be able to instruct the
@@ -10914,23 +10906,44 @@
 
   If unsure, say N.

+Virtual memory file system support
+CONFIG_TMPFS
+  Tmpfs is a file system which keeps all files in virtual memory.
+
+  In contrast to RAM disks, which get allocated a fixed amount of
+  physical RAM, tmpfs grows and shrinks to accommodate the files it
+  contains and is able to swap unneeded pages out to swap space.
+
+  Everything is "virtual" in the sense that no files will be created
+  on your hard drive; if you reboot, everything in tmpfs will be
+  lost.
+  
+  You should mount the filesystem somewhere to be able to use
+  POSIX shared memory. Adding the following line to /etc/fstab should
+  take care of things:
+
+  tmpfs/dev/shmtmpfs   defaults0 0
+
+  Remember to create the directory that you intend to mount tmpfs on
+  if necessary (/dev/shm is automagically created if you use devfs).
+
+  You can set limits for the number of blocks and inodes used by the
+  filesystem with the mount options "size", "nr_blocks" and
+  "nr_inodes". These parameters accept a suffix k, m or g for kilo,
+  mega and giga and can be changed on remount.
+  
+  The initial permissions of the root directory can be set with the
+  mount option "mode".
+
 Simple RAM-based file system support
 CONFIG_RAMFS
   Ramfs is a file system which keeps all files in RAM. It allows
   read and write access.
 
-  In contrast to RAM disks, which get allocated a fixed amount of RAM,
-  ramfs grows and shrinks to accommodate the files it contains.
+  It is more of an programming example than a useable filesystem. If
+  you need a file system which lives in RAM with limit checking use
+  tmpfs.
 
-  Before you can use this RAM-based file system, it has to be mounted,
-  meaning it has to be given a location in the directory hierarchy. If
-  you want to use the location /ramfiles for example, you would have
-  to create that directory first and then mount the file system by
-  saying "mount -t ramfs ramfs /ramfiles" or the equivalent line in
-  /etc/fstab. Everything is "virtual" in the sense that no files will
-  be created on your hard drive; if you reboot, everything in
-  /ramfiles will be lost.
-  
   If you want to compile this as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want),
   say M here and read Documentation/modules.txt. The module will be
diff -uNr 2.4.1/arch/i386/kernel/setup.c 2.4.1-tmpfs-fstat/arch/i386/kernel/setup.c
--- 2.4.1/arch/i386/kernel/setup.c  Tue Jan 30 11:07:00 2001
+++ 2.4.1-tmpfs-fstat/arch/i386/kernel/setup.c  Thu Feb  1 22:02:48 2001
@@ -559,7 +559,7 @@
 * blow away any automatically generated
 * size
 */
-   unsigned long start_at, mem_size;
+  

[patch] make tmpfs_statfs more user friendly

[Christoph Rohland]

Hi Alan,

The following patch make shmem_statfs report some sensible size
estimates in the case that the user does not give a size limit.

This should make it more error prone when used as /tmp

Greetings
Christoph

diff -uNr 2.4.1-tmpfs/mm/shmem.c 2.4.1-tmpfs-fstat/mm/shmem.c
--- 2.4.1-tmpfs/mm/shmem.c  Sun Feb  4 16:08:57 2001
+++ 2.4.1-tmpfs-fstat/mm/shmem.cSun Feb  4 16:09:50 2001
@@ -696,13 +696,20 @@
buf->f_type = TMPFS_MAGIC;
buf->f_bsize = PAGE_CACHE_SIZE;
spin_lock (&sb->u.shmem_sb.stat_lock);
-   if (sb->u.shmem_sb.max_blocks != ULONG_MAX || 
-   sb->u.shmem_sb.max_inodes != ULONG_MAX) {
+   if (sb->u.shmem_sb.max_blocks == ULONG_MAX) {
+   /*
+* This is only a guestimate and not honoured.
+* We need it to make some programs happy which like to
+* test the free space of a file system.
+*/
+   buf->f_bavail = buf->f_bfree = nr_free_pages() + nr_swap_pages + 
+atomic_read(&buffermem_pages);
+   buf->f_blocks = buf->f_bfree + ULONG_MAX - sb->u.shmem_sb.free_blocks;
+   } else {
buf->f_blocks = sb->u.shmem_sb.max_blocks;
buf->f_bavail = buf->f_bfree = sb->u.shmem_sb.free_blocks;
-   buf->f_files = sb->u.shmem_sb.max_inodes;
-   buf->f_ffree = sb->u.shmem_sb.free_inodes;
}
+   buf->f_files = sb->u.shmem_sb.max_inodes;
+   buf->f_ffree = sb->u.shmem_sb.free_inodes;
spin_unlock (&sb->u.shmem_sb.stat_lock);
buf->f_namelen = 255;
return 0;

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

ACPI broken in 2.4.1

[Tony Hoyle]

In my wifes' machine 2.4.1 (both vanilla and -ac2) enabling ACPI causes 
the machine to run so slowly it's unusable.  On my machine it's OK. 
2.4.0 worked fine, so something has changed between 2.4.0 and 2.4.1 that 
broke it.  I couldn't find anything in dmesg that looked any different, 
though.  However since that machine has never successfully booted with 
ACPI on the kern.log hasn't been written so it's unlikely I'd find anything.

Tony

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

Re: [OT] Major Clock Drift

[Steve Underwood]

"Michael B. Trausch" wrote:
> 
> On Sat, 3 Feb 2001, Josh Myer wrote:
> 
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any thoughts on the
> > cause? (Google didn't show up anything worthwhile in the first couple of
> > pages, so i gave up).
> >
> 
> I'm having the same problem here.  AMD K6-II, 450 MHz, VIA Chipset, Kernel
> 2.4.1.

If you don't use software time correction a minute a week is not too
bad, by current PC standards. Most Compaqs are off by more like a minute
a day. I have verified with a frequency counter that it is actually the
Compaq crystal oscillator which is at fault. Most motherboards are
better than this, but many are not great. The battery backed CMOS clock
is usually a lot better than the interrupt based one, but still not
great. They don't tweak them up like a watch maker would, even though
they usually use the same type of crystal.

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

/usr/src/linux/scripts/ver_linux prints out incorrect info when "ls" is aliased.

[Ishikawa]

I just noticed that running

.   /usr/src/linux/script/ver_linux

prints out strange libc version when I run it
as a normal user. It prints out expected output if
I run it as superuser.

Output Example: Incorrect and correct examples.

  Binutils   2.10.0.26
! Linux C Library1.3.so*
  Dynamic linker ldd: version 1.9.11
--- 7,9 
  Binutils   2.10.0.26
! Linux C Library2.1.3
  Dynamic linker ldd: version 1.9.11


After playing with the ver_linux script,
I found that if the command "ls" is aliased to
"ls -aF", the output is incorrect.

Not that I alias "ls" for superuser, but
I usually write bug report, etc. in
a normal user account, and ls is
aliased to "ls -aF" there.

Here is a potential fix to "ver_script".
(Given the possibility of various shell binaries/shell
startup code setting, etc., I think the
common denomiator solution is to use the output of
which as the name of the ls binary.)

I didn't change the handling of other commands.
"ls" is likely to be aliased, but I wonder
whether other commands are aliased. YMMV.

Possible fix to ver_script is attached.

*** ver_linux   Sun Feb  4 23:53:11 2001
--- /tmp/ver_linux  Mon Feb  5 00:00:54 2001
***
*** 7,12 
--- 7,19 
  PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
  echo '-- Versions installed: (if some fields are empty or look'
  echo '-- unusual then possibly you have very old versions)'
+ 
+ # to avoid the effect of aliasing "ls" command.
+ # YMMV.
+ # (I am not sure if other commands require similar
+ #  treatment.)
+ LS=`which ls`
+ 
  uname -a
  insmod -V  2>&1 | awk 'NR==1 {print "Kernel modules",$NF}'
  echo "Gnu C " `gcc --version`
***
*** 14,24 
'/GNU Make/{print "Gnu Make  ",$NF}'
  ld -v 2>&1 | awk -F\) '{print $1}' | awk \
'/BFD/{print "Binutils  ",$NF}'
! ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed -e 's/\.so$//' \
| awk -F'[.-]'   '{print "Linux C Library" $(NF-2)"."$(NF-1)"."$NF}'
  echo -n "Dynamic linker "
  ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1
! ls -l /usr/lib/lib{g,stdc}++.so  2>/dev/null | awk -F. \
 '{print "Linux C++ Library  " $4"."$5"."$6}'
  ps --version 2>&1 | awk 'NR==1{print "Procps", $NF}'
  mount --version | awk -F\- '{print "Mount ", $NF}'
--- 21,31 
'/GNU Make/{print "Gnu Make  ",$NF}'
  ld -v 2>&1 | awk -F\) '{print $1}' | awk \
'/BFD/{print "Binutils  ",$NF}'
! ${LS} -l `ldd /bin/sh | awk '/libc/ { print $3 } ' ` | sed -e 's/\.so$//' \
| awk -F'[.-]'   '{print "Linux C Library" $(NF-2)"."$(NF-1)"."$NF}'
  echo -n "Dynamic linker "
  ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1
! ${LS} -l /usr/lib/lib{g,stdc}++.so  2>/dev/null | awk -F. \
 '{print "Linux C++ Library  " $4"."$5"."$6}'
  ps --version 2>&1 | awk 'NR==1{print "Procps", $NF}'
  mount --version | awk -F\- '{print "Mount ", $NF}'

[2.4.1] "DEVFS+RAID" not working

[Art Boulatov]

Hi,

as I've posted before in [SoftwareRAID in 2.4.1],
I wasn't able to get RAID0 working
with devfs enabled and mounted on /dev.

The problem had gone after I passed devfs=nomount,
and used old device names for configuring/starting raid:

/dev/md0 instead of /dev/md/0
/dev/sda1 instead of /dev/scsi/host0/bus0/target0/lun0/part1
and so on.

Why?
Is that the way it is supposed to be with raid?
Why can't I just use devfs naming scheme,
and mount it on boot?
For some reason I wouldn't want those old device files under /dev.

Thanks in advance,
Art.

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