date:20010625


This is an incremental update to the early flush patch.

Changes:

  - flush_dirty_buffers returns sectors flushed instead of buffers flushed

  - submitted_sectors now treated as signed for robustness

  - misc cleanups

To do:

  - Add retired_sectors, redefine queued_sectors in terms of submitted and
retired.

  - Let the user set the bandwidth estimate through the bdflush_param
interface or alternatively, attempt to measure the bandwidth automatically

The first item needs a careful audit to make sure the two variables can't get 
out of sync, specifically, to ensure their mutual consistancy is properly 
protected by the io_request_lock.  The retired_sectors value would be useful 
for automatic estimation of disk throughput but regardless of whether it gets 
used this way, it is slightly more efficient to derive queued_sectors than to 
maintain it explicitly, and this also eliminates the chance for it to get out 
of sync with submitted_sectors.

I expect automatic estimation of disk throughput to be a tricky item.  It's 
possible it would be better to leave it to be estimated in userspace via 
hdparm -t.

The default settings for low_queued_goal and high_queued_goal are probably 
way too low, which would have the effect of limiting the rate at which the 
early flush proceeds.  These are supposed to be set to the disk throughput in 
terms of sectors per 100 ms polling interval, and twice that, respectively.  
The low setting should not cause any performance degradation but it would 
probably eliminate the chance to see any significant throughput increase.  
Currently I'm working under the theory that the patch should never cause a 
performance loss and should sometimes show a performance gain.  I'd 
appreciate hearing feedback from anyone who feels inspired to do some tests 
:-)

As before, the patch is against 2.4.5.  To apply:

  cd /your/source/tree
  patch b_flushtime = jiffies + bdf_prm.b_un.age_buffer;
+   bh->b_dirtytime = jiffies;
refile_buffer(bh);
 }
 
@@ -2524,12 +2524,18 @@
as all dirty buffers lives _only_ in the DIRTY lru list.
As we never browse the LOCKED and CLEAN lru lists they are infact
completly useless. */
-static int flush_dirty_buffers(int check_flushtime)
+
+static unsigned low_queued_goal = 200;
+static unsigned high_queued_goal = 400;
+
+static int flush_dirty_buffers (int update)
 {
struct buffer_head * bh, *next;
-   int flushed = 0, i;
-
- restart:
+   unsigned sectors_to_flush = bdf_prm.b_un.ndirty << 3;
+   unsigned youngest_to_flush = jiffies - bdf_prm.b_un.age_buffer;
+   int submitted = 0, i;
+   
+restart:
spin_lock(_list_lock);
bh = lru_list[BUF_DIRTY];
if (!bh)
@@ -2544,22 +2550,18 @@
if (buffer_locked(bh))
continue;
 
-   if (check_flushtime) {
-   /* The dirty lru list is chronologically ordered so
-  if the current bh is not yet timed out,
-  then also all the following bhs
-  will be too young. */
-   if (time_before(jiffies, bh->b_flushtime))
-   goto out_unlock;
-   } else {
-   if (++flushed > bdf_prm.b_un.ndirty)
+   if (update) {
+   if (time_before (youngest_to_flush, bh->b_dirtytime))
+   if (atomic_read (_sectors) >= high_queued_goal)
+   goto out_unlock;
+   } else
+   if (sectors_to_flush >= sectors_to_flush)
goto out_unlock;
-   }
 
-   /* OK, now we are committed to write it out. */
atomic_inc(>b_count);
spin_unlock(_list_lock);
ll_rw_block(WRITE, 1, );
+   submitted += bh->b_size >> 9;
atomic_dec(>b_count);
 
if (current->need_resched)
@@ -2569,7 +2571,12 @@
  out_unlock:
spin_unlock(_list_lock);
 
-   return flushed;
+#ifdef DEBUG
+   if (update)
+   printk("updated %i at %lu, %u queued\n",
+   submitted, jiffies, atomic_read (_sectors));
+#endif
+   return submitted;
 }
 
 DECLARE_WAIT_QUEUE_HEAD(bdflush_wait);
@@ -2717,7 +2724,7 @@
 int kupdate(void *sem)
 {
struct task_struct * tsk = current;
-   int interval;
+   int submitted0 = atomic_read (_sectors), countdown = 0;
 
tsk->session = 1;
tsk->pgrp = 1;
@@ -2733,11 +2740,12 @@
up((struct semaphore *)sem);
 
for (;;) {
-   /* update interval */
-   interval = bdf_prm.b_un.interval;
-   if (interval) {
+   unsigned sync_interval = bdf_prm.b_un.interval;
+   unsigned poll_interval = HZ/10;
+   
+   if (sync_interval) {

Re: GCC3.0 Produce REALLY slower code!

2001-06-25 Thread Hacksaw


Well, I haven't gone and looked at every line of assembler, but I'd bet this 
is a hasty characterization.

According to someones recent count there are around 144000 lines of assembler 
in the 2.4.2 kernel.

It seems to me you'd have to jump through a lot of hoops to test this compiler.

Then there's the other question: Why should we test a compiler that seems to 
be quite proprietary? The invitation indicates it uses FLexLM to manage the 
license.

I somehow doubt Linus or just about anyone else is going to care, save for the 
folks in Intel, who can do this for themselves just fine.

But, hey, I won't try and stop you. Have fun.

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

Difference between get_free_page() and page_cache_alloc() ?

2001-06-25 Thread Ho Chak Hung


Never mind.. I figured it out. 
__
Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Difference between get_free_page() and page_cache_alloc() ?

2001-06-25 Thread Ho Chak Hung


get_free_page() returns a pointer to a page while page_cache_alloc returns a pointer 
to a page struct. 
Is page_cache_alloc more efficient than get_free_page()?

Also, does get_free_page returns a pointer to a contiguous block of physical memory?

Thanks
__
Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac18

2001-06-25 Thread H. Peter Anvin


Alan Cox wrote:

>>>oLave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima)
>>> probe for longer on cmd timeout
>>>
>>
>>
>>Please, people... S is siemens, not seconds.  Seconds is "s" (lower
>>case.)  The rule is simple: units named after people have their
>>symbols, but not their names, capitalized.
>>
> 
> The day everyone learns to spell weird properly I'll learn to get seconds right
> - deal ?
> 


You mean people don't know how to spell weird?  That's... weird...

-hpa


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

Hang with usb scanner...2.4.5-acx

2001-06-25 Thread Steve Kieu


HI,

I got scanner epson perfection 640u. I am not sure if
it is a bug or I have to do like that.

Basically I have to compile scanner support as module
and uhci as well. Whenever I need to scan, just turn
on, modprobe ...; it is fine. When no need, remove
modules and turn off.

BUT if i compile built in to th kernel. the system
hang in sush cases:

- turn on pc, start everything, then turn on scanner

- turn on scanner then turn on pc start everything,
scanner works ; now turn off scanner

No messages in /var/log ; just hang all key board wont
work, can not login from remote, ; have to unplug the
power

thanks,




=
S.KIEU

_
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: supermount

2001-06-25 Thread Steve Kieu


 --- Sam Halliday <[EMAIL PROTECTED]> wrote: > This
email was delivered to you by The Free
> Internet,
> a Business Online Group company.
> http://www.thefreeinternet.net
I totally aggree, supermount is nice features and it
should be integrated into the main kernel stream (just
my HO)



>
---
> hello,
> i am fairly new to linux, i need it's fast
> number crunching powers
> for my research... and i have only recently begun to
> have a look at the
> kernel (i believe every workman should know his
> tools). but i have
> noticed that supermount is not a standard part of
> the project, is there
> any reason why this is? is it due to man power? i
> would have been less
> shocked by the absense of other features in the
>

> radio support, supermount seems to me to be
> essential in any operating
> system.
> i apologise if this is a very silly question or
> if i have posted
> this question in the wrong place, but please excuse
> me, im new to this
> whole world.
> 
> and keep up the good work, i wish i knew more about
> the whole thing so i
> could contribute something.
> 
> Sam, Ireland
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/ 

=
S.KIEU

_
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GCC3.0 Produce REALLY slower code!

2001-06-25 Thread Alexander V. Bilichenko


There is not so much code in asm, so it's easy to patch code
the most reasonable method is to write parsing program for that

Best regards,
Alexander mailto:[EMAIL PROTECTED]
--
Let's start the war, said Meggy
--
- Original Message -
From: "Hacksaw" <[EMAIL PROTECTED]>
To: "Alexander V. Bilichenko" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 3:30 AM
Subject: Re: GCC3.0 Produce REALLY slower code!


> >Here is link to Intel C compiler, that provide really faster code.
> >
> >http://developer.intel.com/software/products/compilers/linuxbeta.htm
>
> A quote from the site:
>
> * Not all of the GNU C language extensions, including the GNU inline
assembly
> format, are currently supported and, due to this, one cannot build the
Linux
> kernel with the beta release of the Intel compilers and the initial
product
> release.
>
>

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

Re: Linux and system area networks

2001-06-25 Thread Alan Cox


> OK, how about an Infiniband network with a TCP/IP gateway at the edge?
> Have we thought about how Linux servers should use the gateway to talk
> to internet hosts?  Surely there's no point in running TCP/IP inside
> the Infiniband network, so there needs to be some concept of "socket
> over Infiniband."

So write the library, it shouldnt need the kernel involved, and you can
take over AF_INET socket syscalls with an LD_PRELOAD so it can be transparent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux and system area networks

2001-06-25 Thread Alan Cox


> a properly written host based stack works much better in
> the face of a changing environment: Faster CPUs, new CPUs
> (IA-64), new network protocols (ECN). Besides, it is easy
> to "accelerate" a bad network stack, but try to outdo a
> well done stack.

Putting the stack partly in user spacd can sometimes be a benefit. Linux 8086
does this to cut down kernel size for example ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Joy of Forking



Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but
that does NOT mean you have to use every driver!

Shawn.

On Mon, 25 Jun 2001, Rick Hohensee wrote:

> >
> > Rick Hohensee <[EMAIL PROTECTED]> said:
> > > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has
> > > already stuck his tippy-toe is that pool, and his toe is fine.
> >
> > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave
> > Miller, or any of the arch maintainers. Alan has said several times that he
> > will sync up with Linus, and he still stages patches upwards. Alan doesn't
> > like the "all shall be devfs" ukase (and neither do I, BTW), and will
> > maintain non-devfs systems for the time being.
> >
> > I do see the merit of some kind of devfs, but there still is a lot of stuff
> > that needs a more reasonable solution, so no thanks for now.
>
> I've had quite a good two rants lately and will be happy to get on to
> other things for now. My point is to think of devfs and dozens of other
> things in the context of more than one Linux. Just a thought.
>
> Rick Hohensee
> www.clienux.com
>
> > --
> > 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]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

Re: Linux 2.4.5-ac18

2001-06-25 Thread Alan Cox


> > o   Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima)
> > probe for longer on cmd timeout
> 
> 
> 
> Please, people... S is siemens, not seconds.  Seconds is "s" (lower
> case.)  The rule is simple: units named after people have their
> symbols, but not their names, capitalized.

The day everyone learns to spell weird properly I'll learn to get seconds right
- deal ?

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

Re: The Joy of Forking

2001-06-25 Thread Rick Hohensee


> 
> Rick Hohensee <[EMAIL PROTECTED]> said:
> > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has
> > already stuck his tippy-toe is that pool, and his toe is fine.
> 
> Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave
> Miller, or any of the arch maintainers. Alan has said several times that he
> will sync up with Linus, and he still stages patches upwards. Alan doesn't
> like the "all shall be devfs" ukase (and neither do I, BTW), and will
> maintain non-devfs systems for the time being.
> 
> I do see the merit of some kind of devfs, but there still is a lot of stuff
> that needs a more reasonable solution, so no thanks for now.

I've had quite a good two rants lately and will be happy to get on to
other things for now. My point is to think of devfs and dozens of other
things in the context of more than one Linux. Just a thought. 

Rick Hohensee
www.clienux.com

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

Re: GCC3.0 Produce REALLY slower code!

2001-06-25 Thread Hacksaw


>Here is link to Intel C compiler, that provide really faster code.
>
>http://developer.intel.com/software/products/compilers/linuxbeta.htm

A quote from the site:

* Not all of the GNU C language extensions, including the GNU inline assembly 
format, are currently supported and, due to this, one cannot build the Linux 
kernel with the beta release of the Intel compilers and the initial product 
release.


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

Linux-2.4.5-ac16/17/18: floppy driver problem with lilo boot disks?

2001-06-25 Thread Dieter Nützel


Hello,

I mount my bootdisk (minix filesystem) with "mount /dev/fd0 /mnt" and copy my 
new compiled kernel to it. After that I do a "lilo -v -C /mnt/lilo.conf".

All following commands which are floppy related (filesystem) fall into the D 
state. Load goes up by 100 for every D state process.

ls /mnt
umount /mnt
sync

SunWave1#cat /proc/version
Linux version 2.4.5-ac16 (root@SunWave1) (gcc version 2.95.2 19991024 
(release)) #1 Wed Jun 20 18:01:34 CEST 2001
 
SunWave1#ps aux
root  1039  0.0  0.0  1404   64 pts/1D16:24   0:00 umount /mnt
nuetzel   1108  0.1  0.1  1412  500 pts/5D16:28   0:00 sync

Even "reboot" do nothing. I have to push the reset button.
Luckily I have ReiserFS running and only some seconds to wait during bootup 
for replay the transaction logs.

But mount/umount other disk partitions works as expected.

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

Re: Linux and system area networks

2001-06-25 Thread Roland Dreier


> "Pete" == Pete Zaitcev <[EMAIL PROTECTED]> writes:

Roland> The rough idea is that WSD is a new user space library
Roland> that looks at sockets calls and decides if they have to go
Roland> through the usual kernel network stack, or if they can be
Roland> handed off to a "SAN service provider" which bypasses the
Roland> network stack and uses hardware reliable transport and
Roland> possibly RDMA.

Pete> That can be done in Linux just as easily, using same DLLs
Pete> (they are called .so for "shared object"). If you look at
Pete> Ashok Raj's Infi presentation, you may discern "user-level
Pete> sockets", if you look hard enough. I invite you to try, if
Pete> errors of others did not teach you anything.

I think you misunderstood the point.  Microsoft is providing this WSD
DLL as a standard part of W2K now.  This means that hardware vendors
just have to write a SAN service provider, and all Winsock-using
applications benefit transparently.  No matter how good your TCP/IP
implementation is, you still lose (especially in latency) compared to
using reliable hardware transport.  Oracle-with-VI and DAFS-vs-NFS
benchmarks show this quite clearly.

Linux has nothing to compare to Winsock Direct.  I agree, one could
put an equivalent in glibc, or one could take advantage of Linux's
relatively low system call latency and put something in the kernel.
The unfortunate consequence of this is that SAN (system area network)
hardware vendors are not going to support Linux very well.

BTW, do you have a pointer to Ashok Raj's presentation?

Roland> This means that all applications that use Winsock benefit
Roland> from the advanced network hardware.  Also, it means that
Roland> Windows is much easier for hardware vendors to support
Roland> than other OSes.  For example, Alacritech's TCP/IP offload
Roland> NIC only works under Windows.  Microsoft is also including
Roland> Infiniband support in Windows XP and Windows 2002.

Pete> IMHO, Alacritech is about to join scores and scores of
Pete> vendors who tried that before. Customers understand very
Pete> soon that a properly written host based stack works much
Pete> better in the face of a changing environment: Faster CPUs,
Pete> new CPUs (IA-64), new network protocols (ECN). Besides, it
Pete> is easy to "accelerate" a bad network stack, but try to
Pete> outdo a well done stack.

OK, how about an Infiniband network with a TCP/IP gateway at the edge?
Have we thought about how Linux servers should use the gateway to talk
to internet hosts?  Surely there's no point in running TCP/IP inside
the Infiniband network, so there needs to be some concept of "socket
over Infiniband."

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

Re: Linux 2.4.5-ac18

2001-06-25 Thread David Lang


On 25 Jun 2001, H. Peter Anvin wrote:

> Date: 25 Jun 2001 14:08:26 -0700
> From: H. Peter Anvin <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Linux 2.4.5-ac18
>
> Followup to:  <[EMAIL PROTECTED]>
> By author:Alan Cox <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
>
> > o   Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima)
> > probe for longer on cmd timeout
>
> 
>
> Please, people... S is siemens, not seconds.  Seconds is "s" (lower
> case.)  The rule is simple: units named after people have their
> symbols, but not their names, capitalized.

ok who was Mr/Mrs Byte?


sorry couldn't resist

:-)

David Lang

> Microseconds are written µs, or if the µ symbol is unavailable, us.
>
> Sorry, this one grates on me...
>
>   -hpa
> --
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5 and gcc v3 final

2001-06-25 Thread Andreas Bombe


On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote:
> What gcc objects to is stuff like:
> 
>"This is a nice long string
> that just goes on
> and on\n"
> 
> which is illegal in C AFAIU. It does not object to:
> 
>"This long string"
>"spans several lines, "
>"but legally.\n"

But the first example contains three newlines, the second just one.  A
thing to keep in mind when going around fixing these multi line strings,
explicit newlines have to be added.

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

More module conversion...

2001-06-25 Thread James Lamanna


In my quest to convert a module from 2.2 to 2.4, I came across
a nice oops (it actually was from their code that I thought I didn't
have to touch...).

The oops comes when trying to access address 0xd2000, which the
code for this robot controller has hardcoded as its "BASE_ADDR"
Were the base addresses for io cards moved between 2.2 and 2.4?

* Please cc me since I'm not currently subscribed.
Thanks,
--James Lamanna


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

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Jun 25 15:10:08 martel kernel: Unable to handle kernel paging request at virtual 
address 000d2000
Jun 25 15:10:08 martel kernel: c8853cc0
Jun 25 15:10:08 martel kernel: *pde = 
Jun 25 15:10:08 martel kernel: Oops: 
Jun 25 15:10:08 martel kernel: CPU:0
Jun 25 15:10:08 martel kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Jun 25 15:10:08 martel kernel: EFLAGS: 00010286
Jun 25 15:10:08 martel kernel: eax: 000d2000   ebx: 00fd   ecx: c748e000   edx: 
c0244b64
Jun 25 15:10:08 martel kernel: esi:    edi:    ebp: c8854780   esp: 
c6a11ef0
Jun 25 15:10:08 martel kernel: ds: 0018   es: 0018   ss: 0018
Jun 25 15:10:08 martel kernel: Process insmod (pid: 1071, stackpage=c6a11000)
Jun 25 15:10:08 martel kernel: Stack: 0001 c028853c 0019 00fd  
 0806e918 c8853f66
Jun 25 15:10:08 martel kernel:c8854780 00fd c8854640 c8853000  
 c8853000 c0111a05
Jun 25 15:10:08 martel kernel: c63a8000 16a0 c63a9000 0060 
ffea 0005 c6b25e00
Jun 25 15:10:08 martel kernel: Call Trace: [] [] [] 
[] [] [] []
Jun 25 15:10:08 martel kernel:[] []
Jun 25 15:10:08 martel kernel: Code: 0f b6 34 07 89 f2 80 fa ff 74 08 84 d2 0f 85 09 
01 00 00 47

>>EIP; c8853cc0 <[i200m]i200m_probe+20/168>   <=
Trace; c8853f66 <[i200m]init_module+e2/138>
Trace; c8854780 <[i200m]__module_kernel_version+0/0>
Trace; c8854640 <[i200m]i200m_fops+0/5f>
Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8>
Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8>
Trace; c0111a05 
Trace; c883a000 <[ds].data.end+15c1/1621>
Trace; c8853060 <[i200m]i200m_boot_command+0/d4>
Trace; c0106c4b 
Code;  c8853cc0 <[i200m]i200m_probe+20/168>
 <_EIP>:
Code;  c8853cc0 <[i200m]i200m_probe+20/168>   <=
   0:   0f b6 34 07   movzbl (%edi,%eax,1),%esi   <=
Code;  c8853cc4 <[i200m]i200m_probe+24/168>
   4:   89 f2 mov%esi,%edx
Code;  c8853cc6 <[i200m]i200m_probe+26/168>
   6:   80 fa ff  cmp$0xff,%dl
Code;  c8853cc9 <[i200m]i200m_probe+29/168>
   9:   74 08 je 13 <_EIP+0x13> c8853cd3 
<[i200m]i200m_probe+33/168>
Code;  c8853ccb <[i200m]i200m_probe+2b/168>
   b:   84 d2 test   %dl,%dl
Code;  c8853ccd <[i200m]i200m_probe+2d/168>
   d:   0f 85 09 01 00 00 jne11c <_EIP+0x11c> c8853ddc 
<[i200m]i200m_probe+13c/168>
Code;  c8853cd3 <[i200m]i200m_probe+33/168>
  13:   47inc%edi


1 warning issued.  Results may not be reliable.



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

Re: Linux and system area networks

2001-06-25 Thread Pete Zaitcev


> I'd like to find out if anyone has thought about how Linux will handle
> some of the new network technologies people are starting to push.
> Specifically I'm talking about "System Area Networks," that is, things
> like Infiniband, as well as TCP/IP offload.

Infiniband is doing relatively well, as much as anything can
with Intel at the helm (see "Itanic"). This has nothing to
do with TCP/IP offload, which is an extremely stupid idea.
The whole thing stems from a desire by vendors to sell
"smart" (== very expensive) NICs.

RDMA in Infiniband is, in my view, a little more than
traditional DMA in any other advanced server I/O bus.
Sun UPA is packetized, for instance.

> The rough idea is that WSD is a new user space library that looks at
> sockets calls and decides if they have to go through the usual kernel
> network stack, or if they can be handed off to a "SAN service
> provider" which bypasses the network stack and uses hardware reliable
> transport and possibly RDMA.

That can be done in Linux just as easily, using same DLLs
(they are called .so for "shared object"). If you look
at Ashok Raj's Infi presentation, you may discern "user-level
sockets", if you look hard enough. I invite you to try, if
errors of others did not teach you anything.

> This means that all applications that use Winsock benefit from the
> advanced network hardware.  Also, it means that Windows is much easier
> for hardware vendors to support than other OSes.  For example,
> Alacritech's TCP/IP offload NIC only works under Windows.  Microsoft
> is also including Infiniband support in Windows XP and Windows 2002.

IMHO, Alacritech is about to join scores and scores of vendors
who tried that before. Customers understand very soon that
a properly written host based stack works much better in
the face of a changing environment: Faster CPUs, new CPUs
(IA-64), new network protocols (ECN). Besides, it is easy
to "accelerate" a bad network stack, but try to outdo a
well done stack.

> So I guess my question is whether anyone has started thinking about
> the architectural changes needed to make System Area Networking and
> TCP/IP offload easier under Linux.

Pretty much zero-copy that DaveM and Co. do addresses this.

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

Re: [Ext2-devel] Re: [UPDATE] Directory index for ext2


On Monday 25 June 2001 21:51, Andreas Dilger wrote:
> Daniel writes:
> > > > On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > > > > The main problem I have with this is that e2fsck doesn't know how
> > > > > to deal with it - at least I haven't found a version that will.
> > > > > This makes it rather difficult to use, especially for your root fs.
> >
> > Sure, if your root partition is expendable, by all means go ahead.  Ted
> > has already offered to start the required changes to e2fsck, which
> > reminds me, I have to send the promised docs.  For now, just use normal
> > fsck and it will (in theory) turn the directory indexes back into normal
> > file blocks, and have no effect on inodes.
>
> This is only true without the COMPAT_DIR_INDEX flag.  Since e2fsck _needs_
> to know about every filesystem feature, it will (correctly) refuse to touch
> such a system for now.  You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to
> turn of the COMPAT_DIR_INDEX flag and let e2fsck go to town.  That will
> break all of the directory indexes, I believe.

This is what he wants, a workaround so he can fsck.  However, the above 
command (on version 1.2-WIP) just gives me:

   Invalid filesystem option set: ^FEATURE_C4

Maybe he should just edit the source so it doesn't set the superblock flag 
for now.

BTW, there doesn't seem to be a --version command in tune2fs.

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

Re: EXT2 Filesystem permissions (bug)?



oh ;)

I never noticed that info before, then again 2 hours of sleep might be the
cause :)

On 25 Jun 2001, H. Peter Anvin wrote:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Shawn Starr <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Is this a bug or something thats undocumented somewhere?
> >
> > dT
> > and
> > drwSrwSrwT
> >
> > are these special bits? I'm not aware of +S and +T
> >
>
> It's neither a bug nor undocumented.
>
> "info ls" would have told you the following:
>
>  The permissions listed are similar to symbolic mode
>  specifications
>  (*note Symbolic Modes::.).  But `ls' combines multiple bits into
>  the third character of each set of permissions as follows:
> `s'
>   If the setuid or setgid bit and the corresponding executable
>   bit are both set.
>
> `S'
>   If the setuid or setgid bit is set but the corresponding
>   executable bit is not set.
>
> `t'
>   If the sticky bit and the other-executable bit are both set.
>
> `T'
>   If the sticky bit is set but the other-executable bit is not
>   set.
>
> `x'
>   If the executable bit is set and none of the above apply.
>
> `-'
>   Otherwise.
>
>   -hpa
> --
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

Re: [patch] rio500 devfs support

2001-06-25 Thread Gregory T. Norris

I was thinking of doing some similar updates this evening after work. 
Darn it... now I have to find something else to do!  :-)

Going by this morning's comments from Richard Gooch, it sounds like the

if (rio->devfs == NULL)
dbg("probe_rio: device node registration failed");

part should probably be removed... it looks good to me otherwise, tho. 
I'll try it out tonight and post the results.

Cheers!

On Mon, Jun 25, 2001 at 10:35:21AM -0700, Greg KH wrote:
> Here's a small change that makes the node a child of the usb devfs
> entry.  It also enables the node to only be present when the device is
> actually present.  The patch is against 2.4.6-pre5.
> 
> thanks,
> 
> greg k-h

 PGP signature

Re: EXT2 Filesystem permissions (bug)?

2001-06-25 Thread Luigi Genoni


Those are normal unix permissions, and you can use them on every kind of
Unix FS, (at less i saw them on jfs, hfs, vxfs, xfs, reiserfs, ext2, ufs).


S is suid and sgid without execution bit.
T is stiky bit without any execution bit.

(I hope my english is correct)

Luigi

On Mon, 25 Jun 2001, Shawn Starr wrote:

>
> Is this a bug or something thats undocumented somewhere?
>
> dT
> and
> drwSrwSrwT
>
> are these special bits? I'm not aware of +S and +T
>
> Shawn.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: EXT2 Filesystem permissions (bug)?

2001-06-25 Thread Andreas Dilger


Shawn Star writes:
> Is this a bug or something thats undocumented somewhere?
> 
> dT
> and
> drwSrwSrwT
> 
> are these special bits? I'm not aware of +S and +T

---S-- = setuid (normally shows up as "s" if "x" is also set)
--S--- = setgid (normally shows up as "s" if "x" is also set)
-T = sticky bit (prevents non-owner from deleting a file in
 world-writable directory like /tmp)

See chmod(1) for this info.

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

Re: EXT2 Filesystem permissions (bug)?

2001-06-25 Thread H. Peter Anvin


Followup to:  <[EMAIL PROTECTED]>
By author:Shawn Starr <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Is this a bug or something thats undocumented somewhere?
> 
> dT
> and
> drwSrwSrwT
> 
> are these special bits? I'm not aware of +S and +T
> 

It's neither a bug nor undocumented.

"info ls" would have told you the following:

 The permissions listed are similar to symbolic mode
 specifications
 (*note Symbolic Modes::.).  But `ls' combines multiple bits into
 the third character of each set of permissions as follows:
`s'
  If the setuid or setgid bit and the corresponding executable
  bit are both set.

`S'
  If the setuid or setgid bit is set but the corresponding
  executable bit is not set.

`t'
  If the sticky bit and the other-executable bit are both set.

`T'
  If the sticky bit is set but the other-executable bit is not
  set.

`x'
  If the executable bit is set and none of the above apply.

`-'
  Otherwise.

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

EXT2 Filesystem permissions (bug)?



Is this a bug or something thats undocumented somewhere?

dT
and
drwSrwSrwT

are these special bits? I'm not aware of +S and +T

Shawn.


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

Re: 2.4.6pre iptables masquerading seems to kill eth0

2001-06-25 Thread Thomas Weber


On Fri, Jun 22, 2001 at 09:20:26AM +0200, Helge Hafting wrote:
> Thomas Weber wrote:
> > 
> > I'm on 2.4.6pre3 + freeswan/ipsec on my gateway now for 5 days.
> > It's an old 486/66 32MB with several isdn links, a dsl uplink (with
> > iptables masquerading) behind a ne2k clone and a 3c509 to the inside network.
> > no problems at all with the interfaces (all compiled as modules).
> 
> Nice to know it works for you.  The troubled machine is a dual celeron, 
> so it could be some sort of SMP problem.  I am trying pre5
> to see if it is better, I'll probably know in a few days.

since i just read another report on the list I checked again and it seems 
like i messed it up: 
you were talking about the 3c905, but I have a 3c509 (ISA) card.
I should have known, it's not the first time i mixed them up :(

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

Re: sizeof problem in kernel modules

2001-06-25 Thread Horst von Brand


Alan Shutko <[EMAIL PROTECTED]> said:
> One more tidbit: ISO/IEC 9899:1990 3.14
> 
>   3.14 object: A region of data storage in the execution environment,
> the contents of which can represent values.  Except for
> bit-fields, objects are composed of contiguous sequences of one or
> more bytes, the number, order and encoding of which are either
> explicitely specified or implementation-defined.
> 
> This would specifically prohibit separating any part of a structure
> from the rest.

It just prohibits separating bytes, not subobjects. I.e., everything can be
handled as an array of bytes (of the appropiate length, as given by
sizeof())
-- 
Dr. Horst H. von BrandUsuario #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VM tuning through fault trace gathering [with actual code]

2001-06-25 Thread John Fremlin


Rik van Riel <[EMAIL PROTECTED]> writes:

> On 25 Jun 2001, John Fremlin wrote:
> 
> > Last year I had the idea of tracing the memory accesses of the
> > system to improve the VM - the traces could be used to test
> > algorithms in userspace. The difficulty is of course making all
> > memory accesses fault without destroying system performance.
> 
> Sounds like a cool idea.  One thing you should keep in mind though
> is to gather traces of the WHOLE SYSTEM and not of individual
> applications.

In the current patch all pagefaults are recorded from all sources. I'd
like to be able to catch read(2) and write(2) (buffer cache stuff) as
well but I don't know how . . . .

> There has to be a way to balance the eviction of pages from
> applications against those of other applications.

Of course! It is important not to regard each thread group as an
independent entity IMHO (had a big old argument about this).

[...]

-- 

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

Re: Linux 2.4.5-ac18

2001-06-25 Thread H. Peter Anvin


Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel

> o Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima)
>   probe for longer on cmd timeout



Please, people... S is siemens, not seconds.  Seconds is "s" (lower
case.)  The rule is simple: units named after people have their
symbols, but not their names, capitalized.

Microseconds are written µs, or if the µ symbol is unavailable, us.

Sorry, this one grates on me...

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

[PATCH] skb destructor enhancement idea

2001-06-25 Thread Will


Here is a patch against 2.4.6pre5 that implements a gneric, 'chainable' destructor
mechanism for sk_buff structures. It allows for an arbitrary number of ordered
destructor calls for skbs.

We are currently using this change in a low-level packet monitoring module so we can
allocate our own packet memory and get called back when the skb is done moving
through the stack. It seems like it should be useful to allow network drivers to
implement their own device-specific memory management and thus reduce mem copying
overhead, too.

Any driver people want to try it out and see if they can make their driver use it to
reduce copying?

Any comments on the idea in general?

-- 
-Will  :: AD6XL :: http://tyranny.egregious.net/~will/
 Orton :: finger [EMAIL PROTECTED] for GPG public key


diff -ur linux-246p5-clean/include/linux/skbuff.h linux/include/linux/skbuff.h
--- linux-246p5-clean/include/linux/skbuff.hFri May 25 18:01:43 2001
+++ linux/include/linux/skbuff.hMon Jun 25 12:23:49 2001
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define HAVE_ALLOC_SKB /* For the drivers to know */
 #define HAVE_ALIGNABLE_SKB /* Ditto 8)*/
@@ -114,6 +115,18 @@
__u16 size;
 };
 
+struct sk_buff_dest {
+   struct sk_buff_dest *next;
+   void (*destructor)(void *);
+   void *context;
+};
+
+struct sk_buff_dest_pool {
+   struct sk_buff_dest *head;  
+   spinlock_t  lock;
+   kmem_cache_t*cache;
+};
+
 /* This data is invariant across clones and lives at
  * the end of the header data, ie. at skb->end.
  */
@@ -191,7 +204,7 @@
unsigned char   *tail;  /* Tail pointer
 */
unsigned char   *end;   /* End pointer 
 */
 
-   void(*destructor)(struct sk_buff *);/* Destruct function   
 */
+   struct sk_buff_dest_pooldestructor;
 #ifdef CONFIG_NETFILTER
/* Can be used for communication between hooks. */
 unsigned long  nfmark;
@@ -245,6 +258,78 @@
 /* Internal */
 #define skb_shinfo(SKB)((struct skb_shared_info *)((SKB)->end))
 
+/* SKB destructor stuff */
+extern unsigned int skbd_stat_add_head;
+extern unsigned int skbd_stat_add_dest;
+extern unsigned int skbd_stat_alloc;
+extern unsigned int skbd_stat_call_dest;
+extern unsigned int skbd_stat_maybe_call_dest;
+
+extern struct sk_buff_dest_pool sk_buff_dest_free_pool; 
+
+static inline void skbd_add_head(struct sk_buff_dest_pool *pool,
+struct sk_buff_dest *newnode)
+{
+   skbd_stat_add_head++;
+   newnode->next = pool->head;
+   pool->head = newnode;
+}
+
+static inline void skbd_remove_head(struct sk_buff_dest_pool *pool,
+   struct sk_buff_dest **rmnode)
+{
+   if ((*rmnode = pool->head) != NULL)
+   pool->head = pool->head->next;
+}
+
+
+static inline int skb_add_dest(struct sk_buff *skb, void (*destructor)(void *),
+  void *context, unsigned long gfp_mask)
+{
+   unsigned long flags;
+   struct sk_buff_dest *skbd;
+
+   skbd_stat_add_dest++;
+
+   spin_lock_irqsave(_buff_dest_free_pool.lock, flags);
+   skbd_remove_head(_buff_dest_free_pool, ); 
+   spin_unlock_irqrestore(_buff_dest_free_pool.lock, flags);
+
+   if (!skbd) {
+   skbd_stat_alloc++;
+   skbd = kmem_cache_alloc( sk_buff_dest_free_pool.cache, gfp_mask);
+   if (!skbd) {
+   printk(" out of memory allocating skbd\n");
+   return 1;
+   }
+   }
+
+   skbd->destructor = destructor;
+   skbd->context = context;
+   skbd_add_head(>destructor, skbd);
+   return 0;
+} 
+  
+  
+
+static inline void skb_call_dest(struct sk_buff *skb)
+{
+   unsigned long flags;
+   struct sk_buff_dest *skbd;
+
+   skbd_stat_maybe_call_dest++;
+   skbd_remove_head(>destructor, );
+
+   while (skbd) {
+   skbd_stat_call_dest++;
+   skbd->destructor(skbd->context);
+
+   spin_lock_irqsave(_buff_dest_free_pool.lock, flags);
+   skbd_add_head(_buff_dest_free_pool, skbd);
+   spin_unlock_irqrestore(_buff_dest_free_pool.lock, flags);
+
+   skbd_remove_head(>destructor, );
+   }
+}
+
 /**
  * skb_queue_empty - check if a queue is empty
  * @list: queue head
@@ -971,9 +1056,7 @@
 
 static inline void skb_orphan(struct sk_buff *skb)
 {
-   if (skb->destructor)
-   skb->destructor(skb);
-   skb->destructor = NULL;
+   skb_call_dest(skb);
skb->sk = NULL;
 }
 
diff -ur

Re: Oops in iput

2001-06-25 Thread Stephen C. Tweedie

Hi,

On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote:
> 
> oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4
ones, and simply can't be trusted as a baseline for debugging other
code.  Can you reproduce this problem without them applied?  The oops
here is a networking oops on the face of it, and I wouldn't expect to
see that on 2.2 unless something was corrupting memory.

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

Re: AMD thunderbird oops

2001-06-25 Thread Dan Hollis

On Mon, 25 Jun 2001, Alan Cox wrote:
> Random oopses normally indicate faulty board cpu or ram (and the fault may
> even just be overheating or dimms not in the sockets cleanly). I doubt its
> the board design or model that is the problem, you probably jut have a faulty
> component somewhere if its oopsing randomly even during installs and stuff

Ive found a number of problems can be traced to power supply problems, the
board providing a bit of under voltage. Manually adjusting CPU voltage a
notch or two up has fixed many a board for me.

Also manually adjusting SDRAM drive strength can help, BIOS sometimes gets
this wrong.

-Dan

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

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

2001-06-25 Thread David Grant


I'd be interested in testing any fixes for the VIA Southbridge chip.  I have
an ASUS A7V133.  I was having problems with the IDE controller, but I've
switched to the on-board Promise IDE and it works fine.  I couldn't get rid
of the DMA timeout errors with my VIA vt82c686b, even with the latest
patches.  I even completely disabled DMA (through .config options) and I
although I didn't get DMA timeout errors anymore, everything still came to a
halt under heavy disk usage.

Would it be a good idea to form a small mailing list of people with VIA
chipsets (vt82c686b only)?  Then perhaps we could communicate with Vojtech
more easily, and the VIA southbridge problems might end a little quicker.
It seems like there are a bunch of people still having the VIA problems.

David Grant

- Original Message -
From: "Andy Ward" <[EMAIL PROTECTED]>
To: "Steven Walter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 12:57 PM
Subject: RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))


> I'd love to help out with testing (alas, my kernel coding skills aren't
> up to fixing this kind of problem).  Heck, if it trashes my linux
> install, no biggie... I've got it ghosted to an image elsewhere...
>
> Anyone wanting to work on this just drop me an email.
>
> -- andyw
>

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

Re: Microsoft and Xenix.

2001-06-25 Thread asmith

Hi again,

some old brain-cells got excited with the "good-ol-days" and other names have
surfaced like "Superbrain","Sirius" and "Apricot".Sirius was Victor in the
USA.  If you go done the so-called IBM compatible route then the nearly
compatible  nightmares  will arise and haunt you, your lucky if the scars
have faded!!

I learnt my computing on a PDP8/E with papertape punch/reader, RALF, Fortran
II, then later 2.4Mb removable cartridges (RK05 I think).  toggling in the
bootstrap improved your concentration. Much later you could
get a single chip(?) version of this in a wee knee sized box.

One summer job was working on a PDP15 analog computer alongside an 11/20 with
DECTAPE, trying to compute missile firing angles. [A simple version of Pres
Bush's starwars shield].

--

Andrew Smith in Edinburgh,Scotland

 On 25 Jun 2001, Kai Henningsen wrote:

> [EMAIL PROTECTED] (Rob Landley)  wrote on 24.06.01 in 
><[EMAIL PROTECTED]>:
>
> > Now if somebody here could just point me to a decent reference on A/UX -
> > Apple's mid-80's version of Unix (for the early macintosh, I believe...)
>
> http://www.google.com/search?q=%22%2ba/ux%22
>
> Usually a good idea.
>
>
>
> Also, you probably want to look at RFC 2235.
>
> MfG Kai
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))

2001-06-25 Thread Andy Ward


I'd love to help out with testing (alas, my kernel coding skills aren't
up to fixing this kind of problem).  Heck, if it trashes my linux
install, no biggie... I've got it ghosted to an image elsewhere...

Anyone wanting to work on this just drop me an email.

-- andyw

-Original Message-
From: Steven Walter [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 1:33 AM
To: Andy Ward
Cc: [EMAIL PROTECTED]
Subject: VIA Southbridge bug (Was: Crash on boot (2.4.5))


Great, glad to here it.  Who (if anyone) is still attempting to unravel
the puzzle of the Via southbridge bug?  You, Andy, should try and get in
touch with them and help debug this thing, if you're up to it.

On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote:
> Well, I have tried your suggestion, and it works beautifully...  The
> only change I made was to the cpu type (to 686), and everything *just*
> works now...  Thanks, all!!!
> 
> > From the look of things, you're being bitten by the VIA southbridge
> > problem.  As I've gathered, its some sort of interaction with that
chip
> > and the 3DNow! fast copy routines the kernel uses.
> > 
> > If you compile the kernel for a 686, does the problem go away?  What
> > about 586 or lower?  If so, I believe there are some people working
on
> > finding common aspects of the hardware that experience this problem,
> > though I don't remember who.  You should get in contact with them,
or
> > they might get into contact with you.
> > 
> > Good luck on working this out.
> > -- 
> > -Steven
> > In a time of universal deceit, telling the truth is a revolutionary
act.
> > -- George Orwell
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft and Xenix.

2001-06-25 Thread Erik Mouw


On Mon, Jun 25, 2001 at 10:17:09AM -0400, Rob Landley wrote:
> On Monday 25 June 2001 11:13, you wrote:
> > 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits,"
> >
> > 1948 claude shannon A mathematical theory of information.
> >
> > without those you're kind in trouble on the computing front...

[snip]

> This was the dude who decided to apply a binary and boolean approach to 
> electronic computation, right?  I KNOW I've read some stuff about him... late 
> last year?

Yes, but the latter paper was the real milestone. This was the guy who
actually defined what information *is*, and found out the upper limits
of communication rates on a given channel. This was the guy who laid
the fundaments of the information theory. Without information theory no
compression, reliable transmission, reliable storage, crypthography,
etc.


Erik
[who works in an information theory group]

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))

2001-06-25 Thread Andy Ward


oh really?   I have my memory timings set to 133/cas2/6-4-4-4.  One
wonders... *ponder*

I have noticed some general flakyness (hard to pin down) on the system,
though...  random program crashes, minor visual corruption in X (which
fixes itself when you move things around), etc...  Anyone want to take a
swing at that?

-- andyw

-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 2:07 AM
To: Steven Walter
Cc: Andy Ward; [EMAIL PROTECTED]
Subject: Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))


> Great, glad to here it.  Who (if anyone) is still attempting to
unravel
> the puzzle of the Via southbridge bug?  You, Andy, should try and get
in
> touch with them and help debug this thing, if you're up to it.

The IWILL problem seems unrelated. Its the board that more than others
people
report fails totally when streaming memory copies using movntq
instructions.

The Athlon optimised kernel places pretty much the absolute maximum load

possible on the memory bus. Several people have reported that machines
that
are otherwise stable on the bios fast options require  the proper
conservative
settings to be stable with the Athlon optimisations

Alan

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

Re: Microsoft and Xenix.

2001-06-25 Thread Rob Landley


On Monday 25 June 2001 13:14, [EMAIL PROTECTED] wrote:
> Hi,
>
> If you're really keen on old mags and manuals I'll go up to attic and look
> around.  I know there are old SCO Xenix & TCP/IP, as well as Byte and Dr
> Dobbs
>

Ooh!  Yes!  Very much so.

Thanks,

Rob

The mailing list for this discussion is:
http://lists.sourceforge.net/lists/listinfo/penguicon-comphist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ext2-devel] Re: [UPDATE] Directory index for ext2

2001-06-25 Thread Andreas Dilger


Daniel writes:
> > > On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > > > The main problem I have with this is that e2fsck doesn't know how to
> > > > deal with it - at least I haven't found a version that will. This makes
> > > > it rather difficult to use, especially for your root fs.
> 
> Sure, if your root partition is expendable, by all means go ahead.  Ted has 
> already offered to start the required changes to e2fsck, which reminds me, I 
> have to send the promised docs.  For now, just use normal fsck and it will 
> (in theory) turn the directory indexes back into normal file blocks, and have 
> no effect on inodes.

This is only true without the COMPAT_DIR_INDEX flag.  Since e2fsck _needs_
to know about every filesystem feature, it will (correctly) refuse to touch
such a system for now.  You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to
turn of the COMPAT_DIR_INDEX flag and let e2fsck go to town.  That will
break all of the directory indexes, I believe.

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

[suggested PATCH]: /dev/guid support

2001-06-25 Thread Martin Wilck



Hello,

This is a patch I sent to the Linux-IA64 mailing list some time ago.
David Mosberger has suggested that I send it to linux-kernel to get
broader feedback.

Given support for GUID (UUID) entries in the partition table (as
in the EFI partition table on IA-64 systems), and given devfs support in
the kernel, the patch creates  devfs links /dev/guid/[GUID] which allow
to mount, fsck, partition, ... disks and partitions by their unique GUID.
This wiull be quite helpful on large servers where the GUID, unlike
disk and controller numbers, will stay constat even if disks or
controllers are exchanged.

If partitions are destroyed and created, the links in /dev/guid
(dis)appear as well (thanks to devfs magic).

The patch is against 2.4.5 + David Mosbergers IA64 patch (30/05/2001)
from the "ports" directory.

Feedback very welcome
Martin

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113

diff -ru linux-2.4.5/Documentation/Configure.help 
linux-2.4.5mw/Documentation/Configure.help
--- linux-2.4.5/Documentation/Configure.helpMon Jun 25 14:45:01 2001
+++ linux-2.4.5mw/Documentation/Configure.help  Mon Jun 25 15:48:11 2001
@@ -12036,6 +12036,12 @@
   were partitioned using EFI GPT.  Presently only useful on the
   IA-64 platform.

+/dev/guid support (EXPERIMENTAL)
+CONFIG_DEVFS_GUID
+  Say Y here if you would like to access disks and partitions by
+  their Globally Unique Identifiers (GUIDs) which will appear as
+  symbolic links in /dev/guid.
+
 Ultrix partition support
 CONFIG_ULTRIX_PARTITION
   Say Y here if you would like to be able to read the hard disk
diff -ru linux-2.4.5/fs/devfs/base.c linux-2.4.5mw/fs/devfs/base.c
--- linux-2.4.5/fs/devfs/base.c Mon Jun 25 13:46:26 2001
+++ linux-2.4.5mw/fs/devfs/base.c   Mon Jun 25 15:45:32 2001
@@ -1903,6 +1903,27 @@
 return master->slave;
 }   /*  End Function devfs_get_unregister_slave  */

+#ifdef CONFIG_DEVFS_GUID
+/**
+ * devfs_unregister_slave - remove the slave that is unregistered when @master is 
+unregistered.
+ *  Destroys the connection established by devfs_auto_unregister.
+ *
+ * @master: The master devfs entry.
+ */
+
+void devfs_unregister_slave (devfs_handle_t master)
+{
+   devfs_handle_t slave;
+
+   if (master == NULL) return;
+
+   slave = master->slave;
+   if (slave) {
+   master->slave = NULL;
+   unregister (slave);
+   };
+}
+#endif /* CONFIG_DEVFS_GUID */

 /**
  * devfs_get_name - Get the name for a device entry in its parent directory.
@@ -2103,6 +2124,9 @@
 EXPORT_SYMBOL(devfs_get_next_sibling);
 EXPORT_SYMBOL(devfs_auto_unregister);
 EXPORT_SYMBOL(devfs_get_unregister_slave);
+#ifdef CONFIG_DEVFS_GUID
+EXPORT_SYMBOL(devfs_unregister_slave);
+#endif
 EXPORT_SYMBOL(devfs_register_chrdev);
 EXPORT_SYMBOL(devfs_register_blkdev);
 EXPORT_SYMBOL(devfs_unregister_chrdev);
diff -ru linux-2.4.5/fs/partitions/Config.in linux-2.4.5mw/fs/partitions/Config.in
--- linux-2.4.5/fs/partitions/Config.in Mon Jun 25 14:45:01 2001
+++ linux-2.4.5mw/fs/partitions/Config.in   Mon Jun 25 15:45:32 2001
@@ -25,6 +25,7 @@
   bool 'Solaris (x86) partition table support' CONFIG_SOLARIS_X86_PARTITION
   bool 'Unixware slices support' CONFIG_UNIXWARE_DISKLABEL
   bool 'EFI GUID Partition support' CONFIG_EFI_PARTITION
+  dep_bool '/dev/guid support (EXPERIMENTAL)' CONFIG_DEVFS_GUID 
+$CONFIG_DEVFS_FS $CONFIG_EFI_PARTITION
fi
bool '  SGI partition support' CONFIG_SGI_PARTITION
bool '  Ultrix partition table support' CONFIG_ULTRIX_PARTITION
diff -ru linux-2.4.5/fs/partitions/check.c linux-2.4.5mw/fs/partitions/check.c
--- linux-2.4.5/fs/partitions/check.c   Mon Jun 25 14:45:01 2001
+++ linux-2.4.5mw/fs/partitions/check.c Mon Jun 25 15:45:32 2001
@@ -79,6 +79,20 @@
NULL
 };

+#ifdef CONFIG_DEVFS_GUID
+static devfs_handle_t guid_top_handle;
+
+#define GUID_UNPARSED_LEN 36
+static void
+uuid_unparse_1(efi_guid_t *guid, char *out)
+{
+   sprintf(out, "%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
+   guid->data1, guid->data2, guid->data3,
+   guid->data4[0], guid->data4[1], guid->data4[2], guid->data4[3],
+   guid->data4[4], guid->data4[5], guid->data4[6], guid->data4[7]);
+}
+#endif
+
 /*
  * disk_name() is used by partition check code and the md driver.
  * It formats the devicename of the indicated disk into
@@ -314,6 +328,101 @@
devfs_register_partitions (hd, i, hd->sizes ? 0 : 1);
 }

+#ifdef CONFIG_DEVFS_GUID
+/*
+  devfs_register_guid: create a /dev/guid entry for a disk or partition
+   if it has a GUID.
+
+  The /dev/guid entry will be a symlink to the "real" devfs device.
+  It is marked as "slave" of the real device,
+  to be automatically unregistered by devfs if that device is unregistered.
+
+  If the partition already had a /dev/guid entry, delete (unregister) it.
+  (If the disk was repartitioned, it's likely the

Re: user limits for 'security'?

2001-06-25 Thread LA Walsh


I suppose another question related to the first, is 'limit' checking
part of the 'standard linux security' that embedded Linux users might
find to be a waste of precious code-space?

-l

--
The above thoughts and| I know I don't know the opinions
writings are my own.  | of every part of my company. :-)
L A Walsh, law at sgi.com | Sr Eng, Trust Technology
01-650-933-5338   | Core Linux, SGI



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

Re: Microsoft and Xenix.

2001-06-25 Thread Kai Henningsen


[EMAIL PROTECTED] (Rob Landley)  wrote on 24.06.01 in 
<[EMAIL PROTECTED]>:

> Now if somebody here could just point me to a decent reference on A/UX -
> Apple's mid-80's version of Unix (for the early macintosh, I believe...)

http://www.google.com/search?q=%22%2ba/ux%22

Usually a good idea.



Also, you probably want to look at RFC 2235.

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

proc_file_read() question

2001-06-25 Thread Martin Wilck



Hi,

the "hack" below in proc_file_read() fs/proc/generic.c (2.4.5)
irritates me:

If I do use "start" for a pointer into a memory area
allocated in read_proc, will it be always guaranteed
that (start > page)?

If no, this will IMO lead to spuriously wrong output.
If yes, I'd like to understand why.

Regards & thanks,
Martin

/* This is a hack to allow mangling of file pos independent
 * of actual bytes read.  Simply place the data at page,
 * return the bytes, and set `start' to the desired offset
 * as an unsigned int. - [EMAIL PROTECTED]
 */
n -= copy_to_user(buf, start < page ? page : start, n);
if (n == 0) {
if (retval == 0)
retval = -EFAULT;
break;
}

*ppos += start < page ? (long)start : n; /* Move down the file */

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113



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

[PATCH] wrong disk index in /proc/stat

2001-06-25 Thread Martin Wilck



Hi,

I posted this patch already from my home mail account on June 20 (subject:
disk_index weirdness), but no one seems to have noticed - therefore I
try again. Those who _have_ noticed the other mail - sorry for bothering).

The disk_index routine erroneously adds 2 to the index of disks on the
first IDE controller which is wriong in 2.4, because disks are indexed
by major number now. The patch fixes this and adds support for some more
major numbers. (To fully benefit, DK_MAX_MAJOR in
include/linux/kernel_stat.h must be increased).

The patch is against plain 2.4.5.

Regards,
Martin

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113

diff -ru linux-2.4.5/include/linux/genhd.h linux-2.4.5mw/include/linux/genhd.h
--- linux-2.4.5/include/linux/genhd.h   Tue Mar 27 01:48:11 2001
+++ linux-2.4.5mw/include/linux/genhd.h Mon Jun 25 14:23:57 2001
@@ -248,21 +248,30 @@
unsigned int index;

switch (major) {
-   case DAC960_MAJOR+0:
-   index = (minor & 0x00f8) >> 3;
-   break;
case SCSI_DISK0_MAJOR:
index = (minor & 0x00f0) >> 4;
break;
case IDE0_MAJOR:/* same as HD_MAJOR */
case XT_DISK_MAJOR:
+   case IDE1_MAJOR:
+   case IDE2_MAJOR:
+   case IDE3_MAJOR:
+   case IDE4_MAJOR:
+   case IDE5_MAJOR:
index = (minor & 0x0040) >> 6;
break;
-   case IDE1_MAJOR:
-   index = ((minor & 0x0040) >> 6) + 2;
+   case SCSI_CDROM_MAJOR:
+   index = minor & 0x000f;
break;
default:
-   return 0;
+   if (major >= SCSI_DISK1_MAJOR && major <= SCSI_DISK7_MAJOR)
+   index = (minor & 0x00f0) >> 4;
+   else if (major >= DAC960_MAJOR && major <= DAC960_MAJOR + 7)
+   index = (minor & 0x00f8) >> 3;
+   else if (major >= IDE6_MAJOR && major <= IDE9_MAJOR)
+   index = (minor & 0x0040) >> 6;
+   else
+   return 0;
}
return index;
 }


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

Re: all processes waiting in TASK_UNINTERRUPTIBLE state

2001-06-25 Thread James Stevenson



Hi again

i have a stack now an

#0  schedule () at sched.c:536
#1  0x1002f932 in __wait_on_buffer (bh=0x50eb16e4) at  buffer.c:157
#2  0x10036f46 in block_read (filp=0x5009787c, buf=0x80c08f0
"¤\201", count=8192, ppos=0x5009789c) at
/home/mistral/dev/kernel/linux-2.4.5-um9/include/linux/locks.h:20
#3  0x1002eb4b in sys_read (fd=3, buf=0x80c00f0 "¤\201", count=8192)
at read_write.c:133
#4  0x100fb807 in execute_syscall (regs={regs = {3, 135004400, 8192,
1283476480, 0, 3212835652, 4294967258, 43, 43, 0, 0, 3,
1074582884, 35, 582, 3212835588, 43}}) at syscall_kern.c:332
#5  0x100fb926 in syscall_handler (unused=0x0) at
syscall_user.c:80

this should still be on #umldebug on irc.openproject.net
for the next few ours if anybodys intresting at taking a look though
gdb via a bot.

James

-- 
-
Web: http://www.stev.org
Mobile: +44 07779080838
E-Mail: [EMAIL PROTECTED]
  8:30pm  up 2 days, 42 min,  4 users,  load average: 1.00, 0.94, 0.64

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

user limits for 'security'?

2001-06-25 Thread LA Walsh


I've seen some people saying that user-limits are an essential part of a
secure system to prevent local DoS attacks.  Given that, should
a system call like 'fork' return -EPERM if the user has reached their
limit?

My local manpage (SuSE 7.2 system) says this under fork:

ERRORS
   EAGAIN fork  cannot allocate sufficient memory to copy the
  parent's page tables and allocate a task  structure
  for the child.
-
Should the man page be updated to reflect that EAGAIN is returned
when the user has reached their limit?  From a user-monitoring point
of view, it might be security relevant to know if a EAGAIN is being
returned because the system really is low on resources or if it
is a user hitting their limit.

--
The above thoughts and| I know I don't know the opinions
writings are my own.  | of every part of my company. :-)
L A Walsh, law at sgi.com | Sr Eng, Trust Technology
01-650-933-5338   | Core Linux, SGI



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

Re: MemShared == 0 ?

2001-06-25 Thread Erik Mouw


On Mon, Jun 25, 2001 at 11:21:55AM +0100, Rodrigo Ventura wrote:
> /proc> cat version meminfo
> Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024 (release)) #3 
>Mon Jun 18 19:00:11 WEST 2001
> total:used:free:  shared: buffers:  cached:
> Mem:  261779456 256925696  48537600 134025216 82280448
> Swap: 271425536 10993664 260431872 
> MemTotal:   255644 kB  \
> MemFree:  4740 kB   \
> MemShared:   0 kB  <<  What's the meaning of this? *

Check the lkml FAQ: http://www.tux.org/lkml/#s14-3


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft and Xenix.

2001-06-25 Thread Rob Landley

On Monday 25 June 2001 11:13, you wrote:

> 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits,"
>
> 1948 claude shannon A mathematical theory of information.
>
> without those you're kind in trouble on the computing front...

Yeah, I know I've bumped into that name (and probably taken notes) somewhere. 
 Hmmm...  Might be from "Where wizards stay up late", or might have been an 
article linked from slashdot...  (I don't THINK it was mentioned in 
"Hackers"...  Rodents, where was the reference...  Crystal fire?  That's 
mostly hardware.  Accidental Empries?  Doesn't sound right...  Can't have 
been "Fire in the valley" because I haven't read that yet, it's still sitting 
on the bookshelf.  Not soul of a new machine, that's post-digital Equipment 
Corporation...)

I THINK that's in the set of notes that's on the box that's not hooked up 
right now...  (Shortage of monitors at home.)

This was the dude who decided to apply a binary and boolean approach to 
electronic computation, right?  I KNOW I've read some stuff about him... late 
last year?

Now I remember.  Slashdot linked to his obituary:

http://www.bell-labs.com/news/2001/february/26/1.html

Rob

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

Re: all processes waiting in TASK_UNINTERRUPTIBLE state

2001-06-25 Thread James Stevenson



Hi

i have been looking at it a lot over the past few days i seem to be the
person who can trigger it easyest.

over the past couple of days i have been running with the
#define WAITQUEUE_DEBUG 1
no problems seem to have appeared there though and the bug still triggers.

On Mon, 25 Jun 2001, Jeff Dike wrote:

> [EMAIL PROTECTED] said:
> > I am running in to a problem, seemingly a deadlock situation, where
> > almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
> > All the process eventually stop responding, including login shell, no
> > screen updates, keyboard etc.  Can ping and sysrq key works.   I
> > traced the tasks through sysrq-t key.  The processors are in the idle
> > state.  Tasks all seem to get stuck in the __wait_on_page or
> > __lock_page.

i also seem to get ut ub __wait_on_buffer and ___wait_on_page

James
-- 
-
Web: http://www.stev.org
Mobile: +44 07779080838
E-Mail: [EMAIL PROTECTED]
  8:00pm  up 2 days, 12 min,  4 users,  load average: 1.41, 0.38, 0.40

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

Re: Microsoft and Xenix.

2001-06-25 Thread Kai Henningsen


[EMAIL PROTECTED] (Rob Landley)  wrote on 23.06.01 in 
<[EMAIL PROTECTED]>:

> on April 2, 1987.  (models 50, 60, and 80.)  The SAA/SNA push also extended
> through the System/370 and AS400 stuff too.  (I think 370's the mainframe
> and AS400 is the minicomputer, but I'd have to look it up.  One of them
> (AS400?) had a database built into the OS.  Interestingly, this is where SQL
> originated (my notes say SQL came from the System/370 but I have to
> double-check that, I thought the AS400 was the one with the built in
> database?).

The AS/400 is still going strong. It's a virtual machine based on a  
relational database (among other things), mostly programmed in COBOL (I  
think the C compiler has sizeof(void*) == 16 or something like that, so  
you can put a database position in that pointer), it doesn't know the  
difference between disk and memory (memory is *really* only a cache), and  
these days it's usually running on PowerPC hardware.

ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD  
Sockets. These days, it's often sold as a web server.

Main customer base seems to be medium large businesses and banks.

> Lotus-Intel-Microsoft Expanded Memory Specification), and "DOSShell" which
> conformed to the SAA graphical user interface guidelines.

Nope, the text user interface guidelines, a related but not the same  
beast. That's where F1 == Help is from, by the way.

In fact, the user interface part of SAA was (is?) called CUA. And many IBM  
text mode interfaces more or less follow it, including OS/400 (the os of  
the AS/400). Once upon a time, I had the specs for CUA.

> The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's first
> 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2 (1.0), or
> AIX.

The first 386 PCs where not from IBM, by the way. Was it Compaq?

> AIX was NOT fully SAA/SNA compliant,

AFAICT, nothing ever was fully SAA compliant, though some systems were  
more compliant than others.

> Hmmm...  Notes on the history of shareware (pc-write/bob wallace/quiicksoft,
> pc-file/pc-calc/jim button/buttonware, pc-talk/andrew flugelman, apparently
> the chronological order is andrew-jim-bob, and bob came up with the name
> "shareware" because "freeware" was a trademark of Headlands Press, Inc...)

That may be, but I believe the *concept* was invented in 1980 by Bill  
Basham, with the Apple ][ DOS replacement Diversi-DOS (which was the most  
popular of many versions to increase disk speed by about a factor of 5). I  
still remember discussions how copying this stuff was actually the right  
thing to do. Seems he's still in business as "Diversified Software  
Research", http://www.divtune.com/.

> running AIX.  The engineers (in Austin) whent on for the second generation
> Risc System 6000 (the RS/6000) with AIX version 3, launched February 15
> 1990. The acronym "POWER" stands for Performance Optimized WIth Enhanced
> Risc.

The PowerPC was split off from the POWER architecture, and then the POWER  
stuff was turned into the high end above PowerPC (with system prices about  
a factor of ten higher as the lower bound).

IBM developed a version of OS/2 2.0 for the PowerPC, but *never* marketed  
it - you could buy it if you knew the right number, but they never spent a  
single cent on advertizing - by the time it was done, IBM had given up on  
OS/2. Most OS/2 fans agreed that it was killed by IBM with extremely bad  
marketing.

These days, of course Apple builds the most PowerPC machines; Motorola and  
IBM produce the chips.

> Ummm...  GEM was the Geos stuff?

No. GEM, I believe, originally came from CP/M. Most popular as the  
windowing system of the Atari ST; given that someone did a quick-hack MS- 
DOS clone to support it on the 68K, it seems fairly obvious that by that  
time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know  
of that was actually worse than MS-DOS.)

Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line  
shell and desktop replacement for the Atari that was fairly successful  
shareware for a while ... now how was it called? The CLI was Mupfel  
(German for shell is Muschel, and there was a kid's TV character who  
pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another  
(Julian Reschke) wrote *the* German Atari ST book. This was a fairly  
prominent Atari ST area for a while, but somehow I never had one.

> Using 3d accelerator cards to play MPEG video streams is only now becoming
> feasable to do under X.  And it SHOULD be possible to do that through a
> 100baseT network, let alone gigabit, but the layering's all wrong...)

One might say it's time for X12, except the installed base of X11 has  
become too large.

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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot



Not /dev/hda42, thats odd. From 2.4.5 -> 2.4.6 ReiserFS would refuse to
mount the drive on startup.

I noticed in pre5 there was a reiserfs fix to something but im not sure if
its related or not.

My domain is also back so I'm going to resubscribe.

Shawn.

On Tue, 19 Jun 2001, Neil Brown wrote:

> On Tuesday June 19, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote:
> > >
> > > read_super_block: can't find a reiserfs filesystem on dev 03:42
> > > read_old_super_block: try to find super block in old location
> > > read_old_super_block: can't find a reiserfs filesystem on dev 03:42
> > > Kernel Panic: VFS: Unable to mount root fs on 03:42
> > >
> > > my super block broke somewhere?
> >
> > Out of curiousity, what device are you trying to boot from? 03:42, at least
> > according to linux/Documentation/devices.txt, corresponds to /dev/hda42.
>
> or, noting that kdevname used hexadecimal,
>   /dev/hdb2
>
> NeilBrown
>
> >
> > Is that really the disk you're trying to mount? I'm not familiar with how
> > some IDE RAID controllers present disks, but it was the first thing I
> > noticed.
> >
> > -Jeff
> >
> > --
> > Jeff Mahoney
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

problems with my plexwriter 8/4/32A drive..

2001-06-25 Thread JorgP


I am using AMD 1.2Gig w/ 512Meg Ram, MSI 6330-K7ProA motherboard.

hda: QUANTUM FIREBALLP LM10.2, ATA DISK drive
hdb: IBM-DPTA-372050, ATA DISK drive
hdc: ATAPI 52X CDROM, ATAPI CD/DVD-ROM drive
hdd: PLEXTOR CD-R PX-W8432T, ATAPI CD/DVD-ROM drive

base install is Mandrake 8.0 from CD
it did not work and then tried latest cooker kernel 2.4.5-8 same thing.
I have also tried redhat 7.1 with all recommended updates 2.4.3-12 kernel 
same thing.

using ide-scsi module.
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: PLEXTOR   Model: CD-R   PX-W8432T  Rev: 1.09
  Type:   CD-ROM ANSI SCSI revision: 02

when trying to mount a CD in the plextor the system accesses the drive for a 
few seconds then hangs the process hangs and can not be killed.
If I use X-CD-Roast it tries to access the drive and after a few seconds the 
CPU goes to 100% usage and hangs the machine, have to hard reset it can not 
sys-req it either.

The other CD-Rom drive works great.

This setup works great under a dual boot of Windows 2000, and I can access 
the drive and burn CD's all day long.

cdrecord --scanbus see's the drive the until the first time I try to access 
it the drive, then cdrecord --scanbus hangs.

Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling
Linux sg driver version: 3.1.17
Using libscg version 'schily-0.1'
scsibus0:
0,0,0 0) 'PLEXTOR ' 'CD-R   PX-W8432T' '1.09' Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *

I will attach my dmesg...

Please help.
Thanks
Jorg

Linux version 2.4.3-12 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red 
Hat Linux 7.1 2.96-85)) #1 Fri Jun 8 13:35:30 EDT 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1fff (usable)
 BIOS-e820: 1fff - 1fff3000 (ACPI NVS)
 BIOS-e820: 1fff3000 - 2000 (ACPI data)
 BIOS-e820:  - 0001 (reserved)
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux ro root=347 
BOOT_FILE=/boot/vmlinuz-2.4.3-12 hdd=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 1331.610 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2654.20 BogoMIPS
Memory: 509088k/524224k available (1246k kernel code, 10656k reserved, 93k data, 228k 
init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff  
CPU: After generic, caps: 0183f9ff c1c7f9ff  
CPU: Common caps: 0183f9ff c1c7f9ff  
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
PCI: Found IRQ 10 for device 00:07.2
PCI: The same IRQ used for device 00:07.3
Applying VIA PCI latency patch (found VT82C686B).
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
Starting kswapd v1.8
pty: 512 Unix98 ptys configured
block: queued sectors max/low 338074kB/207002kB, 1024 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA,

Re: Microsoft and Xenix.

2001-06-25 Thread Robert J.Dunlop

Hi,

On Mon, Jun 25, 2001 at 06:27:24PM +0100, [EMAIL PROTECTED] wrote:
> I first used  Unix on a PDP11/44 whilst studying for my Computer Engineering
> degree at Heriot-Watt University in Edinburgh.  I think they and Queen Margaret
> College, London were the first folk running Unix version 6 outside Bell Labs.

Hey! Don't forget UKC ;-) Cut my teeth on pdp11 v6 and VAXen BSD 4.1 once I got
away from the dreaded EMAS. Edinbugh Multi-Access System was the pitts.

> I then used SCO Xenix 286 on early Compaq 286 PC's.   Companies like Chase,
> Specialix and Stallion grew up as suppliers of intelligent RS-232 boards.  As
> a result of all these Xenix machines, Wyse sold a hell of a lot of WY50
> terminals.

Great days.  The business was so incestuous.  We seemed to swap engineers on a
regular basis.  Hacking drivers without kernel source and documentation that
always seemed at least a release behind.  Still keep a WY60 manual on my book
shelf and always regret losing the VT100 one.

> Who remembers terminals from Lear Siegler and Beehive.   All this was before
> networking came about.  Then the Chase Iolan to connect these same Wyse
> terminals to the SCO box but through one bit of co-ax instead of multi-core
> cables.  Also you could get 100m  away from your SCO box  with co-ax.

And the trouble we had explaining to customers that they had to buy a separate
SCO TCP/IP networking package just to hook up the IOLAN.

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

Oops in iput

2001-06-25 Thread Florian Lohoff



Hi,
oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

Intel BX chipset, SCSI Disks Symbios chipset - The crashing process
is the master process of "postfix" an MTA.

Just before the crash all processes on that machine started to segfault
in nameserver resolution (remote dns server) and after 2-3 minutes
this oops happened.



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

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address 4ed90398
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 4ed90330   ebx:    ecx:    edx: c01eef0c
esi: 4ed90330   edi: ce27ed00   ebp: 0002   esp: cf04ddac
ds: 0018   es: 0018   ss: 0018
Process master (pid: 297, process nr: 31, stackpage=cf04d000)
Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330  
   ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0  
   cfce5860 c0158be3 ced903e0 ceeda140  0002 ceeda140 ced90330 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] 
Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 

>>EIP; c0133ca7<=
Trace; c015882f 
Trace; c0158be3 
Trace; c011b26c 
Trace; c01262bd <__fput+25/54>
Trace; c011d2b5 
Trace; c012745c 
Trace; c0127453 
Trace; c01139bb 
Trace; c012634b 
Trace; c011073e 
Trace; c0113958 
Trace; c01184f4 
Trace; c011847d 
Trace; c0109fbb 
Trace; c0b1 
Trace; c0109583 
Trace; c010a100 
Code;  c0133ca7 
 <_EIP>:
Code;  c0133ca7<=
   0:   8b 46 68  mov0x68(%esi),%eax   <=
Code;  c0133caa 
   3:   85 c0 test   %eax,%eax
Code;  c0133cac 
   5:   74 09 je 10 <_EIP+0x10> c0133cb7 
Code;  c0133cae 
   7:   8b 40 18  mov0x18(%eax),%eax
Code;  c0133cb1 
   a:   85 c0 test   %eax,%eax
Code;  c0133cb3 
   c:   74 02 je 10 <_EIP+0x10> c0133cb7 
Code;  c0133cb5 
   e:   89 c3 mov%eax,%ebx
Code;  c0133cb7 
  10:   85 db test   %ebx,%ebx
Code;  c0133cb9 
  12:   74 10 je 24 <_EIP+0x24> c0133ccb 


1 warning issued.  Results may not be reliable.
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-5201-669912
 Why is it called "common sense" when nobody seems to have any?

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

Re: The latest Microsoft FUD. This time from BillG, himself.

2001-06-25 Thread Andreas Bombe


On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote:
> Name one thing Microsoft actually invented.  Other than Microsoft Bob.

I remember there being a web page where all of Microsoft's "innovations"
were listed and where they bought or stole it from.  The only things
that were really Microsoft's invention were, at that time, found to be
a) the .ini config file format (which has spread outside of the MS
world) and b) the annoying paper clip.

Does anyone have the URL handy?  Try finding that in a search engine...

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

Re: Bug in 3c905 driver.

2001-06-25 Thread Martin Dalecki

William Park wrote:
> 
> On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote:
> > Just a note...
> >
> > This card get's detected twofold by the plain 2.4.5 kernel.
> > It get's listed twice under both lspci and during the kernel boot
> > sequence on a HP LHr3 system.
> 
> I get only one message, I have 3c905CX and 2.4.5 kernel.  Maybe you have
> 2 cards inside? ;-)

Could you hand me your .config file over. Maybe there is something
sensitive
in the choices for PCI acess, Power management or not - or whatever else
it may be. I would like to confirm the true source of this error.
(Currently I'm guessing at a buggy compiler provided by SuSE or buggs
in the PCI setup code or some wired kind of BIOS configuration problem).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux and system area networks

2001-06-25 Thread Roland Dreier

I'd like to find out if anyone has thought about how Linux will handle
some of the new network technologies people are starting to push.
Specifically I'm talking about "System Area Networks," that is, things
like Infiniband, as well as TCP/IP offload.

In the past people have advocated VIA as a way to use network hardware
that provides reliability and remote DMA (RDMA). However, VI never
really caught on because it requires applications to be completely
rewritten. In addition, the corporate backers of VI seem to have
mostly given up on it.

Late last year, Network Appliance proposed something they called
"DASockets," which would mostly preserve socket semantics. However
that seems to have been put on hold.

Microsoft recently introduced something called "Winsock Direct" in W2K
Datacenter. For more info you can look at:

http://www.microsoft.com/windows2000/en/datacenter/help/default.asp?url=/WINDOWS2000/en/datacenter/help/WSD_and_SAN.htm

The rough idea is that WSD is a new user space library that looks at
sockets calls and decides if they have to go through the usual kernel
network stack, or if they can be handed off to a "SAN service
provider" which bypasses the network stack and uses hardware reliable
transport and possibly RDMA.

This means that all applications that use Winsock benefit from the
advanced network hardware. Also, it means that Windows is much easier
for hardware vendors to support than other OSes. For example,
Alacritech's TCP/IP offload NIC only works under Windows. Microsoft
is also including Infiniband support in Windows XP and Windows 2002.
(Intel will be pushing Infiniband onto motherboards pretty soon, which
will bring reliable transport, RDMA network hardware into the
mainstream)

So I guess my question is whether anyone has started thinking about
the architectural changes needed to make System Area Networking and
TCP/IP offload easier under Linux.

Thanks,
Roland
--
Roland Dreier<[EMAIL PROTECTED]>
GPG Key fingerprint = A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: VM tuning through fault trace gathering [with actual code]


On 25 Jun 2001, John Fremlin wrote:

> Last year I had the idea of tracing the memory accesses of the system
> to improve the VM - the traces could be used to test algorithms in
> userspace. The difficulty is of course making all memory accesses
> fault without destroying system performance.

Sounds like a cool idea.  One thing you should keep in mind
though is to gather traces of the WHOLE SYSTEM and not of
individual applications.

There has to be a way to balance the eviction of pages from
applications against those of other applications.

regards,

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

Re: Where is check for superuser in TCP port bind.

2001-06-25 Thread Ian Stirling


> 
> Obviously (to me) this check is in tcp_v4_get_port().
> But, I can't find it, or perhaps it's better hidden than I thought.
> Or maybe I'm just very confused.
> Any help would be most welcome.

The above poster was of course deeply stupid, and could have done with
more sleep :)
It's in net/ipv4/af_inet.c

I was looking for some way of letting users own devices, so they
can do some subset of the operations reserved for root on their device.

Further reading led to "route by owner" in netfilter, but it's not quite
it.
This would let me do something like:
ifconfig eth0:www 1.2.3.4
route add default 1.2.3.4 -user www

But would still not let www bind low ports on eth0:www.
There seem to be a few ways to do this. 
Teach capable() about owned routes.

Make interfaces/aliases directly ownable, add  CAP_NET_BIND_ANY 
so you can only bind to an interface you own, or if you have 
CAP_NET_BIND_ANY.

You need CAP_NET_BIND_ANY to chown an interface.

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

Re: What are the VM motivations??


On Mon, 25 Jun 2001, Colonel wrote:

> As a physicist, I learned long ago that if you cannot use the back of
> an envelope and explain your theory to a secretary, you do not
> understand it.  It has only been revealed recently where some VM
> design information may be hidden, and it's apparently out of date.
> Maintenance requires good documentation, especially in critical areas.
> I hope that your suggestion succeeds, and that a document is passed
> around, but I'll bet a large amount that it doesn't happen.

Your contributions are welcome. I'm looking forward to your
updated documentation and patches.

regards,

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

Re: What are the VM motivations??


On Sun, 24 Jun 2001, Colonel wrote:

> >May I suggested an algorithm?
> >
> >  - Write down what you think the optimization constraints are.
> >(be specific, for example, enumerate all the flavors of page types -
> >process code, process data, page cache file data, page cache swap
> >cache, anonymous, shmem, etc.)
> >
> >  - Write down what you think the current algorithms are.
> >(again, be specific, use file names, function names, pseudocode and 
> >snippets of existing code.)
> >
> >  - Send it to Rik.  He'll tell you if it's right.
> 
> POST IT.  Give the rest of us some clues and the opportunity to check
> evaluator's replies.

Why don't YOU post it?

All I've seen from you are complaints and insults, nothing
constructive yet.

regards,

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

Re: Some experience of linux on a Laptop

2001-06-25 Thread Joseph Pingenot


>From Android on Sunday, 24 June, 2001:
>>I have come to the conclusion that linux is NOT suitable for the general 
>>desktop market.
>I have to disagree on this. It runs fine on most PC's, as they use standard 
>devices.  Just say NO to anything proprietary. This includes Toshiba. Makers of such 
>odd machines should supply their own native drivers if they want to be supported.

I would have to concur, if it weren't for almost all manufacturers doing this.
  Grr.

>>5: Better support for toshiba computers... well try =)
>Talk to Toshiba. See if they are willing to part with "secret" information 
>so that you can create specific drivers for Linux. After that, I bet your next comp. 
>won't be from them. :-)

I've been talking sometimes on the Toshiba list, trying to get Toshiba
  to support Linux officially (they do *unofficially*, as shown by the
  inclusion of Linux in a lot of their website).  However, it doesn't
  look likely.
I'd like everyone's help pressing Toshiba to open up some more of
  their specs.  That'd be the ideal solution.  I guess I'd go for
  binary-only drivers, if they'd maintain them well.  It's sub-optimal,
  but it's a workaround for now.  :)
If you have Toshiba hardware, *please* tell them to support Linux
  every chance you get.  Maybe after enough feedback from the
  community, they'll wise up.

Oh, FYI, I am running the unstable distribution of Debian with
  the 2.4.5 kernel.  Everything on my Satellite 1605CDS laptop works, 
  with the notable exception of the scheiss-Winmodem.  I've been
  talking with Conextant (the winmodem chipset manufacturers), so
  I'll see where that gets me.  Be sure that if I get sufficient info
  (and time!!), I'll post what I know and *maybe* even deveop a
  pseudo-serial port driver.  That'd require a *lot* of time, though,
  and time is in very short supply right now.  :)

Anyway, the basic message I wanted to convey was that you need to pressure
  your hardware manufacturer of choice to open up their specs so that
  *everyone* can use their hardware with whatever software they choose.
  It helps find bugs ("your spec says X, but the hardware *really* does
  Y"), and hey, they can hire only a minimal staff to do Linux support
  (if they offload the driver development and maintenance to the kernel
  developers.  :)
If something doesn't work with Linux, given experience and the sheer
  number of developers, chances are *very* good that the manufacturer
  is hoarding the specs.  Unfortunately, it's a common practice that
  requires a good kick in the hiney.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: all processes waiting in TASK_UNINTERRUPTIBLE state


On Mon, 25 Jun 2001, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Can you give more details?  Was there an aic7xxx scsi driver on the
> > box? run_task_queue(_disk) should eventually unlock those pages but
> > they remain locked.  I am trying to narrow it down to fs/buffer code
> > or the SCSI driver aic7xxx in my case.
> 
> Rik would be the one to tell you whether there was an aic7xxx driver
> on the physical box.  There obviously isn't one on UML, so if we're
> looking at the same bug, it's in the generic code.

The box has as AIC-7880U controller. OTOH, my dual P5 also has
an AIC7xxx controller and I've never seen the problem there...

On our quad Xeon this problem really seems to be phase-of-moon
related; it hasn't shown up in the last 5 days or so under heavy
stress testing, but when the kernel is compiled just a little bit
different it doesn't happen. ;)

regards,

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

RE: ACPI + Promise IDE = disk corruption :-(((

2001-06-25 Thread Grover, Andrew


Their processor power state code looks dormant at the moment, so they
haven't hit this particular issue.

They have in the past run into a number of problems, and submitted fixes.
The Linux version is getting much wider testing right now.

-- Andy

PS Just FreeBSD, no Net or OpenBSD just yet.

> From: Chris Wedgwood [mailto:[EMAIL PROTECTED]]
>> It's just *one* issue that has generated all the disk corruption
>> reports.
> 
> The same code is used for FreeBSD and friends too right? Are they
> seeing anywhere near the same number of types of poroblems Linux is?

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

Re: [patch] rio500 devfs support

2001-06-25 Thread Greg KH


On Tue, Jun 19, 2001 at 05:52:24PM -0500, Gregory T. Norris wrote:
> The attached diff adds devfs support to the rio500 driver, so that
> /dev/usb/rio500 gets created automagically.  It was generated against
> 2.4.5, but probably applies fine against any recent kernel.  Comments
> are welcome (but be gentle, this is my first attempt at a kernel
> patch :-).

Here's a small change that makes the node a child of the usb devfs
entry.  It also enables the node to only be present when the device is
actually present.  The patch is against 2.4.6-pre5.

thanks,

greg k-h


diff -Nru a/drivers/usb/rio500.c b/drivers/usb/rio500.c
--- a/drivers/usb/rio500.c  Mon Jun 25 10:31:03 2001
+++ b/drivers/usb/rio500.c  Mon Jun 25 10:31:03 2001
@@ -38,13 +38,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rio500_usb.h"
 
 /*
  * Version Information
  */
-#define DRIVER_VERSION "v1.0.0"
+#define DRIVER_VERSION "v1.1"
 #define DRIVER_AUTHOR "Cesar Miquel <[EMAIL PROTECTED]>"
 #define DRIVER_DESC "USB Rio 500 driver"
 
@@ -60,6 +61,7 @@
 
 struct rio_usb_data {
 struct usb_device *rio_dev; /* init: probe_rio */
+devfs_handle_t devfs;   /* devfs device */
 unsigned int ifnum; /* Interface number of the USB device */
 int isopen; /* nz if open */
 int present;/* Device is present on the bus */
@@ -69,6 +71,8 @@
struct semaphore lock;  /* general race avoidance */
 };
 
+extern devfs_handle_t usb_devfs_handle;/* /dev/usb dir. */
+
 static struct rio_usb_data rio_instance;
 
 static int open_rio(struct inode *inode, struct file *file)
@@ -416,6 +420,15 @@
return read_count;
 }
 
+static struct
+file_operations usb_rio_fops = {
+   read:   read_rio,
+   write:  write_rio,
+   ioctl:  ioctl_rio,
+   open:   open_rio,
+   release:close_rio,
+};
+
 static void *probe_rio(struct usb_device *dev, unsigned int ifnum,
   const struct usb_device_id *id)
 {
@@ -439,6 +452,14 @@
}
dbg("probe_rio: ibuf address:%p", rio->ibuf);
 
+   rio->devfs = devfs_register(usb_devfs_handle, "rio500",
+   DEVFS_FL_DEFAULT, USB_MAJOR,
+   RIO_MINOR,
+   S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP |
+   S_IWGRP, _rio_fops, NULL);
+   if (rio->devfs == NULL)
+   dbg("probe_rio: device node registration failed");
+   
init_MUTEX(&(rio->lock));
 
return rio;
@@ -448,6 +469,8 @@
 {
struct rio_usb_data *rio = (struct rio_usb_data *) ptr;
 
+   devfs_unregister(rio->devfs);
+
if (rio->isopen) {
rio->isopen = 0;
/* better let it finish - the release will do whats needed */
@@ -461,15 +484,6 @@
 
rio->present = 0;
 }
-
-static struct
-file_operations usb_rio_fops = {
-   read:   read_rio,
-   write:  write_rio,
-   ioctl:  ioctl_rio,
-   open:   open_rio,
-   release:close_rio,
-};
 
 static struct usb_device_id rio_table [] = {
{ USB_DEVICE(0x0841, 1) },  /* Rio 500 */

Re: Microsoft and Xenix.

2001-06-25 Thread Wayne . Brown




Beehive -- there's a name I haven't heard in a long time!  The ones I remember
had dual floppy drives and ran CP/M.  I last saw one in about 1985.

Wayne




[EMAIL PROTECTED] on 06/25/2001 12:11:01 PM

To:   William T Wilson <[EMAIL PROTECTED]>
cc:   Rob Landley <[EMAIL PROTECTED]>, "Eric W. Biederman"
  <[EMAIL PROTECTED]>, Alan Chandler <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: Microsoft and Xenix.



Hi,

I first used  Unix on a PDP11/44 whilst studying for my Computer Engineering
degree at Heriot-Watt University in Edinburgh.  I think they and Queen
Margaret
College, London were the first folk running Unix version 6 outside Bell Labs.
If anyone knows where Patrick O'Callaghan is now (ask him).

Another Unix like OS was Cromemco Cromix running on  bank switched Z80 S-100
kit.(later 68000).

I then used SCO Xenix 286 on early Compaq 286 PC's.   Companies like Chase,
Specialix and Stallion grew up as suppliers of intelligent RS-232 boards.  As
a result of all these Xenix machines, Wyse sold a hell of a lot of WY50
terminals.

Who remembers terminals from Lear Siegler and Beehive.   All this was before
networking came about.  Then the Chase Iolan to connect these same Wyse
terminals to the SCO box but through one bit of co-ax instead of multi-core
cables.  Also you could get 100m  away from your SCO box  with co-ax.

--
Andrew Smith in Edinburgh


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

Re: Microsoft and Xenix.

2001-06-25 Thread asmith


Hi,

If you're really keen on old mags and manuals I'll go up to attic and look
around.  I know there are old SCO Xenix & TCP/IP, as well as Byte and Dr Dobbs

On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote:
--

Andrew Smith in Edinburgh

> Sorry, but I'm hanging on to my old computer manuals.  The AIX manuals in
> particular have sentimemtal value for me.
>
> OTOH, I have quite a few old computer magazines (from the 80's) like Byte,
> Infoworld, etc.  I've been intending to get rid of them for some time now, but
> hated just to throw them away.  They're in storage in a neighboring state right
> now, but my wife probably will be driving there in the next couple of weeks to
> pick up a few things.  If you're interested, she could bring back the magazines
> and I can tell you exactly what I have.  You're welcome to them if you want
> them.
>
> Wayne
>
>
>
>
> Rob Landley <[EMAIL PROTECTED]> on 06/24/2001 09:32:43 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   Wayne Brown/Corporate/Altec@Altec, John Adams <[EMAIL PROTECTED]>
> cc:   [EMAIL PROTECTED]
>
> Subject:  Re: Microsoft and Xenix.
>
>
>
> On Saturday 23 June 2001 22:41, [EMAIL PROTECTED] wrote:
> > Ah, yes, the RT/PC.  That brings back some fond memories.  My first
> > exposure to Unix was with AIX on the RT.  I still have some of those
> > weird-sized RT AIX manuals around somewhere...
> >
> > Wayne
>
> Ooh!  Old manuals!
>
> Would you be willing to part with them?
>
> I am collecting old manuals, and old computing magazines.  I even pay for
> postage, with a bit of warning that they're coming...
>
> Rob
>
>
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>


--



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

Re: Microsoft and Xenix.

2001-06-25 Thread asmith

Hi,

I first used  Unix on a PDP11/44 whilst studying for my Computer Engineering
degree at Heriot-Watt University in Edinburgh.  I think they and Queen
Margaret
College, London were the first folk running Unix version 6 outside Bell Labs.
If anyone knows where Patrick O'Callaghan is now (ask him).

Another Unix like OS was Cromemco Cromix running on  bank switched Z80 S-100
kit.(later 68000).

I then used SCO Xenix 286 on early Compaq 286 PC's.   Companies like Chase,
Specialix and Stallion grew up as suppliers of intelligent RS-232 boards.  As
a result of all these Xenix machines, Wyse sold a hell of a lot of WY50
terminals.

Who remembers terminals from Lear Siegler and Beehive.   All this was before
networking came about.  Then the Chase Iolan to connect these same Wyse
terminals to the SCO box but through one bit of co-ax instead of multi-core
cables.  Also you could get 100m  away from your SCO box  with co-ax.

--
Andrew Smith in Edinburgh

On Sun, 24 Jun
2001, William T Wilson wrote:

> On Sun, 24 Jun 2001, Rob Landley wrote:
>
> > I know the geos had nothing to do with digital, it started as a
> > windowing GUI for the commodore 64, if you can believe that...
>
> I've actually got a copy, but it's for the Apple // :}
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: Bug in 3c905 driver.

2001-06-25 Thread William Park


On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote:
> Just a note...
> 
> This card get's detected twofold by the plain 2.4.5 kernel.
> It get's listed twice under both lspci and during the kernel boot
> sequence on a HP LHr3 system.

I get only one message, I have 3c905CX and 2.4.5 kernel.  Maybe you have
2 cards inside? ;-)

-- 
William Park, Open Geometry Consulting, <[EMAIL PROTECTED]>
8 CPUs cluster, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Sc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Making a module 2.4 compatible

2001-06-25 Thread Richard B. Johnson

On Mon, 25 Jun 2001, Timur Tabi wrote:

> ** Reply to message from James Lamanna <[EMAIL PROTECTED]> on Sat, 23
> Jun 2001 22:10:58 -0700
> 
> 
> > It would be nice to have it working under 2.4, so is there someplace
> > that outlines some of the major things that would have changed so I can
> > update the module accordingly?
> 
> Unfortunately, no.  But if it turns out I'm wrong, please let me know what you
> find.
> 

As a start:

wait_queue_head_t   Now defined.
You can do '#if !defined(...)` and make code changes backwards compatible.

Macro, THIS_MODULE  is now the first member of struct file_operations.

Include   __init data type for one-time initialization code
or data.
This is new, hense not backwards compatible.

Explicit initialization of spin-locks, SPIN_LOCK_UNLOCKED and/or
spin_lock_init(spinlock_t *);
If you fix this, it's backwards compatible.

ioremap() and friends is now required even for low memory stuff.
You can no longer access this with a simple pointer, you must
use readl()/writel(), etc., for proper defererence. If you fix
this, it's backwards compatible.

These changes should get your module to compile (or nearly so).

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

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

supermount

2001-06-25 Thread Sam Halliday


This email was delivered to you by The Free Internet,
a Business Online Group company. http://www.thefreeinternet.net
---
hello,
i am fairly new to linux, i need it's fast number crunching powers
for my research... and i have only recently begun to have a look at the
kernel (i believe every workman should know his tools). but i have
noticed that supermount is not a standard part of the project, is there
any reason why this is? is it due to man power? i would have been less
shocked by the absense of other features in the kernel such as sound and
radio support, supermount seems to me to be essential in any operating
system.
i apologise if this is a very silly question or if i have posted
this question in the wrong place, but please excuse me, im new to this
whole world.

and keep up the good work, i wish i knew more about the whole thing so i
could contribute something.

Sam, Ireland

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

Bug in 3c905 driver.

2001-06-25 Thread Martin Dalecki


Just a note...

This card get's detected twofold by the plain 2.4.5 kernel.
It get's listed twice under both lspci and during the kernel boot
sequence on a HP LHr3 system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: all processes waiting in TASK_UNINTERRUPTIBLE state

2001-06-25 Thread Bulent Abali




>[EMAIL PROTECTED] said:
>> I am running in to a problem, seemingly a deadlock situation, where
>> almost all the processes end up in the TASK_UNINTERRUPTIBLE state.
>> All the process eventually stop responding, including login shell, no
>> screen updates, keyboard etc.  Can ping and sysrq key works.   I
>> traced the tasks through sysrq-t key.  The processors are in the idle
>> state.  Tasks all seem to get stuck in the __wait_on_page or
>> __lock_page.
>
>I've seen this under UML, Rik van Riel has seen it on a physical box, and
we
>suspect that they're the same problem (i.e. mine isn't a UML-specific
bug).

Can you give more details?  Was there an aic7xxx scsi driver on the box?
run_task_queue(_disk) should eventually unlock those pages
but they remain locked.  I am trying to narrow it down to fs/buffer
code or the SCSI driver aic7xxx in my case. Thanks. /bulent



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

supermount

2001-06-25 Thread Sam Halliday


This email was delivered to you by The Free Internet,
a Business Online Group company. http://www.thefreeinternet.net
---
hello, i have only been using linux for about a year, i am a physicist
and i need its fast number crunching for my programs, i have recently
become interrested in the kernel (i believe everyone should have some
understanding of their tools),

i have noticed supermount is not a standard part of this project, is
there a good reason why this is? i apologise if this is a very silly
question as i am sure it is, but it really does seem to me to be an
essential feature, are there any plans to include it as a standard
feature or is this due to man-power? i know patches do exist out there
(all beit, really hard to find for recent 2.4.5)

anyways, keep up the good work, i wish i knew enough about the whole
thing to help out in some way,

Sam, Ireland

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

Re: Making a module 2.4 compatible

2001-06-25 Thread Timur Tabi


** Reply to message from James Lamanna <[EMAIL PROTECTED]> on Sat, 23
Jun 2001 22:10:58 -0700


> It would be nice to have it working under 2.4, so is there someplace
> that outlines some of the major things that would have changed so I can
> update the module accordingly?

Unfortunately, no.  But if it turns out I'm wrong, please let me know what you
find.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

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

Re: SMP+USB still crashes in 2.4.6-pre5

2001-06-25 Thread Jakob Borg


On Sun, Jun 24, 2001 at 01:52:37PM +0100, Alan Cox wrote:
> > Just wanted people to know that the same problem I reported about 2.4.4 a
> > while back is still present in 2.4.6-pre6 (hard crash when doing "cat
> > whatever > /dev/dsp1" where /dev/dsp1 is an external USB audio device, where
> > "hard crash" means a freeze followed by "wait on irq" message as reported
> > earlier).
> 
> Does this happen on 2.4.5-ac kernel as well ?

The same problem is present in -ac18.

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

Re: loop device broken in 2.4.6-pre5

2001-06-25 Thread Rogier Wolff


[EMAIL PROTECTED] wrote:
> From: Jari Ruusu <[EMAIL PROTECTED]>
> 
> File backed loop device on 4k block size ext2 filesystem:
> 
> # dd if=/dev/zero of=file1 bs=1024 count=10
> 10+0 records in
> 10+0 records out
> # losetup /dev/loop0 file1
> # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
> dd: /dev/loop0: No space left on device
> 9+0 records in
> 8+0 records out
> # tune2fs -l /dev/hda1 2>&1| grep "Block size"
> Block size:   4096
> # uname -a
> Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown
> 
> Stock 2.4.5 and 2.4.5-ac15 don't have this problem.
> 
> I am not sure there is an error here.

How about:

dd if=/dev/hda1 of=disk.img bs=1k 
mount disk.img /mnt/d1 -o loop


If the filesystem on hda1 happens to use the last 2k of the partition,
and the partition size is 2k mod 4k, then I get a non-working disk.img
if I don't pad the disk.img file with another 2k. And then I might
trip up the "how big is this partition" code in the fs-driver

Roger. 

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

Re: [OT] Re: Thrashing WITHOUT swap.


On Monday 25 June 2001 18:16, Colonel wrote:
> In clouddancer.list.kernel, you wrote:
> >Further to that, I followed Alan's lead and installed xfce.  My laptop,
> > which was really suffering under Gnome with 64 meg (much more so under
> > KDE) is suddenly light on its feet.  Not to mention that it built from
> > source in under 10 minutes and installed with zero 'interesting
> > problems'.
> >
> >After another year of optimizing the kernel to handle bloatware better,
> > and at the same time encouraging the 'big desktop' side of Linux to
> > follow the lead of these lightweight alternatives[1] we will be looking
> > pretty good.
>
> Had you tried fvwm-1.24r (the original) ?  It was designed long ago to
> be lean and fast on the desktop.  I know it whips KDE.

Yes, I did.  It's even faster than xfce but there's one problem: it just 
isn't very much like a modern desktop.  xfce is, to a surprising degree, like 
a modern desktop.  It's roughly equivalent to W95 I'd say - more 
sophisticated in some areas, less in others.  Oh, did I mention I haven't run 
into a bug yet?  It's true.

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

Re: Re: AMD thunderbird oops

2001-06-25 Thread Luigi Genoni



Have you considered to change your dimm at all?
If they are bugged they should be under warranty.

Luigi


On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:

> Thanks,
> I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan 
>in the case. (real nice case).
>
> I think it is the memory, as yesterday my gcc was bombing with 'internel 
>compiler error', which is usually a good mem tester.  So I started setting mem=64m 
>and things worked better and the install went all the way through.  I think I need to 
>slow my drams down a bit or add some delay in the bios settings.
>
>The oops says something like 'kernel null pointer at address 0x00'.  How do I 
>'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am 
>forced to reboot and manually run e2fsck?
>
> Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message 
>that says Error 'missing seperator'.  What does that mean?  It stops in the 
>drivers/net dir when I get this message?
>
> Thanks
> Joe
>
> Alan Cox <[EMAIL PROTECTED]> wrote:
> > > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) 
>processor  / 512Meg of RAM, and an Asus kt7a motherboard.  >
> > It is oppsing left and right.  I recompiled the kernel with Athelon as the CPU but 
>keep getting these oopses..
> >
> > I also get these same problems while trying to install RH 7.1
> >
> > Anyone know is this a supported processor / MB and has anyone had these problems?
>
> Random oopses normally indicate faulty board cpu or ram (and the fault may
> even just be overheating or dimms not in the sockets cleanly). I doubt its
> the board design or model that is the problem, you probably jut have a faulty
> component somewhere if its oopsing randomly even during installs and stuff
>
> memtest86, and heatsink compound may be your best friends
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: For comment: draft BIOS use document for the kernel

2001-06-25 Thread Timur Tabi


** Reply to message from Eric W. Biederman <[EMAIL PROTECTED]> on 23 Jun
2001 14:26:32 -0600


> Pretty decent.  It misses a lot of hardware details that we still
> depend on the BIOS to reliably setup for us.

You're right, it does.  I think that information should be added.  It's a way
for BIOS programmers to know whether or not their BIOS is missing anything
obvious.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

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

Re: Thrashing WITHOUT swap.

2001-06-25 Thread Mike Galbraith


On 25 Jun 2001, Xavier Bestel wrote:

> On 24 Jun 2001 22:36:25 +0100, Alan Cox wrote:
> > > recompiled it yet).  I have a 140 mb swap partition set up but at the time
> > > this happened it was OFF.  I was (still am) running X + twm + two xterms
> > >
> > > top gives me:
> > > mem: 62144k av, 61180k used, 956k free, 0k shrd, 76 buff, 2636 cached
> > > swap: 0k av, 0k used, 0k free [as expected]
> >
> > Not as expected - 0k used 0k free - you have no swap
>
> That's what he said. *WITHOUT* swap.

:)) yeah, exactly what Alan said.

-Mike

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

Re: Re: AMD thunderbird oops

2001-06-25 Thread joeja

Thanks, 
I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan in 
the case. (real nice case). 

I think it is the memory, as yesterday my gcc was bombing with 'internel compiler 
error', which is usually a good mem tester.  So I started setting mem=64m and things 
worked better and the install went all the way through.  I think I need to slow my 
drams down a bit or add some delay in the bios settings.  

   The oops says something like 'kernel null pointer at address 0x00'.  How do I 
'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am 
forced to reboot and manually run e2fsck?  

Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message 
that says Error 'missing seperator'.  What does that mean?  It stops in the 
drivers/net dir when I get this message?

Thanks
Joe

Alan Cox <[EMAIL PROTECTED]> wrote:
> > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) 
>processor  / 512Meg of RAM, and an Asus kt7a motherboard.  > 
> It is oppsing left and right.  I recompiled the kernel with Athelon as the CPU but 
>keep getting these oopses..
> 
> I also get these same problems while trying to install RH 7.1
> 
> Anyone know is this a supported processor / MB and has anyone had these problems?

Random oopses normally indicate faulty board cpu or ram (and the fault may 
even just be overheating or dimms not in the sockets cleanly). I doubt its
the board design or model that is the problem, you probably jut have a faulty
component somewhere if its oopsing randomly even during installs and stuff

memtest86, and heatsink compound may be your best friends

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

Re: What are the VM motivations??


On Monday 25 June 2001 17:46, Colonel wrote:
> >> POST IT.  Give the rest of us some clues and the opportunity to check
> >> evaluator's replies.
> >
> >Well, if you try that strategy you'll find you never get around to posting
> > it because you'll be too worried about getting it right.  The point is
> > not to get it right, it's to get a starting point down on (virtual)
> > paper.  I'd strongly suggest passing something like that around for
> > comment privately first.
>
> Well, it does seem that some ego is involved here...

Not in this case.  Do it whichever way you want, the point is: do it (don't 
just talk about it)

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

Re: [OT] Re: Thrashing WITHOUT swap.

2001-06-25 Thread Colonel


In clouddancer.list.kernel, you wrote:
>
>Further to that, I followed Alan's lead and installed xfce.  My laptop, which 
>was really suffering under Gnome with 64 meg (much more so under KDE) is 
>suddenly light on its feet.  Not to mention that it built from source in 
>under 10 minutes and installed with zero 'interesting problems'.
>
>After another year of optimizing the kernel to handle bloatware better, and 
>at the same time encouraging the 'big desktop' side of Linux to follow the 
>lead of these lightweight alternatives[1] we will be looking pretty good.


Had you tried fvwm-1.24r (the original) ?  It was designed long ago to
be lean and fast on the desktop.  I know it whips KDE.

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

Re: Kernel 2.4.5 crash

2001-06-25 Thread Colonel


In clouddancer.list.kernel, you wrote:
>
>Hi all,
>
>Haven't been on this list for a while, and don't really know if this is the 
>right place for this message... If not, pls let me know.
>...
>Hope you guys can do something with this message!

Nope.  You need to run it thru ksymoops before the wizard's crystal
balls will clear sufficiently to help.  Look in /usr/src/linux/scripts
for clues.

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

Re: [UPDATE] Directory index for ext2

On Monday 25 June 2001 11:46, Tony Gale wrote:
> After some testing, removing the grsecurity patch seems to have solved
> the disappearing-free-space problem. Now just need to find out why.
>
> On 20 Jun 2001 18:58:43 +0200, Daniel Phillips wrote:
> > On Wednesday 20 June 2001 16:59, Tony Gale wrote:
> > > The main problem I have with this is that e2fsck doesn't know how to
> > > deal with it - at least I haven't found a version that will. This makes
> > > it rather difficult to use, especially for your root fs.
> >
> > Good, the file format isn't finalized, this is only recommended for use
> > on a test partition.
>
> It was a test partition, just happended to be a root one. AFAIAA, isn't
> the fact that the file format may change irrelevant. You want people to
> test this stuff or not? If it's not tested on a root fs then how do you
> know there won't be any problems.
>
> Sorry, but when someone reports a problem, and then you say, well don't
> test it like that then, it is really not acceptable.

Sure, if your root partition is expendable, by all means go ahead.  Ted has 
already offered to start the required changes to e2fsck, which reminds me, I 
have to send the promised docs.  For now, just use normal fsck and it will 
(in theory) turn the directory indexes back into normal file blocks, and have 
no effect on inodes.  Lets take advantage of the opportunity to test that 
feature.  The new improved e2fsck should be capable of re-adding the indexes, 
so we'll get to test that too ;-)

Lets continue this privately and see what's going on with your inode leak.

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

Re: 2.4.5-ac12 kernel oops

2001-06-25 Thread Colonel


In clouddancer.list.kernel, you wrote:
>
>On Mon, 25 Jun 2001 08:15:49 -0700 (PDT), 
>[EMAIL PROTECTED] (Colonel) wrote:
>>ksymoops 2.4.1 on i686 2.4.5-ac12.  Options used
>>Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says 
>c01aad00, System.map says c014cba0.  Ignoring ksyms_base entry
>>Why the symbol mismatch?
>
>The mismatch is caused by two variables called partition_name.  What
>does 'nm vmlinux | grep partition_name' show?  Probably one

Can't run that, but : 

grep "partition_name" System.map-2.4.5-ac12 
c014cba0 t partition_name
c01aad00 T partition_name


>partition_name at c01aad00 and another at c014cba0.  Both
>fs/partitions/msdos.c and drivers/md/md.c define that symbol, md

and I have both in the kernel.

>exports its version.  A good reason why exported symbols should have
>unique names.

Only the raid5 was active, the msdos stuff is a module for 'just in
case'.  Something else triggered this, I've run raid for a long time
without problems.



>>Why ignore /proc over the System.map?
>
>ksymoops has a hierarchy of trust.  System.map is more trustworthy than
>/proc/ksyms because ksyms changes, especially if you rebooted after the
>oops and before running ksymoops.

Hmm, I would have thought that /proc was more up to date, because it
would reflect changes.  No reboot, never even considered it (I've
rescued too many junior sysadmins that think rebooting is _the_ answer).




-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

[OT] Re: Thrashing WITHOUT swap.