Fwd: Re: patch-2.4.2-ac19

[Frank Fiene]

--  Forwarded Message  --
Subject: Re: patch-2.4.2-ac19
Date: Tue, 13 Mar 2001 08:46:22 +0100
From: Frank Fiene <[EMAIL PROTECTED]>
To: Joachim Backes <[EMAIL PROTECTED]>


On Tuesday, 13. March 2001 08:14, Joachim Backes wrote:
> Hi,
>
> after applying patch-2.4.2-ac19 to the base 2.4.2 distribution, I
> have problems to install vmware: the vmware install has problems to
> find the symbol
>
> skb_datarefp
>
> in the /usr/src/linux/include tree.
>
> Without applying patch-2.4.2-ac19, it is found in
>
> /usr/src/linux/include/linux/skbuff.h
>
> and vmware-2.0.3-799 can be compiled.

Here is a patch for vmware. You have to apply this on
vmware-distrib/lib/modules/source/vmnet.tar:
untar vmnet
apply patch to vnetInt.h
tar vmnet
install

Regards. Frank.
P.S.: This is not official. It works for me!
--
Frank Fiene, SYNTAGS GmbH, Im Defdahl 5-10, D-44141 Dortmund, Germany
Security, Cryptography, Networks, Software Development
http://www.syntags.de mailto:[EMAIL PROTECTED]

---

-- 
Frank Fiene, SYNTAGS GmbH, Im Defdahl 5-10, D-44141 Dortmund, Germany
Security, Cryptography, Networks, Software Development
http://www.syntags.de mailto:[EMAIL PROTECTED]

 vmware.patch.bz2

test.. don't read..

[Umbra]

damn...it seems i don't get any mails from here :(

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

[PATCH] Using I2O modules with I2O core in kernel (follow up)

[Michael Mueller]

Hi Alan and folks,

I wrote: 
> the EXPORT_SYMBOL within the original source module. This was only done
> for the case it would have been compiled as kernel module. The patch is
> appended.

And again the mysterous lklm problem appeared and I forgot to append the
actual patch. Btw. the problem does exists through all the current
version of the 2.2 and 2.4 kernel line. The patch should apply cleanly
to all but the ac series where the sources were moved within the tree.


Michael

--- linux-2.4.2/drivers/i2o/i2o_core.c.orig Thu Feb 22 18:09:49 2001
+++ linux/drivers/i2o/i2o_core.cTue Mar 13 07:41:04 2001
@@ -3113,8 +3113,6 @@
 }
 
 
-#ifdef MODULE
-
 EXPORT_SYMBOL(i2o_controller_chain);
 EXPORT_SYMBOL(i2o_num_controllers);
 EXPORT_SYMBOL(i2o_find_controller);
@@ -3146,6 +3144,8 @@
 EXPORT_SYMBOL(i2o_dump_message);
 
 EXPORT_SYMBOL(i2o_get_class_name);
+
+#ifdef MODULE
 
 MODULE_AUTHOR("Red Hat Software");
 MODULE_DESCRIPTION("I2O Core");

patch-2.4.2-ac19

[Joachim Backes]

Hi,

after applying patch-2.4.2-ac19 to the base 2.4.2 distribution, I have problems
to install vmware: the vmware install has problems to find the symbol

skb_datarefp

in the /usr/src/linux/include tree.

Without applying patch-2.4.2-ac19, it is found in

/usr/src/linux/include/linux/skbuff.h

and vmware-2.0.3-799 can be compiled.

Regards

Joachim Backes

--

Joachim Backes <[EMAIL PROTECTED]>   | Univ. of Kaiserslautern
Computer Center, Supercomputing Division | Phone: +49-631-205-2438 
D-67653 Kaiserslautern, PO Box 3049, Germany | Fax:   +49-631-205-3056 
-+
WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html  

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

[PATCH] Using I2O modules with I2O core in kernel

[Michael Mueller]

Hi Alan and folks,


I got asked why it gives unresolved symbols (and how to fix it) for the
I2O modules. During the session I noticed this is due to the fact the
I2O core is built into the kernel but the other I2O support built as
module. So the quick hack to resolv that problem was adding the missing
symbols into ksyms.c.

Later on I noticed its possible to avoid this hacking simple by doing
the EXPORT_SYMBOL within the original source module. This was only done
for the case it would have been compiled as kernel module. The patch is
appended.


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

Re: quicksort for linked list

[James R Bruce]

Hi again.  The latter half of my email seems to have been forgotten in
the ensuing discussion, so I'll repost.  For a linked list of any
non-floating point data, radix sort is almost impossible to beat; it's
iterative, fast (linear time for fixed size integers, worst case), can
be stopped early for partial sorting, and has a pretty simple
implementation.

I've been using essentially the same radix sort implementation I
posted before to sort 1000 item lists 60 times a second in a numerical
application, and it barely shows up in the total time used when
profiling.  The other sorts I tried did not fare so well.  I would
much rather see this in a kernel modification than any
merge/quick/heap sort implementations I've seen so far for linked
lists.  OTOH, this conversation seems to have wandered out of
kernel-space anyway...

 - Jim Bruce

(Examples at: http://www.cs.cmu.edu/~jbruce/sort.cc)

10-Mar-2001 Re: quicksort for linked list by David [EMAIL PROTECTED] 
> For modern machines, I'm not sure that quicksort on a linked list is
> typically much cheaper than mergesort on a linked list.  The
> majority of the potential cost is likely to be in the pointer
> chasing involved in bringing the lists into cache, and that will be
> the same for both.  Once the list is in cache, how much pointer
> fiddling you do isn't so important.  For lists that don't fit into
> cache, the advantages of mergesort should become even greater if the
> literature on tape and disk sorts applies (though multiway merges
> rather than simple binary merges would be needed to minimize the
> impact of memory latency).
>
> Given this, mergesort might be generally preferable to quicksort for
> linked lists.  But I haven't investigated this idea thoroughly.
> (The trick described above for avoiding an explicit stack also works
> for mergesort.)

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

Re: make: *** [vmlinux] Error 1

[Krzysztof Halasa]

"J . A . Magallon" <[EMAIL PROTECTED]> writes:

> If you are using pgcc, try getting a real less-buggy compiler, like egcs1.1.2
> or gcc-2.95 (even 2.96 willl work).

... not always. I've had problems with gcc "2.96" from RH-7.0
- the compiler was generating obviously incorrect code in some cases
(and it wasn't .c code fault but a compiler problem).
-- 
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2ac20

[Nathan Walp]

Alan Cox wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/
> 
> Intermediate diffs are available from
> 
> http://www.bzimage.org
> 
> (Note that the cmsfs port to 2.4 is a work in progress)
> 
> Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so
> if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8)
> 
> 2.4.2-ac20
> o   Add support for the GoHubs GO-COM232(Greg Kroah-Hartman)
> o   Remove cobalt remnants  (Ralf Baechle)
> o   First block of mm documentation (Rik van Riel)
> o   Replace ancient Zoran driver with new one   (Serguei Miridonov,
> Wolfgang Scherr, Rainer Johanni, Dave Perks)
> o   Fix Alpha build (Jeff Garzik)
> o   Fix K7 mtrr breakage(Dave Jones)
> o   Fix pcnet32 touching resources before enable(Dave Jones)
> o   Merge with Linus 2.4.3pre4


Debian sid (unstable).  ac18 compiled fine.  ac20, i got this:

gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory
aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory
aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory
aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory
aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory
aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory
aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory
aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory
make[5]: *** [aicasm] Error 1
make[5]: Leaving directory
`/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx/aicasm'
make[4]: *** [aicasm/aicasm] Error 2
make[4]: Leaving directory
`/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory
`/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx'
make[2]: *** [_subdir_aic7xxx] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi'
make[1]: *** [_subdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers'
make: *** [_dir_drivers] Error 2
patience:/usr/src/linux# 



Also, sometime between ac7 and ac18 (spring break kept me from testing
stuff inbetween), i assume during the new aic7xxx driver merge, the
order of detection got changed, and now the ide-scsi virtual host is
host0, and my 29160N is host1.  Is this on purpose?  It messed up a
bunch of my stuff as far as /dev and such are concerned.  


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

ln -l says symlink has size 281474976710666

[John R Lenton]

as the subject says:

  lrwxrwxrwx1 root root 281474976710666 Jan 27 20:50 imlib1 -> imlib-base

it isn't the only one, for example

  lrwxrwxrwx1 root root 281474976710669 Jan 27 14:43 fd -> /proc/self/fd

i.e. 2**48 + what it should be.

ver_linux says

  Gnu C  2.95.3
  Gnu make   3.79.1
  binutils   2.10.91.0.2
  util-linux 2.10s
  modutils   2.4.2
  e2fsprogs  1.19
  reiserfsprogs  3.x.0b
  PPP2.4.0
  Linux C Library2.2.2
  Dynamic linker (ldd)   2.2.2
  Procps 2.0.7
  Net-tools  1.58
  Kbd1.04
  Sh-utils   2.0.11
  Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc rtc

the fs is plain ext2, and I'm running 2.4.2-ac16. My first guess
was I was needing a newer foo, but all my foos seem to be OK
(except for reiserfsprogs, but that's another issue).

-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
L'acne giovanile si cura con la vecchiaia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: Linux 2.4.2ac19

[thunder7]

On Mon, Mar 12, 2001 at 09:19:17PM +0100, J . A . Magallon wrote:
> 
> On 03.12 Alan Cox wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> > 
> 
> Silly idea: could you put the full path of the bz2 patch instead of only
> the dir ?
> 
I have another idea: would it be possible to start a new tree
alan/2.4.3/ when the 2.4.3 patches begin? Piling everything in 2.4/
isn't making things clearer.

Jurriaan
-- 
When you stick your fingers in the mains, its not the imaginary component
which you will feel.
>From an EIST lecturer
GNU/Linux 2.4.2-ac19 SMP/ReiserFS 2x1743 bogomips load av: 0.02 0.12 0.08
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: APIC usb MPS 1.4 and the 2.4.2 kernel

[Pete Toscano]

Well, I can't speak for the consequences of noapic (I've wondered as
much myself), but I know that there's been a problem with SMP 2.4
kernels (even the 2.4 test kernels) and USB running on VIA chipsets for
a while now.  I'm told by the linux-usb maintainers that it's a problem
with the PCI IRQ routing for the VIA chipsets, but I've been unable to
get anyone who knows about this to do anything (and I've been asking for
a while).  Alas, since this stuff is beyond me, I just accept the fact
that it'll probably always be broke.

pete

On Mon, 12 Mar 2001, David DeGeorge wrote:

> I am running 2.4.2 as obtained from redhat, but I have experienced the same 
> problems with a kernel compiled from the 2.4.2 sources at kernel.org.
> I am experiencing troubles with enabling MPS 1.4 and USB. I have an ABIT VP6 
> motherboard with two stock 733MHz PIIIs.
> If I set MPS1.1 in the bios then my IOmega Photoshow usb zip drive works, the 
> usb interrupt appears on irq 9 and after a day or two I experience  a hard 
> (sysreq doesn't work) lock. It seems usb related since doing usb things i.e. 
> mounting the drive sometimes cause the lock.
> If I set MPS1.4 in the bios  then the usb interrupt appears on irq 19, whose 
> count is alway zero, and the zip drive doesn't get registered. If give the 
> noapic command line then things appear to work, irq=9,don't know about the 
> hard locks, but booting seems much slower. Of course I can provide much more 
> information but I wonder is this a common problem and what are the 
> consequences of the noapic command?
> David

 PGP signature

Linux 2.4.2ac20

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/

Intermediate diffs are available from

http://www.bzimage.org

(Note that the cmsfs port to 2.4 is a work in progress)

Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so
if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8)


2.4.2-ac20
o   Add support for the GoHubs GO-COM232(Greg Kroah-Hartman)
o   Remove cobalt remnants  (Ralf Baechle)
o   First block of mm documentation (Rik van Riel)
o   Replace ancient Zoran driver with new one   (Serguei Miridonov,
Wolfgang Scherr, Rainer Johanni, Dave Perks)
o   Fix Alpha build (Jeff Garzik)
o   Fix K7 mtrr breakage(Dave Jones)
o   Fix pcnet32 touching resources before enable(Dave Jones)
o   Merge with Linus 2.4.3pre4

2.4.2-ac19
o   Typo fixes  (David Weinehall)
o   Merge first block of OHCI non x86 support   (Greg Kroah-Hartman)
o   Add Edgeport USB serial support (David Iacovelli,
 Greg Kroah-Hartman)
o   Fix doorlock on scsi removables (Alex Davies)
o   Fix hang when usb storage thread died   (me)
o   Change watchdog disable setup   (Ingo Molnar)
o   Fix bluetooth close and error bugs  (Narayan Mohanram)
o   mpt now has an assigned minor   (me)
| Remember to fix your /dev/mptctl if using MPT
o   Clean up 3270 ifdefs/printk a little(me)
o   Fix NBD deadlocks and update it (Steve Whitehouse)
o   Fix sercon printk divide by zero bug(Roger Gammans)
o   Remove cosine support from MIPS tree(Ralf Baechle)
o   bust_spinlocks for Alpha(Jeff Garzik)
o   Hopefully fix the buslogic corruptions  (me)
| This is a 'test if they went away' release not a 'its fixed' one.
o   Some mips makefile fixes(Ralf Baechle)
| except mips/kernel/Makefile (I got .rej Ralf)
o   ARC firmware interface fixes(Harald Koerfgen)
o   DECstation console drivers  (Michael Engel,
 Karsten Merker,
 Harald Koerfgen)
o   Fix ipx build bug   (Anton Altaparmakov)
o   Fix ptrace race (Stephen Tweedie)
o   Update include/config.h stuff, ver_linux(Niels Jensen)
o   Add missing pci_enable_device to cs4281 (Marcus Meissner,
 Thomas Woller)
o   Fix non PPC build of clgenfb(Andrew Morton)
o   Update CPU docs (Dave Jones)
o   Add mips atlas/malta reference boards   (Carsten Langgaard)
o   Add gt91600 ethernet support(SteveL)
o   Add philips SAA9730 ethernet(Carsten Langgaard)
o   PCnet32 driver fixes(Carsten Langgaard)
o   MIPS fpu emulator   (Algorithmics, Ralf Baechle, Kevin Kissell, 
Carsten Langgaard, Harald Koerfgen, Maciej Rozycki)
o   mips network driver updates (Ralf Baechle)
o   Fix FC920 workarounds in i2o(me)
o   Fix i2o_block hang on exit, 0 event race(me)
o   FIx i2o_core thread kill wakeup race(me)
o   Backport 2.2 VIA 686a clock reset workaround(Arjan van de Ven)
o   Further documentation updates   (Matthew Wilcox)

2.4.2-ac18
o   Debian has another location for db3 (Marc Volovic)
o   Remove duplicated flush_tlb_page export on  (Elliot Lee)
Alpha
o   Fix SB Live! build on SMP Alpha (Elliot Lee)
o   Fix disk corruption on qlogicisp and qlogicpti  (Arjan van de Ven)
o   Fix reporting of >4Gig of swap  (Hugh Dickins)
o   Fix sign issues in mpt fusion   (Andrew Morton)
o   CMS minidisk file system (read only)(Rick Troth)
2.4 port(me)
o   Disable nmi watchdog by default (Andrew Morton)
o   Fix elsa_cs eject problems  (Klaus Lichtenwalder)
o   Remove duplicate config entries (Steven Cole)
o   Fix further wrong license references(Andrzej Krzysztofowicz)
o   Add nmi watchdog disable for sysrq  (Andrew Morton)
o   Experimental test for serverworks/intel AGP (me)
comptability
o   

Re: Modular versus non-modular ISAPNP

[Ion Badulescu]

On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:

> It is highly recommended to always compile with CONFIG_ISAPNP=y due to
> these differences.  If you grep around for CONFIG_ISAPNP versus
> CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
> unprepared for isapnp support compiled as a module.

Another entry for the Kernel Janitor's List, perhaps?

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.4.3-pre3 not recognizing some SCSI CD drives

[jens]

On Mon, 12 Mar 2001 13:19:35 -0800, you wrote:

>I was running 2.2.18 and everything was working fine. I upgraded to
>2.4.3-pre3 and for some unknown reason the kernel will not recognize
>one particular CD drive on my SCSI chain. I doubt it's hardware
>related because switching to the old kernel resolves the problem.
>Furthermore, the other SCSI devices on the chain are recognized by
>2.4.3 indicating that the controller is properly compiled and can be
>accessed. Dmesg in 2.2.18 shows all three scsi devices, dmesg in 2.4.3
>shows all except a Mitsumi CD writer. 
>Is there a known problem ?
>Is it just me ?
>
>Jens

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

Re: system call for process information?

[Alexander Viro]

On Mon, 12 Mar 2001, Nathan Paul Simons wrote:

> On Mon, Mar 12, 2001 at 09:21:37PM +, Guennadi Liakhovetski wrote:
> > CPU utilisation. Each new application has to calculate it (ps, top, qps,
> > kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
> > syscall for that? Wouldn't it be more optimal?

The first rule of optimization: don't. I.e. optimizing something that
is not a bottleneck is pointless.


>   No, it wouldn't be worth it because you're talking about 
> sacrificing simplicity and kernel speed in favor of functionality.

Or, in that case, in favour of nothing. It doesn't add any functionality.

> This has been know to lead to "bloat-ware".  Every new syscall you
> add takes just a little bit more time and space in the kernel, and
> when only a small number of programs will be using it, it's really 
> not worth it.  This time and space may not be large, but once you
> get _your_ syscall added, why can't everyone else get theirs added 
> as well?  And so, after making about a thousand specialized syscalls
> standard in the kernel, you end up with IRIX (from what I've heard).

In that case there is much simpler argument.

If your program checks the system load so often that converting results
from ASCII to integers takes noticable time - all you are measuring
is the load created by that program. In other words, any program that
would get any speedup from such syscall is absolutely worthless, since
the load created by measurement will drown the load you are trying
to measure.

End of story. It's not only unnecessary and tasteless, it's
useless. 
Cheers,
Al

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

Modular versus non-modular ISAPNP (was Re: PATCH - compile fix for 3c509.c in 2.4.3-pre3)

[Jeff Garzik]

Neil Brown wrote:
> On Monday March 12, [EMAIL PROTECTED] wrote:
> > On Tue, 13 Mar 2001, Neil Brown wrote:
> > >  in 2.4.3-pre3, drivers/net/3c509.c will not compile ifdef CONFIG_ISAPNP.
> > >
> > >  The following patches fixes the error.  I suspect that 3c515.c has
> > >  the same problem, but I didn't need to fix that to get my kernel to
> > >  build... so I didn't.

> > 3c509 and 3c515 fixes already sent to him, twice no less :)

> Drat... I didn't remember seeing it go by on linux-kernel, but maybe I
> didn't pay enough attention next time I'll wait till the same
> problem appears in two pre releases before patching...

(re cc'd to lkml...)

My fault on that one, I didn't send it to lkml...

BTW if you noticed, this problem was undetected initially due to
differences between CONFIG_ISAPNP and CONFIG_ISAPNP_MODULE in the
source.

It is highly recommended to always compile with CONFIG_ISAPNP=y due to
these differences.  If you grep around for CONFIG_ISAPNP versus
CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
unprepared for isapnp support compiled as a module.

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: system call for process information?

[Nathan Paul Simons]

On Mon, Mar 12, 2001 at 09:21:37PM +, Guennadi Liakhovetski wrote:
> CPU utilisation. Each new application has to calculate it (ps, top, qps,
> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
> syscall for that? Wouldn't it be more optimal?

No, it wouldn't be worth it because you're talking about 
sacrificing simplicity and kernel speed in favor of functionality.
This has been know to lead to "bloat-ware".  Every new syscall you
add takes just a little bit more time and space in the kernel, and
when only a small number of programs will be using it, it's really 
not worth it.  This time and space may not be large, but once you
get _your_ syscall added, why can't everyone else get theirs added 
as well?  And so, after making about a thousand specialized syscalls
standard in the kernel, you end up with IRIX (from what I've heard).
Don't even get me started about opening security holes, and
increasing code complexity.  Please do a search for every other
syscall that has ever been proposed on this list, read them all 
and the arguments for them, then think long and hard about why yours
should be accepted.  Because I'm sure that I'm not the only person
who's going to want a good explanation as to why this syscall is
essential.

ps - CPU time is cheap, that's why they don't charge for it anymore.
Programmer time is _not_.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

APIC usb MPS 1.4 and the 2.4.2 kernel

[David DeGeorge]

I am running 2.4.2 as obtained from redhat, but I have experienced the same 
problems with a kernel compiled from the 2.4.2 sources at kernel.org.
I am experiencing troubles with enabling MPS 1.4 and USB. I have an ABIT VP6 
motherboard with two stock 733MHz PIIIs.
If I set MPS1.1 in the bios then my IOmega Photoshow usb zip drive works, the 
usb interrupt appears on irq 9 and after a day or two I experience  a hard 
(sysreq doesn't work) lock. It seems usb related since doing usb things i.e. 
mounting the drive sometimes cause the lock.
If I set MPS1.4 in the bios  then the usb interrupt appears on irq 19, whose 
count is alway zero, and the zip drive doesn't get registered. If give the 
noapic command line then things appear to work, irq=9,don't know about the 
hard locks, but booting seems much slower. Of course I can provide much more 
information but I wonder is this a common problem and what are the 
consequences of the noapic command?
David


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

Re: named pipe writes on readonly filesystems

[Alexander Viro]

On Mon, 12 Mar 2001, Chris Mason wrote:

> Hello everyone,
> 
> Since fs/pipe.c:pipe_write() calls mark_inode_dirty, and it is legal to
> write to a named pipe on a readonly filesystem, we can end up writing an
> inode on a readonly FS.

I would check that in pipe_write()...
Cheers,
Al

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

named pipe writes on readonly filesystems

[Chris Mason]

Hello everyone,

Since fs/pipe.c:pipe_write() calls mark_inode_dirty, and it is legal to
write to a named pipe on a readonly filesystem, we can end up writing an
inode on a readonly FS.

reiserfs prints a warning whenever someone tries to write an inode on a
readonly FS, so we've been getting a few complaints about this.

I see at least 3 choices:

drop the reiserfs warning, it was only there to chase things similar to the
remount root readonly bug in 2.4.0.

change mark_inode_dirty or write_inode to exit early on readonly
filesystems.

change pipe_write to leave the inode clean when the FS is readonly.

Does anyone have a preference?  I'd rather not see each FS have to check
for this on their own, but the other filesystems aren't as picky as
reiserfs in this case ;-)

-chris

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

[PATCH] missing pci_enable_device

[davej]

pcnet32 is still touching resources before enabling.
Patch below should apply to ac19.

regards

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/pcnet32.c 
linux-dj/drivers/net/pcnet32.c
--- linux/drivers/net/pcnet32.c Fri Mar  9 03:29:08 2001
+++ linux-dj/drivers/net/pcnet32.c  Fri Mar  9 03:41:33 2001
@@ -482,6 +482,12 @@

 printk(KERN_INFO "pcnet32_probe_pci: found device %#08x.%#08x\n", ent->vendor, 
ent->device);

+if ((err = pci_enable_device(pdev)) < 0) {
+   printk(KERN_ERR "pcnet32.c: failed to enable device -- err=%d\n", err);
+   return err;
+}
+pci_set_master(pdev);
+
 ioaddr = pci_resource_start (pdev, 0);
 printk(KERN_INFO "ioaddr=%#08lx  resource_flags=%#08lx\n", ioaddr, 
pci_resource_flags (pdev, 0));
 if (!ioaddr) {
@@ -494,13 +500,6 @@
return -ENODEV;
 }

-if ((err = pci_enable_device(pdev)) < 0) {
-   printk(KERN_ERR "pcnet32.c: failed to enable device -- err=%d\n", err);
-   return err;
-}
-
-pci_set_master(pdev);
-
 return pcnet32_probe1(ioaddr, pdev->irq, 1, card_idx, pdev);
 }


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

system hang with "__alloc_page: 1-order allocation failed"

[David Shoon]

Hi,

After some testing, 2.4.2, 2.4.2-pre3, and 2.4.3-ac18 and ac19 both
crash/hang when a fork loop (bomb) is executed (under a normal user) and
killed (by a superuser). This isn't what you'd expect in previous
kernels (2.2.x, and 2.0.x), as they both return to normal after killing
the process.

(This might be related to an earlier post about memory allocation?)

Anyway, a 'forkbomb' just looks like this (sorry, just clarifying the
obvious):

int main() {
while (1)
fork();
}

With 2.4.2, 2.4.2-pre3 after killing the process (ctrl-c or killall -9
prog) the kernel dumps error messages of: "__alloc_page: 1-order
allocation failed" continuously for a few minutes and then starts to
(randomly?) kill other processes which are active (such as xfs, bash)
with "Out of Memory: Killed process ### (etc.)". Keyboard input doesn't
work, but you can still switch vconsoles.

Under 2.4.2-ac18/19, the system doesn't show the error messages, but it
still hangs after you kill the process. All keyboard input freezes
eventually (can't switch vconsoles).

I'm not sure if it helps, but the system I'm testing this on is a PIII
500mhz, with 196megs of ram, with swap disabled just so I know it's not
device read/writes.

If anyone needs more info, give me a holler..

[ please cc: replies back to me since i'm not on the linux kernel list ]

p.s. apologies if this is already known or fixed
--
David Shoon
[EMAIL PROTECTED]


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

Re: hotplug and interrupt context

[Andreas Bombe]

On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote:
> Andreas Bombe wrote:
> > 
> > I couldn't trace that down to be 100% sure and it's better to conform to
> > design than implementation, so I'll ask:
> > 
> > Do the probe and remove functions of a pci_driver have to be able to
> > work in interrupt context?  (i.e. GFP_ATOMIC and stuff)
> 
> No, no interrupt context to worry about.  It would really suck if you
> couldn't sleep in pci_driver::probe :)

Very good.  I wasn't sure since I saw GFP_ATOMIC allocations somewhere
in the cardbus code which looked like it was in card initialization.
But it's also confusing and somewhere was a note saying that some of
this is obsolete code which is replaced elsewhere...

> For CardBus, it calls schedule_task ..

Another thing learned, thanks.

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH - compile fix for 3c509.c in 2.4.3-pre3

[Jeff Garzik]

On Tue, 13 Mar 2001, Neil Brown wrote:
>  in 2.4.3-pre3, drivers/net/3c509.c will not compile ifdef CONFIG_ISAPNP.
> 
>  The following patches fixes the error.  I suspect that 3c515.c has
>  the same problem, but I didn't need to fix that to get my kernel to
>  build... so I didn't.

3c509 and 3c515 fixes already sent to him, twice no less :)


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

Oops: 0002 error message, "unexpected IO-APIC", and "SCSI Host abort" messages

[Shane Gibson]

Hello,

I just upgraded my system from dual PII 450s to
dual PIII 750s.  I'm now getting three major problems.
I'm not sure if they are related.  The first is an
'Oops:  0002' crash and burn, the second is an io-apic
error as recorded by dmesg, the third is a crash and
burn with the console saying "SCSI host abort".  Please
note I had Zero problems with this system, until 
installing the PIII750s.  Is that odd, or what...

I'm running a relatively stock RedHat 7.0 platform, on
a SuperMicro PIIIDME dual processor motherboard.  The
processors are Intel PIII 750s, with 256k cache.  The
crash and 'ksymoops' produce:

ksymoops 2.3.4 on i686 2.2.16-22smp.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.16-22smp/ (default)
 -m /boot/System.map (specified)

Error (expand_objects): cannot stat(/lib/aic7xxx.o) for aic7xxx
Error (pclose_local): find_objects pclose failed 0x100
Mar 12 12:30:12 walker kernel: Unable to handle kernel paging request at
virtual address 8620
Mar 12 12:30:12 walker kernel: current->tss.cr3 = 0d17a000, %%cr3 = 0d17a000
Mar 12 12:30:12 walker kernel: *pde = 
Mar 12 12:30:12 walker kernel: Oops: 0002
Mar 12 12:30:12 walker kernel: CPU:0
Mar 12 12:30:12 walker kernel: EIP:0010:[truncate_inode_pages+124/316]
Mar 12 12:30:12 walker kernel: EFLAGS: 00010286
Mar 12 12:30:12 walker kernel: eax:    ebx: d4827288   ecx: c04e87e8
edx: c0433178
Mar 12 12:30:12 walker kernel: esi: d4827210   edi: 8600   ebp: 
esp: c9371ee8
Mar 12 12:30:12 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 12 12:30:12 walker kernel: Process rateup (pid: 18192, process nr: 41,
stackpage=c9371000)
Mar 12 12:30:12 walker kernel: Stack: 0005a178 1af7 d4827288 df045c9c
d4827288 c0136e73 d4827210 

Mar 12 12:30:12 walker kernel:d4827210 c0142f29 d4827210 d4827210
d4827210  c7fe9ce0 d4827210

Mar 12 12:30:12 walker kernel:0017 df00c400  defd90e0
c01438a3 c01438c2 d4827210 c0234860

Mar 12 12:30:12 walker kernel: Call Trace: [clear_inode+19/112]
[ext2_free_inode+293/644] [ext2_delete_inode+
87/124] [ext2_delete_inode+118/124] [iput+155/588] [d_delete+74/104]
[ext2_unlink+385/416]
Mar 12 12:30:12 walker kernel: Code: 89 57 20 8b 51 20 8b 79 10 89 3a c7 41
20 00 00 00 00 ff 0d
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 57 20  mov%edx,0x20(%edi)
Code;  0003 Before first symbol
   3:   8b 51 20  mov0x20(%ecx),%edx
Code;  0006 Before first symbol
   6:   8b 79 10  mov0x10(%ecx),%edi
Code;  0009 Before first symbol
   9:   89 3a mov%edi,(%edx)
Code;  000b Before first symbol
   b:   c7 41 20 00 00 00 00  movl   $0x0,0x20(%ecx)
Code;  0012 Before first symbol
  12:   ff 0d 00 00 00 00 decl   0x0


2 errors issued.  Results may not be reliable.




The IO-APIC error is recorded from this exerpt from the
syslog files.


Mar 11 15:07:10 walker kernel: Pentium-III serial number disabled.
Mar 11 15:07:10 walker kernel: Checking 386/387 coupling... OK, FPU using
exception 16 error reporting.
Mar 11 15:07:10 walker kernel: Checking 'hlt' instruction... OK.
Mar 11 15:07:10 walker kernel: POSIX conformance testing by UNIFIX
Mar 11 15:07:10 walker kernel: mtrr: v1.35a (19990819) Richard Gooch
([EMAIL PROTECTED])
Mar 11 15:07:10 walker kernel: Pentium-III serial number disabled.
Mar 11 15:07:10 walker kernel: per-CPU timeslice cutoff: 50.03 usecs.
Mar 11 15:07:10 walker kernel: CPU0: Intel Pentium III (Coppermine) stepping
03
Mar 11 15:07:10 walker kernel: calibrating APIC timer ...
Mar 11 15:07:10 walker kernel: . CPU clock speed is 745.7690 MHz.
Mar 11 15:07:10 walker kernel: . system bus clock speed is 99.4358 MHz.
Mar 11 15:07:10 walker kernel: Booting processor 1 eip 2000
Mar 11 15:07:10 walker kernel: Calibrating delay loop... 1490.94 BogoMIPS
Mar 11 15:07:10 walker kernel: Pentium-III serial number disabled.
Mar 11 15:07:10 walker kernel: OK.
Mar 11 15:07:10 walker kernel: CPU1: Intel Pentium III (Coppermine) stepping
03
Mar 11 15:07:10 walker kernel: Total of 2 processors activated (2978.61
BogoMIPS).
Mar 11 15:07:10 walker kernel: enabling symmetric IO mode... ...done.
Mar 11 15:07:10 walker kernel: ENABLING IO-APIC IRQs
Mar 11 15:07:10 walker kernel: init IO_APIC IRQs
Mar 11 15:07:10 walker kernel:  IO-APIC (apicid-pin) 2-0, 2-18, 2-19, 2-20,
2-21, 2-22, 2-23, 3-0, 3-1, 3-2,
3-3, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15, 3-16,
3-17, 3-18, 3-19, 3-20, 3-21, 3-22, 3
-23 not connected.
Mar 11 15:07:10 walker kernel: number of MP IRQ sources: 23.
Mar 11 15:07:10 walker kernel: number of IO-APIC #2 registers: 24.
Mar 11 15:07:10 walker kernel: number of IO-APIC #3 registers: 24.
Mar 11 15:07:10 walker kernel: testing the IO 

Re: Broken Tulip Driver

[Ian Zink]

I will try tonight and let you know.

Thanks, Ian

Jeff Garzik wrote:

> Can you try out the updated Tulip driver in 2.4.2-ac19 and let me know
> if it works?
>
> ftp://ftp.us.kernel.org/pub/linux/kernel/people/alan/2.4/
>
> --
> Jeff Garzik   | May you have warm words on a cold evening,
> Building 1024 | a full mooon on a dark night,
> MandrakeSoft  | and a smooth road all the way to your door.

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

PATCH - compile fix for 3c509.c in 2.4.3-pre3

[Neil Brown]

Linus,
 in 2.4.3-pre3, drivers/net/3c509.c will not compile ifdef CONFIG_ISAPNP.

 The following patches fixes the error.  I suspect that 3c515.c has
 the same problem, but I didn't need to fix that to get my kernel to
 build... so I didn't.

NeilBrown



--- ./drivers/net/3c509.c   2001/03/12 00:39:58 1.1
+++ ./drivers/net/3c509.c   2001/03/12 01:31:13 1.2
@@ -327,7 +327,7 @@
irq = idev->irq_resource[0].start;
if (el3_debug > 3)
printk ("ISAPnP reports %s at i/o 0x%x, irq %d\n",
-   el3_isapnp_adapters[i].name, ioaddr, irq);
+   (char *)el3_isapnp_adapters[i].driver_data, 
+ioaddr, irq);
EL3WINDOW(0);
for (j = 0; j < 3; j++)
el3_isapnp_phys_addr[pnp_cards][j] =
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

aicasm build error with db3

[dave]

Hi group,

  I recently seen a message go by regarding this
Sorry for asking if this has been hashed out more than twice.
I didn't see anything in Documentation about it.  Nothing in
Configure.help about db3 either.

make[4]: Entering directory `/usr/src/linux-2.4.2/drivers/scsi/aic7xxx/aicasm'
gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm
/tmp/cc4xDUrp.o: In function `symtable_open':
/tmp/cc4xDUrp.o(.text+0x1b5): undefined reference to `__db185_open'
collect2: ld returned 1 exit status
make[4]: *** [aicasm] Error 1
make[4]: Leaving directory `/usr/src/linux-2.4.2/drivers/scsi/aic7xxx/aicasm'
make[3]: *** [aicasm/aicasm] Error 2
make[3]: Leaving directory `/usr/src/linux-2.4.2/drivers/scsi/aic7xxx'
make[2]: *** [_modsubdir_aic7xxx] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.2/drivers/scsi'
make[1]: *** [_modsubdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.2/drivers'
make: *** [_mod_drivers] Error 2


I have verified the path in aicdb.h is correct.
I am attempting to build it as a module to include in an initrd.

Tnx
-- 
Dave

---
Dave Helton, KD0YU- [EMAIL PROTECTED]  - http://www.kd0yu.com
Real World Computing  - 319-386-4041 - 8am-5pm CST
---


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

Trouble with an ip_conntrack_helper

[Steven Walter]

I'm getting some interesting behavior while writing an ip_conntrack
helper module.  The primary problem is if I specify a destination port
for the struct ip_conntrack_helper, my help routine is never called.
If I specify a source port, rather than a destination port, the routine
gets called for the various packets in the desired connection.

The problem with this is that I my routine doesn't start getting called
until a packet in the opposite direction arrives, and all packets before
that are never sent by my module.  This makes sense, as the tuple
specifies a /source/ port, which would only occur on reverse traffic.

Here is the chunk of code I'm using to register my helper.  Is there
something really obvious that I'm missing.  I really appreciate any help
you can give.

static struct ip_conntrack_helper icq;

static int __init init(void) {
memset(, 0, sizeof(struct ip_conntrack_helper));
icq.tuple.dst.protonum = IPPROTO_UDP;
icq.tuple.dst.u.udp.port = __constant_htons(4000);
icq.mask.dst.protonum = 0x;
icq.mask.dst.u.udp.port = 0x;
icq.help = help;
printk(KERN_INFO "ip_conntrack_icq: registered\n");
return ip_conntrack_helper_register();
}


-- 
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Broken Tulip Driver

[Ian Zink]

Hello all, I have an SMC Etherpower10/100 in my system that refuses to
work under linux 2.4.2, it worked fine in 2.4.0 and the 2.2.x series. I
know the card is working fine since when I dual-boot into windows it
links fine. Strangely, once the linux drivers load it will not even link
to my hub at all. The light on the back of the card blinks green.
ifconfig shows lots of carrier errors. I will attach below all the
relevant information I can think of. Any help will be greatly
appreciated. Please CC me on any responses, as I'm not on the kernel
mailing list.

Thanks, Ian Zink


zforce:/home/zforce# gcc --version
2.95.3

(Note: I tried the 2.4.3-pre3 patch to see if the problem was already
fixed)

zforce:/home/zforce# uname -a
Linux zforce 2.4.3-pre3 #1 Sun Mar 11 20:13:44 CST 2001 i686 unknown

Interesting parts of /proc/pci
(This card works perfectly fine)

  Bus  0, device   9, function  0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
(rev 0).
  IRQ 5.
  I/O at 0xd000 [0xd01f].
  Bus  0, device  10, function  0:
...

  Bus  0, device  11, function  0:
Ethernet controller: Digital Equipment Corporation DECchip 21140
[FasterNet] (rev 32).
  IRQ 10.
  Master Capable.  Latency=32.  Min Gnt=20.Max Lat=40.
  I/O at 0xb000 [0xb07f].
  Non-prefetchable 32 bit memory at 0xe080 [0xe080007f].


zforce:/home/zforce# ifconfig -a
(Take note of all of the carrier errors)
eth0  Link encap:Ethernet  HWaddr 00:00:C0:41:99:E9
  inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:199 dropped:0 overruns:0 carrier:199
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  Interrupt:10 Base address:0xb000

(IP address edited out for security)
eth1  Link encap:Ethernet  HWaddr 00:C0:F0:45:BD:04
  inet addr:xxx.xxx.xxx.xxx  Bcast:216.162.97.255
Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:7736 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8543 errors:0 dropped:0 overruns:0 carrier:0
  collisions:1 txqueuelen:100
  RX bytes:5565587 (5.3 Mb)  TX bytes:978504 (955.5 Kb)
  Interrupt:5 Base address:0xd000

zforce:/home/zforce# less /var/log/dmesg

Linux Tulip driver version 0.9.14 (February 20, 2001)
PCI: Found IRQ 10 for device 00:0b.0
eth0: Digital DS21140 Tulip rev 32 at 0xb000, 00:00:C0:41:99:E9, IRQ 10.

eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1)
block.
eth0:  MII transceiver #3 config 3100 status 7809 advertising 01e1.
eth0:  Advertising 0001 on PHY 3, previously advertising 01e1.
eth0:  Advertising 0001 (to advertise is 0001).
ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker
  http://www.scyld.com/network/ne2k-pci.html
PCI: Found IRQ 5 for device 00:09.0
PCI: The same IRQ used for device 00:04.2
eth1: RealTek RTL-8029 found at 0xd000, IRQ 5, 00:C0:F0:45:BD:04.
...


Please remember to CC! Thanks again...


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

Re: [NFS] Oops in 2.4.2 - please give advice

[Keith Owens]

On Mon, 12 Mar 2001 18:36:33 +0100, 
Jean-Eric Cuendet <[EMAIL PROTECTED]> wrote:
>Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says
>c02086c0, System.map says c014f200.  Ignoring ksyms_base entry

That message is suspicious.  It looks like you have md built into the
kernel but some module has redefined partition_name.  Since the only
code that defines partition_name in 2.4.2 is drivers/md/md.c, it looks
like you managed to build md.o into the kernel and as a module.  Please
double check your config and modules_install.

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

Free Palm VII with Qwest Business DSL

[DSL]

Visit DataRFP, www.datarfp.com, and pre-qualify for Qwest High Speed DSL
service.

Qwest DSL, free Cisco 678 Router and Palm Pilot III Xe. 

DataRFP, the one stop for all of your telecommunications needs.

www.datarfp.com
[EMAIL PROTECTED]


























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

Re: curious messages

[David S. Miller]

David Ford writes:
 > Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0

 > simple debug messages, or is someone (andy/dave) interested in them?

Debug messages, ignore...

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix MTRR support for AMD Athlon

[davej]

On Mon, 12 Mar 2001, Troels Walsted Hansen wrote:

Hi Troels,

> Dave Jones' recent 2.4.2ac17 patch to mtrr.c to support the Cyrix III
> unfortunately broke the AMD Athlon support. Here's a patch to correct
> the problem (Dave must have overlooked the fall-through logic of the
> switch statement).

Indeed I did. I was about to look into this just as your mail arrived,
after someone told me about MTRRs with 'size=16773376MB'.
This should fix it. However I think the patch below would be a
better fix, removing the drop-through case, and making the switch
more obvious. It guarantees no-one will make the mistake again :)
(At least not with this switch).

Patch rediffed against 2.4.2-ac19

regards,

Dave.


diff -urN --exclude-from=/home/davej/.exclude linux/arch/i386/kernel/mtrr.c 
linux-dj/arch/i386/kernel/mtrr.c
--- linux/arch/i386/kernel/mtrr.c   Mon Mar 12 20:40:28 2001
+++ linux-dj/arch/i386/kernel/mtrr.cMon Mar 12 21:06:28 2001
@@ -235,6 +235,12 @@
   v1.38
 20010309   Dave Jones <[EMAIL PROTECTED]>
   Add support for Cyrix III.
+
+  v1.39
+20010312   Dave Jones <[EMAIL PROTECTED]>
+   Ugh, I broke AMD support.
+  Reworked fix by Troels Walsted Hansen <[EMAIL PROTECTED]>
+
 */
 #include 
 #include 
@@ -274,7 +280,7 @@
 #include 
 #include 

-#define MTRR_VERSION"1.37 (20001109)"
+#define MTRR_VERSION"1.39 (20010312)"

 #define TRUE  1
 #define FALSE 0
@@ -1964,6 +1970,7 @@
get_mtrr = intel_get_mtrr;
set_mtrr_up = intel_set_mtrr_up;
switch (boot_cpu_data.x86_vendor) {
+
case X86_VENDOR_AMD:
/* The original Athlon docs said that
   total addressable memory is 44 bits wide.
@@ -1982,6 +1989,10 @@
size_and_mask = ~size_or_mask & 0xfff0;
break;
}
+   size_or_mask  = 0xff00; /* 36 bits */
+   size_and_mask = 0x00f0;
+   break;
+
case X86_VENDOR_CENTAUR:
/* Cyrix III has Intel style MTRRs, but doesn't support PAE */
if (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 6) {
@@ -1996,6 +2007,7 @@
size_and_mask = 0x00f0;
break;
}
+
 } else if ( test_bit(X86_FEATURE_K6_MTRR, _cpu_data.x86_capability) ) {
/* Pre-Athlon (K6) AMD CPU MTRRs */
mtrr_if = MTRR_IF_AMD_K6;


-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

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

[PATCH] documentation mm.h, mmzone.h and swap.h

[Rik van Riel]

Hi Linus, Alan,

The patch below adds documentation to mm.h, mmzone.h and swap.h.
I know it's not complete, but I'm stopping with the documentation
for now, I'll continue at a later date ;)

Please apply this for the next (pre)kernel.

thanks,

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

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



--- linux-2.4.2-doc/include/linux/mm.h.orig Wed Mar  7 15:36:32 2001
+++ linux-2.4.2-doc/include/linux/mm.h  Fri Mar  9 19:48:15 2001
@@ -39,32 +39,38 @@
  * library, the executable area etc).
  */
 struct vm_area_struct {
-   struct mm_struct * vm_mm;   /* VM area parameters */
-   unsigned long vm_start;
-   unsigned long vm_end;
+   struct mm_struct * vm_mm;   /* The address space we belong to. */
+   unsigned long vm_start; /* Our start address within vm_mm. */
+   unsigned long vm_end;   /* The first byte after our end address
+  within vm_mm. */

/* linked list of VM areas per task, sorted by address */
struct vm_area_struct *vm_next;

-   pgprot_t vm_page_prot;
-   unsigned long vm_flags;
+   pgprot_t vm_page_prot;  /* Access permissions of this VMA. */
+   unsigned long vm_flags; /* Flags, listed below. */

/* AVL tree of VM areas per task, sorted by address */
short vm_avl_height;
struct vm_area_struct * vm_avl_left;
struct vm_area_struct * vm_avl_right;

-   /* For areas with an address space and backing store,
+   /*
+* For areas with an address space and backing store,
 * one of the address_space->i_mmap{,shared} lists,
 * for shm areas, the list of attaches, otherwise unused.
 */
struct vm_area_struct *vm_next_share;
struct vm_area_struct **vm_pprev_share;

+   /* Function pointers to deal with this struct. */
struct vm_operations_struct * vm_ops;
-   unsigned long vm_pgoff; /* offset in PAGE_SIZE units, *not* 
PAGE_CACHE_SIZE */
-   struct file * vm_file;
-   unsigned long vm_raend;
+
+   /* Information about our backing store: */
+   unsigned long vm_pgoff; /* Offset (within vm_file) in PAGE_SIZE
+  units, *not* PAGE_CACHE_SIZE */
+   struct file * vm_file;  /* File we map to (can be NULL). */
+   unsigned long vm_raend; /* XXX: put full readahead info here. */
void * vm_private_data; /* was vm_pte (shared mem) */
 };

@@ -90,6 +96,7 @@
 #define VM_LOCKED  0x2000
 #define VM_IO   0x4000 /* Memory mapped I/O or similar */

+   /* Used by sys_madvise() */
 #define VM_SEQ_READ0x8000  /* App will access data sequentially */
 #define VM_RAND_READ   0x0001  /* App will not benefit from clustered reads */

@@ -124,37 +131,145 @@
 };

 /*
+ * Each physical page in the system has a struct page associated with
+ * it to keep track of whatever it is we are using the page for at the
+ * moment. Note that we have no way to track which tasks are using
+ * a page.
+ *
  * Try to keep the most commonly accessed fields in single cache lines
  * here (16 bytes or greater).  This ordering should be particularly
  * beneficial on 32-bit processors.
  *
  * The first line is data used in page cache lookup, the second line
  * is used for linear searches (eg. clock algorithm scans).
+ *
+ * TODO: make this structure smaller, it could be as small as 32 bytes.
  */
 typedef struct page {
-   struct list_head list;
-   struct address_space *mapping;
-   unsigned long index;
-   struct page *next_hash;
-   atomic_t count;
-   unsigned long flags;/* atomic flags, some possibly updated asynchronously 
*/
-   struct list_head lru;
-   unsigned long age;
-   wait_queue_head_t wait;
-   struct page **pprev_hash;
-   struct buffer_head * buffers;
-   void *virtual; /* non-NULL if kmapped */
-   struct zone_struct *zone;
+   struct list_head list;  /* ->mapping has some page lists. */
+   struct address_space *mapping;  /* The inode (or ...) we belong to. */
+   unsigned long index;/* Our offset within mapping, in
+  units of PAGE_CACHE_SIZE. */
+   struct page *next_hash; /* Next page sharing our hash bucket in
+  the page cache hash table. */
+   atomic_t count; /* Usage count, see below. */
+   unsigned long flags;/* atomic flags, some possibly
+  updated asynchronously */
+   struct list_head lru;   /* Pageout list, eg active_list;
+  

Re: [tulip] Linux 2.2.16/Tulip Smartbits testing.

[Godfrey Livingstone]

Chip Are you going to make your driver available for others to use?


Godfrey

Chip Rodden wrote:

> John,
>
> It's the driver.  We have been doing smartbits testing for more
> than a year and found the same results as you appear to be getting.
> The driver just dies and never recovers.  It attempts to do
> interrupt mitigation(coalescing) but that appears to be useless.
>
> The solution is to write a new driver which is what we have done
> here...
>
> Chip
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: IDE on 2.4.2

[Steven Walter]

On Mon, Mar 12, 2001 at 08:50:23AM +0100, Martin Diehl wrote:
> 
> On Sun, 11 Mar 2001, Steven Walter wrote:
> > I have this exact same chip on my board (a PCChips M599-LMR or something
> > like that) which works flawlessly on 2.4.2, even with UDMA66.
> 
> Do you have CONFIG_BLK_DEV_SIS5513 and autotuning enabled at the
> same time? Unless I enable them both it works flawlessly for me too - up
> to UDMA33. In fact, I've never seen any docs claiming the 5591/5513 would
> even provide UDMA66 support. How do you program the controler to do UDMA66
> cycles?
> Anyway, might be interesting to have a look at your lspci -d:5513 -vvvxxx
> report from working UDMA33/66 setups!

The big man himself, Andre Hedrick, has stated that the SiS5513 should
work in UDMA/66 mode, as is evidenced by my setup.

Yep, both are enabled (from .config):
CONFIG_BLK_DEV_SIS5513=y
CONFIG_IDEDMA_AUTO=y

I don't have to do anything to program it to UDMA66, as this is what it
defaults to on boot (from dmesg):

SIS5513: IDE controller on PCI bus 00 dev 01
PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try using pci=biosirq.
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS530
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD84AA, ATA DISK drive
hdc: ATAPI 48X CDROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 16514064 sectors (8455 MB) w/2048KiB Cache, CHS=1027/255/63, UDMA(66)
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33)

And, as you've requested, here is the lspci output from my system, which
is working and in UDMA66.

00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev
d0) (prog-if 80 [Master])
Subsystem: Silicon Integrated Systems [SiS]: Unknown device 5513
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at ffa0 [size=16]
00: 39 10 13 55 05 00 00 00 d0 80 01 01 00 80 80 00
10: f1 01 00 00 f5 03 00 00 71 01 00 00 75 03 00 00
20: a1 ff 00 00 00 00 00 00 00 00 00 00 39 10 13 55
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
40: 01 93 00 00 01 b3 00 00 23 07 e6 11 00 02 00 02
50: 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Be sure that you have an 80-conductor cable, however.  On my system,
there is a BIOS option for UDMA.  This apparently overrides/takes the
place of proper cable detection.  If I turn it on without an 80-pin
cable, Linux defaults to UDMA66 and I get drive major drive corruption.
When off, I can't use UDMA66.

I hope all this is helpful to you!
-- 
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: system call for process information?

[Guennadi Liakhovetski]

On Mon, 12 Mar 2001, Alexander Viro wrote:

> On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:
> 
> > I need to collect some info on processes. One way is to read /proc
> > tree. But isn't there a system call (ioctl) for this? And what are those
> 
> Occam's Razor.  Why invent new syscall when read() works?

CPU utilisation. Each new application has to calculate it (ps, top, qps,
kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
syscall for that? Wouldn't it be more optimal?

> > task[], task_struct, etc. about?
> 
> What branch? (2.0, 2.2, 2.4?)

Well, what I mean was - don't these structures contain the information I
am looking for? Let's start from the end - 2.4, then what's the difference
with 2.2 and finally 2.0?

Thanks
Guennadi
___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]


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

Re: [tulip] Linux 2.2.16/Tulip Smartbits testing.

[Chip Rodden]

John,

It's the driver.  We have been doing smartbits testing for more
than a year and found the same results as you appear to be getting.
The driver just dies and never recovers.  It attempts to do
interrupt mitigation(coalescing) but that appears to be useless.

The solution is to write a new driver which is what we have done
here...

Chip
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

Kernel 2.4.3-pre3 not recognizing some SCSI CD drives

[jens]

I was running 2.2.18 and everything was working fine. I upgraded to
2.4.3-pre3 and for some unknown reason the kernel will not recognize
one particular CD drive on my SCSI chain. I doubt it's hardware
related because switching to the old kernel resolves the problem.
Furthermore, the other SCSI devices on the chain are recognized by
2.4.3 indicating that the controller is properly compiled and can be
accessed. Dmesg in 2.2.18 shows all three scsi devices, dmesg in 2.4.3
shows all except a Mitsumi CD writer. 
Is there a known problem ?
Is it just me ?

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

Linux 2.4.1 fails to detect any IDE drives upon boot.

[Richard B. Johnson]

Hello,
A new system upon which I installed RH 7.0. I tried to install
Linux-2.4.1 since that't what all my software is written for...

Linux 2.2.16-22 (Came with RedHat 7.0) shows this upon successful
startup:

VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL EX10.2A, ATA DISK drive
hdb: FX4830T, ATAPI CDROM drive
hdc: no response (status = 0xbf), resetting drive
hdc: no response (status = 0xbf)
hdd: no response (status = 0xbf), resetting drive
hdd: no response (status = 0xbf)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: QUANTUM FIREBALL EX10.2A, 9787MB w/418kB Cache, CHS=1247/255/63


Attempts to install Linux-2.4.1 show this upon unsuccessful startup:

VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio
hda: no response (status = 0xbf), resetting drive
hda: no response (status = 0xbf)
hdb: no response (status = 0xbf), resetting drive
hdb: no response (status = 0xbf)
hdc: no response (status = 0xbf), resetting drive
hdc: no response (status = 0xbf)
hdd: no response (status = 0xbf), resetting drive
hdd: no response (status = 0xbf)

Appropriate ./configs of grep =y, grep =m :


CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M486=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_NOHIGHMEM=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_PARPORT_OTHER=y
CONFIG_PNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IPV6_EUI64=y
CONFIG_IPX_INTERN=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_HD_IDE=y
CONFIG_BLK_DEV_HD=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_AEC62XX_TUNING=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_WDC_ALI15X3=y
CONFIG_BLK_DEV_AMD7409=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_OPTI621=y
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_OSB4=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
CONFIG_BLK_DEV_DTC2278=y
CONFIG_BLK_DEV_HT6560B=y
CONFIG_BLK_DEV_PDC4030=y
CONFIG_BLK_DEV_QD6580=y
CONFIG_BLK_DEV_UMC8672=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y
CONFIG_AIC7XXX_PROC_STATS=y
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_G_NCR5380_PORT=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_NET_ISA=y
CONFIG_NET_PCI=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_FT_NORMAL_DEBUG=y
CONFIG_FT_STD_FDC=y
CONFIG_QUOTA=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_JOLIET=y
CONFIG_NTFS_RW=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_QNX4FS_RW=y
CONFIG_EXT2_FS=y
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_TOSHIBA=m
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_IPV6=m
CONFIG_IPX=m
CONFIG_X25=m
CONFIG_LAPB=m
CONFIG_ECONET=m
CONFIG_WAN_ROUTER=m
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m

Re: 2.4 and PPPoE problem

[Martin Hicks]

Yes...my MTU on ppp0 was to high.  Thanks.

mh

On Mon, Mar 12, 2001 at 10:06:15PM +0200, mulix wrote:
> hi, 
> 
> you might want to check your mtu and mru values on both the external
> interface (i assume you are using an ADSL modem, from your usage of
> PPPoE, so that will be eth0) and the internal interface (ppp0). the mtu
> and mru values on the internal interface should be a bit less than those
> on the external interface, to work around modem bugs. 
> 
> here in israel, an MTU value of 1500 for the external interface and 1452
> for the internal (1452) seems to work fine and solve a problem which
> sounds exactly like yours. 
> 
> On Mon, 12 Mar 2001, Martin Hicks wrote:
> 
> > The machine connects fine and allows network traffic to pass
> > through the link.
> > 
> > However, certain websites seem to choke.
> > (notable ones are www.chapters.ca and www.hp.com)
> > 
> > Using Lynx or Netscape I get the same results, a few bytes of
> > traffic are received and then nothing (eventually the connection
> > times out).  
> 
> -- 
> mulix
> http://www.advogato.com/person/mulix
> 
> linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
> 

-- 
Martin Hicks   || [EMAIL PROTECTED]
Use PGP/GnuPG  || DSS PGP Key: 0x4C7F2BEE  
Beer: So much more than just a breakfast drink.

 PGP signature

[PATCH] Fix MTRR support for AMD Athlon

[Troels Walsted Hansen]

Hello world,

Dave Jones' recent 2.4.2ac17 patch to mtrr.c to support the Cyrix III
unfortunately broke the AMD Athlon support. Here's a patch to correct
the problem (Dave must have overlooked the fall-through logic of the
switch statement).

Enjoy...

-- 
Troels Walsted Hansen

--- mtrr.c1.38  Sun Mar 11 13:42:30 2001
+++ mtrr.c  Mon Mar 12 21:02:15 2001
@@ -235,6 +235,12 @@
   v1.38
 20010309   Dave Jones <[EMAIL PROTECTED]>
   Add support for Cyrix III.
+
+  v1.39
+20010312   Troels Walsted Hansen <[EMAIL PROTECTED]>
+  Fixed the AMD Athlon support that Dave Jones' patch
broke.
+  Also updated the version number to match this changelog.
+
 */
 #include 
 #include 
@@ -274,7 +280,7 @@
 #include 
 #include 
 
-#define MTRR_VERSION"1.37 (20001109)"
+#define MTRR_VERSION    "1.39 (20010312)"
 
 #define TRUE  1
 #define FALSE 0
@@ -1964,6 +1970,14 @@
get_mtrr = intel_get_mtrr;
set_mtrr_up = intel_set_mtrr_up;
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_CENTAUR:
+   /* Cyrix III has Intel style MTRRs, but doesn't support
PAE */
+   if (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model ==
6) {
+   size_or_mask  = 0xfff0; /* 32 bits */
+   size_and_mask = 0;
+   }
+   break;
+
case X86_VENDOR_AMD:
/* The original Athlon docs said that
   total addressable memory is 44 bits wide.
@@ -1982,13 +1996,7 @@
size_and_mask = ~size_or_mask & 0xfff0;
break;
}
-   case X86_VENDOR_CENTAUR:
-   /* Cyrix III has Intel style MTRRs, but doesn't support
PAE */
-   if (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model ==
6) {
-   size_or_mask  = 0xfff0; /* 32 bits */
-   size_and_mask = 0;
-   }
-   break;
+   /* NOTE: fallthrough to default here! */
 
default:
/* Intel, etc. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: make: *** [vmlinux] Error 1

[tmwhitehead]

Thanks for the tips. Yes, I'm using pgcc... Guess I'll switch back to gcc.

Thanks again

tw


Le jour Sun Mar 11, 2001 at 08:54:08PM -0600, Tim Whitehead a ecrit... 

> On a compile of 2.4.2 I get the following (using make bzImage) 
> 
> 
> make[2]: Leaving directory `/usr/src/linux-2.4.2/linux/arch/i386/lib'
> make[1]: Leaving directory `/usr/src/linux-2.4.2/linux/arch/i386/lib'
> ld -m elf_i386 -T /usr/src/linux-2.4.2/linux/arch/i386/vmlinux.lds -e stext
> arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o
> \
> --start-group \
> arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
> fs/fs.o ipc/ipc.o \
> drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
> drivers/net/net.o drivers/media/media.o  drivers/parport/driver.o
> drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o
> drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o \
> net/network.o \
> /usr/src/linux-2.4.2/linux/arch/i386/lib/lib.a
> /usr/src/linux-2.4.2/linux/lib/lib.a
> /usr/src/linux-2.4.2/linux/arch/i386/lib/lib.a \
> --end-group \
> -o vmlinux
> init/main.o: In function `check_fpu':
> init/main.o(.text.init+0x63): undefined reference to `__buggy_fxsr_alignment'
> make: *** [vmlinux] Error 1
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Feedback for fastselect and one-copy-pipe

[kuznet]

Hello!

> freebsd-4.0 doesn't use direct transfers for PAGE_SIZE'd pipe write()s:
> it uses  MINDIRECT=8192.

I see.

> (and PIPE_BUF is 512, so 4096 was possible for
> them)

8) I see.

Thank you for patience. 8)

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

Re: linux localization

[Andreas Dilger]

XingFei writes:
> My work will concern with the internationalization of Linux
> So, could anybody tell me what kinds of features should be in the
> consideration when linux be localized from english to Japanese or chinese,
> say using 2 bytes character set.

Is this for Linux console i18n?  TurboLinux has a kernel patch (2.2)
for Unicode support on the console (with CJK input):

http://www.turbolinux.com.cn/TLDN/chinese/project/unicon/

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

[jamagallon@able.es: Re: Linux 2.4.2ac19]

[J . A . Magallon]

On 03.12 J . A . Magallon wrote:

On 03.12 Alan Cox wrote:
> But then I have to remember to change it each time
> 

I am not used to smileys, but obviously there was one missing in my mail...

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

Linux werewolf 2.4.2-ac18 #1 SMP Sun Mar 11 01:21:35 CET 2001 i686

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

Re: Feedback for fastselect and one-copy-pipe

[Manfred Spraul]

From: <[EMAIL PROTECTED]>
>
> > freebsd
>
> Very funny, the idea is borrowed from there.
>
> As you could understand your patch kills it. PAGE_SIZE is one of the
most
> frequently used transfer unit.
>

freebsd-4.0 doesn't use direct transfers for PAGE_SIZE'd pipe write()s:
it uses  MINDIRECT=8192. (and PIPE_BUF is 512, so 4096 was possible for
them)


--
Manfred

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

Re: Linux 2.4.2ac19

[Matti Aarnio]

On Mon, Mar 12, 2001 at 09:19:17PM +0100, J . A . Magallon wrote:
> On 03.12 Alan Cox wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
> Silly idea: could you put the full path of the bz2 patch instead of only
> the dir ?
> 
> So people will only have to cut'n'paste for wget...

Sigh...  "The Man is smart, the man is stupid panicy ..."
(never seen that written -- from MiB, anyway)

Folks, you are SUPPOSED to be smart and replace 'ftp.kernel.org'
with   ftp.XX.kernel.org  where XX is your NEAREST ccTLD.
When you do that, does it really matter that you have to use
some other tool than wget ?

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

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

Re: 2.4 and PPPoE problem

[Jeremy Jackson]

Martin Hicks wrote:

> Hello,
>
> I'm using PPPoE with an i586 machine running 2.4.2.

are you using the kernel pppoe or the user-space one (rp-pppoe, etc)?
did it work on other kernels?

>
>
> The machine connects fine and allows network traffic to pass
> through the link.
>
> However, certain websites seem to choke.
> (notable ones are www.chapters.ca and www.hp.com)
>
> Using Lynx or Netscape I get the same results, a few bytes of
> traffic are received and then nothing (eventually the connection
> times out).
>
> The same does not happen in windows.  (ugh)
>
> I have not encountered any machine that I have telnet/ftp/ssh
> access to that breaks in this way so I can only confirm that http traffic
> is not working.
>
> This gateway machine does masquerading, and internal machines and the external
> machine react the same way.

are you positive the external (2.4.2 machine, right?) acts this way?

you can send me a tcpdump trace of a session or two that chokes.

>
>
> TIA
> mh
>
> Here is some useful info:
>
> mort@galileo:~$ uname -a
> Linux galileo 2.4.2 #4 Thu Feb 22 14:13:23 EST 2001 i586 unknown
>
> mort@galileo:~$ /sbin/ifconfig ppp0
> ppp0  Link encap:Point-to-Point Protocol
>   inet addr:209.217.122.37  P-t-P:209.217.122.1  Mask:255.255.255.255
>   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
>   RX packets:1272056 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1476697 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:3
>   RX bytes:430171737 (410.2 Mb)  TX bytes:1260803415 (1202.3 Mb)
>
> mort@galileo:~$ /sbin/route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> magma   *   255.255.255.255 UH0  00 ppp0
> 192.168.69.0*   255.255.255.0   U 0  00 eth0
> default magma   0.0.0.0 UG0  00 ppp0
>
> --
> Martin Hicks   || [EMAIL PROTECTED]
> Use PGP/GnuPG  || DSS PGP Key: 0x4C7F2BEE
> Beer: So much more than just a breakfast drink.
>
>   
>Part 1.2Type: application/pgp-signature

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

Re: Linux 2.4.2ac19

[J . A . Magallon]

On 03.12 Alan Cox wrote:
> 
>   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 

Silly idea: could you put the full path of the bz2 patch instead of only
the dir ?

So people will only have to cut'n'paste for wget...

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

Linux werewolf 2.4.2-ac18 #1 SMP Sun Mar 11 01:21:35 CET 2001 i686

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

Re: Feedback for fastselect and one-copy-pipe

[kuznet]

Hello!

> freebsd

Very funny, the idea is borrowed from there.

As you could understand your patch kills it. PAGE_SIZE is one of the most
frequently used transfer unit.

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

Re: Feedback for fastselect and one-copy-pipe

[Manfred Spraul]

From: <[EMAIL PROTECTED]>
>
> PS BTW "all unix" is unlikely to include freebsd. 8)
>

freebsd, openbsd, netbsd, tru64, openvms - all unix versions I found
free telnet guest accounts for.

Running for cover,
Manfred

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

Linux 2.4.2ac19

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

(Note that the cmsfs port to 2.4 is a work in progress)

2.4.2-ac19
o   Typo fixes  (David Weinehall)
o   Merge first block of OHCI non x86 support   (Greg Kroah-Hartman)
o   Add Edgeport USB serial support (David Iacovelli,
 Greg Kroah-Hartman)
o   Fix doorlock on scsi removables (Alex Davies)
o   Fix hang when usb storage thread died   (me)
o   Change watchdog disable setup   (Ingo Molnar)
o   Fix bluetooth close and error bugs  (Narayan Mohanram)
o   mpt now has an assigned minor   (me)
| Remember to fix your /dev/mptctl if using MPT
o   Clean up 3270 ifdefs/printk a little(me)
o   Fix NBD deadlocks and update it (Steve Whitehouse)
o   Fix sercon printk divide by zero bug(Roger Gammans)
o   Remove cosine support from MIPS tree(Ralf Baechle)
o   bust_spinlocks for Alpha(Jeff Garzik)
o   Hopefully fix the buslogic corruptions  (me)
| This is a 'test if they went away' release not a 'its fixed' one.
o   Some mips makefile fixes(Ralf Baechle)
| except mips/kernel/Makefile (I got .rej Ralf)
o   ARC firmware interface fixes(Harald Koerfgen)
o   DECstation console drivers  (Michael Engel,
 Karsten Merker,
 Harald Koerfgen)
o   Fix ipx build bug   (Anton Altaparmakov)
o   Fix ptrace race (Stephen Tweedie)
o   Update include/config.h stuff, ver_linux(Niels Jensen)
o   Add missing pci_enable_device to cs4281 (Marcus Meissner,
 Thomas Woller)
o   Fix non PPC build of clgenfb(Andrew Morton)
o   Update CPU docs (Dave Jones)
o   Add mips atlas/malta reference boards   (Carsten Langgaard)
o   Add gt91600 ethernet support(SteveL)
o   Add philips SAA9730 ethernet(Carsten Langgaard)
o   PCnet32 driver fixes(Carsten Langgaard)
o   MIPS fpu emulator   (Algorithmics, Ralf Baechle, Kevin Kissell, 
Carsten Langgaard, Harald Koerfgen, Maciej Rozycki)
o   mips network driver updates (Ralf Baechle)
o   Fix FC920 workarounds in i2o(me)
o   Fix i2o_block hang on exit, 0 event race(me)
o   FIx i2o_core thread kill wakeup race(me)
o   Backport 2.2 VIA 686a clock reset workaround(Arjan van de Ven)
o   Further documentation updates   (Matthew Wilcox)

2.4.2-ac18
o   Debian has another location for db3 (Marc Volovic)
o   Remove duplicated flush_tlb_page export on  (Elliot Lee)
Alpha
o   Fix SB Live! build on SMP Alpha (Elliot Lee)
o   Fix disk corruption on qlogicisp and qlogicpti  (Arjan van de Ven)
o   Fix reporting of >4Gig of swap  (Hugh Dickins)
o   Fix sign issues in mpt fusion   (Andrew Morton)
o   CMS minidisk file system (read only)(Rick Troth)
2.4 port(me)
o   Disable nmi watchdog by default (Andrew Morton)
o   Fix elsa_cs eject problems  (Klaus Lichtenwalder)
o   Remove duplicate config entries (Steven Cole)
o   Fix further wrong license references(Andrzej Krzysztofowicz)
o   Add nmi watchdog disable for sysrq  (Andrew Morton)
o   Experimental test for serverworks/intel AGP (me)
comptability
o   Fix ipx reference counting for routes   (Arnaldo Carvalho
 de Melo)

2.4.2-ac17
o   Make the aic7xxx code handle multiple db3 paths (me)
o   Small further via updates   (Vojtech Pavlik)
o   IDE tape updates for Onstream tape drives   (Marcel Mol)
o   Remove some bits of module.c that cant get  (Keith Owens
executed Andrew Morton)
o   Configure.help fixups   (Steven Cole)
o   Add Cyrix MTRR data (Dave Jones)
o   Fix a slight bogon in the i386 Makefile (Dave Jones)
o   Kill an escaped modversions.h   (Keith Owens)

2.4 and PPPoE problem

[Martin Hicks]

Hello,

I'm using PPPoE with an i586 machine running 2.4.2.

The machine connects fine and allows network traffic to pass
through the link.

However, certain websites seem to choke.
(notable ones are www.chapters.ca and www.hp.com)

Using Lynx or Netscape I get the same results, a few bytes of
traffic are received and then nothing (eventually the connection
times out).  

The same does not happen in windows.  (ugh)

I have not encountered any machine that I have telnet/ftp/ssh
access to that breaks in this way so I can only confirm that http traffic 
is not working.

This gateway machine does masquerading, and internal machines and the external
machine react the same way.

TIA
mh


Here is some useful info:

mort@galileo:~$ uname -a
Linux galileo 2.4.2 #4 Thu Feb 22 14:13:23 EST 2001 i586 unknown

mort@galileo:~$ /sbin/ifconfig ppp0
ppp0  Link encap:Point-to-Point Protocol  
  inet addr:209.217.122.37  P-t-P:209.217.122.1  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
  RX packets:1272056 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1476697 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:3 
  RX bytes:430171737 (410.2 Mb)  TX bytes:1260803415 (1202.3 Mb)


mort@galileo:~$ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
magma   *   255.255.255.255 UH0  00 ppp0
192.168.69.0*   255.255.255.0   U 0  00 eth0
default magma   0.0.0.0 UG0  00 ppp0




-- 
Martin Hicks   || [EMAIL PROTECTED]
Use PGP/GnuPG  || DSS PGP Key: 0x4C7F2BEE  
Beer: So much more than just a breakfast drink.

 PGP signature

Re: Feedback for fastselect and one-copy-pipe

[kuznet]

Hello!

> It returns immediately on all unix platforms I tested

I see. It is essential moment. PAGE_SIZE was really bad threshold value.
Sigh and alas.

Alexey


PS BTW "all unix" is unlikely to include freebsd. 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: static scheduling - SCHED_IDLE?

[Adrian Cox]

Jamie Lokier wrote:

> Adrian Cox wrote:

>> Jamie Lokier's suggestion of raising priority when in the kernel doesn't 
>> help. You need to raise the priority of the task which is currently in 
>> userspace and will call up() next time it enters the kernel. You don't 
>> know which task that is.

> Dear oh dear.  I was under the impression that kernel semaphores are
> supposed to be used as mutexes only -- there are other mechanisms for
> signalling between processes.

I think most of the kernel semaphores are used as mutexes, with 
occasional producer/consumer semaphores. I think the core kernel code is 
fine, the risk mostly comes from miscellaneous character devices. I've 
written code that does this for a specialised device driver. I wanted 
only one process to have the device open at once, and for others to 
block on open. Using semaphores meant that multiple shells could do "cat 
 > /dev/mywidget" and be serialised.

Locking up users of this strange piece of hardware doesn't bring down 
the system, so your suggestion could work. We need a big fat warning in 
semaphore.h, and a careful examination of the current code.

- Adrian

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

Re: Linux kernel - and regular sync'ing?

[Mark Shewmaker]

On Thu, Mar 08, 2001 at 02:50:46PM -0800, Brian Dushaw wrote:
> - the problem is fixed by adding the "noatime" option when mounting the
> root filesystem (I use /etc/fstab to do this)
> - there appears to be no harm in not updating the inode access times with
> this option.

As an aside, you may want to keep in mind the fact that you've edited
the /etc/fstab in this way, in case random oddities show up in the future.

Short story:

Once after a system upgrade, some of the user accounts developed a problem
in which the message "You have new mail" would be printed on the screen
at every login.  The message would be printed whether or not the user
actually had new mail.  The problem was independent of the login shell
used, but it would only happen for some users.

It turned out that the "problem" was a few lines in the login program
itself.  login was comparing the atime and mtime timestamps of $MAIL.
If mtime>atime, then it figured you had new mail and would print that
message.

That makes sense--if your mailbox had been written to (modified) since
it was last read (accessed), then that's as as good a definition as any
of having new mail.  But, I had put "noatime" in /etc/fstab during the
upgrade for the line for the filesystem that /var/spool/mail was in,
and no one's mail spool had had its atime updated since the upgrade, hence
"You have new mail" messages were printed during some users' logins.

(It turned out that the folks who were not getting the message at all
were sorting all their mail into separate folders, leaving $MAIL
empty all the time.)

We decided that the slight performance advantages of the noatime option
weren't worth it and quickly removed the option.  (-o remount is great!)

It's probably very much worth it for you to keep your /etc/fstab as you've
edited it, but I did want to warn you that the noatime option can
still unexpectedly break programs that make quite reasonable assumptions.

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

Re: Linux 2.4.2ac12 (vt82c686 info)

[Andre Hedrick]

Daniela,

Great to hear from you again my dear! ;-)

On Fri, 9 Mar 2001, Vojtech Pavlik wrote:

> On Fri, Mar 09, 2001 at 08:25:43AM +0100, Daniela Engert wrote:
> 
> > >They're about the same - only Alan didn't like the PCI speed measurement
> > >code that's new in the 4.x series, so I added all the other changes to
> > >the 3.20 driver, and 3.21 was born.
> > 
> > I do understand Alan's objections against this speed measurement code
> > very well. I have similar code built into other (non-Linux) drivers,
> > and according to the many user reports that I got the measurement
> > results should be taken with a grain of salt. It is working perfectly
> > in most cases, but it may fail from time to time. There is a hidden
> > assumption in this type of measurement which the device that you run
> > the test against has to fulfill. If it doesn't (and it is not required
> > to do to be conforming to the ATA spec), the measurement results (PCI
> > bus clock) are bogus (typically way too high).
> 
> Actually I don't think my method can ever result in a measurement higher
> than real PCI clock, but can result in a lower one (if the device
> deasserts IORDY even on a speed slower than PIO_0), which is also a
> problem. Anyway, on fast machines the accuracy of the current algorithm
> is +- .01 MHz.
> 
> Once tested a little more, the measurement will probably go in, however
> with an option for the user to override it with a command line
> parameter.
> 
> Btw, if it isn't a secret - what other drivers are those and what is the
> exact method you used ... ?
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: [patch] Does this correct a bug in ibmcam.c?

[Alan Cox]

> + int chan;
>  
> - if (copy_from_user(, arg, sizeof(v)))
> - return -EFAULT;
> - if ((v < 0) || (v >= 3)) /* 3 grades of lighting conditions */
> - return -EINVAL;
> - if (v != ibmcam->vchan.channel) {
> - ibmcam->vchan.channel = v;
> + chan = (int)arg;
> + 
> + if ((chan < 0) || (chan >= 3)) /* 3 grades of lighting 
>conditions */ 
> + return -EINVAL; 
> + 
> + if (chan != ibmcam->vchan.channel) {
> + ibmcam->vchan.channel = chan;   
>   usb_ibmcam_change_lighting_conditions(ibmcam);
> - }
> + }
>   return 0;
>   }

This change is wrong. I think you are calling the ioctl wrongly

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

Re: quicksort for linked list

[Jamie Lokier]

David Wragg wrote:
> For modern machines, I'm not sure that quicksort on a linked list is
> typically much cheaper than mergesort on a linked list.
...
> For lists that don't fit into cache, the advantages of mergesort
> should become even greater if the literature on tape and disk sorts
> applies (though multiway merges rather than simple binary merges would
> be needed to minimize the impact of memory latency).
...
> Given this, mergesort might be generally preferable to quicksort for
> linked lists.  But I haven't investigated this idea thoroughly.  (The
> trick described above for avoiding an explicit stack also works for
> mergesort.)

Fwiw, below is a pretty good list mergesort.  It takes linear time on
"nearly sorted" lists (i.e. better than classic mergesort), and degrades
to O(n log n) worst case (i.e. better than quicksort).  It's
non-recursive and uses a small bounded stack.

enjoy ;-)

-- Jamie

/* A macro to sort linked lists efficiently.
   O(n log n) worst case, O(n) on nearly sorted lists.

   Copyright (C) 1995, 1996, 1999 Jamie Lokier.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA */

#ifndef __fast_merge_sort_h
#define __fast_merge_sort_h

/* {{{ Description */

/* This macro sorts singly-linked lists efficiently.

   To sort a doubly-linked list: sort, then traverse the forward
   links to regenerate the reverse links.

   Written by Jamie Lokier <[EMAIL PROTECTED]>, 1995-1999.
   Version 2.0.

   Properties
   ==

   1. Takes O(n) time to sort a nearly-sorted list; very fast indeed.

   2. Takes O(n log n) time for worst case and for random-order average.
  Worst case is a reversed list.  Sorting is still fast.
  NB: This is much faster than unmodified quicksort, which is O(n^2).

   3. Requires no extra memory: sorts in place like heapsort and
  quicksort.  Uses a small array (typically 32 pointers) on the
  stack.

   4. Stable: equal elements are kept in the same relative order.

   5. Macro so the comparisons and structure modifications are in line.
  You typically have a C function which calls the macro and does
  very little else.  The sorting code is not small enough to be worth
  inlining in its caller; however, the comparisons and strucure
  modifications generally _are_ worth inlining into the sorting code.

   Requirements
   

   Any singly-linked list structure.  You provide the structure type,
   and the name of the structure member to reach the next element, and
   the address of the first element.  The last element is identified by
   having a null next pointer.

   How to sort a list
   ==

   Call as `FAST_MERGE_SORT (LIST, TYPE, NEXT, LESS_THAN_OR_EQUAL_P)'.

  `LIST' points to the first node in the list, or can be null.
  Afterwards it is updated to point to the beginning of the sorted list.

  `TYPE' is the type of each node in the linked list.

  `NEXT' is the name of the structure member containing the links.
  In C++, this can be a call to a member function which returns a
  non-const reference.

  `LESS_THAN_OR_EQUAL_P' is the name of a predicate which, given two
  pointers to objects of type `TYPE', determines if the first is
  less than or equal to the second.  The equality test is important
  to keep the sort stable (see earlier).

  The total number of items must fit in `unsigned long'.

   How to update a sorted list
   ===

   A call is provided to sort a list, and combine that with another
   which is already sorted.  This is useful when you've sorted a list,
   but later want to add some new elements.  The code is optimised by
   assuming that the already sorted list is likely to be the larger.

   The already sorted list comes earlier in the input, for the purpose
   of stable sorting.  That is, if an element in the already sorted list
   compares equal to one in the list to sort, the element from the
   already sorted list will come first in the output.

   Call as `FAST_MERGE_SORT_APPEND (ALREADY_SORTED, LIST, TYPE, NEXT,
   LESS_THAN_OR_EQUAL_P)'.

  `ALREADY_SORTED' points to the first node of an already sorted
  list, or can be null.  If the list isn't sorted already, the
  result is undefined.

  `LIST' points to the first node in the list to 

[patch] Does this correct a bug in ibmcam.c?

[Lee Brown]

I had problems with copy_from_user.

Please CC me as I am not on this list.
__


--- ibmcam.c.orig   Fri Feb  9 14:30:23 2001
+++ ibmcam.cMon Mar 12 02:58:57 2001
@@ -2527,16 +2527,17 @@
}
case VIDIOCSCHAN:
{
-   int v;
+   int chan;
 
-   if (copy_from_user(, arg, sizeof(v)))
-   return -EFAULT;
-   if ((v < 0) || (v >= 3)) /* 3 grades of lighting conditions */
-   return -EINVAL;
-   if (v != ibmcam->vchan.channel) {
-   ibmcam->vchan.channel = v;
+   chan = (int)arg;
+   
+   if ((chan < 0) || (chan >= 3)) /* 3 grades of lighting 
+conditions */ 
+   return -EINVAL; 
+   
+   if (chan != ibmcam->vchan.channel) {
+   ibmcam->vchan.channel = chan;   
usb_ibmcam_change_lighting_conditions(ibmcam);
-   }
+   }
return 0;
}
case VIDIOCGPICT:



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

Re: scsi vs ide performance on fsync's

[Andre Hedrick]

On Wed, 7 Mar 2001, Stephen C. Tweedie wrote:

> Hi,
> 
> On Tue, Mar 06, 2001 at 10:44:34AM -0800, Linus Torvalds wrote:
> 
> > On Tue, 6 Mar 2001, Alan Cox wrote:
> > > You want a write barrier. Write buffering (at least for short intervals) in
> > > the drive is very sensible. The kernel needs to able to send drivers a write
> > > barrier which will not be completed with outstanding commands before the
> > > barrier.
> > 
> > But Alan is right - we needs a "sync" command or something. I don't know
> > if IDE has one (it already might, for all I know).
> 
> Sync and barrier are very different models.  With barriers we can
> enforce some elemnt of write ordering without actually waiting for the
> IOs to complete; with sync, we're explicitly asking to be told when
> the data has become persistant.  We can make use of both of these.
> 
> SCSI certainly lets us do both of these operations independently.  IDE
> has the sync/flush command afaik, but I'm not sure whether the IDE
> tagged command stuff has the equivalent of SCSI's ordered tag bits.
> Andre?

ATA-TCQ suxs to put is plain and simple.  It really requires a special
host and only the HPT366 series works.  It is similar but not clear as to
the nature.  We are debating the usage of it now in T13.

Cheers,

Andre Hedrick
Linux ATA Development

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

Re: Feedback for fastselect and one-copy-pipe

[Manfred Spraul]

From: <[EMAIL PROTECTED]>
> Hello!
>
> > * davem's patch breaks apps that assume that write(,PIPE_BUF) after
> > poll(POLLOUT) never blocks, even for blocking pipes.
>
> Pardon, but PIPE_BUF <= PAGE_SIZE yet, so that fears have no reasons.
>

The difference is the =

> < davem's patch
> +   if (count >= PAGE_SIZE &&
>   ^^
> +   !(filp->f_flags & O_NONBLOCK)) {
> <<< my patch
> +  if (count > PIPE_BUF && chars == PIPE_SIZE &&
 ^
> +  (!(filp->f_flags & O_NONBLOCK))) {
> <<<

davem used >=, I used >. All other differences between our patches are
code cleanups.

Just try this on i386: (PIPE_BUF is defined to 4096 on i386 - I really
don't understand why, but now it's too late to reverse it back to 512)


char buf[PIPE_BUF];
void main()
{
int pipes[2];
pipe(pipes);
write(pipes[1],buf,sizeof(buf));
}
<<<

It returns immediately on all unix platforms I tested, including all
linux versions, except with davem's patch.
It's not guaranteed in sus or posix, but I'm reluctant to change it.

--
Manfred


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

Re: How can I get promise FastTrak 66 work in kernel?

[Andre Hedrick]

FastTrak will not work, but Ultra will.

On Mon, 5 Mar 2001, Thomas Lau wrote:

> anyone have idea?
> I am helping my friend to ask this question, Thanks
> I mean kernel 2.4.1
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: system call for process information?

[Alexander Viro]

On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:

> Hello
> 
> I asked this question on kernel-newbies - no reply, hope to be luckier
> here:-)
> 
> I need to collect some info on processes. One way is to read /proc
> tree. But isn't there a system call (ioctl) for this? And what are those

Occam's Razor.  Why invent new syscall when read() works?

> task[], task_struct, etc. about?

What branch? (2.0, 2.2, 2.4?)
Cheers,
Al

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

Re: How can I get promise FastTrak 66 work in kernel?

[Andre Hedrick]

On Mon, 5 Mar 2001, Thomas Lau wrote:

> he is using RAID card !

He is using a fraud!

> his 2.2.x promise hacked modules work fine, but I didn't install that old 
> modules, it's not support SCSI emulator

surprize gomer, shazam andi, gool-ly opie.

When is the world going to learn that until they open souce their junk it
is not going to happen?

> well, if using 2.2.x hacked kernel, it can tell out that HD are SCSI HD ( 
> sda0 ), but in 2.4.x, it's display ( hde ) and can not boot up to linux!
> what's problem is it??
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

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

Re: static scheduling - SCHED_IDLE?

[Jamie Lokier]

Adrian Cox wrote:
> Unfortunately the kernel is already full of counting semaphores. 
> Priority inheritance won't save you, as the task which is going to call 
> up() need not be the same one that called down().
> 
> Jamie Lokier's suggestion of raising priority when in the kernel doesn't 
> help. You need to raise the priority of the task which is currently in 
> userspace and will call up() next time it enters the kernel. You don't 
> know which task that is.

Dear oh dear.  I was under the impression that kernel semaphores are
supposed to be used as mutexes only -- there are other mechanisms for
signalling between processes.

Do any processes ever enter userspace holding a critical semaphore?

(Things like userspace signalling another userspace don't count -- it's
your own fault and your own problem if _that_ deadlocks).

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

Re: Feedback for fastselect and one-copy-pipe

[kuznet]

Hello!

> * davem's patch breaks apps that assume that write(,PIPE_BUF) after
> poll(POLLOUT) never blocks, even for blocking pipes.

Pardon, but PIPE_BUF <= PAGE_SIZE yet, so that fears have no reasons.

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

Linux 2.2.16/Tulip Smartbits testing.

[John Brosnan]

Hi,

we've been running some throughput tests (Smartbits
test box) using Donald Becker's tulip.c:v0.92 on Linux 2.2.16,
on a Pentium 3 800Mhz and a 4 port Dlink DFE-570TX see log below.
Basically Smartbits allows one to set the packet size, speed, protocol,
etc. For example if you start at 64 byte size packets and set
an initial rate of 20Mb/s and a max of 80 Mb/s it goes
up and down until it finds the optimum rate. At the moment
w're trying some UDP tests.

The problem is that as the rate increases, the number of
packets received decreases until is goes to zero, then for all
further iterations of that 64 packet size test, no matter
how slow the rate gets, the number of packets received is always
0. It does not recover from being flooded until the Smartbits moves to
the next packet size, performs learning frames and then the same
eventually thing happens again.

Has anybody ever run any tests like this before ?
Is it a driver or a kernel issue ? Any ideas ?

Performance also looks pretty bad for the smaller packet sizes
but does improve as the packet size increases.

We're just trying to figure out why absolutely no packets
are received no matter how slow the rate gets.

thanks in advance for any help,

John.


Mar  9 15:52:41 : tulip.c:v0.92 4/17/2000  Written by Donald Becker
<[EMAIL PROTECTED]>
Mar  9 15:52:41 :   http://www.scyld.com/network/tulip.html
Mar  9 15:52:41 : eth1: Digital DS21143 Tulip rev 65 at 0xc8812c00,
00:80:C8:CF:BE:D1, IRQ 11.
Mar  9 15:52:41 : eth1:  EEPROM default media type Autosense.
Mar  9 15:52:41 : eth1:  Index #0 - Media MII (#11) described by a 21142 MII
PHY (3) block.
Mar  9 15:52:41 : eth1:  MII transceiver #1 config 3100 status 7869
advertising 01e1.
Mar  9 15:52:41 : eth2: Digital DS21143 Tulip rev 65 at 0xc8814800,
00:80:C8:CF:BE:D2, IRQ 10.
Mar  9 15:52:41 : eth2:  EEPROM default media type Autosense.
Mar  9 15:52:41 : eth2:  Index #0 - Media MII (#11) described by a 21142 MII
PHY (3) block.
Mar  9 15:52:41 : eth2:  MII transceiver #1 config 3100 status 7869
advertising 01e1.
Mar  9 15:52:41 : eth3: Digital DS21143 Tulip rev 65 at 0xc8816400,
00:80:C8:CF:BE:D3, IRQ 9.
Mar  9 15:52:41 : eth3:  EEPROM default media type Autosense.
Mar  9 15:52:41 : eth3:  Index #0 - Media MII (#11) described by a 21142 MII
PHY (3) block.

Mar  9 15:52:41 : eth3:  MII transceiver #1 config 3100 status 7869
advertising 01e1.
Mar  9 15:52:41 : eth4: Digital DS21143 Tulip rev 65 at 0xc8818000,
00:80:C8:CF:BE:D4, IRQ 12.
Mar  9 15:52:41 : eth4:  EEPROM default media type Autosense.
Mar  9 15:52:41 : eth4:  Index #0 - Media MII (#11) described by a 21142 MII
PHY (3) block.
Mar  9 15:52:41 : eth4:  MII transceiver #1 config 3100 status 7849
advertising 01e1.
Mar  9 15:52:41 : eth1: Setting full-duplex based on MII #1 link partner
capability of 41e1.
Mar  9 15:52:41 : eth2: Setting full-duplex based on MII #1 link partner
capability of 41e1.
Mar  9 15:52:41 : eth3: Setting full-duplex based on MII #1 link partner
capability of 41e1.
Mar  9 15:52:42


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

Re: 21041 transmit timed out

[Geert Uytterhoeven]

On Mon, 12 Mar 2001, Geert Uytterhoeven wrote:
> I made a list of driver versions that showed the problem so far:
> 
> | Tulip driver version 0.9.14 (February 20, 2001)

Wow! 0.9.14 in my 2.4.3-pre2 kernel just seem to have recovered from the
problem:

| NETDEV WATCHDOG: eth0: transmit timed out
| eth0: 21041 transmit timed out, status fc66, CSR12 01c8, CSR13 ef05, 
|CSR14 ff3f, resetting...
| eth0: 21143 100baseTx sensed media.
| NETDEV WATCHDOG: eth0: transmit timed out
| eth0: 21041 transmit timed out, status fc260010, CSR12 02c8, CSR13 ef0d, 
|CSR14 f73d, resetting...
| NETDEV WATCHDOG: eth0: transmit timed out
| eth0: 21041 transmit timed out, status fc260010, CSR12 02c8, CSR13 ef0d, 
|CSR14 f73d, resetting...
| eth0: Out-of-sync dirty pointer, 243506 vs. 243524.

And eth0 is back online.

The next few lines in the syslog do look suspicious, though:

| release_dev: driver.table[1] not tty for ()
| release_dev: driver.table[7] not tty for (FikXZdoGQcCWQFGjV5evDzG+mv
| Q1jmH5buYh7LWpmXr8mfjykOCoR2Ry+NmzL3sE49mLozzdT22tUJKu6ztÄPÂÜð)
| Warning: dev (04:08) tty->count(2) != #fd's(1) in release_dev
| release_dev: driver.table[7] not tty for ()
| Warning: dev (04:41) tty->count(2) != #fd's(1) in tty_open
| Warning: dev (04:08) tty->count(3) != #fd's(1) in tty_open
| Warning: dev (04:41) tty->count(3) != #fd's(2) in tty_open
| Warning: dev (04:41) tty->count(3) != #fd's(2) in release_dev
| Warning: dev (04:41) tty->count(3) != #fd's(2) in tty_open

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

Re: Ide Hot-swaping?

[Andre Hedrick]

Yes, but I have not made public that code until more clean ups.

On Mon, 12 Mar 2001, Pozsar Balazs wrote:

> 
> Is it possible to hot-swap ide drives and re-detect them?
> Does 'normal' Pc-hardware allow it?
> 
> thanks,
> Balazs Pozsar.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: Feedback for fastselect and one-copy-pipe

[Mike Galbraith]

On Mon, 12 Mar 2001, Ingo Oeser wrote:

> On Mon, Mar 12, 2001 at 05:20:12PM +0100, Mike Galbraith wrote:
> > I just happen to have a 2.4.2 IKD patch sitting here, and therein
> > sits Ingo's memory leak detector... poor thing is bored to tears 8)
>
> Could to point me to mingos[1] memleak-detector? I need to know,
> whats going on here.

I see that Andrea has released a new IKD.  You can find it in
the people/andrea/ikd/v2.4 directory of your favorite mirror.

-Mike

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

Re: Linux 2.4.2ac18

[Alan Cox]

> But this won't catch FSB overclocking at all (which nowadays seems the
> most common way of oc-ing, since it does not involve any modifications
> to the CPU other than maybe a better cooler). Or am I missing something?

The overclocking experiment was a side line

> And what exactly does the multiplier reading alone buy us? (No offense
> meant - I am just curious because I really liked the feature, did not
> even know that it was possible, and am a bit sad to see it go again)

We need to detect configurations where the bus speed is the same for all cpus
and the multiplier is not. These are legal MP configurations. In these cases
we need to (but currently dont) disable the TSC usage for anything but
delay timing as the TSC isnt lock-step

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

[NFS] Oops in 2.4.2 - please give advice

[Jean-Eric Cuendet]

Hi,
I have this Oops with the following config:
- Stock 2.4.2 (no patch)
- I have LVM volumes (0.9.1b5)
- I have Raid0 + Raid5 volumes (v0.90)
- Filesystems are ext2
- The machine is a PII 733 with SCSI and IDE disks.
- The chipset is a VIA but DMA is disabled (for IDE disks).
Thanks for any help
-jec


ksymoops 2.4.0 on i686 2.4.2-lb5-n3-6.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2-lb5-n3-6/ (default)
 -m /boot/System.map-2.4.2-lb5-n3-6 (specified)

Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says
c02086c0, System.map says c014f200.  Ignoring ksyms_base entry
Mar 12 10:00:02 fatboy kernel: Unable to handle kernel paging request at
virtual address 00b50008
Mar 12 10:00:02 fatboy kernel: c0124407
Mar 12 10:00:02 fatboy kernel: *pde = 
Mar 12 10:00:02 fatboy kernel: Oops: 
Mar 12 10:00:02 fatboy kernel: CPU:0
Mar 12 10:00:02 fatboy kernel: EIP:0010:[generic_file_readahead+415/708]
Mar 12 10:00:02 fatboy kernel: EFLAGS: 00010206
Mar 12 10:00:02 fatboy kernel: eax: c7fa   ebx: 00b5   ecx: 000f
edx: c7fb25e0
Mar 12 10:00:02 fatboy kernel: esi: 022b   edi: c2f9e8a0   ebp: c200bea4
esp: c377fef8
Mar 12 10:00:02 fatboy kernel: ds: 0018   es: 0018   ss: 0018
Mar 12 10:00:02 fatboy kernel: Process tar (pid: 20695, stackpage=c377f000)
Mar 12 10:00:02 fatboy kernel: Stack: c10f36a8 0001 c2f9e8a0 0600
c119c9e8 0124 c7fb25e0 001f
Mar 12 10:00:02 fatboy kernel:0111 0013 0020 00f2
022b c0124753 0001 c2f9e8a0
Mar 12 10:00:02 fatboy kernel:c200be00 c10f36a8 2800 0806d9c0
 baac c10f36a8 
Mar 12 10:00:02 fatboy kernel: Call Trace: [do_generic_file_read+551/1412]
[generic_file_read+99/128] [file_read_actor+0/84] [sys_read+142/196]
[system_call+51/56]
Mar 12 10:00:02 fatboy kernel: Code: 39 6b 08 75 f4 8b 74 24 14 39 73 0c 75
eb 53 e8 c9 4e 00 00
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   39 6b 08  cmp%ebp,0x8(%ebx)
Code;  0003 Before first symbol
   3:   75 f4 jnefff9 <_EIP+0xfff9> fff9
 fff9
 4edd Before
first symbol


1 warning issued.  Results may not be reliable.



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
http://www.linkvest.com  E-mail: [EMAIL PROTECTED]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 




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

Re: Ide Hot-swaping?

[Jeremy Jackson]

Pozsar Balazs wrote:

> Is it possible to hot-swap ide drives and re-detect them?
> Does 'normal' Pc-hardware allow it?

read a recent man page for hdparm and you will see kernel
allows remove/add ide interface.  scripts with correct
parameter usage are in contrib directory of hdparm source.
IDE maintainer has code to electrically turn off (tristate)
ide channels on most PC ide chips, but is waiting to
demonstrate at an industry conference before releasing
to public.

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

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

Re: Linux 2.4.2ac18

[Holger Lubitz]

Alan Cox wrote:
> > [overclocked CPU detection code]
> It doesnt work usefully. The bit we really needed (clock multiplier reading)
> does work so its a case of one won lost one

But this won't catch FSB overclocking at all (which nowadays seems the
most common way of oc-ing, since it does not involve any modifications
to the CPU other than maybe a better cooler). Or am I missing something?
And what exactly does the multiplier reading alone buy us? (No offense
meant - I am just curious because I really liked the feature, did not
even know that it was possible, and am a bit sad to see it go again)

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

Re: Feedback for fastselect and one-copy-pipe

[Ingo Oeser]

On Mon, Mar 12, 2001 at 05:20:12PM +0100, Mike Galbraith wrote:
> I just happen to have a 2.4.2 IKD patch sitting here, and therein
> sits Ingo's memory leak detector... poor thing is bored to tears 8)

Could to point me to mingos[1] memleak-detector? I need to know,
whats going on here.

I have had a load of 10 today, a much to busy disk and a full
swap.

I killed X and killed -9 netscape several times and waited a
while. Things didn't settle down until reboot.

So I definitly would like to try all that doesn't corrupt my fs ;-)

Regards

Ingo Oeser

[1] If people wonder, why I ask about "my own" patch: Mike means
   Ingo *Molnar* (nickname mingo), which is NOT me (nickname ioe).

   I'm NOT going to change my name because of this, ok? ;-)
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

system call for process information?

[Guennadi Liakhovetski]

Hello

I asked this question on kernel-newbies - no reply, hope to be luckier
here:-)

I need to collect some info on processes. One way is to read /proc
tree. But isn't there a system call (ioctl) for this? And what are those
task[], task_struct, etc. about?

Thanks
Guennadi
___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]


-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:   http://mail.nl.linux.org/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:  http://www.surriel.com/kernelnewbies.shtml

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

Re: 2.2.18 IDE tape problem, with ide-scsi

[Khalid Aziz]

11,3 is "Multiple read errors". You can find all of the ASC and ASCQ
listed in any SCSI spec document. You can find the SCSI-2 specs at
.

--
Khalid

Camm Maguire wrote:
> 
> Thank you again for your help.  While I do seem to get more errors
> with the ide-tape driver, I am also seeing some problems on further
> examination which are common to both ide-tape and st over ide-scsi, so
> perhaps I have a bad drive or tape.
> 
> When trying to mt eom, for example, I get
> 
> =
> st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
> [valid=0] Info fld=0x0, Current st09:00: sns = 70  5
> ASC=20 ASCQ= 0
> Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
>0x00 0x00
> st0: Can't read block limits.
> st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
> st0: Density 45, tape length: 0, drv buffer: 1
> st0: Block size: 512, buffer size: 32768 (64 blocks).
> st0: Retensioning tape.
> st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
> [valid=0] Info fld=0x0, Current st09:00: sns = 70  5
> ASC=20 ASCQ= 0
> Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
>0x00 0x00
> st0: Can't read block limits.
> st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
> st0: Density 45, tape length: 0, drv buffer: 1
> st0: Block size: 512, buffer size: 32768 (64 blocks).
> st0: Spacing tape forward over 16383 filemarks.
> st0: Spacing to end of recorded medium.
> st0: Error: 2800, cmd: 11 3 0 0 0 0 Len: 16
> Info fld=0x3feb, Deferred st09:00: sns = f1  3
> ASC=11 ASCQ= 3
> Raw sense data:0xf1 0x00 0x03 0x00 0x00 0x3f 0xeb 0x0a 0x00 0x00 0x00 0x00 0x11 0x03 
>0x00 0x00
> st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
> [valid=0] Info fld=0x0, Current st09:00: sns = 70  5
> ASC=20 ASCQ= 0
> Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
>0x00 0x00
> st0: Can't read block limits.
> st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
> st0: Density 45, tape length: 0, drv buffer: 1
> st0: Block size: 512, buffer size: 32768 (64 blocks).
> st0: Rewinding tape.
> =
> 
> What is the 11,3?  Where can I find these codes listed?  Why is the
> drive having trouble finding the end of the tape?  I'll be testing
> more tapes soon, but this definitely happens with at least several.
> The mt command returned to the prompt with 'Input/ouput error'.
> 
> Many Thanks again,
> 

-- 

Khalid Aziz Linux Development Laboratory
(970)898-9214Hewlett-Packard
[EMAIL PROTECTED]Fort Collins, CO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

raw device and linux scheduling performance weirdness

[Ying Chen]

Hi,

I ran some really trivial raw disk performance tests on 2.4.0 using
the raw disk support in it. I seem to be getting some really strange
performance results. My program opens up a raw device, then does
a sequence of sequential/random reads/writes on the raw device using
pread/pwrite. I put timing around both the sequence and the individual
requests. I noticed that in some of the runs the elapsed time for
the whole sequence of I/O requests is significantly longer than
the sum of the individual I/O request response times (like 100 times
longer say), yet my program does nothing in between the requests but
a gettimeofday call to record the request starting time. The system
has nothing else running when the tests were run, so the process should not 
be contenting with other things.

This seems to me that somehow the raw device I/O process is either
stuck or the linux scheduler is skewing things up somewhere. I tried to nice 
the process to higher priority values, it didn't seem to help.
Any ideas?

Thanks,

Ying

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

Re: Linux 2.4.2ac18

[Alan Cox]

> noticed that the overclocked CPU detection code was dropped between ac16
> and ac17. Since the changelog did not mention it - was the feature
> dropped intentionally, and if so, why?

It doesnt work usefully. The bit we really needed (clock multiplier reading)
does work so its a case of one won lost one

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

Re: fbdev cursor management

[James Simmons]

>Guys,
>
>I've been taking a look at the cursor flashing code,
>from the point of view of how it's affected by the
>recent enabling of interrupts across the console code.

I see the problems. I just pursposed a new cursor api soe we can have a
clean fbdev to fbcon abstraction. Also we really need to move the curent
cursor code in fbcon.c:fbcon_startup. They really belong in their
respected drivers.

>It all happens in timer handlers and interrupt handlers,
>with no protection against mainline code accessing the
>hardware simultaneously.

Many drivers use spinlocks to manage access.

>- Collapse all the various per-driver cursor flashing
>  routines into a single place - manage the timer from
>  drivers/video/fbcon.c and from there, call into the
>  driver layer if requested.

fbcon_cursor :-)

> The only way we have of doing this at present is to call
> schedule_task() from within the timer handler.  This works
> fine, but it complicates the device close and module unload
> problem somewhat.  del_timer_sync + flush_scheduled_tasks
> will be needed in the right places.

Yuck!!! I see this also a problem for VBL dependent drivers. Some
drivers to require you sync with the VBL to do things like change
the color map. Worst some of these drivers require you poll a bit
to see if the VBL occured.

[snip] rivafb problems. These will be fixed now they are pointed out.


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

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

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

Re: Feedback for fastselect and one-copy-pipe

[Manfred Spraul]

Ingo Oeser wrote:
> 
> Hi Manfred,
> 
> I'm running your patches [1] with sucess for a while now.
> 
> Did you get any feedback about problems regarding these patches?
>
No feedback yet.

> They seem to work for me, but there seems to be a memleak in
> 2.4.x (x: 0-2), which I'm chasing down.
>
You are right, there's a stupid bug in my poll patch:

p = kmalloc(PAGE_SIZE);
free_page((unsigned long)p);

This causes a memory leak for the slab control structures.

> 
> [1] put on http://www.tu-chemnitz.de/~ioe/fastpipe.patch
>
That's davem's original 
I rewrote it because I didn't like the nested loops. pipe_read() and
_write() were never easy to follow, and adding yet another set of goto &
for(;;) loops is IMHO a bad idea.

The main difference between my patch and davem's patch is that davem
uses zerocopy for exactly PAGE_SIZE sized transfers, I only use it for
transfers larger than PIPE_BUF.

< davem's patch
+   if (count >= PAGE_SIZE &&
+   !(filp->f_flags & O_NONBLOCK)) {
<<< my patch
+  if (count > PIPE_BUF && chars == PIPE_SIZE &&
+  (!(filp->f_flags & O_NONBLOCK))) {
<<<

On i386 PIPE_BUF is 4096, and thus

* davem's patch is faster, since glibc by default writes in 4096 byte
blocks
* davem's patch breaks apps that assume that write(,PIPE_BUF) after
poll(POLLOUT) never blocks, even for blocking pipes.

I've attached the newest versions of both patches.


--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 2
//  EXTRAVERSION = -ac17
--- 2.4/fs/pipe.c   Thu Feb 22 22:29:46 2001
+++ build-2.4/fs/pipe.c Mon Mar 12 16:02:48 2001
@@ -2,6 +2,9 @@
  *  linux/fs/pipe.c
  *
  *  Copyright (C) 1991, 1992, 1999  Linus Torvalds
+ *
+ *  Major pipe_read() and pipe_write() cleanup, kiobuf based
+ *  single copyCopyright (C) 2001 Manfred Spraul
  */
 
 #include 
@@ -10,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -36,97 +41,149 @@
down(PIPE_SEM(*inode));
 }
 
+struct pipe_pio {
+   int *pdone;
+   struct kiobuf iobuf;
+};
+
+static int
+pio_copy_to_user(struct kiobuf* iobuf, int offset, char* ubuf, int chars)
+{
+   int page_nr;
+   offset += iobuf->offset;
+   page_nr = offset/PAGE_SIZE;
+   offset %= PAGE_SIZE;
+   while(chars) {
+   int pcount = PAGE_SIZE-offset;
+   void *kaddr;
+   if (pcount > chars)
+   pcount = chars;
+   kaddr = kmap(iobuf->maplist[page_nr]);
+   if (copy_to_user(ubuf, kaddr+offset, pcount))
+   return 1;
+   kunmap(iobuf->maplist[page_nr]);
+   chars -= pcount;
+   ubuf += pcount;
+   offset = 0;
+   page_nr++;
+   }
+   return 0;
+}
+
 static ssize_t
 pipe_read(struct file *filp, char *buf, size_t count, loff_t *ppos)
 {
struct inode *inode = filp->f_dentry->d_inode;
-   ssize_t size, read, ret;
+   ssize_t read, ret;
 
-   /* Seeks are not allowed on pipes.  */
-   ret = -ESPIPE;
-   read = 0;
+   /* pread is not allowed on pipes.  */
if (ppos != >f_pos)
-   goto out_nolock;
+   return -ESPIPE;
 
/* Always return 0 on null read.  */
-   ret = 0;
if (count == 0)
-   goto out_nolock;
+   return 0;
 
-   /* Get the pipe semaphore */
-   ret = -ERESTARTSYS;
-   if (down_interruptible(PIPE_SEM(*inode)))
-   goto out_nolock;
+   down(PIPE_SEM(*inode));
 
-   if (PIPE_EMPTY(*inode)) {
-do_more_read:
+   read = 0;
+   for (;;) {
+   /* read what data is available */
+   int chars = PIPE_LEN(*inode);
+   if (chars) {
+   char *pipebuf = PIPE_BASE(*inode);
+   int offset = PIPE_START(*inode);
+
+   if (chars > count)
+   chars = count;
+   ret = -EFAULT;
+   if(PIPE_IS_PIO(*inode)) {
+   struct pipe_pio* pio = ((struct pipe_pio*)pipebuf);
+   if(pio_copy_to_user(>iobuf, offset, buf, chars))
+   goto out;
+
+   PIPE_LEN(*inode) -= chars;
+   if(!PIPE_LEN(*inode)) {
+   unmap_kiobuf(>iobuf);
+   *pio->pdone = 1;
+   PIPE_IS_PIO(*inode) = 0;
+   PIPE_START(*inode) = 0;
+   } else {
+   PIPE_START(*inode) += chars;
+   }
+   } else {
+   if (chars > PIPE_SIZE-offset)
+   chars = PIPE_SIZE-offset;

Re: Linux 2.4.2ac18

[Holger Lubitz]

Hmm, I seem to have missed the changelog posting for ac17. However, I
noticed that the overclocked CPU detection code was dropped between ac16
and ac17. Since the changelog did not mention it - was the feature
dropped intentionally, and if so, why?

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

Re: curious messages

[Hank Leininger]

On 2001-03-12, David Ford <[EMAIL PROTECTED]> wrote:

> 2.4.2-ac4

> Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1
> Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0
[snip]
> simple debug messages, or is someone (andy/dave) interested in them?

They can be safely ignored--or silenced.  See:

http://marc.theaimsgroup.com/?l=linux-kernel=9794687353=2

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

Re: Feedback for fastselect and one-copy-pipe

[Mike Galbraith]

On Mon, 12 Mar 2001, Ingo Oeser wrote:

> They seem to work for me, but there seems to be a memleak in
> 2.4.x (x: 0-2), which I'm chasing down.

I just happen to have a 2.4.2 IKD patch sitting here, and therein
sits Ingo's memory leak detector... poor thing is bored to tears 8)

-Mike

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

Ide Hot-swaping?

[Pozsar Balazs]

Is it possible to hot-swap ide drives and re-detect them?
Does 'normal' Pc-hardware allow it?

thanks,
Balazs Pozsar.

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

Re: [PATCH] /drivers/char/cyclades.c: panic() call removal

[Ivan Passos]

On Sun, 11 Mar 2001, Andrey Panin wrote:
> 
> this patch removes panic() calls and adds MODULE_DEVICE_TABLE to 
> cyclades driver.

Patch looks good. Thanks for the patch, Andrey!

However: Linus, please do not apply this yet. I'll do tests with a new
Cyclades driver version we're about to release, and then I'll submit
patches to the Cyclades driver once the tests are done (and they'll
include Andrey's patch).

Later,
Ivan

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

curious messages

[David Ford]

2.4.2-ac4

Undo partial loss 208.179.59.2/5432 c1 l1 ss2/2 p1
Undo loss 208.179.59.2/5432 c2 l0 ss2/2 p0
Undo loss 208.179.59.2/25 c2 l0 ss2/2 p0
Undo partial loss 208.179.59.2/22 c1 l3 ss2/2 p3
Undo loss 208.179.59.2/143 c2 l0 ss2/3 p0

simple debug messages, or is someone (andy/dave) interested in them?

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



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

curious bug

[David Ford]

2.4.3-pre3

richh12557  0.0  0.7  5096 1704 pts/10   D04:32   0:00 ./egg
idaho
richh12558  0.0  0.0 00 pts/10   Z04:32   0:00 [egg
]
richh12560  0.0  0.7  5096 1704 pts/10   S04:32   0:00 ./egg
idaho

# ps -eo args,wchan|grep egg
./egg idaho  down
[egg ]  do_exit
./egg idaho  rt_sigsuspend

kill -9 had no effect on 12557 until i killed 12560.  this D state
process held the load at 1.01 for hours.

any takers?

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



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

Sony VAIO PCI (NOT USB) MemoryStick Recognition

[D Watanabe]

Hi folks,

I'm trying to use MemoryStick slot on SonyVAIO PCG-Z600NE,
and currently no luck.
Product Name "Z600NE" is a bit funny,
probably this is used for Europe domain.
I believe some "505" series should have same spedification. 


Linux/OS does not recognize MemoryStick as HD at all.

What I can see is:
  * This machine's Memorystick seems to be 
connected to PCI not USB. <-- important!
So USB-MASS-STRAGE is no help.

Anyway, those below config=y but still no help.
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_USB_STORAGE=y

  * As above, SCSI config are included in kernel, but no help.

  * "MemoryStick Controller" appears on /proc/pci 
so device itself is existing anyway.
And it will act as ATA-Drive/Scsi(?) HardDrive
but Linux cannot recognized it as HD.

  * Kernel parameter "hdc=autotune" is no help.
"hdc=247/2/16" (for example!) leads kernel panic,
 no wander.
Kernel says, it's "non-ATA Drive".  


Here is specs/logs which could help to tell the situation.
* Debian: woody(testing).
* Linux Kernel Version: 2.4.2 with devfs
* Eithernet/Audio devices are working fine.
* USB-Floppy is working on the same environment,
  which is recognized as SCSI device and appers under
  /dev/scsi/host0(snip)




* BIOS setup.
Menu [Advanced]

> Primary IDE Adapter [12073MB]
> Secondary IDE Adapter [None]
   --> Submenu
   Type [Auto]
   This "Type" option has "ATAPI Removable"
   and "CD-ROM" etc.

Any change for "Secondary IDE Adapter [None]" canNOT be made.
for example, change it to "ATAPI Removbale" from "None"
and Save(F10) and quit restart.
Then the menu "Secondary IDE Adapter" has been back to [None].
No way to change it, as far as I have tested.
Anyway, on the same BIOS configration, Win2K can recognize
memorystick properly.



* dmesg digest

Linux version 2.4.2 (root@chariot) (gcc version 2.95.3 20010125 (prerelease)) 
(snip)
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
  got res[1000:1fff] for resource 0 of Ricoh Co Ltd RL5c475
  got res[10001000:100013ff] for resource 0 of Sony Corporation Memory Stick Controller
Limiting direct PCI/PCI transfers.
(snip)
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfcb0-0xfcb7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfcb8-0xfcbf, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DARA-212000, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 23579136 sectors (12073 MB) w/418KiB Cache, CHS=1467/255/63, UDMA(33)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 > p4
Floppy drive(s): fd0 is 1.44M
(snip)


[Note]: No "hdc" recognition.



* lspci -vt 
-[00]-+-00.0  Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
  +-01.0-[01]00.0  Neomagic Corporation: Unknown device 0016
  +-07.0  Intel Corporation 82371AB PIIX4 ISA
  +-07.1  Intel Corporation 82371AB PIIX4 IDE
  +-07.2  Intel Corporation 82371AB PIIX4 USB
  +-07.3  Intel Corporation 82371AB PIIX4 ACPI
  +-08.0  Sony Corporation CXD3222 i.LINK Controller
  +-09.0  Yamaha Corporation YMF-744B [DS-1S Audio Controller]
  +-0a.0  CONEXANT: Unknown device 2443
  +-0b.0  Intel Corporation 82557 [Ethernet Pro 100]
  +-0c.0  Ricoh Co Ltd RL5c475
  \-0d.0  Sony Corporation Memory Stick Controller


* lspci -vvx (digest)

00:0d.0 FLASH memory: Sony Corporation Memory Stick Controller (rev 01)
Subsystem: Sony Corporation: Unknown device 8085
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SER
R- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 
00: 4d 10 8a 80 00 00 10 02 01 00 01 05 00 00 00 00
10: 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 10 85 80
30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 01 00 00



* kernel configuration (digest)

CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y


--- USB/SCSI
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
...
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
...
#
# USB support
#
...
CONFIG_USB_STORAGE=y
...





I cannot decide this problem caused by
  * Need some special driver for the controller
  * some kernel mis configuration
  * lack of some appropriate kernel param
  * some 

Re: Should mount --bind not follow symlinks?

[Anthony]

Alexander Viro wrote:
> Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
> been deliberately prohibited. You _really_ don't want to handle the
> broken symlinks and all the realted fun [...]

No. But I hoped _you_ might :-)

> - race-ridden at extreme and useless.
> In automount-like setups you can _replace_ symlinks with bindings.
> No need to mix them.

Hmm.  My /etc/auto.opt contains

*   :/export/opt/&/LATEST

where all the "LATEST"s etc are symlinks.  I found it quite
an elegant way to maintain different versions: the symlink
was de-facto a trivially simple version database.

Does the version state now *have* to be listed in
/etc/auto.opt explicitly?  That feels a little retrograde.

Perhaps I'm blissfully unaware of all sorts of vile
race conditions, but why can't the *automounter* chase
the symlinks even if mount shouldn't?  Or am I missing
a neater solution?

Rgds

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

Re: NFS times out with 2.4.2 as client

[Trond Myklebust]

> " " == sidewinder  <[EMAIL PROTECTED]> writes:

 > Here's a typical entry from tcpdump, from the server's point of
 > view.
 > 192.168.1.1 is the client, 192.168.1.10 is the server.

 > tcpdump: listening on eth0 11:32:24.958338
 > localhost.localdomain.631 > 192.168.1.255.631: udp 124
 > 11:32:55.958333 localhost.localdomain.631 > 192.168.1.255.631:
 > udp 124 11:32:56.736047 arp who-has localhost.localdomain tell
 > 192.168.1.1 11:32:56.736083 arp reply localhost.localdomain
 > is-at 0:0:e8:35:77:ae 11:32:56.736615 192.168.1.1.745 >
 > localhost.localdomain.sunrpc: S 1160224917:1160224917(0) win
 > 5840  (DF)
 > 11:32:56.736772 localhost.localdomain.sunrpc > 192.168.1.1.745:
 > S 980802949:980802949(0) ack 1160224918 win 32120  1460,nop,nop,sackOK,nop,wscale 0> (DF) 11:32:56.737386
 > 192.168.1.1.745 > localhost.localdomain.sunrpc: . ack 1 win
 > 5840 (DF) 11:32:56.738109 192.168.1.1.745 >
 > localhost.localdomain.sunrpc: P 1:45(44) ack 1 win 5840 (DF)
 > 11:32:56.738152 localhost.localdomain.sunrpc > 192.168.1.1.745:
 > . ack 45 win 32120 (DF) 11:32:56.738412
 > localhost.localdomain.sunrpc > 192.168.1.1.745: P 1:293(292)
 > ack 45 win 32120 (DF) 11:32:56.738692
 > localhost.localdomain.1051 > 151.164.1.8.domain: 52408+ (42)
 > 11:32:56.739497 192.168.1.1.745 > localhost.localdomain.sunrpc:
 > . ack 293 win 6432 (DF) 11:32:56.740010 192.168.1.1.745 >
 > localhost.localdomain.sunrpc: F 45:45(0) ack 293 win 6432 (DF)
 > 11:32:56.740041 localhost.localdomain.sunrpc > 192.168.1.1.745:
 > . ack 46 win 32120 (DF) 11:32:56.740137
 > localhost.localdomain.sunrpc > 192.168.1.1.745: F 293:293(0)
 > ack 46 win 32120 (DF) 11:32:56.740779 192.168.1.1.745 >
 > localhost.localdomain.sunrpc: . ack 294 win 6432 (DF)
 > 11:32:56.741604 192.168.1.1.746 > localhost.localdomain.1026:
 > udp 144 (DF) 11:32:56.742060 localhost.localdomain.1026 >
 > 192.168.1.1.746: udp 60 11:32:56.743109 192.168.1.1.748 >
 > localhost.localdomain.sunrpc: udp 56 (DF) 11:32:56.743255
 > localhost.localdomain.sunrpc > 192.168.1.1.748: udp 28
 > 11:32:56.745189 192.168.1.1.2121638 >
 > localhost.localdomain.nfs: 152 getattr [|nfs] (DF)
 > 11:32:56.745254 localhost.localdomain.nfs >
 > 192.168.1.1.2121638: reply ok 96 getattr [|nfs]11:32:56.746302
 > 192.168.1.1.18898854 > localhost.localdomain.nfs: 152 statfs
 > [|nfs] (DF) 11:32:56.746375 localhost.localdomain.nfs >
 > 192.168.1.1.18898854: reply ok 48 statfs [|nfs]11:33:01.748311
 > localhost.localdomain.1051 > 151.164.1.7.domain: 52408+ (42)
 > 11:33:51.778238 arp who-has 192.168.1.1 tell
 > localhost.localdomain 11:33:51.778738 arp reply 192.168.1.1
 > is-at 0:0:e8:35:7e:51 11:33:55.078917 0:20:78:d:3d:ce >
 > 3:0:0:0:0:1 sap f0 ui/C len=169
 >  2c00 ffef 0800    0102
 >  5f5f 4d53 4252 4f57 5345 5f5f 0201
 >  5241 4242 4954 2020 2020 2020 2020
 >  2000 ff53 4d42 2500 00

 > The rest is more of the same, or other traffic.

 > Any one have similar problems? I've tried recompiling 2.4.2,
 > thinking I might have missed something. No change.

Exactly what does localhost.localdomain map to? Most applications
would be mildly surprised if 'localhost' maps to anything other than
127.0.0.1.

In particular you might be confusing glibc here when it explicitly
calls gethostbyname("localhost") in pmapdump in its RPC layer.

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

Re: [PATCH]: allow notsc option for buggy cpus

[Jes Sorensen]

> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:

>> I think this behaviour can be controlled with tpctl for the
>> Thinkpads and possibly with the Toshiba utils on Toshibas...

Alan> If tpctl can do it and we know how it does it then that may be
Alan> sufficient since the kernel init code can use DMI to find the
Alan> 600E, tpctl copied code to go to high speed, bogomip it and then
Alan> drop back.

Well I can confirm that tpctl allows you to disable it and run the cpu
at 400MHz all the time, thats what I did for my 600E.

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

Re: New net features for added performance

[Jes Sorensen]

> "Werner" == Werner Almesberger <[EMAIL PROTECTED]> writes:

Werner> Jeff Garzik wrote:
>> 3) Slabbier packet allocation.

Werner> Hmm, this may actually be worse during bursts: if you burst
Werner> exceeds the preallocated size, you have to perform more
Werner> expensive/slower operations (e.g. running a tasklet) to refill
Werner> your cache.

You may want to look at how I did this in the acenic driver. If the
water mark goes below a certain level I schedule the tasklet, if it
gets below an urgent watermark I do the allocation in the interrupt
handler itself.

This is of course mainly useful for cards which give you deep
queues.

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

Re: ISSUE : ppp failure with kernel 2.4.2 - used to work with 2.4.0

[Andreas Tobler]

Pascal Bonfils wrote:
> Mar 12 14:22:14 a0 pppd[808]: pppd 2.3.11 started by root, uid 0

You should upgrade to ppp-2.4

E.g. linuxcare.com.au/pub/ppp

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

Re: [NFS] New files on read only NFS mount

[Trond Myklebust]

> " " == Chris Jensen <[EMAIL PROTECTED]> writes:

>> Details please, the minimum info required being 'which kernel
>> is your client running'?
>>

 > Oh yeah, whoops, sorry The server is a 586 and the client is
 > 686.  They're both using nfs-utils 0.2.1, under linux 2.4.0
 > with NFS v3 enabled, with glibc 2.2.1 The pertinent line in
 > /etc/exports is / 192.168.0.1(rw,no_root_squash)

How does the following patch work out?

Cheers,
  Trond

--- fs/nfs/dir.c.orig   Fri Feb  9 20:29:44 2001
+++ fs/nfs/dir.cMon Mar 12 15:54:14 2001
@@ -1097,6 +1097,10 @@
 
if (!NFS_PROTO(inode)->access)
goto out;
+
+   if (error == -EROFS)
+   goto out;
+
/*
 * Trust UNIX mode bits except:
 *



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

ISSUE : ppp failure with kernel 2.4.2 - used to work with 2.4.0

[Pascal Bonfils]

1 - ppp failure with kernel 2.4.2 - used to work with 2.4.0

2 - Kernel 2.4.2 has been compiled exactly with the same options
(config) as the 2.4.0.
Now when I try to reach my ISP, everything runs well until pppd launch
the serial connection (see the message file attached)

3 - Keywords : kernel ppp

4 - Kernel version : Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version
2.96 2731 (Red Hat Linux 7.0))

5 - Extract of the /var/log/message file :
Mar 12 14:22:14 a0 ifup-ppp: pppd started for ppp0 on /dev/ttyS2 at
115200
Mar 12 14:22:14 a0 pppd[808]: pppd 2.3.11 started by root, uid 0
Mar 12 14:22:15 a0 WvDial: WvDial: Internet dialer version 1.41
Mar 12 14:22:15 a0 WvDial: Initializing modem.
Mar 12 14:22:15 a0 WvDial: Sending: ATZ
Mar 12 14:22:15 a0 WvDial: ATZ
Mar 12 14:22:15 a0 WvDial: OK
Mar 12 14:22:15 a0 WvDial: Sending: ATQ0 V1 E1 S0=0   S11=55
+FCLASS=0
Mar 12 14:22:15 a0 WvDial: ATQ0 V1 E1 S0=0   S11=55 +FCLASS=0
Mar 12 14:22:15 a0 WvDial: OK
Mar 12 14:22:15 a0 WvDial: Sending: ATM0L1
Mar 12 14:22:16 a0 WvDial: ATM0L1
Mar 12 14:22:16 a0 WvDial: OK
Mar 12 14:22:16 a0 WvDial: Modem initialized.
Mar 12 14:22:16 a0 WvDial: Sending: ATDT ...
Mar 12 14:22:16 a0 WvDial: Waiting for carrier.
Mar 12 14:22:16 a0 WvDial: ATDT .
mar 12 14:22:25 a0 PAM_unix[843]: (su) session opened for user root by
..(uid=)
Mar 12 14:22:38 a0 WvDial: CONNECT 31200/ARQ/V34/LAPM/V42BIS
Mar 12 14:22:38 a0 WvDial: Carrier detected.  Waiting for prompt.
Mar 12 14:22:38 a0 WvDial: Login:
Mar 12 14:22:38 a0 WvDial: Looks like a login prompt.
Mar 12 14:22:38 a0 WvDial: Sending: ..
Mar 12 14:22:39 a0 WvDial: ..
Mar 12 14:22:39 a0 WvDial: Password:
Mar 12 14:22:39 a0 WvDial: Looks like a password prompt.
Mar 12 14:22:39 a0 WvDial: Sending: (password)
Mar 12 14:22:39 a0 WvDial: Entering PPP Session.
Mar 12 14:22:39 a0 WvDial: IP address is 
Mar 12 14:22:39 a0 WvDial: MTU is 1524.
Mar 12 14:22:39 a0 WvDial: Looks like a welcome message.
Mar 12 14:22:39 a0 pppd[808]: Serial connection established.
Mar 12 14:22:39 a0 pppd[808]: ioctl(PPPIOCGFLAGS): Invalid argument
Mar 12 14:22:39 a0 pppd[808]: Hangup (SIGHUP)
Mar 12 14:22:39 a0 pppd[808]: Exit.

6 - at the end of rp3 (or wvdial, same result), pppd aborts ...

7.1 - output of ver_linux : see file attached

7.2 - /proc/cpuinfo : see file attached

7.3 - /proc/modules : no such file (no option module compiled in kernel)

7.4 - /proc/ioport & /proc/iomem : see files attached

7.5 - output of lspci -vvv : see file attached

7.6 - /proc/scsi/scsi : Attached devices: none


Best regards and good luck (many thanks in advance)

Pascal Bonfils / Paris - France
[EMAIL PROTECTED]


00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B+

00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-  [disabled] [size=64K]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] AGP version 1.0
Status: RQ=1 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=



-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000-000c83ff : Extension ROM
000f-000f : System ROM
0010-0bff : System RAM
  0010-00240fcb : Kernel code
  00240fcc-002adae3 : Kernel data
e000-e3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
e400-e5ff : PCI Bus #01
  e500-e500 : Silicon Integrated Systems [SiS] 86C326
e700-e77f : PCI Bus #01
  e700-e77f : Silicon Integrated Systems [SiS] 86C326
e780-e7800fff : Symbios Logic Inc. (formerly NCR) 53c875
e7801000-e78010ff : Symbios Logic Inc. (formerly NCR) 53c875
e7802000-e78020ff : Realtek Semiconductor Co., Ltd. RTL-8139
  e7802000-e78020ff : eth0
- : reserved


-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0

Re: Subtle NFS/VFS/GLIBC interaction bug

[Trond Myklebust]

> " " == Leon Bottou <[EMAIL PROTECTED]> writes:

 > Note the strange numbers in the d_off fields.  These are in
 > fact cookies used internally by nfs.  Under nfs2, these are 32
 > bit unsigned number, sign extended to 64 bits.

 > The last cookie has not been properly sign extended.  The
 > glibc-2.2.2 source code for readdir uses __NR_getdents64 and
 > converts the result into 32 bit dirents.  But it sees that the
 > last d_ino cannot fit in an off_t and it simply bails out.

 > There is already a problem in the making since nfs3 cookies are
 > 64 bits long.  But things should work with nfs2.

This is why I wish glibc would drop the whole idea of relying on
seekdir/telldir existing. The LFS does in fact not specify any
equivalent seekdir64/telldir64, and most implementations of *NIX don't
support them.
Currently, the VFS only allows us to support the minimum
implementation which is required to support the 32-bit interface.

 > I can fix the problem using the following hack:

I've got a more complete one. See the 'IRIX' patch on

  http://www.fys.uio.no/~trondmy/src/2.4.2/linux-2.4.2-dir.dif

That patch also sign-extends 32-bit cookies at the NFS level, so that
we can
  a) convert cookies back so that the server accepts them
  b) match sign-extended 32-bit cookies in the page cache

 > That is acceptable as long as filldir_t does not handle 64bits
 > offsets anyway.

 > But it won't last.

Yes and no. All NFSv3 implementations are supposed to support 32-bit
client implementations. All you lose here is the ability to handle
multi-Gigabyte directories.

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