Re: /dev/random probs in 2.4test(12-pre3)

[Albert D. Cahalan]

H. Peter Anvin writes:

>> Yeah, people write annoying little wrapper functions that
>> bounce right back into the kernel until the job gets done.
>> This is slow, it adds both source and object bloat, and it
>> is a source of extra bugs. What a lovely API, eh?
>>
>> The fix: write_write_write_damnit() and read_read_read_damnit(),
>> which go until they hit a fatal error or complete the job.
>
> RTFM(fwrite), RTFM(fread).

Those sure look like "annoying little wrapper functions that
bounce right back into the kernel until the job gets done".

They don't even operate directly on file descriptors.
Actually they look like they come from VMS... records???
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Jeff Garzik <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
> > 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the
> > number of sectors that can be read at once (i.e. in one track).
> > 
> > This routine does not work with the Sony UDF5 USB floppy disk, mapped as an
> > Int13 device by the Vaio C1VE (Crusoe) BIOS.
> > Therefore, a bzdisk floppy will not be bootable.
> 
> The bzdisk code is used so infrequently compared to the normal
> bootloaders, lilo, grub, and syslinux, that I'm not surprised it has
> problems with many edge cases.
> 
> Although I imagine this is an unpopular opinion, I think that we
> should remove all bzdisk-type code from X86...syslinux and other
> boot loaders handle weird BIOS quirks much better, simply because
> they are used in far more situations than bzdisk.
> 
> syslinux especially is quite nice for loading kernels from floppy.
> It's very small, and "syslinux -s" adds in some wonderfully-paranoid
> sanity checks which make boot loading works on many a quirky BIOS.
> (don't use '-s' unless you need it, of course, it slows things down...)
> 

I concur, but I'm biased :)

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

Re: /dev/random probs in 2.4test(12-pre3)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Hmm.. Some came to mind :
> 
> Making /dev/random block if the amount requirements aren't met makes sense
> to me. If I request x bytes of random stuff, and get less, I probably
> reread /dev/random. If it's entropy pool is exhausted it makes sense to be
> to block.
> 

Yes, it does, but it doesn't make any sense to block if there are data
to be read.  If you need a larger read then you should advance your
pointer and try again with the residual size, or use fread() which
does this for you.

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

Re: /dev/random probs in 2.4test(12-pre3)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"Albert D. Cahalan" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Yeah, people write annoying little wrapper functions that
> bounce right back into the kernel until the job gets done.
> This is slow, it adds both source and object bloat, and it
> is a source of extra bugs. What a lovely API, eh?
> 
> The fix: write_write_write_damnit() and read_read_read_damnit(),
> which go until they hit a fatal error or complete the job.
> 

RTFM(fwrite), RTFM(fread).

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

Re: /dev/random probs in 2.4test(12-pre3)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> > For a blocking fd, read(2) has always blocked until some data is
> > available.  There has never been a guarantee, for any driver, that
> > a read(2) will return the full amount of bytes requested.
> 
> I know. Still leaves lot's of people that assume that reading /dev/random
> will return data, or will block.
> 
> I've seen lots of programs that will assume that if we request x bytes
> from /dev/random it will return x bytes.
> 

Again, that's wrong even when you replace /dev/random with something
else.  After all, you could be getting EINTR at any time, too, or get
interrupted by a signal in the middle (in which case you'd get a short
read.)

SUCH CODE IS BROKEN.  PERIOD.  FULL STOP.

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

Re: /dev/random probs in 2.4test(12-pre3)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Igmar Palsenberg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > Indeed, you are correct.  Is vpnd broken then, for assuming
> > that it can gather the required randomness in one read?
> 
> Yep. It assumes that if the required randommness numbers aren't met a read
> to /dev/random will block.
> 
> And it's not the only program that assumes this : I also did. 
> 
> /dev/random is called a blocking random device, which more or less implies
> that it will totally block. I suggest we put this somewhere in the kernel
> docs, since lots of people out there assume that it totally blocks.
> 

That's pretty much ALWAYS wrong -- for pipes, sockets, you name it.  A
blocking read() will only block if there is nothing to read at all.

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

Re: lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)

[Mohammad A. Haque]

You saying that you were running test kernels on a production box and
seriously didn't expect something bad to happen?

Filesystem corruptions arent things you can recover files from. You're
confusing accidentally deleting files and undeleting them later.

What would be useful is if you noted where/why you ran 'fsck -y'. Did
you crash and fs check at boot failed? What?

Saber Taylor wrote:
> 
> Well that's the last time I run a devel kernel with a nontest
> system.  sigh.
> 
> Had one directory replaced with a different directory
> and also a directory replaced with a file. Possible further
> corruption.
> 
> I don't think I lost the directories until I did a 'fsck -y'
> on the partition. Something to remember.
> 
> If anyone has advice on recovering the directories other than
> the following links, I'm all ears:
> 
> http://www.datafoundation.org/lde/
> http://www.linuxdoc.org/HOWTO/mini/Ext2fs-Undeletion.html
> (last updated February 1999)
> http://www.linuxdoc.org/HOWTO/mini/Ext2fs-Undeletion-Dir-Struct/
> 
> Saber Taylor

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)

[Saber Taylor]

Well that's the last time I run a devel kernel with a nontest
system.  sigh.

Had one directory replaced with a different directory
and also a directory replaced with a file. Possible further
corruption.

I don't think I lost the directories until I did a 'fsck -y'
on the partition. Something to remember.

If anyone has advice on recovering the directories other than
the following links, I'm all ears:

http://www.datafoundation.org/lde/
http://www.linuxdoc.org/HOWTO/mini/Ext2fs-Undeletion.html
(last updated February 1999)
http://www.linuxdoc.org/HOWTO/mini/Ext2fs-Undeletion-Dir-Struct/


Saber Taylor
_
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

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

negative NFS cookies: bad C library or bad kernel?

[Kevin Buhr]

Trond:

Fiddling with the Crytographic File System the other day, I managed to
tickle a mysterious bug.  When some directories grew large enough,
suddenly a chunk of files would half "disappear".  "find" would list
them fine, but "ls" and "echo *" wouldn't.

After a bit of troubleshooting, I discovered that the CFS daemon
(which presents itself to the system as an NFS daemon) was using
small, big-endian cookies in its directory entries.  These became
large positive and negative little-endian "d_off" values in the dirent
structs.

The C library (in glibc-2.1.3/sysdeps/unix/sysv/linux/getdents.c) does
some fancy, double-buffering footwork in getdents(2) to try to guess
how many bytes of kernel_dirents it needs to read into a temporary
buffer to fill the user-supplied buffer with user dirents (which have
an extra "d_type" field).  When its heuristic screws up, it does an
lseek on the directory so the next getdents(2) will start with the
right directory entry:

  if ((char *) dp + new_reclen > buf + nbytes)
{
  /* Our heuristic failed.  We read too many entries.  Reset
 the stream.  `last_offset' contains the last known
 position.  If it is zero this is the first record we are
 reading.  In this case do a relative search.  */
  if (last_offset == 0)
__lseek (fd, -retval, SEEK_CUR);
  else
__lseek (fd, last_offset, SEEK_SET);
  break;
}

In my case, for "ls" and "bash", the "last_offset" happened to be a
negative little-endian cookie.  The kernel's "default_lseek" returned
EINVAL, the error was ignored, and "ls" and "bash" were blissfully
unaware that a bunch of directory entries had been read into the
temporary buffer and forever lost.  Since "find" used a different
buffer size, it happened to have a positive little-endian cookie for
"last_offset" and didn't exhibit the problem.

A fix was easy---after modifying CFS to convert its cookies to small,
little-endian numbers, everything worked fine.

However, who's to blame here?  It can't be CFS---any four-byte cookie
should be valid, right?

Is the kernel NFS client code to blame?  If it's going to be using
cookies as offsets, shouldn't we have an nfs_lseek that special-cases
directory lseeks (at least those using SEEK_SET) to take negative
offsets, so utilities and libraries don't need to be bigfile-aware
just to read directories?  And what in the world can we do about bogus
code like the:

__lseek (fd, -retval, SEEK_CUR);

that appears above?  Shouldn't any non-SEEK_SET lseek on an NFS
directory fail with an error?

Any thoughts?

Thanks.

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

Re: Fasttrak100 questions...

[Jeff V. Merkey]

On Sat, Dec 02, 2000 at 10:42:29PM -0500, Theodore Y. Ts'o wrote:
>Date: Sat, 2 Dec 2000 18:21:26 -0700
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> 
>Under this argument, it is argued that the engineer who had source 
>code access "inevitably used" negative knowledge he gained from 
>his study of the Linux sources.  Absent the vague descriptions of
>what a "derivative work" is in the GPL, it could be argued that 
>conversion of any knowledge contained in GPL code is a "derivative
>work".  
> 
> That's bullshit.  Copyright law very clearly states that it protects the
> fixation of an idea in a medium, and that copyright explicitly does not
> protect the idea itself.  The concept of what is a derived work is very

State Laws may be controlling if they involve contracts.  It has nothing 
to do with Copyright Law, but with the terms of license for someone's
code.  I've seen this crap applied.  I've even been on the receiving
end of it, and been enjoined from working on PUBLIC GPL CODE for 
18 months because of an AGREEMENT and not copyright laws.   

> clearly understood, and there have been a lot of court cases to define

Under inevitability, the neural impules in your brain can be ruled 
to be a derivative work.  Believe me, I am not arguing for the doctrine,
but informing you of it's existence and the broad scope it has 
in IP cases.  

> this precedent.  (My understanding is that in realm of music 7 notes in
> sequence, if copied, is prima facie evidence that there is a derived
> work.  Not 5 notes, and not 8 notes, but seven notes.  Gotta love those
> lawyers at work.  Aren't you glad they settled that?)
> 
>Personally, I think the doctrine is one of the most evil fucking things
>in existence, legal opponents call it "the doctrine of intellectual
>slavery" because it has the affect under the law to be able to convert
>simple NDA agreements into non-compete agreements, and I've seen it 
>used this way.
> 
> That's a different matter.  If you use NDA and Trade secret law, then
> yes, might be able to enslave programmers using such a law.  However
> most courts have strict limits to how far they will take non-compete
> arguments, and if an NDA turned into a non-compete, past a certain point

The legal limit is 18 months in most states.  This "I have a right to 
make a living argument" only holds water if the other side refuses to
post a bond.  If they post a large enough bond, a court WILL rule 
in favor of inevitability if they make a good case for it.  (The 
bond required to keep me from programming for 18 months cost Novell 
$10,000,000.00.)

> they will say that a person has a right to earn a living.
> Fortunately most judges will apply some amount of common sense, even

US Judges are pontius pilate's all -- with hearts as black as the robes
they wear.  They don't care about you, or your rights.  Remember, almost
all judges are lawyers who are too old or to incompetent to practice law
so they get themselves an appointment.  Most of them were crooked lawyers
who went into politics (which is how a lawyer gets made into a judge, BTW,
he goes into politics).

> despite their law school training.  In any case, the GPL doesn't involve
> NDA's or Trade Secrets, so saying that this doctrine could be used to

It has to do with contract law, which is what the doctrine of 
inevitability is all about.  Trade secrets have nothing to do 
with it, it's a question of knowledge gained via access to 
code through some form of agreement.  In employment 
situations, it's a trade secret agreement, here in Linux, it's 
a GPL agreement.

> contaminate non-GPL code simply by having people look at GPL code is
> bullshit.

I argued that looking at Novell Public Code under their form of GPL
would not contaminate -- a court ruled otherwise.  The court ruled 
that under inevitability, public code on Novell's website and 
slides presented at Brianshare, even though they were public, 
had the affect of contaminating our internal projects under 
this doctrine.  You don't want to kill all the lawyers, you want to 
kill all the judges -- it was a judge that came up with this 
inevitability doctrine in the first place

:-)

Jeff


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

Re: Fasttrak100 questions...

[Theodore Y. Ts'o]

   Date: Sat, 2 Dec 2000 18:21:26 -0700
   From: "Jeff V. Merkey" <[EMAIL PROTECTED]>

   Under this argument, it is argued that the engineer who had source 
   code access "inevitably used" negative knowledge he gained from 
   his study of the Linux sources.  Absent the vague descriptions of
   what a "derivative work" is in the GPL, it could be argued that 
   conversion of any knowledge contained in GPL code is a "derivative
   work".  

That's bullshit.  Copyright law very clearly states that it protects the
fixation of an idea in a medium, and that copyright explicitly does not
protect the idea itself.  The concept of what is a derived work is very
clearly understood, and there have been a lot of court cases to define
this precedent.  (My understanding is that in realm of music 7 notes in
sequence, if copied, is prima facie evidence that there is a derived
work.  Not 5 notes, and not 8 notes, but seven notes.  Gotta love those
lawyers at work.  Aren't you glad they settled that?)

   Personally, I think the doctrine is one of the most evil fucking things
   in existence, legal opponents call it "the doctrine of intellectual
   slavery" because it has the affect under the law to be able to convert
   simple NDA agreements into non-compete agreements, and I've seen it 
   used this way.

That's a different matter.  If you use NDA and Trade secret law, then
yes, might be able to enslave programmers using such a law.  However
most courts have strict limits to how far they will take non-compete
arguments, and if an NDA turned into a non-compete, past a certain point
they will say that a person has a right to earn a living.
Fortunately most judges will apply some amount of common sense, even
despite their law school training.  In any case, the GPL doesn't involve
NDA's or Trade Secrets, so saying that this doctrine could be used to
contaminate non-GPL code simply by having people look at GPL code is
bullshit.

No question, though, the first thing we should do, is kill all the
lawyers.  (And this is now definitely off-topic for the linux-kernel
list.)

- Ted

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

Re: 2.2.18pre2[34] freezes

[Horst von Brand]

Horst von Brand <[EMAIL PROTECTED]> said:
> P3/600 (Katmai, stepping 3), intel SR440BX mobo + latest BIOS, 128Mb; RH7 +
> local updates (notably binutils-2.10.0.33-1).
> 
> 2.2.18pre23: Machine was mostly idle (around 15:40, no users, running Gnome
> + screensaver). No response at all to mouse/keyboard (C-A-BS nor
> C-A-DEL). No traces in the logs.
> 
> 2.2.18pre24: Rebooted into 24, downloaded latest CVS update for gcc started
> building, was reading email via emacs + mh-e in Gnome. Full freeze again.

Happened twice again when compiling today's CVS of gcc + running dip (CSLIP
connection).
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: how to compile redhat6.0 kernel

[Paul Schulz]

Mourad,

   i wanna recompile the kernel to reset some variables "ip multicasting",
   and i have a root access.

   so can you please tell me in steps (detailed) , how to recompile an
   installed kernel of redhat6.0.

Download the kernel source (or have a look in /usr/src/linux)
Read the 'README' in the home directory... 

   thanx
   mourad,   

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


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

how to compile redhat6.0 kernel

[Mourad Lakhdar]

hi:

i wanna recompile the kernel to reset some variables "ip multicasting",
and i have a root access.

so can you please tell me in steps (detailed) , how to recompile an
installed kernel of redhat6.0.

thanx
mourad,   

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

Re: /dev/random probs in 2.4test(12-pre3)

[Theodore Y. Ts'o]

   Date: Sat, 2 Dec 2000 18:34:44 -0500 (EST)
   From: Alexander Viro <[EMAIL PROTECTED]>

   Erm... Not that ignoring the return values was a bright idea, but the
   lack of reliable ordered datagram protocol in IP family is not a good
   thing. It can be implemented over TCP, but it's a big overkill. IL is a
   nice thing to have...

You mean RDP (Reliable Data Protocol), RFC-908 and RFC-1151?  It
provides reliable (i.e., will handle retransmission and dropping
duplicate) datagrams with optional sequencing guarantees if requested by
the application (but if you don't need sequencing, you don't have to pay
for it).  It's built on top of IP.  It's specified, but it never become
popular.  But it *is* a member of the IP family, however neglected and
ignored it might be.

- Ted

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

Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]

[Linus Torvalds]

On Sat, 2 Dec 2000, Ion Badulescu wrote:
> 
> If it's the same bug that locks up the ATI chipset on my Dell laptop,
> then you can safely enable DPMS if only enable the standby mode,
> not the others (suspend and off). The panel gets turned off anyway,
> even in standby.

Yup, same bug, and yes, "dpms standby" works, only suspend and off are
broken.

Linus

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

[uPATCH] duplicate pci ids

[Peter Samuelson]

A patch hunk got duplicated somewhere, it seems.

--- test12pre3/include/linux/pci_ids.h~ Sat Dec  2 19:23:51 2000
+++ test12pre3/include/linux/pci_ids.h  Sat Dec  2 20:45:53 2000
@@ -406,10 +406,6 @@
 #define PCI_DEVICE_ID_ELSA_MICROLINK   0x1000
 #define PCI_DEVICE_ID_ELSA_QS3000  0x3000
 
-#define PCI_VENDOR_ID_ELSA 0x1048
-#define PCI_DEVICE_ID_ELSA_MICROLINK   0x1000
-#define PCI_DEVICE_ID_ELSA_QS3000  0x3000
-
 #define PCI_VENDOR_ID_SGS  0x104a
 #define PCI_DEVICE_ID_SGS_2000 0x0008
 #define PCI_DEVICE_ID_SGS_1764 0x0009
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18pre2[34] freezes

[Horst von Brand]

P3/600 (Katmai, stepping 3), intel SR440BX mobo + latest BIOS, 128Mb; RH7 +
local updates (notably binutils-2.10.0.33-1).

2.2.18pre23: Machine was mostly idle (around 15:40, no users, running Gnome
+ screensaver). No response at all to mouse/keyboard (C-A-BS nor
C-A-DEL). No traces in the logs.

2.2.18pre24: Rebooted into 24, downloaded latest CVS update for gcc started
building, was reading email via emacs + mh-e in Gnome. Full freeze again.

First time this happens to me with this machine. Back to 2.2.18pre22 for
now.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: multiprocessor kernel problem

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> 
> I have 2.4.0  test 10 and test 11 installed on a multiprocessor (Intel)
> machine.  I have tried both test versions of the kernel.  I configured
> the kernel for single
> and multi processor.  When I boot single processor, iptables will run
> fine.  When I boot the machine with the multiprocessor kernel and run
> iptables, the kernel dumps several pages of hex and the final two lines
> of output are:
> 
> Killing interrupt handler
> scheduling in interrupt

My development box (running test10pre5) is SMP, and it works fine.  I
haven't updated to the latest kernel version because I like my
filesystems in one piece, and the netfilter code hasn't changed.

What is your kernel configuration, and iptables version?  Have you
patched the kernel?

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

[patch-2.4.0-test12-pre3] ip_conntrack_proto_tcp.c compilation fix.

[Yoann Vandoorselaere]

--- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.orig  Sat Dec  2 16:18:05 
2000
+++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c   Sat Dec  2 16:19:04 2000
@@ -228,6 +228,6 @@
 }
 
 struct ip_conntrack_protocol ip_conntrack_protocol_tcp
-= { { NULL, NULLpkt_IPPROTO_TCP, "tcp",
-tcp_ableto_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
+= { { NULL, NULL }, IPPROTO_TCP, "tcp",
+tcp_pkt_to_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
 tcp_packet, tcp_new, NULL };


-- 
-- Yoann http://www.mandrakesoft.com/~yoann/
   An engineer from NVidia, while asking him to release cards specs said :
"Actually, we do write our drivers without documentation."








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

Re: Fasttrak100 questions...

[Jeff V. Merkey]

On Sat, Dec 02, 2000 at 06:21:26PM -0700, Jeff V. Merkey wrote:
> On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote:
> >Date:Sat, 2 Dec 2000 17:18:43 + (GMT)
> >From: Alan Cox <[EMAIL PROTECTED]>
> > 
> > Well, it's not up to just me, given that Linus also has his copyright on
> > the code (although I doubt there's more than a few lines which are
> > originally his).  There are some other people who have contributed code
> > to the serial driver in the past, although most have probably not given
> > me more than a dozen lines of code or so, which seems to be the
> > (completely untested in court) standard which the FSF uses to decide
> > whether or not they need to get formal legal papers signed.  
> > 
> > The legal issues are also incredibly murky, 
> 
> that's "Merkey"
> 
> > since the customers create
> > the derived work, and issues of intent aside, you can't necessarily use
> > intent to change the legal definition of "derived work".  (Be glad;
> > although it can be used to create a loophole in GPL, just meditate a
> > while on what the MPAA could do with such an "intent" argument before
> > you decide whether or not it's a good thing.  Or think what Microsoft
> > could do if they could make their EULA's as infectious as the GPL with
> > the "intent" argument.)  The whole dynamic linking argument is a very
> > slippery slope; where do you draw the line?  Does a shell script which
> > calls a GPL program get infected?  What about a propietary C program
> > which makes a system() call to invoke a GPL'ed bash?  What about an RPC
> > call across the network?  What about a GNOME Corba interface?  Is it OK
> > if it's on separate machines, but are they considered a single program
> > if the CORBA client and server are on the same machine, since now they
> > share the same VM?


BTW, for those legal folks who also demand I post case law citations, please
see the Pesico vs. (I forget the guys name) case.  Just get on Westlaw, 
and look up "Pepsico".   This is the case where this doctrine was created 
and applied by a state judge.  The case was upheld, and has been used all 
over the US since then to shaft departing employees from big software/hardware 
companies.

Jeff


> 
> Under the "Doctrine of Inevitable Disclosure" even looking at GPL code
> and using techniques it contains would contaminate anything someone 
> works on.  This doctrine put forward two concepts that have been
> used in trade secret cases to justify injunctions and non-competes
> in areas of IP pollution -- negative knowledge and inevitable 
> misappropriation.
> 
> The argument goes something like this.  Negative knowledge is defined as 
> knowing what techniques do not work (as opposed to what techniques 
> do work).   In the course of development of a piece of software,
> there are many "blind alleys" and "false starts" that are encountered
> as an individual uses trial and error to perfect whatever piece 
> of software he is writing.  Over time, the person learns what 
> approaches are blind alleys and which work.  This knowledge becomes
> imprinted into the actual thinking processes of this person.  
> 
> Source code can also contain notes and comments about what does not
> work, and what does work.  Someone reading this source code would
> then incorporate these ideas and knowledge into their thinking 
> processes.  Companies spend lots of money paying engineers to 
> develop software, and this "negative knowledge", under the 
> doctrine of inevitable disclosure is legally the property 
> of an employer since they paid an engineer to experiment and 
> learn it.   This is how companies are able to get non-compete
> court orders against employees in trade secret lawsuits -- they 
> argue that noone is going to go down a development path using ideas 
> or approaches they know do not work.  This argument goes on 
> to state that if two engineers, one who had access to a piece of 
> code vs. one who did not were to start at the same time working 
> on the same problem, the person who had access to the code would
> finish first because he would "inevitably use" the knowledge gained
> from access to the source code.  
> 
> Let's say for example two engineers wanted to write a new Linux-like
> replacement.  One of them had access to ftp.kernel.org and the other
> did not.  Which one of the engineers would finish first?  Obviously
> the one with access to ftp.kernel.org would finish first and 
> would not have had to use trial and error to get all the IOCTL calls 
> working, etc.   The engineer without source code access would take 
> longer, perhaps by a factor of years, to complete the same project.
> 
> Under this argument, it is argued that the engineer who had source 
> code access "inevitably used" negative knowledge he gained from 
> his study of the Linux sources.  Absent the vague descriptions of
> what a "derivative work" is in the GPL, it could be argued that 
> conversion of any knowledge 

Re: Fasttrak100 questions...

[Jeff V. Merkey]

On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote:
>Date:  Sat, 2 Dec 2000 17:18:43 + (GMT)
>From: Alan Cox <[EMAIL PROTECTED]>
> 
> Well, it's not up to just me, given that Linus also has his copyright on
> the code (although I doubt there's more than a few lines which are
> originally his).  There are some other people who have contributed code
> to the serial driver in the past, although most have probably not given
> me more than a dozen lines of code or so, which seems to be the
> (completely untested in court) standard which the FSF uses to decide
> whether or not they need to get formal legal papers signed.  
> 
> The legal issues are also incredibly murky, 

that's "Merkey"

> since the customers create
> the derived work, and issues of intent aside, you can't necessarily use
> intent to change the legal definition of "derived work".  (Be glad;
> although it can be used to create a loophole in GPL, just meditate a
> while on what the MPAA could do with such an "intent" argument before
> you decide whether or not it's a good thing.  Or think what Microsoft
> could do if they could make their EULA's as infectious as the GPL with
> the "intent" argument.)  The whole dynamic linking argument is a very
> slippery slope; where do you draw the line?  Does a shell script which
> calls a GPL program get infected?  What about a propietary C program
> which makes a system() call to invoke a GPL'ed bash?  What about an RPC
> call across the network?  What about a GNOME Corba interface?  Is it OK
> if it's on separate machines, but are they considered a single program
> if the CORBA client and server are on the same machine, since now they
> share the same VM?

Under the "Doctrine of Inevitable Disclosure" even looking at GPL code
and using techniques it contains would contaminate anything someone 
works on.  This doctrine put forward two concepts that have been
used in trade secret cases to justify injunctions and non-competes
in areas of IP pollution -- negative knowledge and inevitable 
misappropriation.

The argument goes something like this.  Negative knowledge is defined as 
knowing what techniques do not work (as opposed to what techniques 
do work).   In the course of development of a piece of software,
there are many "blind alleys" and "false starts" that are encountered
as an individual uses trial and error to perfect whatever piece 
of software he is writing.  Over time, the person learns what 
approaches are blind alleys and which work.  This knowledge becomes
imprinted into the actual thinking processes of this person.  

Source code can also contain notes and comments about what does not
work, and what does work.  Someone reading this source code would
then incorporate these ideas and knowledge into their thinking 
processes.  Companies spend lots of money paying engineers to 
develop software, and this "negative knowledge", under the 
doctrine of inevitable disclosure is legally the property 
of an employer since they paid an engineer to experiment and 
learn it.   This is how companies are able to get non-compete
court orders against employees in trade secret lawsuits -- they 
argue that noone is going to go down a development path using ideas 
or approaches they know do not work.  This argument goes on 
to state that if two engineers, one who had access to a piece of 
code vs. one who did not were to start at the same time working 
on the same problem, the person who had access to the code would
finish first because he would "inevitably use" the knowledge gained
from access to the source code.  

Let's say for example two engineers wanted to write a new Linux-like
replacement.  One of them had access to ftp.kernel.org and the other
did not.  Which one of the engineers would finish first?  Obviously
the one with access to ftp.kernel.org would finish first and 
would not have had to use trial and error to get all the IOCTL calls 
working, etc.   The engineer without source code access would take 
longer, perhaps by a factor of years, to complete the same project.

Under this argument, it is argued that the engineer who had source 
code access "inevitably used" negative knowledge he gained from 
his study of the Linux sources.  Absent the vague descriptions of
what a "derivative work" is in the GPL, it could be argued that 
conversion of any knowledge contained in GPL code is a "derivative
work".  

There are a lot of big software companies who believe this and 
fear application of the doctrine of inevitable disclosure relative
to GPL code.  Novell and Microsoft both do not even allow employees 
to bring GPL code into the building -- period -- for fear that someone
will attempt to file a claim that they have "converted" GPL code 
and created derivative works that may have contaminated non-GPL
code projects.  Novell has an official standing policy barring employees
from using GPL code.  That's why all the Linux work for NetWare is 
done in the India development 

Re: [RFC] Configuring synchronous interfaces in Linux

[Keith Owens]

On Sat, 2 Dec 2000 13:07:29 -0600 (CST), 
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>If yes, my guess is correct, I think the proper solution is to:
>* create a generic set_config, which does nothing but convert the calls'
>semantics into ethtool semantics, and
>* add ethtool support to the specific driver

cc list trimmed.

If you go down this path, please add a standard performance monitoring
method to query the current capacity of an interface.  It is frustrating
to report "eth0 is handling 1 Megabyte/second, but we cannot tell if
that is 90% (10BaseT) or 9% (100BaseT) utilization".  We should report
capacity rather than speed because speed alone is not the controlling
factor, other things like half or full duplex affect the capacity.

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

Re: Fasttrak100 questions...

[Theodore Y. Ts'o]

   Date:Sat, 2 Dec 2000 17:18:43 + (GMT)
   From: Alan Cox <[EMAIL PROTECTED]>

   > This is currently happening with lucent winmodem driver: there's
   > modified version of serial.c, and customers are asked to compile it
   > and (staticaly-)link it against proprietary code to get usable
   > driver. Is that okay or not?

   Probably not, its up to Ted to enforce I suspect.

Well, it's not up to just me, given that Linus also has his copyright on
the code (although I doubt there's more than a few lines which are
originally his).  There are some other people who have contributed code
to the serial driver in the past, although most have probably not given
me more than a dozen lines of code or so, which seems to be the
(completely untested in court) standard which the FSF uses to decide
whether or not they need to get formal legal papers signed.  

The legal issues are also incredibly murky, since the customers create
the derived work, and issues of intent aside, you can't necessarily use
intent to change the legal definition of "derived work".  (Be glad;
although it can be used to create a loophole in GPL, just meditate a
while on what the MPAA could do with such an "intent" argument before
you decide whether or not it's a good thing.  Or think what Microsoft
could do if they could make their EULA's as infectious as the GPL with
the "intent" argument.)  The whole dynamic linking argument is a very
slippery slope; where do you draw the line?  Does a shell script which
calls a GPL program get infected?  What about a propietary C program
which makes a system() call to invoke a GPL'ed bash?  What about an RPC
call across the network?  What about a GNOME Corba interface?  Is it OK
if it's on separate machines, but are they considered a single program
if the CORBA client and server are on the same machine, since now they
share the same VM?

In any case, the FSF has their opinion, and at least one Ivy League law
professor laughed aloud when he was asked what he thought about the
FSF's legal theories; other people have their own.  Most importantly,
none of this has been tested in court.  So it's probably not worth
trying to settle this on the linux-kernel list.

As far as this particular case is concerned, at least Lucent is shipping
part of the driver in source.  Some of the other winmodem drivers are
shipping a pure binary module, which means it will only work against a
single kernel version, which locks out users form upgrading to newer
kernels if they still want to use their winmodem.  So at least Lucent is
trying to be at least somewhat good guys about this.  

I could threaten to sue them, but it's not clear to me what good it will
do, short of depriving some users from being able to use their
winmodem.  I suppose we could encourage them to rewrite the
modified-serial.c for scratch, but aside from making some GPL fanatics
feel good, enriching some consultant and making Lucent a little poorer,
what good does it really do in the long run?  And I have better things
to do with my time.  At the same time, I certainly won't bless what they
are doing.  What they are doing is clearly wrong, and illegal.  But it
is an imperfect world that we live in, as the events in Florida have
been clearly demonstrating over the past month.

Given the limited time that I have, I'd much rather spend it going after
the Rockwell/Connexant winmodem driver, which also pretty clearly uses
serial.c, but for which they've only distributed a single .o file for a
specific kernel version.  Or I could spend it on programming.

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

Re: /dev/random probs in 2.4test(12-pre3)

[Alexander Viro]

On Sat, 2 Dec 2000, Theodore Y. Ts'o wrote:

> particularly people who writing network programs.  The number of people
> who assume that they can get an entire (variable-length) RPC packet by
> doing a single read() call astounds me.  TCP doesn't provide message
> boundaries, never did and never will.  The problem is that such program
> will work on a LAN, and then blow up when you try using them across the
> real Internet.

Erm... Not that ignoring the return values was a bright idea, but the
lack of reliable ordered datagram protocol in IP family is not a good
thing. It can be implemented over TCP, but it's a big overkill. IL is a
nice thing to have...

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

Re: /dev/random probs in 2.4test(12-pre3)

[Theodore Y. Ts'o]

   From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
   Date:Sat, 2 Dec 2000 17:00:32 -0500 (EST)

   > Any programmer who has evolved sufficiently from a scriptie
   > should take necessary precautions to check how much data was
   > transferred.  Those who don't..well, there is still tomorrow.

   Yeah, people write annoying little wrapper functions that
   bounce right back into the kernel until the job gets done.
   This is slow, it adds both source and object bloat, and it
   is a source of extra bugs. What a lovely API, eh?

Well, that's the Unix interface you.  I you don't like it, why don't you
become a Windows programmer and try your hand at the Win32 interface?  :-)

Seriously, doing something different for /dev/random compared to all
other read(2) calls is a bad idea; it will get people confused.  The
answer is whenever you call read(2), you must check the return values.
People who don't are waiting to get themselves into a lot of trouble,
particularly people who writing network programs.  The number of people
who assume that they can get an entire (variable-length) RPC packet by
doing a single read() call astounds me.  TCP doesn't provide message
boundaries, never did and never will.  The problem is that such program
will work on a LAN, and then blow up when you try using them across the
real Internet.

Secondly, the number of times that you end up going into a kernel is
relatively rare; I doubt you'd be able to notice a performance
difference in the real world using a real-world program.  As far as
source/object code bloat, well, how much space does a while loop take?
And I usyally write a helper function which takes care of the while
loop, checks for errors, calls read again if EINTR is returned, etc.

- Ted

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

Re: make oldconfig with menuconfig

[Peter Samuelson]

[Frédéric L . W . Meunier]
> What's the best way to use make oldconfig with menuconfig?
> oldconfig with config isn't what will make my life easier.

You mean you want menuconfig, but only one small menu with the new
options?  Can't be done, currently.

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

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

[Peter Samuelson]

[Wolfgang Spraul]
> I didn't find the "Transmeta" thread, though.
> In the thread you mentioned, did they post any patches?

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

No patch but a description, and Linus will apparently put it in the
next prepatch.

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

[patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

Second attempt. The linux-kernel list is broken at the moment (reported
fault to postmaster already) so some messages get lost at random:


-- Forwarded message --
Date: Sat, 2 Dec 2000 21:49:21 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]

diff -urN -X dontdiff linux/CREDITS ucode/CREDITS
--- linux/CREDITS   Fri Dec  1 15:44:03 2000
+++ ucode/CREDITS   Fri Dec  1 15:47:23 2000
@@ -41,7 +41,7 @@
 E: [EMAIL PROTECTED]
 W: http://www.ocston.org/~tigran
 D: BFS filesystem
-D: Intel P6 CPU microcode update support
+D: Intel IA32 CPU microcode update support
 D: Various kernel patches
 S: United Kingdom
 
diff -urN -X dontdiff linux/Documentation/Changes ucode/Documentation/Changes
--- linux/Documentation/Changes Thu Oct 26 21:49:15 2000
+++ ucode/Documentation/Changes Fri Dec  1 15:47:23 2000
@@ -185,10 +185,10 @@
 kernel source.  Pay attention when you recompile your kernel ;-).
 Also, be sure to upgrade to the latest pcmcia-cs release.
 
-Intel P6 microcode
---
+Intel IA32 microcode
+
 
-A driver has been added to allow updating of Intel P6 microcode,
+A driver has been added to allow updating of Intel IA32 microcode,
 accessible as both a devfs regular file and as a normal (misc)
 character device.  If you are not using devfs you may need to:
 
@@ -198,6 +198,13 @@
 
 as root before you can use this.  You'll probably also want to
 get the user-space microcode_ctl utility to use with this.
+
+If you have compiled the driver as a module you may need to add
+the following line:
+
+alias char-major-10-184 microcode
+
+to your /etc/modules.conf file.
 
 Networking
 ==
diff -urN -X dontdiff linux/Documentation/Configure.help 
ucode/Documentation/Configure.help
--- linux/Documentation/Configure.help  Fri Dec  1 15:44:03 2000
+++ ucode/Documentation/Configure.help  Fri Dec  1 15:47:23 2000
@@ -13427,13 +13427,13 @@
   Toshiba Linux utilities website at:
   http://www.buzzard.org.uk/toshiba/
 
-/dev/cpu/microcode - Intel P6 CPU microcode support
+/dev/cpu/microcode - Intel IA32 CPU microcode support
 CONFIG_MICROCODE
   If you say Y here and also to "/dev file system support" in the
   'File systems' section, you will be able to update the microcode on
-  Intel processors in the P6 family, e.g. Pentium Pro, Pentium II,
-  Pentium III, Xeon etc. You will obviously need the actual microcode
-  binary data itself which is not shipped with the Linux kernel.
+  Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
+  Pentium III, Pentium 4, Xeon etc. You will obviously need the actual 
+  microcode binary data itself which is not shipped with the Linux kernel.
 
   For latest news and information on obtaining all the required
   ingredients for this driver, check:
@@ -13442,7 +13442,9 @@
   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
   The module will be called microcode.o. If you want to compile it as
-  a module, say M here and read Documentation/modules.txt.
+  a module, say M here and read Documentation/modules.txt. If you use
+  modprobe or kmod you may also want to add the line
+  'alias char-major-10-184 microcode' to your /etc/modules.conf file.
 
 /dev/cpu/*/msr - Model-specific register support
 CONFIG_X86_MSR
diff -urN -X dontdiff linux/Documentation/ioctl-number.txt 
ucode/Documentation/ioctl-number.txt
--- linux/Documentation/ioctl-number.txtMon Jun 19 20:56:07 2000
+++ ucode/Documentation/ioctl-number.txtFri Dec  1 15:47:23 2000
@@ -74,8 +74,8 @@
 0x22   all scsi/sg.h
 '1'00-1F  PPS kit from Ulrich Windl


-'6'00-10 Intel P6 microcode update driver
-   <[EMAIL PROTECTED]>
+'6'00-10 Intel IA32 microcode update driver
+   
 '8'all SNP8023 advanced NIC card

 'A'00-1F   linux/apm_bios.h
diff -urN -X dontdiff linux/MAINTAINERS ucode/MAINTAINERS
--- linux/MAINTAINERS   Fri Dec  1 15:44:04 2000
+++ ucode/MAINTAINERS   Fri Dec  1 15:47:23 2000
@@ -633,7 +633,7 @@
 W: http://sourceforge.net/projects/gkernel/
 S: Maintained
 
-INTEL P6 MICROCODE UPDATE SUPPORT
+INTEL IA32 MICROCODE UPDATE SUPPORT
 P: Tigran Aivazian
 M: [EMAIL PROTECTED]
 S: Maintained
diff -urN -X dontdiff linux/arch/i386/kernel/microcode.c 
ucode/arch/i386/kernel/microcode.c
--- linux/arch/i386/kernel/microcode.c  Mon Oct 30 22:44:29 2000
+++ ucode/arch/i386/kernel/microcode.c  Sat Dec  2 20:46:49 2000
@@ -4,13 +4,13 @@
  * Copyright (C) 2000 Tigran Aivazian
  *
  * This driver allows to upgrade microcode on Intel processors
- * belonging to 

Re: /dev/random probs in 2.4test(12-pre3)

[Albert D. Cahalan]

David Ford writes:
> Igmar Palsenberg wrote:

>> I've seen lots of programs that will assume that if we request x bytes
>> from /dev/random it will return x bytes.
>
> I find this really humorous honestly.  I see a lot of people
> assuming that if you write N bytes or read N bytes that you will
> have done N bytes.  There are return values for these functions
> that tell you clearly how many bytes were done.
>
> Any programmer who has evolved sufficiently from a scriptie
> should take necessary precautions to check how much data was
> transferred.  Those who don't..well, there is still tomorrow.

Yeah, people write annoying little wrapper functions that
bounce right back into the kernel until the job gets done.
This is slow, it adds both source and object bloat, and it
is a source of extra bugs. What a lovely API, eh?

The fix: write_write_write_damnit() and read_read_read_damnit(),
which go until they hit a fatal error or complete the job.

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Tigran Aivazian wrote:
> 
> On Sat, 2 Dec 2000, Tigran Aivazian wrote:
> 
> > On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> > >
> > > OK, fair enough.  Let me make a new statement then: I suggest we preface
> > > these with MSR_ anyway so we can tell what they really are.
> > >
> >
> > That is much better. Actually, I accept your suggestion.
> 
> on the other hand -- that makes them much longer and it is always obvious
> from the context what they are, i.e.:
> 
> a) if they appear in the code then it is unlikely they are outside of
> rdmsr()/wrmsr() which makes their meaning obvious.
> 
> b) if they are in the header, the name of the header asm/msr.h and the
> comment above their definition explains what they are.
> 
> I don't know -- if people really think MSR_ is needed then it can be
> done.
> 
> I think my intuitive IA32_ naming was adequate but if you really believe
> we should prefix it with MSR_ then so be it.
> 

I really think so... after all, it might be obvious when you use them in
the correct context, but it definitely isn't obvious when you're using
them in the wrong context.  I am also worried about namespace collisions
doing back things.

-hpa

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Tigran Aivazian wrote:
> 
> On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> >
> > OK, fair enough.  Let me make a new statement then: I suggest we preface
> > these with MSR_ anyway so we can tell what they really are.
> >
> 
> That is much better. Actually, I accept your suggestion. (because I have
> just found a few more cleanups to be done in the code but they were not
> worth a patch on their own but together with the above it is worth
> remaking the patch).
> 
> So, unless Linus already applied it I will resend a new one to him
> shortly.
> 
> Regards,
> Tigran
> 
> PS. Btw, the proof of my statement is found at:
> 
> http://developer.intel.com/design/pentium4/manuals/245472.htm
> 
> and download the PDF, then read the section 8.11.1 on page 8-32.

I believe you :)  Pardon me now, I have a foot to get unstuck from this
here mouth of mine...

-hpa

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

Re: /dev/random probs in 2.4test(12-pre3)

[David Ford]

Igmar Palsenberg wrote:

> > For a blocking fd, read(2) has always blocked until some data is
> > available.  There has never been a guarantee, for any driver, that
> > a read(2) will return the full amount of bytes requested.
>
> I know. Still leaves lot's of people that assume that reading /dev/random
> will return data, or will block.
>
> I've seen lots of programs that will assume that if we request x bytes
> from /dev/random it will return x bytes.

I find this really humorous honestly.  I see a lot of people assuming that if
you write N bytes or read N bytes that you will have done N bytes.  There are
return values for these functions that tell you clearly how many bytes were
done.

Any programmer who has evolved sufficiently from a scriptie should take
necessary precautions to check how much data was transferred.  Those who
don't..well, there is still tomorrow.

There is no reason to add any additional documentation.  If we did, we'd be
starting the trend of documenting the direction a mouse moves when it's
pushed and not to be alarmed if you turn the mouse sideways and the result is
90 degrees off.

-d



begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard

Re: 'holey files' not holey enough.

[Jaakko Hyvätti]

  Hi!

On Sat, 2 Dec 2000, Adam wrote:
> It seems you are right. If I remove the file first, then it will show
> correct amount.

  (For the list: In private mail it was discovered that this behaviour was
caused by the file 'holed.file' not being empty before the dd command.)

  dd behaves here correctly.  It does not append to file, but it just
opens the file for writing.  It does not remove or truncate it first.

  If you have executed this command:

dd if=/dev/zero of=holed.file bs=1000 count=1000

You have a simple file with zeroes, like this:

'0'

Then with this command dd opens the file for write but does not destroy
its contents - it is not supposed to do that.  (You can alter files with
dd, you can overwrite single bytes if you like.)

 dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000

After opening the file dd seeks to what you specify, and at the same time
extends the file by seeking and Linux converts this to holes:

'0-'

  And after seeking it writes the new block of zeroes:

'0-0'

..and you have 2MB of stuff there instead of 1M!

Yours,
Jaakko

-- 
Weather Service Finland Ltd  [EMAIL PROTECTED]
Pursimiehenkatu 29-31 B, FIN-00150 Helsinki, Finland http://www.weather.fi

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

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

[Wolfgang Spraul]

Yes, the C1VE has a Crusoe processor (5600 stepping 03).
I didn't find the "Transmeta" thread, though.
test12-pre still has the problem. And to change the PCI access from  to
 or  doesn't help either.
In the thread you mentioned, did they post any patches?
Wolfgang

Quoting Jeff Garzik <[EMAIL PROTECTED]>:

> On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
> > PhoenixBIOS, Sony Vaio C1VE
> > 
> > I did some printk() debugging, but the kernel hangs at various places
> in
> > pci_setup_device(), mostly in pci_read_bases().
> 
> This is a Transmeta laptop, right?
> 
> See the recent thread with "Transmeta" in the subject.  The problem
> seems to have been identified, and hopefully the fix will appear in
> test12-pre4, when released...
> 
>   Jeff
> 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: /dev/random probs in 2.4test(12-pre3)

[Igmar Palsenberg]

> "totally block"?
> 
> For a blocking fd, read(2) has always blocked until some data is
> available.  There has never been a guarantee, for any driver, that
> a read(2) will return the full amount of bytes requested.

Hmm.. Some came to mind :

Making /dev/random block if the amount requirements aren't met makes sense
to me. If I request x bytes of random stuff, and get less, I probably
reread /dev/random. If it's entropy pool is exhausted it makes sense to be
to block.

Just some mind spin.

> There is no need to document this...  man read(2)  ;-)
> 
>   Jeff




Igmar

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Alan Cox wrote:
> 
> > Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> > besides, the preferred prefix in existing locations in the Linux
> > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
> 
> I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)

They are MSRs, most of all.  His naming didn't reflect that, and quite
frankly, I'd much rather use the names (all starting with MSR_) that the
Intel documentation uses.

-hpa

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

Re: /dev/random probs in 2.4test(12-pre3)

[Igmar Palsenberg]

> For a blocking fd, read(2) has always blocked until some data is
> available.  There has never been a guarantee, for any driver, that
> a read(2) will return the full amount of bytes requested.

I know. Still leaves lot's of people that assume that reading /dev/random
will return data, or will block.

I've seen lots of programs that will assume that if we request x bytes
from /dev/random it will return x bytes.

> There is no need to document this...  man read(2)  ;-)
> 
>   Jeff


Igmar

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

Re: Transmeta and Linux-2.4.0-test12-pre3

[Aaron Lehmann]

On Fri, Dec 01, 2000 at 09:09:25PM -0800, Linus Torvalds wrote:
> NOTE! Getting the 2.4.x kernel up and running is the easy part.  The
> machine also has a very recent ATI Rage Mobility chip in it, and you
> need the newest XFree86 CVS snapshot to make it work (along with a
> one-liner patch from me, unless that has already made it into the CVS
> tree by now).

It seems to just have:

  1067. Fix ATI clock generator recognition when an adapter BIOS
  cannot be retrieved (Linus Torvals).

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

Re: [RFC] Configuring synchronous interfaces in Linux

[Philip Blundell]

>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?

Yes.

p.


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

Re: [RFC] Configuring synchronous interfaces in Linux

[Donald Becker]

On Sun, 3 Dec 2000, Chris Wedgwood wrote:

> On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote:
> 
> Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
> and 3c59x drivers, and that is consistent.
> 
> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.
> 
> I am now wondering whether it make sense to break 3c59x into smaller
> peices which hander fewer cards each; there soom to be many things
> the driver knows about which probably don't relate to my needs.

It's certainly possible to break the driver up, but it will be even more of
a problem to maintain.  Some of the complicated media selection code applies
to several generations.  Splitting the driver to have a copy for each
generation means a lot of duplicated code, which quickly leads to version
skew.

The story usually goes like this:

Someone wants to experiment with a driver.  It's always exciting to tweak
the code for the latest and greatest.  But the driver has all of this
complicated stuff for other, usually older, card/kernel versions.  So the
hacker tosses out the code, "simplifying" the driver.  They then release the
"new and improved driver".

They have no CVS tree to maintain, no old driver or hardware versions to
keep track of.  No one has been using the driver for years, and thus there
is no one screaming when their production machine stop working.  All of the
people with problems are just referred to the guy who did the original
driver, who is still expected to be there when things break.  They don't
realize they have just removed all of the excitement and motivation for they
guy who is doing all of the time consuming maintenance and testing work.

I don't mean to pick on 3Com, but the driver they released is a good
example.  It supported only a tiny set of card types that 3Com was currently
selling, and only with the current kernel.  It didn't support the previous
card types, the OEMed versions, or the older kernels.  The assumption was
that my driver would exist to support those hard cases, but by handling the
easy 90% that 3Com would get most of the credit.

Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

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

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

[Jeff Garzik]

On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
> PhoenixBIOS, Sony Vaio C1VE
> 
> I did some printk() debugging, but the kernel hangs at various places in
> pci_setup_device(), mostly in pci_read_bases().

This is a Transmeta laptop, right?

See the recent thread with "Transmeta" in the subject.  The problem
seems to have been identified, and hopefully the fix will appear in
test12-pre4, when released...

Jeff



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

Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

[Jeff Garzik]

On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
> 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the
> number of sectors that can be read at once (i.e. in one track).
> 
> This routine does not work with the Sony UDF5 USB floppy disk, mapped as an
> Int13 device by the Vaio C1VE (Crusoe) BIOS.
> Therefore, a bzdisk floppy will not be bootable.

The bzdisk code is used so infrequently compared to the normal
bootloaders, lilo, grub, and syslinux, that I'm not surprised it has
problems with many edge cases.

Although I imagine this is an unpopular opinion, I think that we
should remove all bzdisk-type code from X86...  syslinux and other
boot loaders handle weird BIOS quirks much better, simply because
they are used in far more situations than bzdisk.

syslinux especially is quite nice for loading kernels from floppy.
It's very small, and "syslinux -s" adds in some wonderfully-paranoid
sanity checks which make boot loading works on many a quirky BIOS.
(don't use '-s' unless you need it, of course, it slows things down...)

Jeff



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

2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

[Wolfgang Spraul]

PhoenixBIOS, Sony Vaio C1VE

I did some printk() debugging, but the kernel hangs at various places in
pci_setup_device(), mostly in pci_read_bases().

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

2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

[Wolfgang Spraul]

2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the
number of sectors that can be read at once (i.e. in one track).

This routine does not work with the Sony UDF5 USB floppy disk, mapped as an
Int13 device by the Vaio C1VE (Crusoe) BIOS.
Therefore, a bzdisk floppy will not be bootable.

I solved the problem for me by changing "disksizes: .byte 36, 18, 15, 9" to
"disksizes: .byte 18, 18, 18, 18", but I think someone should do it right.
I will assist debugging if needed.

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

Re: [RFC] Configuring synchronous interfaces in Linux

[Jeff Garzik]

On Sun, 3 Dec 2000, Chris Wedgwood wrote:
> > Russell King <[EMAIL PROTECTED]> écrit :
> > [...]
> > > We already have a standard interface for this, but many drivers do not
> > > support it.  Its called "ifconfig eth0 media xxx":

> Actually, I starteed work on adding this to the 3c59x code last
> night; I am now a little dispondent though as it wasn't as simple as
> I first thought it might be.

Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?

If yes, my guess is correct, I think the proper solution is to:
* create a generic set_config, which does nothing but convert the calls'
semantics into ethtool semantics, and
* add ethtool support to the specific driver

And you might even go so far as to create a generic MII implementation
of ethtool support, so that existing drivers can simply plug in their
mdio_{read,write} functions to automatically get full ethtool support.
(disclaimer:  this is a spur-of-the-moment thought, creating a generic
MII module for ethtool support may not be feasible)

drivers/net/sis900.c implements set_config, if you want an example..

Finally, if you want to just use ethtool directly, grab the SRPM and
install it on your system.

Jeff



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

Re: /dev/random probs in 2.4test(12-pre3)

[Jeff Garzik]

On Sat, 2 Dec 2000, Igmar Palsenberg wrote:
> > Indeed, you are correct.  Is vpnd broken then, for assuming
> > that it can gather the required randomness in one read?
> 
> Yep. It assumes that if the required randommness numbers aren't met a read
> to /dev/random will block.
> 
> And it's not the only program that assumes this : I also did. 
> 
> /dev/random is called a blocking random device, which more or less implies
> that it will totally block. I suggest we put this somewhere in the kernel
> docs, since lots of people out there assume that it totally blocks.

"totally block"?

For a blocking fd, read(2) has always blocked until some data is
available.  There has never been a guarantee, for any driver, that
a read(2) will return the full amount of bytes requested.

There is no need to document this...  man read(2)  ;-)

Jeff



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

Re: corruption

[Alexander Viro]

On Sat, 2 Dec 2000, Petr Vandrovec wrote:

[I wrote:]

> > ed fs/buffer.c < > /unmap_buffer/
> > /}/i
spin_lock(_list_lock);
> > remove_inode_queue(bh);
spin_unlock(_list_lock);
> > .
> > wq
> > EOF

Damn. I claim the sudden idiocy attack - didn't look at the locking
rules for the ->b_inode_buffers. My apologies.

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

Re: /dev/random probs in 2.4test(12-pre3)

[Igmar Palsenberg]

> Indeed, you are correct.  Is vpnd broken then, for assuming
> that it can gather the required randomness in one read?

Yep. It assumes that if the required randommness numbers aren't met a read
to /dev/random will block.

And it's not the only program that assumes this : I also did. 

/dev/random is called a blocking random device, which more or less implies
that it will totally block. I suggest we put this somewhere in the kernel
docs, since lots of people out there assume that it totally blocks.

Means I've got to updates some sources of mine :)

> Matthew.


Igmar

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

Re: corruption

[Alexander Viro]

On Sat, 2 Dec 2000, Petr Vandrovec wrote:

> Nothing new (was it meant to run remove_inode_queue() conditionaly inside 
> buffer_mapped() branch? ed did it that way). First is list of buffers at 
> time of destroy_inode, then process. If you want full oops trace, it is 

what list of buffers? ->i_dirty_buffers one?

> available at http://platan.vc.cvut.cz/oops3.txt, but last part is always 
> iput. For now I'm back on test9, as I lost inetd.conf again :-( Someone 
> should shoot sendmail Debian maintainer... Running update-inetd at startup 
> is really bad idea, as fsck then usually removes both old and new inetd.conf, 
> so I'm back on inetd.conf from 25 Aug 1999 :-(((
> 
> Fields printed from buffer_head are b_next, b_blocknr, b_size, b_list,
> b_count, b_state and b_inode. (oops now I see that I left
> remove_inode_queue(bh) in printing loop (I copied it from
> invalidate_inode_buffers()), but it should not hurt, I believe. Dirty buffers
> should find its way to disk anyway, or not?)

When you delete the inode? Why would they? Petr, could you send me the
diff between the variant you've run and pristine 12-pre3? I'ld really
like to see what exactly was doing the printks...

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

Re: Fasttrak100 questions...

[Alan Cox]

> This is currently happening with lucent winmodem driver: there's
> modified version of serial.c, and customers are asked to compile it
> and (staticaly-)link it against proprietary code to get usable
> driver. Is that okay or not?

Probably not, its up to Ted to enforce I suspect.

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

Re: Fasttrak100 questions...

[Pavel Machek]

Hi!

> > You are wrong: If you modify the kernel you have to make it available for
> > anyone who wishes to use it; that's also in the GPL. You can't add stuff
> 
> No it isnt. Some people seem to think it is. You only have to provide a 
> change if you give someone the binaries concerned. Some people also think
> that 'linking' clauses mean they can just direct the customer to do the link,
> that also would appear to be untrue in legal precedent - the law cares about
> the intent.

This is currently happening with lucent winmodem driver: there's
modified version of serial.c, and customers are asked to compile it
and (staticaly-)link it against proprietary code to get usable
driver. Is that okay or not?
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

make oldconfig with menuconfig

[Frédéric L . W . Meunier]

What's the best way to use make oldconfig with menuconfig?
oldconfig with config isn't what will make my life easier.

TIA.

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

Re: corruption

[Petr Vandrovec]

On Sat, Dec 02, 2000 at 10:33:36AM -0500, Alexander Viro wrote:
> On Sun, 3 Dec 2000, Andrew Morton wrote:
> 
> > It appears that this problem is not fixed.
> 
> Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer().
> Add the call of remove_inode_queue(bh) there and see if it helps. I.e.
> 
> ed fs/buffer.c < /unmap_buffer/
> /}/i
>   remove_inode_queue(bh);
> .
> wq
> EOF
> 
> Linus, could you apply that? We are leaving the unmapped buffers on the
> inode queue. I.e. every truncate_inode_pages() leaves a lot of junk around.
> Now, guess what happens when we destroy the last link to inode that nobody
> keeps open...

Nothing new (was it meant to run remove_inode_queue() conditionaly inside 
buffer_mapped() branch? ed did it that way). First is list of buffers at 
time of destroy_inode, then process. If you want full oops trace, it is 
available at http://platan.vc.cvut.cz/oops3.txt, but last part is always 
iput. For now I'm back on test9, as I lost inetd.conf again :-( Someone 
should shoot sendmail Debian maintainer... Running update-inetd at startup 
is really bad idea, as fsck then usually removes both old and new inetd.conf, 
so I'm back on inetd.conf from 25 Aug 1999 :-(((

Fields printed from buffer_head are b_next, b_blocknr, b_size, b_list,
b_count, b_state and b_inode. (oops now I see that I left
remove_inode_queue(bh) in printing loop (I copied it from
invalidate_inode_buffers()), but it should not hurt, I believe. Dirty buffers
should find its way to disk anyway, or not?)
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

BTW, running 'ksymoops < oops > oops.txt' is great source of errors below,
as it (probably) uses couple of unlinked temorary files...

next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7bf3ce0

Process mount (pid: 30, stackpage=c7df3000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7bf3ce0

Process mount (pid: 31, stackpage=c7df3000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7c1a860

Process mount (pid: 68, stackpage=c7997000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b54c80

Process mount (pid: 70, stackpage=c7997000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b54c80

Process mount (pid: 70, stackpage=c7997000)


next=, nr=3375109, size=4096, list=2
count=0
state=001B inode=c77e2260

Process rm (pid: 82, stackpage=c7b35000)


next=, nr=3506180, size=4096, list=2
count=0
state=001B inode=c77eb9c0

Process rm (pid: 121, stackpage=c776d000)

next=, nr=3506180, size=4096, list=2
count=0
state=001B inode=c77ebb40
next=, nr=3507147, size=4096, list=2
count=0
state=001B inode=c77ebb40

Process rm (pid: 122, stackpage=c776d000)


next=, nr=1179657, size=4096, list=2
count=0
state=001B inode=c77ebb40

Process rm (pid: 123, stackpage=c776d000)


next=, nr=294919, size=4096, list=2
count=0
state=001B inode=c77eb240

Process rm (pid: 129, stackpage=c775d000)


next=, nr=294919, size=4096, list=2
count=0
state=001B inode=c77eb0c0

Process rm (pid: 130, stackpage=c775d000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7889c60

Process mv (pid: 138, stackpage=c7985000)


next=c796fce0, nr=294916, size=4096, list=2
count=0
state=001B inode=c77eb6c0

Process rm (pid: 142, stackpage=c7721000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c75e83a0

Process update-inetd (pid: 273, stackpage=c715d000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b359a0

Process rm (pid: 305, stackpage=c6b33000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b356a0

Process rm (pid: 305, stackpage=c6b33000)


next=c6ed8980, nr=753674, size=4096, list=2
count=0
state=001B inode=c655a3a0

Process mc (pid: 330, stackpage=c6703000)


next=, nr=196617, size=4096, list=2
count=0
state=001B inode=c656c4e0

Process mc (pid: 330, stackpage=c6703000)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gnea]

On Sat, 02 Dec 2000 00:04:27 +1300, Gerard Sharp blurted forth:

> Hello.
>  [1.] One line summary of the problem:
>  Intermittent corruption of 4 bytes in SMP kernels using HPT366
[snip]
>  [7.] Environment
>  Redhat 6.2 basis.
>  Abit BP6 Motherboard.
>  Dual Celeron 466's
>  128 Mb ram; 13.6 Gb Seagate Barracuda HDD
>  "hda: ST313620A, ATA DISK drive"
>  CD-ROM on hdd
[snip]

Have you tried updating the bios on the bp6? This solved a LOT of
problems for me, and afaik, ru is the latest... if you need a hand with
it, i've put together a dos boot disk with everything you'll need at:
http://garson.org/~gnea/bp6-biosupdate.img

just dd if=bp6-biosupdate.img of=/dev/fd0 and boot it, run awdflash.exe
and tell it to use bp6_ru.bin when it asks for a file... have it back
up the current bios (just in case) and reboot when ready.. you'll of
course need to go into the bios on reboot and reset everything to
defaults, then go thru and re-tweak (this is the proper method.. not
doing so can create further problems) all of your settings until it's
satisfactorily set... also, the overclocking might be a bad thing in
this case unless you have the proper cooling for it (lm-sensors is
great for this sort of thing :) there's a neat wm applet called wmbp6
too) so u may want to try clocking it straight at 300 for awhile and
see what effect that has.. hope this helps

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

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

Re: HOW-DO-I: Diagnosing hardware problems

[Gnea]

On Thu, 30 Nov 2000 10:12:34 -0500, Buddha Buck blurted forth:

> Hi,
[snip]
>  When this first started (under 2.4.0pre10), I was getting oopses, showing 
>  the system was dying in wake_up, while trying to schedule during an 
>  interrupt (I think that's what the oops said).  Some oopses would be 
>  logged, and not kill the system, others would kill the system, and not be 
>  logged.  When I downgraded to 2.2.17+ide, I stopped getting oopses, and the 
>  lockups stopped, for a while.  Now the system (under both 2.2.18 and 
>  2.4.0pre11) lockups but doesn't oops, not even to the console.
[snip]

sounds like a bad CPU fan, take the cover off of the computer and start
it up, observe how fast the fan on the CPU is running. if it's not
running at all, that's your problem. turn the computer off and do not
start it again until you've replaced it, you can seriously burn stuff
out if it continues to run like that.  also, is there a lot of clutter
in the case? wires everywhere? u may want to consider getting some
twist-ties or rubber bands or whatever and using them to clean up the
mess to allow proper ventilation of the system and get heat out of
there... this sounds like the most logical problem/solution to me, but
of course i could be wrong.. give this a go and see what happens.

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

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

Re: multiprocessor kernel problem

[Johan Kullstam]

Roger Crandell <[EMAIL PROTECTED]> writes:

> I should have mentioned this is a 4 processor machine with a 64 bit
> buss.

perhaps the netfilter stuff isn't 4-way SMP safe.  my quad ppro box
seizes with iptables too.  however, many people report it working with
2-way SMP boxen.

has anyone gotten netfilter/iptables to work on a SMP box with more
than 2 processors?

i recall old 2.0.x kernels deadlocking on a 4-way
until x=35 or so.  maybe this is somehow similar.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Configuring synchronous interfaces in Linux

[Donald Becker]

On Fri, 1 Dec 2000, Francois Romieu wrote:

> Russell King <[EMAIL PROTECTED]> écrit :
> [...]
> > We already have a standard interface for this, but many drivers do not
> > support it.  Its called "ifconfig eth0 media xxx":

Uhmmm, it's not a standard if "many drivers do not support it".

It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.

Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.

I'll start you out: the possible 100baseTx configurations for the 3c59x
driver are SYM transceiver, MII transceiver, and "NWay" transceiver.  The
latter two may use autonegotiation, only speed autosensing, or a fixed
speed.  The SYM transceiver version can do static speed sensing.

[[ Note static speed sensing on the 3c595 is potentially evil.  The chip
must generate 100baseTx link beat while checking for 100baseTx link beat.
This commonly hoses a 10baseT repeater with constant collisions.  So does
"auto speed" mean "check for 100baseTx link beat, even though I sense
10baseT" or "do the safe thing and stick with 10baseT". ]]

> Ok. Hmmm... If I want to do something like 
> 'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or 
> ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to 
> distinguish Ethernet and synchrone interface based on interface.type,
> right ?

Correct.  And just speed isn't good enough for Ethernet.  We have 1/10HPNA,
100base-Fx,Tx,T4.

We should not just give up.
My point is that the issue isn't a trivial one.
Media selection code is the most time consuming and error prone code in many
drivers.  I would have avoiding doing that work if there had been an easy
answer.

Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

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

Re: multiprocessor kernel problem

[Johan Kullstam]

Roger Crandell <[EMAIL PROTECTED]> writes:

> I have 2.4.0  test 10 and test 11 installed on a multiprocessor (Intel)
> machine.  I have tried both test versions of the kernel.  I configured
> the kernel for single
> and multi processor.  When I boot single processor, iptables will run
> fine.  When I boot the machine with the multiprocessor kernel and run
> iptables, the kernel dumps several pages of hex and the final two lines
> of output are:
> 
> Killing interrupt handler
> scheduling in interrupt
> 
> The kernel logs nothing and you must reset the machine to bring it back
> up.  I believe this is a kernel issue rather than an iptables
> issue.
> 
> Does anyone have experience with iptables on a multiprocessor
> machine?

i tried it about a month back with -test11.  my quad ppro simply
locked up and died when i issued "iptables -nL".  i got no logs just a
freeze.  perhaps only my keyboard mouse and NIC died and the rest of
the machine kept on running.  i posted a couple of times to the
netfilter mailing list but got zero response.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] livelock in elevator scheduling

[Jens Axboe]

On Fri, Dec 01 2000, Russell Cattelan wrote:
> > If performance is down, then that problem is most likely elsewhere.
> > I/O limited benchmarking typically thrives on lots of request
> > latency -- with that comes better throughput for individual threads.
> >
> > > Anyway, I'll try your patch.
> 
> Well this patch does help with the request starvation problem.
> Unfortunately it has introduced another problem.
> Running 4 doio programs, on and XFS partion with KIO buf IO turned on.

This looks like a generic aic7xxx problem, and not block related. Since
you are doing such nice traces, what is the other CPU doing? CPU1
seems to be stuck grabbing the io_request_lock (for reasons not entirely
clear from reading the aic7xxx source...)

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

Re: corruption

[Petr Vandrovec]

Andrew Morton wrote:
> Andrew Morton wrote:
> > 
> > actual assertion in destroy_inode() which is a little bogus.
> > 
> > But the wierd thing is that this BUG only hit a single time,
> > after three hours of intensive testing.  If my theory is
> > right, the BUG should hit every time.   Will investigate further...
> > 
> 
> It appears that this problem is not fixed.
> 
> My destroy_inode() is now
> 
> static void destroy_inode(struct inode *inode)
> {
> if (!list_empty(>i_dirty_buffers)) {
> printk(">i_dirty_buffers=0x%p\n", >i_dirty_buffers);
> printk("next=0x%p\n", inode->i_dirty_buffers.next);
> printk("prev=0x%p\n", inode->i_dirty_buffers.prev);
> BUG();
> }
> kmem_cache_free(inode_cachep, (inode));
> }

I used do { if (inode_has_buffers(inode)) { printstate(); } kmem_cache_free } 
while (0)

and machine complained very loudly during boot...

> This is 2.4.0-test11-pre3 + list_del patch + sct's inode
> patch (buffer.c, inode.c).  x86 dual processor.  gcc 2.91.66.
> I rediffed my tree.  No rogue patches.

test12-pre3, NULL in list_del, destroy_inode as above, UP, 2.95.2

So I thought that adding fsync_inode_buffers() added into iput() just below
atomic_dec_and_lock(>i_count...) would be good idea. It is not, bug
was still trigerred. So there are oopses... I removed disassembled code,
as it is same for all oopses (as my printstate dumps itself).

Before fsync_inode_buffers() it was almost same, there were also traces
through sys_close() in additon to this. But maybe that I just did not
trigger this code path during testing.

I think that buffer_insert_inode_queue and __remove_inode_queue should
also do iget() and iput(), but maybe I'm wrong.

And I have no idea why fsync_inode_buffers() does not work. I thought that
inode should not have any buffers attached after this function returns if 
inode use count was zero... Maybe it is a bit complicated when inode
is going to cease...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]


ksymoops 2.3.4 on i686 2.4.0-test9-smp.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -k none (specified)
 -l none (specified)
 -o /lib/modules/2.4.0-test12-pre3-smp/ (specified)
 -m /boot/System.map (specified)

Error (regular_file): read_ksyms stat none failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0202
eax: 0001   ebx: c13fe9a0   ecx: c022ce90   edx: c13fe9b8
esi: c022f500   edi: c7d940a0   ebp: c7d69fbc   esp: c7d69f38
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 34, stackpage=c7d69000)
Stack: c7d69f3c c0140018 c01475b5 c13ffd40 c13fe9a0 c0145296 c13fe9a0 c7d68000 
    c01400b2 c13ffd40 c7d68000 08058fd0 08059930 c123d920 c13ffd40 
   c123d920 c7d12000 c7f45000 c123d920 c7f7b8c0 c7d12005 0004 0006a272 
Call Trace: [] [] [] [] [] 
Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 a9 fe ff ff 83 c4 

>>EIP; c010b9b5<=
Trace; c0140018 
Trace; c01475b5 
Trace; c0145296 
Trace; c01400b2 
Trace; c010b513 
Code;  c010b9b5 
 <_EIP>:
Code;  c010b9b5<=
   0:   50push   %eax   <=
Code;  c010b9b6 
   1:   1epush   %ds
Code;  c010b9b7 
   2:   06push   %es
Code;  c010b9b8 
   3:   50push   %eax
Code;  c010b9b9 
   4:   55push   %ebp
Code;  c010b9ba 
   5:   57push   %edi
Code;  c010b9bb 
   6:   56push   %esi
Code;  c010b9bc 
   7:   52push   %edx
Code;  c010b9bd 
   8:   51push   %ecx
Code;  c010b9be 
   9:   53push   %ebx
Code;  c010b9bf 
   a:   89 e0 mov%esp,%eax
Code;  c010b9c1 
   c:   50push   %eax
Code;  c010b9c2 
   d:   e8 a9 fe ff ffcall   febb <_EIP+0xfebb> c010b870 

Code;  c010b9c7 
  12:   83 c4 00  add$0x0,%esp

CPU:0
EIP:0010:[]
EFLAGS: 0202
eax: 0001   ebx: c7c5cb40   ecx: c022ce90   edx: c7c5cb58
esi: c022f500   edi: c7f3d4e0   ebp: c132a460   esp: c7d69f4c
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 34, stackpage=c7d69000)
Stack: c7d69f50 c0140018 c01475b5 c132a460 c7c5cb40 c0145df8 c7c5cb40 c7d68000 
    c013f110 c132a460 c132a460 c132a460 c7f45000 c7d69fa4 c013f1e7 
   c7f3d4e0 c132a460 c7d68000 08058fd0 08059930 bb8c c123d920 c7f7b8c0 
Call Trace: [] [] [] [] [] 
[] 
Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 a9 fe ff ff 83 c4 

>>EIP; c010b9b5<=
Trace; c0140018 
Trace; c01475b5 
Trace; c0145df8 
Trace; c013f110 
Trace; c013f1e7 
Trace; c010b513 
Code;  c010b9b5 

libc load error

[mike]

All,

Anyone know what causes an error like this:

init: error while loading shared libraries: init: 
symbol __ctype_h, version GLIBC_2.0 not defined in 
file libc.so.6 with link time reference

Booted a 2.2.18pre16 box and it failed to come back
up throwing that message after the unused kernel space
was freed.

Any information is appreciated.

-- 
___
Thanks,
Mike Elmore
[EMAIL PROTECTED]

"The more you complain, the longer God makes 
you live."
-unknown

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

On 1 Dec 2000, H. Peter Anvin wrote:
> > +/* symbolic names for some interesting MSRs */
> > +#define IA32_PLATFORM_ID   0x17
> > +#define IA32_UCODE_WRITE   0x79
> > +#define IA32_UCODE_REV 0x8B
> > 
> 
> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the preferred prefix in existing locations in the Linux
> kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
> are standard symbolic names for most MSRs in volume 3 of the Intel
> processor manuals; I would suggest we use those.
  ~~~

which is exactly what I did. The old name for 0x17 was something like
BBL_CR_OVRD which had absolutely no meaning (or no meaning that I could
discern) so in the past I use just the number 0x17. Now (see P4 manuals,
already on developer.intel.com) they renamed to a very meaningful
IA32_PLATFORM_ID so I used that one. It is more important to match the
naming of the original specs than to be consistent with other naming used
in the kernel. To prove this point I suggest you look at NFSv2/NFSv3
naming used in the Linux kernel -- it matches rfc1094/rfc1813 which I
liked very much because it simplified reading kernel code (I assume
everyone first studies the specs and then reads Linux implementation).

Now that was about 0x17. As for 0x79 and 0x8B I made up my own names using
the Intel's one for 0x17 as a guideline. So they "look just like" as if
they were from the manual too ;) (and they are meaningful, which is a
bonus)

I am also glad Alan agrees with me.

Regards,
Tigran

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Alan Cox]

> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the preferred prefix in existing locations in the Linux
> kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there

I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)


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

Re: Transmeta and Linux-2.4.0-test12-pre3

[Alan Cox]

> Anyway, I do have this machine working now, although not everything is
> to my liking.  Unlike older picture-books, for example, this one has a
> WinModem.  Ugh.  And the sound chip is supported, but only by the ALSA
> driver (the OSS version is too broken to be used). 

The OSS ymf_sb legacy driver doesn't work on the Vaio, it seems they didnt
wire it to do the sideband crap. The newer ymf driver (the experimental one)
Pete Zaitcev did should. I'll submit that from 2.2.18pre to 2.4 at some point

> But the camera is cool, and works beautifully (once you get XFree86
> happy) thanks to Andrew Tridgell.  (If I could just coax the X server
> into giving my a YUV overlay I could play DVD's with this thing). 

Start at http://www.core.binghamton.edu/~insomnia/gatos/

Enjoy 8)

Alan

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

Re: ext2 directory size bug (?)

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 02.12.00 in 
<[EMAIL PROTECTED]>:

> On Sat, 2 Dec 2000, Chris Wedgwood wrote:
>
> > On Sat, Dec 02, 2000 at 12:14:34AM -0500, Alexander Viro wrote:
> >
> > Not really. Anything that modifies directories holds both ->i_sem and
> > ->i_zombie, lookups hold ->i_sem and emptiness checks (i.e. victim in
> > rmdir and overwriting rename) hold ->i_zombie, readdir holds both.
> >
> > what performance issues does this raise in the cast of a directory
> > with _many_ files in it -- when we are renaming often involving that
> > directory?
> >
> > I ask this because certain MTAs do just that; and when you have
> > 10,000 to 100,000 messages queued I immagine you might spend much of
> > your time waiting for ->i_sem locks?
>
> And where do you get contending processes? 'Cause it takes at least two
> to get that...

More than one queue worker running, for example. On systems with that much  
mail, that's just about essential to have.

But I suspect scanning the directory is much worse than renaming. Scanning  
long ext2 (or traditional Unix, for that matter) directories gets *really*  
ugly. That's why Exim, for example, has the "split spool directory" code  
(works very similar to the traditional terminfo split).

> When you have that size of message queues your best bet is to split them
> into many directories, though - all FFS derivatives do linear searches, so
> locking or not, you are going to lose.

Exactly.

> > ext2 directories seem somewhat susepctable to corruption on badly
> > timed shutdowns anyhow; and I don't think there is any way to do
> > atomic writes to them with most disk hardware is there?

I don't think I've seen that. Possibly if you're doing massive directory  
creation just at that moment (unpacking a kernel source tarball, say), but  
in that case I'd call it expected on a non-journalling fs.

If anything, I've seen chopped-up regular files (usually stuff like spool  
files the MTA was just messing around with).

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

Re: why volatile on vgacon.c?

[Jeff Garzik]

On Wed, 29 Nov 2000, Andries Brouwer wrote:
> On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote:
> > That was on 2.2 series, but since I moved it to 2.4 series I don't have that
> > cga card found anymore. I have looked on the kernel code and followed it to
> > the __init function in vgacon.c, more concretely this piece of code...

> > scr_writew(0xAA55, p);
> > scr_writew(0x55AA, p + 1);
> > if (scr_readw(p) != 0xAA55 || scr_readw(p + 1) != 0x55AA) {

> > Well, the thing is that this code and the code in this function is almost
> > the same in 2.4 as in 2.2, however reading returns the written values on 2.2
> > and different ones (0x) on 2.4

> Probably without the volatile the compiler optimizes the entire
> if statement away because it very well knows that it just wrote
> these values there.  With the volatile it has to check, and finds
> that there is nothing there.

hmmm.  That's why barriers exist, right?

Jeff



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

Re: /dev/random probs in 2.4test(12-pre3)

[Matthew Kirkwood]

On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote:

> > open("/dev/random", O_RDONLY)   = 3
> > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
> > close(3)= 0

> I've seen that happen with kernel version 2.2.16!

Indeed, you are correct.  Is vpnd broken then, for assuming
that it can gather the required randomness in one read?

Matthew.

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

Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]

[Ion Badulescu]

On 1 Dec 2000 21:09:25 -0800, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> Even then XFree86 does something bad with DPMS, and will lock up the
> graphics chipset when it tries to shut down the flat panel display. 
> Solution: don't enable DPMS is XF86Config.  That's an XFree86 problem,
> but happily easily worked around. 

If it's the same bug that locks up the ATI chipset on my Dell laptop,
then you can safely enable DPMS if only enable the standby mode,
not the others (suspend and off). The panel gets turned off anyway,
even in standby.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: rocketport pci question... it stopped working after 250 days uptime

[Federico Grau]

Ok, 

I have another box which has had the same failure (rocketport serial ports
stoped working after 248 days and 16 hours).  I have about 2 more hours before
I need to reboot the box and get it back into production.

I have both a working and non-working example, where I have re-compiled and
re-loaded the rocketport module with the debugging info turned on.


On my working example:
# when I load the module the init function gets called
int rp_init(void)   

# when I cat from the tty device the open function gets called
static int rp_open(struct tty_struct *tty, struct file * filp) #

# then somehow automagically the rp_handle_port() gets called by
# rp_do_poll()... and data gets read
void rp_handle_port(struct r_port *info)
static void rp_do_poll(void)

On my non-working example:
# the init and the open seem to hapen fine, however the rp_do_poll() never
# gets called?!


I see that in rp_init(), rp_do_poll() gets saved to a "structure" called
"timer_table[COMTROL_TIMER].fn = rp_do_poll;", however I have yet to find what
that is.


Where else could I look to find the problem?

I am working with kernel 2.2.14 (/usr/src/linux/drivers/char/rocket.c), which
except for two lines is the same in 2.2.17.  I am not yet subscribed to the
kernel list, so please cc responses to me.

Thanks,
donfede

On Thu, Nov 30, 2000 at 03:27:49AM +, Alan Cox wrote:
> > These three boxes had similar uptimes (since their last kernel rebuild); 249
> > days, 248 days, 250 days.  Comparing the logs of each box, we saw that each
> > box's rocketport stopped working after aproximately 248 days 16 hours uptime.
> > So, my questions are:
> >  - has anyone heard of such a bug before?
> 
> Yes. Someone is doing signed maths on time stamps (2^31 1/100th of a second)
> 
> Ted ?
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: 240t12p3: Reproducable Oops

[Burton Windle]

[1.] One line summary of the problem:
PROBLEM: 240t12p3: Reproducable oops involving ping

[2.] Full description of the problem/report:
While teaching myself Perl, I've either demonstrated a compiler error, or
appear to have found a way to make the 2.4.0-test12-pre3 kernel oops
reproducably many times.  Perhaps the kernel is just scared of my poor
Perl, but something doesn't like it. I was originally trying to see what a
full arpcache would like like, but then was having fun annoying my
roommates with ping storms when my die got more annoyed.

[3.] Keywords (i.e., modules, networking, kernel):
2.4.0-test12-pre3 oops ping

[4.] Kernel version (from /proc/version):
Linux version 2.4.0-test12-pre3 (root@toy) (gcc version 2.95.2 2220
(Debian GNU/Linux)) #1 Wed Nov 29 11:53:59 EST 2000


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)
Note: the oops happens many many times in a row, so much that it fills my
dmesg. This is the first entire oops that I can see, but all the ones
after this look very very similar.

ksymoops 2.3.4 on i586 2.4.0-test12-pre3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test12-pre3/ (default)
 -m /usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address cc012078
c0125ef0
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010803
eax: 0218   ebx: c11ffc14   ecx: 44012720   edx: c4012000
esi: 0246   edi: 0007   ebp: c1d15d40   esp: c4adff38
ds: 0018   es: 0018   ss: 0018
Process manyping.pl (pid: 478, stackpage=c4adf000)
Stack: c450a000 fff4 c21ff620 c01162e6 c11ffc14 0007 c4ade000
080fa490
   0004 c4adffbc c21ff620 c4adff94  c4ade000 c4c23920
c21ff62c
   fff4 fff4    c4adffa0 c4adffa0

Call Trace: [] [] []
Code: 8b 44 82 18 89 42 14 83 f8 ff 75 05 8b 02 89 43 08 56 9d 89

>>EIP; c0125ef0<=
Trace; c01162e6 
Trace; c010944f 
Trace; c010aa03 
Code;  c0125ef0 
 <_EIP>:
Code;  c0125ef0<=
   0:   8b 44 82 18   mov0x18(%edx,%eax,4),%eax   <=
Code;  c0125ef4 
   4:   89 42 14  mov%eax,0x14(%edx)
Code;  c0125ef7 
   7:   83 f8 ff  cmp$0x,%eax
Code;  c0125efa 
   a:   75 05 jne11 <_EIP+0x11> c0125f01 

Code;  c0125efc 
   c:   8b 02 mov(%edx),%eax
Code;  c0125efe 
   e:   89 43 08  mov%eax,0x8(%ebx)
Code;  c0125f01 
  11:   56push   %esi
Code;  c0125f02 
  12:   9dpopf   
Code;  c0125f03 
  13:   89 00 mov%eax,(%eax)


[6.] A small shell script or example program which triggers the
 problem (if possible)
swapoff -a
cat manyping.pl
#!/usr/bin/perl -w

@ip = (1 .. 255);
foreach (@ip) {
system("ping -c 40 -s 5000 192.168.0.$_ &");
}

I was backgrounding the above program (./manyping.pl &), and running it
with several (15?) instances at the same time.

[7.] Environment
This is an up-to-date Debian Woody system.

[7.1.] Software (add the output of the ver_linux script here)
Linux toy 2.4.0-test12-pre3 #1 Wed Nov 29 11:53:59 EST 2000 i586 unknown
Kernel modules 2.3.21
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.10.1.0.2
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount  2.10q
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0i
Modules Loaded rtc es1371 ac97_codec ne 8390

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 400.901
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 799.54

[7.3.] Module information (from /proc/modules):
rtc 5280   0 (autoclean)
es1371 24400   0
ac97_codec  7504   0 [es1371]
ne  6352   1
83906064   0 [ne]

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
toy:~# cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0280-029f : eth0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0cf8-0cff : PCI conf1
5c20-5c3f : PCI device 

PROBLEM: 240t12p3: Reproducable Oops

[Burton Windle]

[1.] One line summary of the problem:
PROBLEM: 240t12p3: Reproducable oops involving ping

[2.] Full description of the problem/report:
While teaching myself Perl, I've either demonstrated a compiler error, or
appear to have found a way to make the 2.4.0-test12-pre3 kernel oops
reproducably many times.  Perhaps the kernel is just scared of my poor
Perl, but something doesn't like it. I was originally trying to see what a
full arpcache would like like, but then was having fun annoying my
roommates with ping storms when my die got more annoyed.

[3.] Keywords (i.e., modules, networking, kernel):
2.4.0-test12-pre3 oops ping

[4.] Kernel version (from /proc/version):
Linux version 2.4.0-test12-pre3 (root@toy) (gcc version 2.95.2 2220
(Debian GNU/Linux)) #1 Wed Nov 29 11:53:59 EST 2000


[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)
Note: the oops happens many many times in a row, so much that it fills my
dmesg. This is the first entire oops that I can see, but all the ones
after this look very very similar.

ksymoops 2.3.4 on i586 2.4.0-test12-pre3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test12-pre3/ (default)
 -m /usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address cc012078
c0125ef0
*pde = 
Oops: 
CPU:0
EIP:0010:[c0125ef0]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010803
eax: 0218   ebx: c11ffc14   ecx: 44012720   edx: c4012000
esi: 0246   edi: 0007   ebp: c1d15d40   esp: c4adff38
ds: 0018   es: 0018   ss: 0018
Process manyping.pl (pid: 478, stackpage=c4adf000)
Stack: c450a000 fff4 c21ff620 c01162e6 c11ffc14 0007 c4ade000
080fa490
   0004 c4adffbc c21ff620 c4adff94  c4ade000 c4c23920
c21ff62c
   fff4 fff4    c4adffa0 c4adffa0

Call Trace: [c01162e6] [c010944f] [c010aa03]
Code: 8b 44 82 18 89 42 14 83 f8 ff 75 05 8b 02 89 43 08 56 9d 89

EIP; c0125ef0 kmem_cache_alloc+24/54   =
Trace; c01162e6 do_fork+5be/940
Trace; c010944f sys_fork+13/18
Trace; c010aa03 system_call+33/40
Code;  c0125ef0 kmem_cache_alloc+24/54
 _EIP:
Code;  c0125ef0 kmem_cache_alloc+24/54   =
   0:   8b 44 82 18   mov0x18(%edx,%eax,4),%eax   =
Code;  c0125ef4 kmem_cache_alloc+28/54
   4:   89 42 14  mov%eax,0x14(%edx)
Code;  c0125ef7 kmem_cache_alloc+2b/54
   7:   83 f8 ff  cmp$0x,%eax
Code;  c0125efa kmem_cache_alloc+2e/54
   a:   75 05 jne11 _EIP+0x11 c0125f01 
kmem_cache_alloc+35/54
Code;  c0125efc kmem_cache_alloc+30/54
   c:   8b 02 mov(%edx),%eax
Code;  c0125efe kmem_cache_alloc+32/54
   e:   89 43 08  mov%eax,0x8(%ebx)
Code;  c0125f01 kmem_cache_alloc+35/54
  11:   56push   %esi
Code;  c0125f02 kmem_cache_alloc+36/54
  12:   9dpopf   
Code;  c0125f03 kmem_cache_alloc+37/54
  13:   89 00 mov%eax,(%eax)


[6.] A small shell script or example program which triggers the
 problem (if possible)
swapoff -a
cat manyping.pl
#!/usr/bin/perl -w

@ip = (1 .. 255);
foreach (@ip) {
system("ping -c 40 -s 5000 192.168.0.$_ ");
}

I was backgrounding the above program (./manyping.pl ), and running it
with several (15?) instances at the same time.

[7.] Environment
This is an up-to-date Debian Woody system.

[7.1.] Software (add the output of the ver_linux script here)
Linux toy 2.4.0-test12-pre3 #1 Wed Nov 29 11:53:59 EST 2000 i586 unknown
Kernel modules 2.3.21
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.10.1.0.2
Linux C Library libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount  2.10q
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0i
Modules Loaded rtc es1371 ac97_codec ne 8390

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 400.901
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
features: fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 799.54

[7.3.] Module information (from /proc/modules):
rtc 5280   0 (autoclean)
es1371 24400   0
ac97_codec  7504   0 [es1371]
ne  6352   1
83906064   0 [ne]

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
toy:~# cat /proc/ioports
-001f : 

Re: rocketport pci question... it stopped working after 250 days uptime

[Federico Grau]

Ok, 

I have another box which has had the same failure (rocketport serial ports
stoped working after 248 days and 16 hours).  I have about 2 more hours before
I need to reboot the box and get it back into production.

I have both a working and non-working example, where I have re-compiled and
re-loaded the rocketport module with the debugging info turned on.


On my working example:
# when I load the module the init function gets called
int rp_init(void)   

# when I cat from the tty device the open function gets called
static int rp_open(struct tty_struct *tty, struct file * filp) #

# then somehow automagically the rp_handle_port() gets called by
# rp_do_poll()... and data gets read
void rp_handle_port(struct r_port *info)
static void rp_do_poll(void)

On my non-working example:
# the init and the open seem to hapen fine, however the rp_do_poll() never
# gets called?!


I see that in rp_init(), rp_do_poll() gets saved to a "structure" called
"timer_table[COMTROL_TIMER].fn = rp_do_poll;", however I have yet to find what
that is.


Where else could I look to find the problem?

I am working with kernel 2.2.14 (/usr/src/linux/drivers/char/rocket.c), which
except for two lines is the same in 2.2.17.  I am not yet subscribed to the
kernel list, so please cc responses to me.

Thanks,
donfede

On Thu, Nov 30, 2000 at 03:27:49AM +, Alan Cox wrote:
  These three boxes had similar uptimes (since their last kernel rebuild); 249
  days, 248 days, 250 days.  Comparing the logs of each box, we saw that each
  box's rocketport stopped working after aproximately 248 days 16 hours uptime.
  So, my questions are:
   - has anyone heard of such a bug before?
 
 Yes. Someone is doing signed maths on time stamps (2^31 1/100th of a second)
 
 Ted ?
 
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]

[Ion Badulescu]

On 1 Dec 2000 21:09:25 -0800, Linus Torvalds [EMAIL PROTECTED] wrote:

 Even then XFree86 does something bad with DPMS, and will lock up the
 graphics chipset when it tries to shut down the flat panel display. 
 Solution: don't enable DPMS is XF86Config.  That's an XFree86 problem,
 but happily easily worked around. 

If it's the same bug that locks up the ATI chipset on my Dell laptop,
then you can safely enable DPMS if only enable the standby mode,
not the others (suspend and off). The panel gets turned off anyway,
even in standby.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: /dev/random probs in 2.4test(12-pre3)

[Matthew Kirkwood]

On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote:

  open("/dev/random", O_RDONLY)   = 3
  read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
  close(3)= 0

 I've seen that happen with kernel version 2.2.16!

Indeed, you are correct.  Is vpnd broken then, for assuming
that it can gather the required randomness in one read?

Matthew.

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

Re: why volatile on vgacon.c?

[Jeff Garzik]

On Wed, 29 Nov 2000, Andries Brouwer wrote:
 On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote:
  That was on 2.2 series, but since I moved it to 2.4 series I don't have that
  cga card found anymore. I have looked on the kernel code and followed it to
  the __init function in vgacon.c, more concretely this piece of code...

  scr_writew(0xAA55, p);
  scr_writew(0x55AA, p + 1);
  if (scr_readw(p) != 0xAA55 || scr_readw(p + 1) != 0x55AA) {

  Well, the thing is that this code and the code in this function is almost
  the same in 2.4 as in 2.2, however reading returns the written values on 2.2
  and different ones (0x) on 2.4

 Probably without the volatile the compiler optimizes the entire
 if statement away because it very well knows that it just wrote
 these values there.  With the volatile it has to check, and finds
 that there is nothing there.

hmmm.  That's why barriers exist, right?

Jeff



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

Re: ext2 directory size bug (?)

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 02.12.00 in 
[EMAIL PROTECTED]:

 On Sat, 2 Dec 2000, Chris Wedgwood wrote:

  On Sat, Dec 02, 2000 at 12:14:34AM -0500, Alexander Viro wrote:
 
  Not really. Anything that modifies directories holds both -i_sem and
  -i_zombie, lookups hold -i_sem and emptiness checks (i.e. victim in
  rmdir and overwriting rename) hold -i_zombie, readdir holds both.
 
  what performance issues does this raise in the cast of a directory
  with _many_ files in it -- when we are renaming often involving that
  directory?
 
  I ask this because certain MTAs do just that; and when you have
  10,000 to 100,000 messages queued I immagine you might spend much of
  your time waiting for -i_sem locks?

 And where do you get contending processes? 'Cause it takes at least two
 to get that...

More than one queue worker running, for example. On systems with that much  
mail, that's just about essential to have.

But I suspect scanning the directory is much worse than renaming. Scanning  
long ext2 (or traditional Unix, for that matter) directories gets *really*  
ugly. That's why Exim, for example, has the "split spool directory" code  
(works very similar to the traditional terminfo split).

 When you have that size of message queues your best bet is to split them
 into many directories, though - all FFS derivatives do linear searches, so
 locking or not, you are going to lose.

Exactly.

  ext2 directories seem somewhat susepctable to corruption on badly
  timed shutdowns anyhow; and I don't think there is any way to do
  atomic writes to them with most disk hardware is there?

I don't think I've seen that. Possibly if you're doing massive directory  
creation just at that moment (unpacking a kernel source tarball, say), but  
in that case I'd call it expected on a non-journalling fs.

If anything, I've seen chopped-up regular files (usually stuff like spool  
files the MTA was just messing around with).

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

Re: Transmeta and Linux-2.4.0-test12-pre3

[Alan Cox]

 Anyway, I do have this machine working now, although not everything is
 to my liking.  Unlike older picture-books, for example, this one has a
 WinModem.  Ugh.  And the sound chip is supported, but only by the ALSA
 driver (the OSS version is too broken to be used). 

The OSS ymf_sb legacy driver doesn't work on the Vaio, it seems they didnt
wire it to do the sideband crap. The newer ymf driver (the experimental one)
Pete Zaitcev did should. I'll submit that from 2.2.18pre to 2.4 at some point

 But the camera is cool, and works beautifully (once you get XFree86
 happy) thanks to Andrew Tridgell.  (If I could just coax the X server
 into giving my a YUV overlay I could play DVD's with this thing). 

Start at http://www.core.binghamton.edu/~insomnia/gatos/

Enjoy 8)

Alan

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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Alan Cox]

 Please call these MSR_* instead, "IA32_*" isn't very descriptive,
 besides, the preferred prefix in existing locations in the Linux
 kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there

I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)


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

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

On 1 Dec 2000, H. Peter Anvin wrote:
  +/* symbolic names for some interesting MSRs */
  +#define IA32_PLATFORM_ID   0x17
  +#define IA32_UCODE_WRITE   0x79
  +#define IA32_UCODE_REV 0x8B
  
 
 Please call these MSR_* instead, "IA32_*" isn't very descriptive,
 besides, the preferred prefix in existing locations in the Linux
 kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
 are standard symbolic names for most MSRs in volume 3 of the Intel
 processor manuals; I would suggest we use those.
  ~~~

which is exactly what I did. The old name for 0x17 was something like
BBL_CR_OVRD which had absolutely no meaning (or no meaning that I could
discern) so in the past I use just the number 0x17. Now (see P4 manuals,
already on developer.intel.com) they renamed to a very meaningful
IA32_PLATFORM_ID so I used that one. It is more important to match the
naming of the original specs than to be consistent with other naming used
in the kernel. To prove this point I suggest you look at NFSv2/NFSv3
naming used in the Linux kernel -- it matches rfc1094/rfc1813 which I
liked very much because it simplified reading kernel code (I assume
everyone first studies the specs and then reads Linux implementation).

Now that was about 0x17. As for 0x79 and 0x8B I made up my own names using
the Intel's one for 0x17 as a guideline. So they "look just like" as if
they were from the manual too ;) (and they are meaningful, which is a
bonus)

I am also glad Alan agrees with me.

Regards,
Tigran

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

libc load error

[mike]

All,

Anyone know what causes an error like this:

init: error while loading shared libraries: init: 
symbol __ctype_h, version GLIBC_2.0 not defined in 
file libc.so.6 with link time reference

Booted a 2.2.18pre16 box and it failed to come back
up throwing that message after the unused kernel space
was freed.

Any information is appreciated.

-- 
___
Thanks,
Mike Elmore
[EMAIL PROTECTED]

"The more you complain, the longer God makes 
you live."
-unknown

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

Re: corruption

[Petr Vandrovec]

Andrew Morton wrote:
 Andrew Morton wrote:
  
  actual assertion in destroy_inode() which is a little bogus.
  
  But the wierd thing is that this BUG only hit a single time,
  after three hours of intensive testing.  If my theory is
  right, the BUG should hit every time.   Will investigate further...
  
 
 It appears that this problem is not fixed.
 
 My destroy_inode() is now
 
 static void destroy_inode(struct inode *inode)
 {
 if (!list_empty(inode-i_dirty_buffers)) {
 printk("inode-i_dirty_buffers=0x%p\n", inode-i_dirty_buffers);
 printk("next=0x%p\n", inode-i_dirty_buffers.next);
 printk("prev=0x%p\n", inode-i_dirty_buffers.prev);
 BUG();
 }
 kmem_cache_free(inode_cachep, (inode));
 }

I used do { if (inode_has_buffers(inode)) { printstate(); } kmem_cache_free } 
while (0)

and machine complained very loudly during boot...

 This is 2.4.0-test11-pre3 + list_del patch + sct's inode
 patch (buffer.c, inode.c).  x86 dual processor.  gcc 2.91.66.
 I rediffed my tree.  No rogue patches.

test12-pre3, NULL in list_del, destroy_inode as above, UP, 2.95.2

So I thought that adding fsync_inode_buffers() added into iput() just below
atomic_dec_and_lock(inode-i_count...) would be good idea. It is not, bug
was still trigerred. So there are oopses... I removed disassembled code,
as it is same for all oopses (as my printstate dumps itself).

Before fsync_inode_buffers() it was almost same, there were also traces
through sys_close() in additon to this. But maybe that I just did not
trigger this code path during testing.

I think that buffer_insert_inode_queue and __remove_inode_queue should
also do iget() and iput(), but maybe I'm wrong.

And I have no idea why fsync_inode_buffers() does not work. I thought that
inode should not have any buffers attached after this function returns if 
inode use count was zero... Maybe it is a bit complicated when inode
is going to cease...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]


ksymoops 2.3.4 on i686 2.4.0-test9-smp.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -k none (specified)
 -l none (specified)
 -o /lib/modules/2.4.0-test12-pre3-smp/ (specified)
 -m /boot/System.map (specified)

Error (regular_file): read_ksyms stat none failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
CPU:0
EIP:0010:[c010b9b5]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0202
eax: 0001   ebx: c13fe9a0   ecx: c022ce90   edx: c13fe9b8
esi: c022f500   edi: c7d940a0   ebp: c7d69fbc   esp: c7d69f38
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 34, stackpage=c7d69000)
Stack: c7d69f3c c0140018 c01475b5 c13ffd40 c13fe9a0 c0145296 c13fe9a0 c7d68000 
    c01400b2 c13ffd40 c7d68000 08058fd0 08059930 c123d920 c13ffd40 
   c123d920 c7d12000 c7f45000 c123d920 c7f7b8c0 c7d12005 0004 0006a272 
Call Trace: [c0140018] [c01475b5] [c0145296] [c01400b2] [c010b513] 
Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 a9 fe ff ff 83 c4 

EIP; c010b9b5 printstate+9/2c   =
Trace; c0140018 sys_rename+154/270
Trace; c01475b5 iput+1a1/1b4
Trace; c0145296 dput+116/174
Trace; c01400b2 sys_rename+1ee/270
Trace; c010b513 system_call+33/38
Code;  c010b9b5 printstate+9/2c
 _EIP:
Code;  c010b9b5 printstate+9/2c   =
   0:   50push   %eax   =
Code;  c010b9b6 printstate+a/2c
   1:   1epush   %ds
Code;  c010b9b7 printstate+b/2c
   2:   06push   %es
Code;  c010b9b8 printstate+c/2c
   3:   50push   %eax
Code;  c010b9b9 printstate+d/2c
   4:   55push   %ebp
Code;  c010b9ba printstate+e/2c
   5:   57push   %edi
Code;  c010b9bb printstate+f/2c
   6:   56push   %esi
Code;  c010b9bc printstate+10/2c
   7:   52push   %edx
Code;  c010b9bd printstate+11/2c
   8:   51push   %ecx
Code;  c010b9be printstate+12/2c
   9:   53push   %ebx
Code;  c010b9bf printstate+13/2c
   a:   89 e0 mov%esp,%eax
Code;  c010b9c1 printstate+15/2c
   c:   50push   %eax
Code;  c010b9c2 printstate+16/2c
   d:   e8 a9 fe ff ffcall   febb _EIP+0xfebb c010b870 
show_registers+0/13c
Code;  c010b9c7 printstate+1b/2c
  12:   83 c4 00  add$0x0,%esp

CPU:0
EIP:0010:[c010b9b5]
EFLAGS: 0202
eax: 0001   ebx: c7c5cb40   ecx: c022ce90   edx: c7c5cb58
esi: c022f500   edi: c7f3d4e0   ebp: c132a460   esp: c7d69f4c
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 34, stackpage=c7d69000)
Stack: c7d69f50 c0140018 c01475b5 c132a460 c7c5cb40 c0145df8 c7c5cb40 c7d68000 
    c013f110 

Re: [RFC] Configuring synchronous interfaces in Linux

[Donald Becker]

On Fri, 1 Dec 2000, Francois Romieu wrote:

 Russell King [EMAIL PROTECTED] écrit :
 [...]
  We already have a standard interface for this, but many drivers do not
  support it.  Its called "ifconfig eth0 media xxx":

Uhmmm, it's not a standard if "many drivers do not support it".

It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.

Hey, I'll make it easy.  Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.

I'll start you out: the possible 100baseTx configurations for the 3c59x
driver are SYM transceiver, MII transceiver, and "NWay" transceiver.  The
latter two may use autonegotiation, only speed autosensing, or a fixed
speed.  The SYM transceiver version can do static speed sensing.

[[ Note static speed sensing on the 3c595 is potentially evil.  The chip
must generate 100baseTx link beat while checking for 100baseTx link beat.
This commonly hoses a 10baseT repeater with constant collisions.  So does
"auto speed" mean "check for 100baseTx link beat, even though I sense
10baseT" or "do the safe thing and stick with 10baseT". ]]

 Ok. Hmmm... If I want to do something like 
 'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or 
 ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to 
 distinguish Ethernet and synchrone interface based on interface.type,
 right ?

Correct.  And just speed isn't good enough for Ethernet.  We have 1/10HPNA,
100base-Fx,Tx,T4.

We should not just give up.
My point is that the issue isn't a trivial one.
Media selection code is the most time consuming and error prone code in many
drivers.  I would have avoiding doing that work if there had been an easy
answer.

Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

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

Re: multiprocessor kernel problem

[Johan Kullstam]

Roger Crandell [EMAIL PROTECTED] writes:

 I have 2.4.0  test 10 and test 11 installed on a multiprocessor (Intel)
 machine.  I have tried both test versions of the kernel.  I configured
 the kernel for single
 and multi processor.  When I boot single processor, iptables will run
 fine.  When I boot the machine with the multiprocessor kernel and run
 iptables, the kernel dumps several pages of hex and the final two lines
 of output are:
 
 Killing interrupt handler
 scheduling in interrupt
 
 The kernel logs nothing and you must reset the machine to bring it back
 up.  I believe this is a kernel issue rather than an iptables
 issue.
 
 Does anyone have experience with iptables on a multiprocessor
 machine?

i tried it about a month back with -test11.  my quad ppro simply
locked up and died when i issued "iptables -nL".  i got no logs just a
freeze.  perhaps only my keyboard mouse and NIC died and the rest of
the machine kept on running.  i posted a couple of times to the
netfilter mailing list but got zero response.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: multiprocessor kernel problem

[Johan Kullstam]

Roger Crandell [EMAIL PROTECTED] writes:

 I should have mentioned this is a 4 processor machine with a 64 bit
 buss.

perhaps the netfilter stuff isn't 4-way SMP safe.  my quad ppro box
seizes with iptables too.  however, many people report it working with
2-way SMP boxen.

has anyone gotten netfilter/iptables to work on a SMP box with more
than 2 processors?

i recall old 2.0.x kernels deadlocking on a 4-way
until x=35 or so.  maybe this is somehow similar.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gnea]

On Sat, 02 Dec 2000 00:04:27 +1300, Gerard Sharp blurted forth:

 Hello.
  [1.] One line summary of the problem:
  Intermittent corruption of 4 bytes in SMP kernels using HPT366
[snip]
  [7.] Environment
  Redhat 6.2 basis.
  Abit BP6 Motherboard.
  Dual Celeron 466's
  128 Mb ram; 13.6 Gb Seagate Barracuda HDD
  "hda: ST313620A, ATA DISK drive"
  CD-ROM on hdd
[snip]

Have you tried updating the bios on the bp6? This solved a LOT of
problems for me, and afaik, ru is the latest... if you need a hand with
it, i've put together a dos boot disk with everything you'll need at:
http://garson.org/~gnea/bp6-biosupdate.img

just dd if=bp6-biosupdate.img of=/dev/fd0 and boot it, run awdflash.exe
and tell it to use bp6_ru.bin when it asks for a file... have it back
up the current bios (just in case) and reboot when ready.. you'll of
course need to go into the bios on reboot and reset everything to
defaults, then go thru and re-tweak (this is the proper method.. not
doing so can create further problems) all of your settings until it's
satisfactorily set... also, the overclocking might be a bad thing in
this case unless you have the proper cooling for it (lm-sensors is
great for this sort of thing :) there's a neat wm applet called wmbp6
too) so u may want to try clocking it straight at 300 for awhile and
see what effect that has.. hope this helps

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

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

Re: HOW-DO-I: Diagnosing hardware problems

[Gnea]

On Thu, 30 Nov 2000 10:12:34 -0500, Buddha Buck blurted forth:

 Hi,
[snip]
  When this first started (under 2.4.0pre10), I was getting oopses, showing 
  the system was dying in wake_up, while trying to schedule during an 
  interrupt (I think that's what the oops said).  Some oopses would be 
  logged, and not kill the system, others would kill the system, and not be 
  logged.  When I downgraded to 2.2.17+ide, I stopped getting oopses, and the 
  lockups stopped, for a while.  Now the system (under both 2.2.18 and 
  2.4.0pre11) lockups but doesn't oops, not even to the console.
[snip]

sounds like a bad CPU fan, take the cover off of the computer and start
it up, observe how fast the fan on the CPU is running. if it's not
running at all, that's your problem. turn the computer off and do not
start it again until you've replaced it, you can seriously burn stuff
out if it continues to run like that.  also, is there a lot of clutter
in the case? wires everywhere? u may want to consider getting some
twist-ties or rubber bands or whatever and using them to clean up the
mess to allow proper ventilation of the system and get heat out of
there... this sounds like the most logical problem/solution to me, but
of course i could be wrong.. give this a go and see what happens.

-- 
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

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

Re: corruption

[Petr Vandrovec]

On Sat, Dec 02, 2000 at 10:33:36AM -0500, Alexander Viro wrote:
 On Sun, 3 Dec 2000, Andrew Morton wrote:
 
  It appears that this problem is not fixed.
 
 Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer().
 Add the call of remove_inode_queue(bh) there and see if it helps. I.e.
 
 ed fs/buffer.c EOF
 /unmap_buffer/
 /}/i
   remove_inode_queue(bh);
 .
 wq
 EOF
 
 Linus, could you apply that? We are leaving the unmapped buffers on the
 inode queue. I.e. every truncate_inode_pages() leaves a lot of junk around.
 Now, guess what happens when we destroy the last link to inode that nobody
 keeps open...

Nothing new (was it meant to run remove_inode_queue() conditionaly inside 
buffer_mapped() branch? ed did it that way). First is list of buffers at 
time of destroy_inode, then process. If you want full oops trace, it is 
available at http://platan.vc.cvut.cz/oops3.txt, but last part is always 
iput. For now I'm back on test9, as I lost inetd.conf again :-( Someone 
should shoot sendmail Debian maintainer... Running update-inetd at startup 
is really bad idea, as fsck then usually removes both old and new inetd.conf, 
so I'm back on inetd.conf from 25 Aug 1999 :-(((

Fields printed from buffer_head are b_next, b_blocknr, b_size, b_list,
b_count, b_state and b_inode. (oops now I see that I left
remove_inode_queue(bh) in printing loop (I copied it from
invalidate_inode_buffers()), but it should not hurt, I believe. Dirty buffers
should find its way to disk anyway, or not?)
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

BTW, running 'ksymoops  oops  oops.txt' is great source of errors below,
as it (probably) uses couple of unlinked temorary files...

next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7bf3ce0

Process mount (pid: 30, stackpage=c7df3000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7bf3ce0

Process mount (pid: 31, stackpage=c7df3000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7c1a860

Process mount (pid: 68, stackpage=c7997000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b54c80

Process mount (pid: 70, stackpage=c7997000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b54c80

Process mount (pid: 70, stackpage=c7997000)


next=, nr=3375109, size=4096, list=2
count=0
state=001B inode=c77e2260

Process rm (pid: 82, stackpage=c7b35000)


next=, nr=3506180, size=4096, list=2
count=0
state=001B inode=c77eb9c0

Process rm (pid: 121, stackpage=c776d000)

next=, nr=3506180, size=4096, list=2
count=0
state=001B inode=c77ebb40
next=, nr=3507147, size=4096, list=2
count=0
state=001B inode=c77ebb40

Process rm (pid: 122, stackpage=c776d000)


next=, nr=1179657, size=4096, list=2
count=0
state=001B inode=c77ebb40

Process rm (pid: 123, stackpage=c776d000)


next=, nr=294919, size=4096, list=2
count=0
state=001B inode=c77eb240

Process rm (pid: 129, stackpage=c775d000)


next=, nr=294919, size=4096, list=2
count=0
state=001B inode=c77eb0c0

Process rm (pid: 130, stackpage=c775d000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7889c60

Process mv (pid: 138, stackpage=c7985000)


next=c796fce0, nr=294916, size=4096, list=2
count=0
state=001B inode=c77eb6c0

Process rm (pid: 142, stackpage=c7721000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c75e83a0

Process update-inetd (pid: 273, stackpage=c715d000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b359a0

Process rm (pid: 305, stackpage=c6b33000)


next=, nr=2457654, size=4096, list=2
count=0
state=001B inode=c7b356a0

Process rm (pid: 305, stackpage=c6b33000)


next=c6ed8980, nr=753674, size=4096, list=2
count=0
state=001B inode=c655a3a0

Process mc (pid: 330, stackpage=c6703000)


next=, nr=196617, size=4096, list=2
count=0
state=001B inode=c656c4e0

Process mc (pid: 330, stackpage=c6703000)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

make oldconfig with menuconfig

[Frédéric L . W . Meunier]

What's the best way to use make oldconfig with menuconfig?
oldconfig with config isn't what will make my life easier.

TIA.

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

Re: Fasttrak100 questions...

[Pavel Machek]

Hi!

  You are wrong: If you modify the kernel you have to make it available for
  anyone who wishes to use it; that's also in the GPL. You can't add stuff
 
 No it isnt. Some people seem to think it is. You only have to provide a 
 change if you give someone the binaries concerned. Some people also think
 that 'linking' clauses mean they can just direct the customer to do the link,
 that also would appear to be untrue in legal precedent - the law cares about
 the intent.

This is currently happening with lucent winmodem driver: there's
modified version of serial.c, and customers are asked to compile it
and (staticaly-)link it against proprietary code to get usable
driver. Is that okay or not?
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Fasttrak100 questions...

[Alan Cox]

 This is currently happening with lucent winmodem driver: there's
 modified version of serial.c, and customers are asked to compile it
 and (staticaly-)link it against proprietary code to get usable
 driver. Is that okay or not?

Probably not, its up to Ted to enforce I suspect.

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

Re: corruption

[Alexander Viro]

On Sat, 2 Dec 2000, Petr Vandrovec wrote:

 Nothing new (was it meant to run remove_inode_queue() conditionaly inside 
 buffer_mapped() branch? ed did it that way). First is list of buffers at 
 time of destroy_inode, then process. If you want full oops trace, it is 

what list of buffers? -i_dirty_buffers one?

 available at http://platan.vc.cvut.cz/oops3.txt, but last part is always 
 iput. For now I'm back on test9, as I lost inetd.conf again :-( Someone 
 should shoot sendmail Debian maintainer... Running update-inetd at startup 
 is really bad idea, as fsck then usually removes both old and new inetd.conf, 
 so I'm back on inetd.conf from 25 Aug 1999 :-(((
 
 Fields printed from buffer_head are b_next, b_blocknr, b_size, b_list,
 b_count, b_state and b_inode. (oops now I see that I left
 remove_inode_queue(bh) in printing loop (I copied it from
 invalidate_inode_buffers()), but it should not hurt, I believe. Dirty buffers
 should find its way to disk anyway, or not?)

When you delete the inode? Why would they? Petr, could you send me the
diff between the variant you've run and pristine 12-pre3? I'ld really
like to see what exactly was doing the printks...

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

Re: /dev/random probs in 2.4test(12-pre3)

[Igmar Palsenberg]

 Indeed, you are correct.  Is vpnd broken then, for assuming
 that it can gather the required randomness in one read?

Yep. It assumes that if the required randommness numbers aren't met a read
to /dev/random will block.

And it's not the only program that assumes this : I also did. 

/dev/random is called a blocking random device, which more or less implies
that it will totally block. I suggest we put this somewhere in the kernel
docs, since lots of people out there assume that it totally blocks.

Means I've got to updates some sources of mine :)

 Matthew.


Igmar

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

Re: corruption

[Alexander Viro]

On Sat, 2 Dec 2000, Petr Vandrovec wrote:

[I wrote:]

  ed fs/buffer.c EOF
  /unmap_buffer/
  /}/i
spin_lock(lru_list_lock);
  remove_inode_queue(bh);
spin_unlock(lru_list_lock);
  .
  wq
  EOF

Damn. I claim the sudden idiocy attack - didn't look at the locking
rules for the -b_inode_buffers. My apologies.

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

Re: /dev/random probs in 2.4test(12-pre3)

[Jeff Garzik]

On Sat, 2 Dec 2000, Igmar Palsenberg wrote:
  Indeed, you are correct.  Is vpnd broken then, for assuming
  that it can gather the required randomness in one read?
 
 Yep. It assumes that if the required randommness numbers aren't met a read
 to /dev/random will block.
 
 And it's not the only program that assumes this : I also did. 
 
 /dev/random is called a blocking random device, which more or less implies
 that it will totally block. I suggest we put this somewhere in the kernel
 docs, since lots of people out there assume that it totally blocks.

"totally block"?

For a blocking fd, read(2) has always blocked until some data is
available.  There has never been a guarantee, for any driver, that
a read(2) will return the full amount of bytes requested.

There is no need to document this...  man read(2)  ;-)

Jeff



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

Re: [RFC] Configuring synchronous interfaces in Linux

[Jeff Garzik]

On Sun, 3 Dec 2000, Chris Wedgwood wrote:
  Russell King [EMAIL PROTECTED] écrit :
  [...]
   We already have a standard interface for this, but many drivers do not
   support it.  Its called "ifconfig eth0 media xxx":

 Actually, I starteed work on adding this to the 3c59x code last
 night; I am now a little dispondent though as it wasn't as simple as
 I first thought it might be.

Does 'ifconfig eth0 media xxx' wind up calling dev-set_config?

If yes, my guess is correct, I think the proper solution is to:
* create a generic set_config, which does nothing but convert the calls'
semantics into ethtool semantics, and
* add ethtool support to the specific driver

And you might even go so far as to create a generic MII implementation
of ethtool support, so that existing drivers can simply plug in their
mdio_{read,write} functions to automatically get full ethtool support.
(disclaimer:  this is a spur-of-the-moment thought, creating a generic
MII module for ethtool support may not be feasible)

drivers/net/sis900.c implements set_config, if you want an example..

Finally, if you want to just use ethtool directly, grab the SRPM and
install it on your system.

Jeff



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

2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

[Wolfgang Spraul]

2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the
number of sectors that can be read at once (i.e. in one track).

This routine does not work with the Sony UDF5 USB floppy disk, mapped as an
Int13 device by the Vaio C1VE (Crusoe) BIOS.
Therefore, a bzdisk floppy will not be bootable.

I solved the problem for me by changing "disksizes: .byte 36, 18, 15, 9" to
"disksizes: .byte 18, 18, 18, 18", but I think someone should do it right.
I will assist debugging if needed.

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

2.4.0-test11: hangs while Probing PCI hardware for Sony Vaio C1VE (Crusoe)

[Wolfgang Spraul]

PhoenixBIOS, Sony Vaio C1VE

I did some printk() debugging, but the kernel hangs at various places in
pci_setup_device(), mostly in pci_read_bases().

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

Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

[Jeff Garzik]

On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the
 number of sectors that can be read at once (i.e. in one track).
 
 This routine does not work with the Sony UDF5 USB floppy disk, mapped as an
 Int13 device by the Vaio C1VE (Crusoe) BIOS.
 Therefore, a bzdisk floppy will not be bootable.

The bzdisk code is used so infrequently compared to the normal
bootloaders, lilo, grub, and syslinux, that I'm not surprised it has
problems with many edge cases.

Although I imagine this is an unpopular opinion, I think that we
should remove all bzdisk-type code from X86...  syslinux and other
boot loaders handle weird BIOS quirks much better, simply because
they are used in far more situations than bzdisk.

syslinux especially is quite nice for loading kernels from floppy.
It's very small, and "syslinux -s" adds in some wonderfully-paranoid
sanity checks which make boot loading works on many a quirky BIOS.
(don't use '-s' unless you need it, of course, it slows things down...)

Jeff



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

Re: 2.4.0-test11: hangs while Probing PCI hardware for Sony Vaio C1VE (Crusoe)

[Jeff Garzik]

On Sat, 2 Dec 2000, Wolfgang Spraul wrote:
 PhoenixBIOS, Sony Vaio C1VE
 
 I did some printk() debugging, but the kernel hangs at various places in
 pci_setup_device(), mostly in pci_read_bases().

This is a Transmeta laptop, right?

See the recent thread with "Transmeta" in the subject.  The problem
seems to have been identified, and hopefully the fix will appear in
test12-pre4, when released...

Jeff



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