linux crashes when i try to burn audio cd's

[Michael]

I'm using kernel 2.2.16-22 w/ RedHat 7.0 w/ cdrecord 1.9. I have a P133 w/
64M RAM w/ a Smart & Friendly 2006 Plus SCSI CD-R. It burns data discs
without problem but when I try to burn an audio disc Linux comes to a
complete halt. I can't get any console or network response and no error
messages appear or get logged. I've tried both wav and cdr sound files. In
Windows the audio discs burn without problems.

Thanks.

*^*^*^*
Michael McGlothlin <[EMAIL PROTECTED]>
http://www.kavlon.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: Longstanding APIC/NE2K bug

[Jens Gecius]

[EMAIL PROTECTED] writes:

> There has been a bug in the 2.4.x series of kernels for a long time (at
> least -pre9) concerning SMP and ne2k-pci.
> 
> Maciej W. Rozycki posted a patch back during 2.4.0 that fixed this problem
> "[patch] 2.4.0, 2.4.0-ac12: APIC lock-ups" in late January.  I've been
> trying new kernels regularly since, and the patch doesn't seem to have
> made it in (tested 2.4.2, .3, .4 and .5).  Falling back on my patched
> 2.4.0 works fine.
> 
> Symptoms: Network driver locks up.  Repeated messages of "ETH0: Transmit
> timeout" occurs.  Unloading and reloading network drivers does not help,
> reboot is required.  Usually only triggered by heavy network traffic
> (300-400 megs at 700k or so usually does it).

This fits exactly my problems I mentioned a couple weeks ago. Same
question here. Therefore my question: can we expect to see this patch
implemented? If not, any other suggestions?

-- 
Tschoe,Get my gpg-public-key here
 Jens http://gecius.de/gpg-key.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] HotPlug CPU patch against 2.4.5

[Alexander Viro]

On Sun, 17 Jun 2001, Rusty Russell wrote:

> In message <[EMAIL PROTECTED]> you write:
> > In article  you wrote:
> > >   # Up...
> > >   echo 1 > /proc/sys/cpu/1
> > 
> > Wouldn't /proc/sys/cpu//enable be better?  This way other per-cpu
> > sysctls could be added more easily...
> 
> Yep.  But rewrite the sysctl crap first to make dynamically adding and
> deleting entries sane.

I had, actually. 2.5 stuff, but as soon as fs/super.c merge gets into the
sane area I'll see what can be safely merged into 2.4. Sorry - it touches
quite a few places and running two splitups in parallel...  As
soon as this fscking roll of barbwire^W^W^Wset of locking changes gets
untangled...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE] HotPlug CPU patch against 2.4.5

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> In article  you wrote:
> > # Up...
> > echo 1 > /proc/sys/cpu/1
> 
> Wouldn't /proc/sys/cpu//enable be better?  This way other per-cpu
> sysctls could be added more easily...

Yep.  But rewrite the sysctl crap first to make dynamically adding and
deleting entries sane.

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

More spontaneous reboots with 440LX chipsets (2.4.5ac7)

[Mourad De Clerck]

Hi,


I have a Soltek AT motherboard with
- a 440LX/EX chipset
- a celeron 533
- 96 mb of ram (tested with memtest86, just to be sure)
- an ATI rage pro (agp)
- a western digital harddisk
- a 3c509b

that's it, nothing fancy.

But ever since the 2.4 series (i used 2.4.3, 2.4.4acXX, and now 
2.4.5ac7) i get spontaneous reboots quite often. Usually it isn't doing 
anything fancy when it happens, no harddisk activity or memory pressure, 
it just pops and croaks.

I'm using reiserfs by the way.

Just thought i'd mention it, because i've seen other people having 
spontaneous reboots with LX chipsets.

Mourad DC

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Partial devfs support for raw IO devices

[Chris Rankin]

Hi,
I hacked together this quick patch to make the "master" raw IO device
appear in devfs. It seems odd that I need *both* devfs_register...()
calls but the first one only seems to make the entry appear in
/proc/devices.

The logical corollary to this patch is to make raw IO devices
magically appear in devfs as they are bound to block devices. However,
this presents namespacing issues. Would it be reasonable to assume
that they should appear in a subdirectory called /dev/rawIO, e.g.

/dev/rawIO/1
/dev/rawIO/2  ... etc?

devfsd could then provide compatibility links.

Anyway, first things first :-)
Cheers,
Chris


--- linux-2.4.5/drivers/char/raw.c.orig Sat May 26 11:58:45 2001
+++ linux-2.4.5/drivers/char/raw.c  Sat Jun 16 20:54:10 2001
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define dprintk(x...) 
@@ -28,6 +29,7 @@
 } raw_device_data_t;
 
 static raw_device_data_t raw_devices[256];
+static const char RAW_DEVICE_NAME[] = "raw";
 
 static ssize_t rw_raw_dev(int rw, struct file *, char *, size_t, loff_t *);
 
@@ -53,7 +55,11 @@
 static int __init raw_init(void)
 {
int i;
-   register_chrdev(RAW_MAJOR, "raw", &raw_fops);
+   devfs_register_chrdev(RAW_MAJOR, RAW_DEVICE_NAME, &raw_fops);
+   devfs_register(NULL, RAW_DEVICE_NAME, DEVFS_FL_DEFAULT,
+  RAW_MAJOR, 0,
+  S_IFCHR | S_IRUSR | S_IWUSR,
+  &raw_fops, NULL);
 
for (i = 0; i < 256; i++)
init_MUTEX(&raw_devices[i].mutex);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Longstanding APIC/NE2K bug

[rc]

There has been a bug in the 2.4.x series of kernels for a long time (at
least -pre9) concerning SMP and ne2k-pci.

Maciej W. Rozycki posted a patch back during 2.4.0 that fixed this problem
"[patch] 2.4.0, 2.4.0-ac12: APIC lock-ups" in late January.  I've been
trying new kernels regularly since, and the patch doesn't seem to have
made it in (tested 2.4.2, .3, .4 and .5).  Falling back on my patched
2.4.0 works fine.

Symptoms: Network driver locks up.  Repeated messages of "ETH0: Transmit
timeout" occurs.  Unloading and reloading network drivers does not help,
reboot is required.  Usually only triggered by heavy network traffic
(300-400 megs at 700k or so usually does it).

Robert Cicconetti
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

On Sat, 16 Jun 2001, Christian Robottom Reis wrote:

> I'm having a ton of problems with a set of boxes that use an onboard
> variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
> documentation - motherboard is model D815EEA2) but eepro100-diag reports:
>
> eepro100-diag.c:v2.05 6/13/2001 Donald Becker ([EMAIL PROTECTED])
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Intel i82562 Pro/100 V adapter at 0xdf00.

I've just tested with Intel's epro-1.6.6 driver, and it does work (the
full bonanza works; simultaneous netperf and ftp and whatnot run with no
errors or hangs). This makes my situation a bit easier (and my head a bit
less confused, specially with Andrey pointing out the different versions
to the driver).

I am _very_ willing to devote some time to getting this fixed in both the
kernel and Donald's drivers if anyone is interested in tracking down the
problem. I'm not very familiar with the hardware, but I have a test box I
can use freely, a bit of time spare, and I can reproduce the problem
easily. I'd hate to see somebody else go through what I have just had to,
so it would be nice to see this fixed or documented in an official-ese
place.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Newbie idiotic questions.

[Arnaldo Carvalho de Melo]

Em Sat, Jun 16, 2001 at 09:35:34PM -0400, Richard B. Johnson escreveu:
> > [main.c, line 223]
> > if ((card->mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))
> > 
> > Why is the struct type referenced for the allocation size?  Why not,
> > 
> > if ((card->mpuout = kmalloc(sizeof(card->mpuout), GFP_KERNEL))
> > 
> > This seems to get the size for the actual object being allocated.
> > 
> 
> Again, you are correct. However, you may not know the history of the
> driver. Perhaps at one time the above statement was correct.

yes, and in fact this should be one of the entries in the kernel Janitor's
TODO list, please take a look at http://bazar.conectiva.com.br/~acme/TODO
and consider submitting some more things to cleanup so that people wanting
to start hacking the kernel can have some easy starting points. Also please
consider reading http://kernel-janitor.sourceforge.net

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

ANN: Linux-NTFS 1.0.0 stable released

[Anton Altaparmakov]

Linux-NTFS 1.0.0 stable is now released.

Get it from http://sf.net/projects/linux-ntfs/

NTFS utilities
==
NtfsFix v1.15 - Attempt to fix an NTFS partition that has been damaged by 
the Linux NTFS driver. Note that you should run it every time after you 
have used the Linux NTFS driver to write to an NTFS partition to prevent 
massive data corruption from happening when Windows mounts the partition. 
IMPORTANT: Run this only *after* unmounting the partition in Linux but 
*before* rebooting into Windows NT/2000 or you *will* suffer! - You have 
been warned!

mkntfs v1.39 - Format a partition with the NTFS filesystem. See man 8 
mkntfs for command line options.

NtfsDump_LogFile v1.0 - Interpret and display information about the journal 
($LogFile) of an NTFS volume.

dumplog v1.0. - As NtfsDump_LogFile but operates on a file rather than a 
partition, so can use it on a live mounted file system.

ldm v1.3 - Interpret and display the Logical Disk Manager database (of a 
Windows 2000/XP dynamic disk/block device).

NTFS library

Provides common NTFS access functions to the ntfstools and other foreign 
open source applications. Note, that the library is still under heavy 
development and doesn't include the majority of functionality yet. It only 
is capable of just about supporting the current ntfstools, so I wouldn't 
recommend using it for your own applications at this stage.

Changes:
* mkntfs release and bugfixes to libntfs and the other utilities. Includes 
a man (8) page.
* ldm release which dumps the ldm database on Win2k/XP dynamic disks.
* updated ntfsdump_logfile and new dumplog operating on the logfile itself 
rather than the partition, suitable for live mounted file systems.
* Building of shared libraries is disabled by default as it breaks on some 
systems.
* Probably need at least gcc-2.95 or something like that from now on.

Please report any bugs/problems to:
 [EMAIL PROTECTED]

Enjoy,

 Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

Just noticed:

On Sat, 16 Jun 2001, Christian Robottom Reis wrote:

> Steps to reproduce problem:
>
> * Run large ( > 2MB works ) ftp transfer in box.
> * ssh in from another box and attempt an ls -lR /

Note below:

> * 2.2.19 with Donald's eepro100.c scyld:network/
>   Hard lock (seems to take longer to hang) - it also creates
>   8 devices eth0-eth7!
>
> * 2.2.19 with Donald's eepro100.c fromscyld:network/test/
>   Hard lock (pretty fast) - no multiple creation bugs

Actually, they don't hang _immediately_. They report:

eth0: Transmit timed out: status 0050   at 6022/6034 commands 000c
000c 000c
Command  was not immediately accepted, 10001 ticks!

And the ssh connection stalls but does on trying (it eventually hangs, but
not after a lot of errors are reported on the problem-box's console)

And then the box hard locks. Interesting to see that only when I run the
ssh ls -lR is that any error at all is produced. The lockups I was seeing
were all interactive use and I never really noticed if errors were showing
up or not; I just assumed they weren'.

Any help you can provide is very much appreciated. I'm about to try
Intel's drivers to see how they do.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

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

eepro100 problems with 2.2.19 _and_ 2.4.0

[Christian Robottom Reis]

Hello everybody,

I'm having a ton of problems with a set of boxes that use an onboard
variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
documentation - motherboard is model D815EEA2) but eepro100-diag reports:

eepro100-diag.c:v2.05 6/13/2001 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82562 Pro/100 V adapter at 0xdf00.
i82557 chip registers at 0xdf00:
     00080002 183f 

Okay, now for the bad part. Symptoms:

* slow transfers (internet ftps are the case) hard lock box.
* interactive use hard locks box.
* basic Netperf tests run fine.
* wget of > 20MB files from local server run fine.

Steps to reproduce problem:

* Run large ( > 2MB works ) ftp transfer in box.
* ssh in from another box and attempt an ls -lR /

So it seems that only when the network i/o is low does the lock occur.

I've tried up to now four sets of drivers (all non-modules):

* 2.2.19 straight (Andrey?)
Kills networking, but stays alive - reports (typed in):
epro100: cmd_wait for (0xff00) timedout with (0xff00)!

* 2.2.19 with Donald's eepro100.c scyld:network/
Hard lock (seems to take longer to hang) - it also creates
8 devices eth0-eth7!

* 2.2.19 with Donald's eepro100.c fromscyld:network/test/
Hard lock (pretty fast) - no multiple creation bugs

* 2.4.5 straight
Hangs ssh connection, reports (typed in):
epro100: wait_for_cmd_done timeout!
Data socket timed out:
eth0: Transmit timed out: status 0050  0c00 at 907/935 command 000c.

So now I'm left here stuck with a stupid unworking on-board card.

Donald, Andrey, anyone? have you seen this before? What can I do to help
this get diagnosed properly?

BTW: eepro100-diag reports sleep mode on - this is bad, right? And I can
turn it off?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311





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

Kernel configuration. It's not just a job, it's an adventure!

[Eric S. Raymond]

Various people on the Linux kernel mailing list and elsewhere have been heard
to opine that CML2's user interface is too oriented towards nontechnical
users.  In response to these complaints, I have implemented a fourth CML2
front end with an interface style expressly designed for the serious,
hard-core hacker.  A transcript of an example session follows:


Welcome to CML2 Adventure, version 1.6.1.
You are in a maze of twisty little Linux kernel options menus, all different.
The main room.  A sign reads `Linux Kernel Configuration System'.
Passages lead off in all directions.

> n
The arch room.  A sign reads `Processor type'.
A passage leads upwards.

Choose your processor architecture.
A brass lantern is here.
There is a row of buttons on the wall of this room. They read:
X86, ALPHA, SPARC32, SPARC64, MIPS32, MIPS64, PPC, M68K, ARM, SUPERH, IA64, PARISC, 
S390, S390X, CRIS
The button marked X86 is pressed.
> take lantern
Lantern: taken.
> look X86
Value of X86 is y.
This is Linux's home port.  Linux was originally native to the Intel
386, and runs on all the later x86 processors including the Intel
486, 586, Pentiums, and various instruction-set-compatible chips by
AMD, Cyrix, and others.
> up
In main room.
> nearby
The arch room.  A sign reads `Processor type'.
The archihacks room.  A sign reads `Architecture-specific hardware hacks'.
The buses room.  A sign reads `System buses and controller types'.
The pm room.  A sign reads `Power management'.
The mtd room.  A sign reads `Memory Technology Device (MTD) support'.
The x86 room.  A sign reads `Intel and compatible 80x86 processor options'.
The policy room.  A sign reads `Configuration policy options'.
The generic room.  A sign reads `Architecture-independent feature selections'.
The block_devices room.  A sign reads `Block devices'.

> go generic
The generic room.  A sign reads `Architecture-independent feature selections'.
A passage leads upwards.

There is an option named MODULES here.
There is an option named NET here.
There is an option named SYSVIPC here.
There is an option named BSD_PROCESS_ACCT here.
There is an option named SYSCTL here.
There is an option named BINFMT_AOUT here.
There is an option named BINFMT_MISC here.
There is an option named SMP here.
> take NET
NET: taken.
> take MODULES
Tristate symbols won't default to M.
MODULES: taken.
> up
In main room.
> nearby
The arch room.  A sign reads `Processor type'.
The archihacks room.  A sign reads `Architecture-specific hardware hacks'.
The buses room.  A sign reads `System buses and controller types'.
The pm room.  A sign reads `Power management'.
The mtd room.  A sign reads `Memory Technology Device (MTD) support'.
The x86 room.  A sign reads `Intel and compatible 80x86 processor options'.
The policy room.  A sign reads `Configuration policy options'.
The generic room.  A sign reads `Architecture-independent feature selections'.
The block_devices room.  A sign reads `Block devices'.

> go buses
The buses room.  A sign reads `System buses and controller types'.
A passage leads upwards.

Specify the buses, disk controllers, and internal interconnection standards
that you want your kernel to support.
It is very dark.  If you continue, you are likely to be eaten by a grue.
There is an option named EISA here.
There is an option named PCI here.
There is an option named PNP here.
There is an option named PARPORT here.
There is an option named HOTPLUG here.
There is an option named IDE here.
There is an option named SCSI here.
There is an option named USB here.
There is an option named I2O here.
There is an option named MTD here.
There is an option named WATCHDOG here.
> light lantern
The lantern radiates a mellow golden light.
> take PCI
PCI: taken.
> help
Welcome to the adventure configurator.  For a command summary, type `commands'.
In general, a three-letter abbreviation of any command word is sufficient
to identify it to the parser.

This interface emulates the style of classic text adventure games such as
Colossal Cave Adventure and Zork.  Configuration menus are rooms, and
configuration options are objects that can be taken and dropped (except
for choice/radiobutton symbols, which become buttons on various room walls).
Objects and rooms may silently appear and disappear as visibilities
change.

Have fun, and beware of the grues!

In main room.
> commands
look [target] -- look here or at target (direction or option).
nearby-- list nearby rooms (useful with go)
go-- go to a named menu (follow with the label).
inventory -- show which options you have picked up.
drop  -- unset option.
take [module] -- set option, follow with option name.
press -- press a button (follow with the button name).
set   -- set numeric or string; follow with symbol and value.
load  -- read in a configuration (follow with the filename).
save  -- save the configuration (follow wit

[docPATCH] mm.h documentation

[Rik van Riel]

Hi Linus,

please consider the attached patch for inclusion
in the next -pre kernel, all it does is add and
update the documentation in mm.h

ObDisclaimer: -ac users have been running it for ages

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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



--- mm.h.orig   Wed Mar  7 15:36:32 2001
+++ mm.hWed Mar  7 19:30:44 2001
@@ -39,32 +39,37 @@
  * library, the executable area etc).
  */
 struct vm_area_struct {
-   struct mm_struct * vm_mm;   /* VM area parameters */
-   unsigned long vm_start;
-   unsigned long vm_end;
+   struct mm_struct * vm_mm;   /* The address space we belong to. */
+   unsigned long vm_start; /* Our start address within vm_mm. */
+   unsigned long vm_end;   /* Our end address within vm_mm. */

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

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

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

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

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

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

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

@@ -124,37 +130,144 @@
 };

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

Re: Newbie idiotic questions.

[Richard B. Johnson]

On 16 Jun 2001, Bill Pringlemeir wrote:

> 
> I have been looking at the emu10k1 driver and I had a few questions
> about general idioms used there.
> 
> In a line like this,
> 
> [main.c, line 175]
> 
>   for (count = 0; count < sizeof(card->digmix) / sizeof(card->digmix[0]); 
>count++) {
> 
> Isn't there some sort of `ALEN' macro available, or is this
> considered to muddy things by using a macro?

Note that code in drivers range from very nice to awful, and every level
in between.

I generally use a macro called ArraySize(), defined up-front.

> 
> [main.c, line 223]
>   if ((card->mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))
> 
> Why is the struct type referenced for the allocation size?  Why not,
> 
>   if ((card->mpuout = kmalloc(sizeof(card->mpuout), GFP_KERNEL))
> 
> This seems to get the size for the actual object being allocated.
> 

Again, you are correct. However, you may not know the history of the
driver. Perhaps at one time the above statement was correct.

> [cardmi.c, line 42]
> 
> static struct {
>   int (*Fn) (struct emu10k1_mpuin *, u8);
> } midistatefn[] = {
> ...
> 

[...snipped]



> 
> regards,
> Bill Pringlemeir.


What you should do is supply a patch. Call it a "general cleanup". Send
it first to the maintainer of the driver. If this doesn't work, send it
to linux-kernel. Test your patch well because you may fix something that
breaks something else. 


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/

Re: Newbie idiotic questions.

[Jeff Garzik]

Bill Pringlemeir wrote:
> [main.c, line 175]
> 
> for (count = 0; count < sizeof(card->digmix) / sizeof(card->digmix[0]); 
>count++) {
> 
> Isn't there some sort of `ALEN' macro available, or is this
> considered to muddy things by using a macro?

Yes, we have array size

> [main.c, line 223]
> if ((card->mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))
> 
> Why is the struct type referenced for the allocation size?  Why not,
> 
> if ((card->mpuout = kmalloc(sizeof(card->mpuout), GFP_KERNEL))

because then you would be allocating the size of a pointer, not the size
of a structure


> Why aren't all the gobs of constant data in this driver declared as
> constant?  Do it give a performance advantage by having the data in a
> different MMU section and better cache effects or something?

Marking data const is usually a good idea.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Newbie idiotic questions.

[Bill Pringlemeir]

I have been looking at the emu10k1 driver and I had a few questions
about general idioms used there.

In a line like this,

[main.c, line 175]

for (count = 0; count < sizeof(card->digmix) / sizeof(card->digmix[0]); 
count++) {

Isn't there some sort of `ALEN' macro available, or is this
considered to muddy things by using a macro?

[main.c, line 223]
if ((card->mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))

Why is the struct type referenced for the allocation size?  Why not,

if ((card->mpuout = kmalloc(sizeof(card->mpuout), GFP_KERNEL))

This seems to get the size for the actual object being allocated.

[cardmi.c, line 42]

static struct {
int (*Fn) (struct emu10k1_mpuin *, u8);
} midistatefn[] = {
...

Why aren't all the gobs of constant data in this driver declared as
constant?  Do it give a performance advantage by having the data in a
different MMU section and better cache effects or something?

Thanks for any helpful pointers.  I did read the FAQ.  I am just
wonder if I would get screamed at for changing things like this and
why... so I will probably get yelled at for suggesting them anyway,
but at least I won't have went through the effort.  Now that I have
pointed that out, the will probably irk people even more...

regards,
Bill Pringlemeir.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Client receives TCP packets but does not ACK

[Robert Kleemann]

In order to figure out what this problem is I'm going to add some
printk statements in the networking code on the client machine.
Hopefully, this will show me what's going on.  My goal is to trace the
receipt of the datagram by tcp, see why/how it's deciding to ack or
not ack, and then trace the sending of the ack.

There are quite a few files that seem to be involved including:
linux/net/ipv4/tcp*.c as well as some important structures in
linux/include/net/sock.h

I'm guessing this is going to take me a while just to figure out where
to look and what to look for.  Can any of you networking gurus save me
some time and suggest some functions to start looking at?

thanx!
Robert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] apm and cs46xx sound

[Justin Guyett]

This is a pretty minor nitpick...

hardware: ibm thinkpad t21 using the apm driver

With 2.4.5-ac13, unplugging from AC, reconnecting to AC no longer causes
sound to be scratchy/garbled, but if something already has /dev/sound/dsp
open and AC state changes, the sound is garbled until the program reopens
the device (usually requires restarting the program e.g. mpg123).

At last, though, i don't have to rmmod and insmod.  That at least is a
relief.


Justin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] to init/main.c

[Richard Gooch]

Daniel Dickman writes:
> Here is a small patch to main.c.
> 
> It does the following:
> - makes sure that asm/mtrr.h actually gets included, and

What the hell is this? It is already included!

> - changes formatting in one place as per Documentation/CodingStyle
> 
> --- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001
> +++ linux/init/main.c   Sat Jun 16 11:48:42 2001
> @@ -50,7 +50,7 @@
>  #endif
>  
>  #ifdef CONFIG_MTRR
> -#  include 
> +#include 
>  #endif
>  
>  #ifdef CONFIG_NUBUS

I don't want this change. It's not fixing anything and removes the
intentional indentation.

And was there a reason not to Cc: me?

Regards,

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

Re: threading question

[Dan Maas]

> Is there a user-space implemenation (library?) for 
> coroutines that would work from C?

Here is another one:

http://oss.sgi.com/projects/state-threads/


Regards,
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/

Oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B)

[Peter Cordes]

 This is a bug report about the VIA IDE driver.  I'm forwarding it here
because [EMAIL PROTECTED] bounced.

- Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> 
-
  [EMAIL PROTECTED]
SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>:
host mail.linux-ide.org [24.219.123.215]: 550 5.7.1 Unable to relay for 
[EMAIL PROTECTED]

-- This is a copy of the message, including all the headers. --

Return-path: <[EMAIL PROTECTED]>
Received: from peter by llama.nslug.ns.ca with local (Exim 3.22 #1 (Debian))
id 15Ajcp-0005Jz-00
for <[EMAIL PROTECTED]>; Thu, 14 Jun 2001 23:46:19 -0300
Date: Thu, 14 Jun 2001 23:46:19 -0300
To: [EMAIL PROTECTED]
Subject: oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B)
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
From: Peter Cordes <[EMAIL PROTECTED]>


 I rescued a P5BV3+ (a super 7) mobo with a VIA MVP3 chipset from the trash
(I know the guy who was tossing it, and he didn't say anything about it
being damaged, just old).  I moved my disks over from my old system, and
compiled myself a kernel for it.  It's got an AMD k6-2 at 350MHz, and the
memory bus is running at 100MHz.  I've run memtest86 for a long time
(several complete passes, one with "extended tests") and found no errors.

 The problem is that all the 2.4 kernels I've tried oops under heavy disk
load.  A couple typical ones are like this:

ksymoops 2.4.1 on i586 2.2.19-idepci.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -K (specified)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5 (specified)
 -m /boot/System.map-2.4.5 (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Jun 12 02:11:40 yeti kernel: Unable to handle kernel paging request at virtual address 
848d
Jun 12 02:11:40 yeti kernel: c010fb03
Jun 12 02:11:40 yeti kernel: *pde = 
Jun 12 02:11:40 yeti kernel: Oops: 
Jun 12 02:11:40 yeti kernel: CPU:0
Jun 12 02:11:40 yeti kernel: EIP:0010:[__wake_up+51/168]
Jun 12 02:11:40 yeti kernel: EFLAGS: 00010017
Jun 12 02:11:40 yeti kernel: eax: c123fe10   ebx: 8491   ecx: c8b6a6e4   edx: 
c123fdf8
Jun 12 02:11:40 yeti kernel: esi: c8b6a6e4   edi: 8489   ebp: c8b87ef4   esp: 
c8b87ed8
Jun 12 02:11:40 yeti kernel: ds: 0018   es: 0018   ss: 0018
Jun 12 02:11:40 yeti kernel: Process bonnie++ (pid: 329, stackpage=c8b87000)
Jun 12 02:11:40 yeti kernel: Stack: c123fdf4 c8b6a6e4 c123fdcc c123fdf8 0001 
0282 0003 20e9 
Jun 12 02:11:40 yeti kernel:c0125481 c01e2134 c01e2304 0002  
c0126b34 c01e2134  
Jun 12 02:11:40 yeti kernel:c01e230c  c13bee48 c0126c11 c01e2300 
 0002 0001 
Jun 12 02:11:40 yeti kernel: Call Trace: [reclaim_page+969/1016] 
[__alloc_pages_limit+108/148] [__alloc_pages+181/584] [generic_file_write+843/1336] 
[sys_write+142/196] [system_call+51/64] 
Jun 12 02:11:40 yeti kernel: Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa 
c7 01 00 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 4f 04  mov0x4(%edi),%ecx
Code;  0003 Before first symbol
   3:   8b 1b mov(%ebx),%ebx
Code;  0005 Before first symbol
   5:   8b 01 mov(%ecx),%eax
Code;  0007 Before first symbol
   7:   85 45 fc  test   %eax,0xfffc(%ebp)
Code;  000a Before first symbol
   a:   74 51 je 5d <_EIP+0x5d> 005d Before first symbol
Code;  000c Before first symbol
   c:   31 c0 xor%eax,%eax
Code;  000e Before first symbol
   e:   9cpushf  
Code;  000f Before first symbol
   f:   5epop%esi
Code;  0010 Before first symbol
  10:   facli
Code;  0011 Before first symbol
  11:   c7 01 00 00 00 00 movl   $0x0,(%ecx)




Jun 12 04:06:20 yeti kernel: Unable to handle kernel paging request at virtual address 
45bd
Jun 12 04:06:20 yeti kernel: c010fb03
Jun 12 04:06:20 yeti kernel: *pde = 075d6067
Jun 12 04:06:20 yeti kernel: Oops: 
Jun 12 04:06:20 yeti kernel: CPU:0
Jun 12 04:06:20 yeti kernel: EIP:0010:[__wake_up+51/168]
Jun 12 04:06:20 yeti kernel: EFLAGS: 00010017
Jun 12 04:06:20 yeti kernel: eax: c123fe10   ebx: 45c1   ecx: c8b6a6e4   edx: 
c111edf8
Jun 12 04:06:20 yeti kernel: esi: c111edf4   edi: 45b9   ebp: c13c3f94   esp: 
c13c3f78
Jun 12 04:06:20 yeti kernel: ds: 0018   es: 0018   ss: 0018
Jun 12 04:06:20 yeti kernel: Process kswapd (pid: 3, stackpage=c13c3000)
Jun 12 04:06:20 yeti kernel: Stack: c111edcc c111edf4  c111edf8 0001 
0282 0003 41c8 
Jun 12 04:06:20 yeti kernel:c01259dc 0004  000

Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Rik van Riel]

On Sat, 16 Jun 2001, Daniel Phillips wrote:

> > Does the patch below do anything good for your laptop? ;)
> 
> I'll wait for the next one ;-)

OK, here's one which isn't reversed and should work ;))

--- fs/buffer.c.origSat Jun 16 18:05:29 2001
+++ fs/buffer.c Sat Jun 16 18:05:15 2001
@@ -2550,7 +2550,8 @@
   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))
+   if (++flushed > bdf_prm.b_un.ndirty &&
+   time_before(jiffies, bh->b_flushtime))
goto out_unlock;
} else {
if (++flushed > bdf_prm.b_un.ndirty)

cheers,

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: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Daniel Phillips]

On Saturday 16 June 2001 23:06, Rik van Riel wrote:
> On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > As a side note, the good old multisecond delay before bdflush kicks in
> > doesn't really make a lot of sense - when bandwidth is available the
> > filesystem-initiated writeouts should happen right away.
>
> ... thus spinning up the disk ?

Nope, the disk is already spinning, some other writeouts just finished.

> How about just making sure we write out a bigger bunch
> of dirty pages whenever one buffer gets too old ?

It's simpler than that.  It's basically just: disk traffic low? good, write 
out all the dirty buffers.  Not quite as crude as that, but nearly.

> Does the patch below do anything good for your laptop? ;)

I'll wait for the next one ;-)

--
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: Linux 2.4.5-ac14

[Arnaldo Carvalho de Melo]

Em Sat, Jun 16, 2001 at 05:56:08PM -0300, Thiago Vinhas de Moraes escreveu:
> Em Sex 15 Jun 2001 18:15, Alan Cox escreveu:
> > > Why the 2.4.5-ac series doesn't have merges from Linus 2.4.6-pre anymore?
> >
> > Because right now I dont consider the 2.4.6 page cache ext2 stuff safe
> > enough to merge. I'm letting someone else be the sucide squad.. so far it
> > looks like it is indeed fine but I want to wait and see more yet
> 
> But wouldn't be safe/possible/viable to merge 2.4.6-pre partially, excluding 
> the page cache stuff for the moment?
> IMHO, the 2.4.6-pre has important improvements, and it would be difficult to 
> merge to it later.
> Just a stupid opinion. No offenses.

If you look closely, some of the good things in 2.4.6-pre3 were backported
by Marcelo and included in 2.4.5-ac15

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Going beyond 256 PCI buses

[Jeff Garzik]

"David S. Miller" wrote:
> 
> Jeff Garzik writes:
>  > ok with me.  would bus #0 be the system or root bus?  that would be my
>  > preference, in a tiered system like this.
> 
> Bus 0 is controller 0, of whatever bus type that happens to be.
> If we want to do something special we could create something
> like /proc/bus/root or whatever, but I feel this unnecessary.

Basically I would prefer some sort of global tree so we can figure out a
sane ordering for PM.  Power down the pcmcia cards before the add-on
card containing a PCI-pcmcia bridge, that sort of thing.  Cross-bus-type
ordering.

-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pci_disable_device() vs. arch

[Jeff Garzik]

Benjamin Herrenschmidt wrote:
> 
> >
> >Its not clutter -- what you are doing is hiding pieces of the driver
> >from the driver maintainer.  pcibios_enable_device should not be
> >cluttered up with such mess, too.
> 
> Well... pcibios_enable_device() has to at least make sure the device
> gets powered up as it's powered down after PCI probe. Except if we
> end up calling pci_set_power_state() to power it up early in the
> sungem driver.

huh?  pci_enable_device calls pci_set_power_state.  sungem calls
pci_enable_device.

pcibios_enable_device shouldn't have to worry about power stuff.  If it
does, you need a pcibios_set_power_state, called from
pci_set_power_state, instead.


> >I point out that I recently fixed a bug where Via interrupts were being
> >assigned incorrectly.  If I had not done a global grep for Via
> >irq-related code, I would have missed the spot where the PPC code was
> >doing a kludge for one of the four on-board Via devices, hardcoding the
> >USB irq number to 11.
> 
> Hrm... interrupt routing on some PPC-based motherboard is quite a
> mess, fortunately that's not the case on pmacs. The IRQ assignement
> has to be part of the arch AFAIK, only the arch knows on which
> interrupt line of the controller a given chip is wired and how
> interrupt controllers are cascaded.

Via is an exception


> What I suggest if for pci_bus to have an optional set_power_state
> function that is called when a device on that bus calls
> pci_set_power_state(). This function would then be able to implement
> those cases where power control is possible, while not done
> via PCI PM caps.

> A pci_bus structure exist for both "root" busses and busses under
> PCI<->PCI bridges, so effectively, there's a pci_bus structure per
> bridge (beeing host or PCI<->PCI). I beleive it makes sense for
> the bridge to have a way to handle the child power state.

Ok, agreed.  There are always gonna be special case bridges, including
(for my interest) multi-port NICs whose interfaces are presented as PCI
devices downstream from a PCI-PCI bridge.  Controlling power for these
nics is sometimes done by messing around with the PM bits on the bridge,
not on the downstream devices.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Coroutines [was Re: threading question]

[Russell Leighton]

Any chance this or the equiv could become part of glibc?

This seems a very handy abstraction,  in many apps
threads would then really only be needed for true parallelism.


Michael Rothwell wrote:

> Try this:
>
> http://lecker.essen.de/~froese/coro/
>
> -M
>
> On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
> >
> > Is there a user-space implemenation (library?) for coroutines that would work from 
>C?
> >
> >
> > Alan Cox wrote:
> >
> > > > Can you provide any info and/or examples of co-routines? I'm curious to
> > > > see a good example of co-routines' "betterness."
> > >
> > > With co-routines you don't need
> > >
> > > 8K of kernel stack
> > > Scheduler overhead
> > > Fancy locking
> > >
> > > You don't get the automatic thread switching stuff though.
> > >
> > > So you might get code that reads like this (note that aio_ stuff works rather
> > > well combined with co-routines as it fixes a lack of asynchronicity in the
> > > unix disk I/O world)
> > >
> > > select()
> > >
> > > if(FD_ISSET(copier_fd))
> > > run_coroutine(&copier_state);
> > >
> > > ...
> > >
> > > and the copier might be something like
> > >
> > > while(1)
> > > {
> > > // Yes 1 at a time is dumb but this is an example..
> > > // Yes Im ignoring EOF for this
> > > if(read(copier_fd, buf[bufptr], 1)==-1)
> > > {
> > > if(errno==-EWOULDBLOCK)
> > > {
> > > coroutine_return();
> > > continue;
> > > }
> > > }
> > > if(bufptr==255  || buf[bufptr]=='\n')
> > > {
> > > run_coroutine(run_command, buf);
> > > bufptr=0;
> > > }
> > > else
> > > bufptr++;
> > > }
> > >
> > > it lets you express a state machine as a set of multiple such small state
> > > machines instead.  run_coroutine() will continue a routine where it last
> > > coroutine_return()'d from. Thus in the above case we are expressing read
> > > bytes until you see a new line cleanly - not mangled in with keeping state
> > > in global structures but by using natural C local variables and code flow
> > >
> > > 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/
> >
> > --
> > ---
> > Russell Leighton[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/
> --
> Michael Rothwell
> [EMAIL PROTECTED]



--
---
Russell Leighton[EMAIL PROTECTED]
---


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

Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Rik van Riel]

On Sat, 16 Jun 2001, Rik van Riel wrote:


Oops, I did something stupid and the patch is reversed ;)


> --- buffer.c.orig Sat Jun 16 18:05:15 2001
> +++ buffer.c  Sat Jun 16 18:05:29 2001
> @@ -2550,8 +2550,7 @@
>  if the current bh is not yet timed out,
>  then also all the following bhs
>  will be too young. */
> - if (++flushed > bdf_prm.b_un.ndirty &&
> - time_before(jiffies, bh->b_flushtime))
> + if(time_before(jiffies, bh->b_flushtime))
>   goto out_unlock;
>   } else {
>   if (++flushed > bdf_prm.b_un.ndirty)


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: sis630 - help needed debugging in the kernel

[René Rebe]

Hi all!

On Wed, 13 Jun 2001 23:25:02 +0200
René Rebe <[EMAIL PROTECTED]> wrote:

> Thanks for the quick reply!
> 
> On Wed, 13 Jun 2001 09:54:21 -0700 (PDT)
> James Simmons <[EMAIL PROTECTED]> wrote:
> 
> > 
> > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630
> > > based laptop - linux-2.4.5-ac13).
> > 
> > You can do one of two things. Post both System.map and the complete oops
> > or you can run ksymoops on the oops. I can find the problem then. Thanks.
> 
> ksymoops' output is attached.

Is there any result with this trace??

[...]

k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pci_disable_device() vs. arch

[Benjamin Herrenschmidt]

>
>Its not clutter -- what you are doing is hiding pieces of the driver
>from the driver maintainer.  pcibios_enable_device should not be
>cluttered up with such mess, too.

Well... pcibios_enable_device() has to at least make sure the device
gets powered up as it's powered down after PCI probe. Except if we
end up calling pci_set_power_state() to power it up early in the
sungem driver.

>I point out that I recently fixed a bug where Via interrupts were being
>assigned incorrectly.  If I had not done a global grep for Via
>irq-related code, I would have missed the spot where the PPC code was
>doing a kludge for one of the four on-board Via devices, hardcoding the
>USB irq number to 11.

Hrm... interrupt routing on some PPC-based motherboard is quite a
mess, fortunately that's not the case on pmacs. The IRQ assignement
has to be part of the arch AFAIK, only the arch knows on which
interrupt line of the controller a given chip is wired and how
interrupt controllers are cascaded.

>Correct.  If your driver uses the API correctly, then when/if we want to
>mess around with hotplug resource assignment, we can un-assign resources
>as we like.  Since there aren't too many users of pci_disable_device so
>far, I want to make sure early adopters get it right.

Well... at least with sungem, there's no such risk as the entire bus
(up to the host bridge) where it lives is internal to the UniNorth
ASIC.

>Can you give a -specific- example of arch code that is -not- sungem
>related, but needs to occur when one powers-down a sungem MAC?
>
>If the PM code is related to sungem, it belongs in sungem.
>So far I don't see a need for arch-specific hooks anywhere...

Hrm... let me try again...

Powering down individual devices can be controlled by the PCI PM
capabilities, or in some cases (at least 2 cases here on UniNorth
based pmacs) by other bits in the host bridge.

What I suggest if for pci_bus to have an optional set_power_state
function that is called when a device on that bus calls
pci_set_power_state(). This function would then be able to implement
those cases where power control is possible, while not done
via PCI PM caps.

A pci_bus structure exist for both "root" busses and busses under
PCI<->PCI bridges, so effectively, there's a pci_bus structure per
bridge (beeing host or PCI<->PCI). I beleive it makes sense for
the bridge to have a way to handle the child power state. 

Ben


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Re: 2.4.2 yenta_socket problems on ThinkPad 240

[Jeff Garzik]

Linus Torvalds wrote:
> As far as I can tell, the yenta code should _really_ do something like
> 
> PCI_PROMARY_BUS:dev->subordinate->primary
> PCI_SECONDARY_BUS:  dev->subordinate->secondary
> PCI_SUBORDINATE_BUS:dev->subordinate->subordinate
> PCI_SEC_LATENCY_TIMER:  preferably settable, not just hardcoded to 176

Ah, nice.  That produces numbers on my laptop that look a bit better. 
Patch attached (which conflicts with the previous yenta.c patch).

I left 176 hardcoded for now, pending thinking on the rest of your
message...

-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |

Index: drivers/pcmcia/yenta.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/pcmcia/yenta.c,v
retrieving revision 1.1.1.25.4.1
diff -u -r1.1.1.25.4.1 yenta.c
--- drivers/pcmcia/yenta.c  2001/06/16 19:21:56 1.1.1.25.4.1
+++ drivers/pcmcia/yenta.c  2001/06/16 21:09:40
@@ -644,9 +644,9 @@
config_writeb(socket, PCI_LATENCY_TIMER, 168);
config_writel(socket, PCI_PRIMARY_BUS,
(176 << 24) |  /* sec. latency timer */
-   (dev->subordinate->number << 16) | /* subordinate bus */
-   (dev->subordinate->number << 8) |  /* secondary bus */
-   dev->bus->number); /* primary bus */
+   (dev->subordinate->subordinate << 16) | /* subordinate bus */
+   (dev->subordinate->secondary << 8) |  /* secondary bus */
+   dev->subordinate->primary);/* primary bus */
 
/*
 * Set up the bridging state:

2.4.5-ac14: machine responds to _every fifth_ ping!

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all, 

I am using a box with 2.4.5-ac14, 3c59x eth0 driver, 3c905C network card.
When working with it, the network has been behaving ok. Now I ping it from
a remote location, and I see the following strange effect:

After a few seconds, only every fifth ping gets back! (quite
exactly, reproducible). Ping output attached.

Another box on the same hub responds totally normal, so it is no network
congestion. I cannot ssh in at the moment, unfortunately. I tried several
different ping source machines, running 2.2.14(SuSE71), 2.2.14 SMP
(vanilla+int.crypto), 2.2.19, and a SPARCstation - they all give basically
the same result.

(Well, besides the target machine is one of these still constantly logging
"clock timer configuration lost - probably a VIA686a motherboard".)

lspci:
00:00.0 Host bridge: Acer Laboratories Inc. [ALi]: Unknown device 1647
(rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5247
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
00:04.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c4)
00:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev
10)
00:06.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge
[Aladdin IV]
00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 74)
00:11.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
01:00.0 VGA compatible controller: nVidia Corporation NV11 (rev a1) 

I hope this helps fixing some bug. 

best regards, Andreas

- -
Andreas K. Huettel  [EMAIL PROTECTED]
81627 Muenchen  [EMAIL PROTECTED]
Germany http://www.akhuettel.de/
- -  
Please use GNUPG or PGP for signed and encrypted email. My public key 
can be found at http://www.akhuettel.de/pgp_key.html
- -  

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7K8spL+gLs3iH94cRAisYAKCBS4t4zpO3Pro6fUPirHnJzWF84QCeI/ok
QSZa20+XBuESVEf+KqHEvlA=
=AkrB
-END PGP SIGNATURE-



huettel@centralservices:~/DiplomTalk > ping qubit
PING qubit.some-domain (x.y.142.6): 56 data bytes
64 bytes from x.y.142.6: icmp_seq=0 ttl=255 time=0.587 ms
64 bytes from x.y.142.6: icmp_seq=1 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=2 ttl=255 time=0.551 ms
64 bytes from x.y.142.6: icmp_seq=3 ttl=255 time=0.544 ms
64 bytes from x.y.142.6: icmp_seq=4 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=9 ttl=255 time=0.547 ms
64 bytes from x.y.142.6: icmp_seq=14 ttl=255 time=0.544 ms
64 bytes from x.y.142.6: icmp_seq=19 ttl=255 time=0.553 ms
64 bytes from x.y.142.6: icmp_seq=24 ttl=255 time=0.538 ms
64 bytes from x.y.142.6: icmp_seq=29 ttl=255 time=0.528 ms
64 bytes from x.y.142.6: icmp_seq=34 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=39 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=44 ttl=255 time=0.542 ms
64 bytes from x.y.142.6: icmp_seq=49 ttl=255 time=0.522 ms
64 bytes from x.y.142.6: icmp_seq=54 ttl=255 time=0.519 ms
64 bytes from x.y.142.6: icmp_seq=59 ttl=255 time=0.535 ms
64 bytes from x.y.142.6: icmp_seq=64 ttl=255 time=0.540 ms
--- qubit.some-domain ping statistics ---
65 packets transmitted, 17 packets received, 73% packet loss
round-trip min/avg/max = 0.519/0.542/0.587 ms

huettel@centralservices:~/DiplomTalk > ping qubit
PING qubit.some-domain (x.y.142.6): 56 data bytes
64 bytes from x.y.142.6: icmp_seq=0 ttl=255 time=0.607 ms
64 bytes from x.y.142.6: icmp_seq=1 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=2 ttl=255 time=0.540 ms
64 bytes from x.y.142.6: icmp_seq=3 ttl=255 time=0.537 ms
64 bytes from x.y.142.6: icmp_seq=4 ttl=255 time=0.539 ms
64 bytes from x.y.142.6: icmp_seq=5 ttl=255 time=0.537 ms
64 bytes from x.y.142.6: icmp_seq=6 ttl=255 time=0.538 ms
64 bytes from x.y.142.6: icmp_seq=11 ttl=255 time=0.543 ms
64 bytes from x.y.142.6: icmp_seq=16 ttl=255 time=0.550 ms
64 bytes from x.y.142.6: icmp_seq=21 ttl=255 time=0.518 ms
64 bytes from x.y.142.6: icmp_seq=26 ttl=255 time=0.609 ms
64 bytes from x.y.142.6: icmp_seq=31 ttl=255 time=0.543 ms
64 bytes from x.y.142.6: icmp_seq=36 ttl=255 time=0.545 ms
64 bytes from x.y.142.6: icmp_seq=41 ttl=255 time=0.551 ms
64 bytes from x.y.142.6: icmp_seq=46 ttl=255 time=0.543 ms
64 bytes from x.y.142.6: icmp_seq=51 ttl=255 time=0.537 ms
--- qubit.some-domain ping statistics ---
52 packets transmitted, 16 packets received, 69% packet loss
round-trip min/avg/max = 0.518/0.548/0.609 ms

huettel@centralservices:~/DiplomTalk > ping qubit
PING qubit.some-domain (x.y.142.6): 56 data bytes
64 bytes from x.y.142.6: icmp_seq=0 ttl=255 time=0.598 ms
64 bytes from x.y.1

Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Rik van Riel]

On Sat, 16 Jun 2001, Daniel Phillips wrote:

> In other words, any episode of pageouts is followed immediately by a
> short episode of preemptive cleaning.

linux/mm/vmscan.c::page_launder(), around line 666:
/* Let bdflush take care of the rest. */
wakeup_bdflush(0);


> The definition of 'for a while' and 'plenty of disk bandwidth' can be
> tuned, but I don't think either is particularly critical.

Can be tuned a bit, indeed.

> As a side note, the good old multisecond delay before bdflush kicks in 
> doesn't really make a lot of sense - when bandwidth is available the 
> filesystem-initiated writeouts should happen right away.

... thus spinning up the disk ?

How about just making sure we write out a bigger bunch
of dirty pages whenever one buffer gets too old ?

Does the patch below do anything good for your laptop? ;)

regards,

Rik
--


--- buffer.c.orig   Sat Jun 16 18:05:15 2001
+++ buffer.cSat Jun 16 18:05:29 2001
@@ -2550,8 +2550,7 @@
   if the current bh is not yet timed out,
   then also all the following bhs
   will be too young. */
-   if (++flushed > bdf_prm.b_un.ndirty &&
-   time_before(jiffies, bh->b_flushtime))
+   if(time_before(jiffies, bh->b_flushtime))
goto out_unlock;
} else {
if (++flushed > bdf_prm.b_un.ndirty)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-ac14

[Thiago Vinhas de Moraes]

Em Sex 15 Jun 2001 18:15, Alan Cox escreveu:
> > Why the 2.4.5-ac series doesn't have merges from Linus 2.4.6-pre anymore?
>
> Because right now I dont consider the 2.4.6 page cache ext2 stuff safe
> enough to merge. I'm letting someone else be the sucide squad.. so far it
> looks like it is indeed fine but I want to wait and see more yet

But wouldn't be safe/possible/viable to merge 2.4.6-pre partially, excluding 
the page cache stuff for the moment?
IMHO, the 2.4.6-pre has important improvements, and it would be difficult to 
merge to it later.
Just a stupid opinion. No offenses.

Regards,
-- 

 Thiago Vinhas de Moraes
 NetWorx - A SuaCompanhia.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: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Daniel Phillips]

On Friday 15 June 2001 17:23, Pavel Machek wrote:
> Hi!
>
> > Roger> It does if you are running on a laptop. Then you do not want
> > Roger> the pages go out all the time. Disk has gone too sleep, needs
> > Roger> to start to write a few pages, stays idle for a while, goes to
> > Roger> sleep, a few more pages, ...
> >
> > That could be handled by a metric which says if the disk is spun down,
> > wait until there is more memory pressure before writing.  But if the
> > disk is spinning, we don't care, you should start writing out buffers
> > at some low rate to keep the pressure from rising too rapidly.
>
> Notice that write is not free (in terms of power) even if disk is spinning.
> Seeks (etc) also take some power. And think about flashcards. It certainly
> is cheaper tha spinning disk up but still not free.
>
> Also note that kernel does not [currently] know that disks went spindown.

There's an easy answer that should work well on both servers and laptops, 
that goes something like this: when memory pressure has been brought to 0, if 
there there is plenty of disk bandwidth available, continue writeout for a 
while and clean some extra pages.  In other words, any episode of pageouts 
is followed immediately by a short episode of preemptive cleaning.

This gives both the preemptive cleaning we want in order to respond to the 
next surge, and lets the laptop disk spin down.  The definition of 'for a 
while' and 'plenty of disk bandwidth' can be tuned, but I don't think either 
is particularly critical.

As a side note, the good old multisecond delay before bdflush kicks in 
doesn't really make a lot of sense - when bandwidth is available the 
filesystem-initiated writeouts should happen right away.

It's not necessary or desirable to write out more dirty pages after the 
machine has been idle for a while, if only because the longer it's idle the 
less the 'surge protection' matters in terms of average throughput.

--
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: [PATCH] fix warning in tdfxfb.c

[Steven Walter]

On Sat, Jun 16, 2001 at 02:59:34PM -0500, Josh Myer wrote:
> It might be better to add a default case to the switch statement below, so
> this symbol doesn't just eat up another 4(8 on some platforms, and i'm
> sure others) bytes of memory unneccesarily.

I'm not quite sure I follow you.  The default case should never be
reached, because only the three cases currently present are allowed by
the encapsulating 'if' statement.  Even so, how would adding a default
case get rid of the variable or save space some other way?

> anyway, it doesn't really matter. i'd test my hypothesis, but i've got
> people coming over this afternoon =) the driver looks like it might use
> some scrubbing anyway (s!//(.*)$!/\* $1 \*/!...)

Good point.  Perhaps I'll prepare a larger patch with this and other
cleanups.
-- 
-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: pci_disable_device() vs. arch

[Jeff Garzik]

Benjamin Herrenschmidt wrote:
> 
> Hi !
> 
> Would it make sense to add a
> 
> pcibios_disable_device(pci_dev*) called from the end of
> pci_disable_device() ?
> 
> I'm adding a call to it to sungem along with other pmac stuffs
> so that the chip can be properly power down (actually it's not
> really powered down but unclocked) after module removal.
> Of course, the arch code must be able to catch it in order to
> play with the various UniNorth control bits.

What arch-specific things need to be done?

arch-specific pcibios_disable_device may be a good idea... but in this
case it sounds like you need to put #ifdef CONFIG_ALL_PPC code in
sungem.c instead, if the power-down code is specific to gmacs.


> Note that my current gmac driver does shut the chip down when
> the interface is down, which makes it a bit more useful for
> laptops as most users currently compile the driver in the kernel.

Although some drivers already do this, you really need an inactivity
timer instead of unconditionally powering-down the hardware on
dev->stop().  dhcp and other applications will often bounce the
interface...


> I have nothing about changing the policy if you prefer so that
> users will now have to rmmod the driver once done with the
> interface to save power.

For power-down specifically, you should use pci-set-power-state not
pci-disable-device.  pci_disable_device is the opposite of
pci_enable_device.  pci_enable_device not only wakes up the device, but
also assigns resources.  Which implies that pci-disable-device is
allowed to un-assign resources.  There shouldn't be a problem with a net
device doing that per se, but you should be aware of the implications.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Pavel Machek]

Hi!

> Roger> It does if you are running on a laptop. Then you do not want
> Roger> the pages go out all the time. Disk has gone too sleep, needs
> Roger> to start to write a few pages, stays idle for a while, goes to
> Roger> sleep, a few more pages, ...
> 
> That could be handled by a metric which says if the disk is spun down,
> wait until there is more memory pressure before writing.  But if the
> disk is spinning, we don't care, you should start writing out buffers
> at some low rate to keep the pressure from rising too rapidly.  

Notice that write is not free (in terms of power) even if disk is spinning.
Seeks (etc) also take some power. And think about flashcards. It certainly
is cheaper tha spinning disk up but still not free.

Also note that kernel does not [currently] know that disks went spindown.
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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/

pci_disable_device() vs. arch

[Benjamin Herrenschmidt]

Hi !

Would it make sense to add a 

pcibios_disable_device(pci_dev*) called from the end of 
pci_disable_device() ?

I'm adding a call to it to sungem along with other pmac stuffs
so that the chip can be properly power down (actually it's not
really powered down but unclocked) after module removal.
Of course, the arch code must be able to catch it in order to
play with the various UniNorth control bits.

Note that my current gmac driver does shut the chip down when
the interface is down, which makes it a bit more useful for
laptops as most users currently compile the driver in the kernel.

I have nothing about changing the policy if you prefer so that
users will now have to rmmod the driver once done with the
interface to save power.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: threading question

[Michael Rothwell]

Try this:

http://lecker.essen.de/~froese/coro/

-M

On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
> 
> Is there a user-space implemenation (library?) for coroutines that would work from C?
> 
> 
> Alan Cox wrote:
> 
> > > Can you provide any info and/or examples of co-routines? I'm curious to
> > > see a good example of co-routines' "betterness."
> >
> > With co-routines you don't need
> >
> > 8K of kernel stack
> > Scheduler overhead
> > Fancy locking
> >
> > You don't get the automatic thread switching stuff though.
> >
> > So you might get code that reads like this (note that aio_ stuff works rather
> > well combined with co-routines as it fixes a lack of asynchronicity in the
> > unix disk I/O world)
> >
> > select()
> >
> > if(FD_ISSET(copier_fd))
> > run_coroutine(&copier_state);
> >
> > ...
> >
> > and the copier might be something like
> >
> > while(1)
> > {
> > // Yes 1 at a time is dumb but this is an example..
> > // Yes Im ignoring EOF for this
> > if(read(copier_fd, buf[bufptr], 1)==-1)
> > {
> > if(errno==-EWOULDBLOCK)
> > {
> > coroutine_return();
> > continue;
> > }
> > }
> > if(bufptr==255  || buf[bufptr]=='\n')
> > {
> > run_coroutine(run_command, buf);
> > bufptr=0;
> > }
> > else
> > bufptr++;
> > }
> >
> > it lets you express a state machine as a set of multiple such small state
> > machines instead.  run_coroutine() will continue a routine where it last
> > coroutine_return()'d from. Thus in the above case we are expressing read
> > bytes until you see a new line cleanly - not mangled in with keeping state
> > in global structures but by using natural C local variables and code flow
> >
> > 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/
> 
> --
> ---
> Russell Leighton[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/
--
Michael Rothwell
[EMAIL PROTECTED]


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

Re: Buffer management - interesting idea

[Jeremy Fitzhardinge]

On 15 Jun 2001 11:07:20 +0200, Helge Hafting wrote:
> The "resistance to scanning" seemed interesting, maybe one-time
> activities like a "find" run or big cat/dd will have less impact with
> this.

It should also be good for streaming file use.  It gives a natural way
of detecting when you should be doing drop-behind (things fall out of
the fifo without ever making it into the LRU); doubly nice because it
works for both reads and writes without needing to treat them
differently.  It's also nice that it gives a natural interpretation to
the various madvise() flags.

J

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

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Christian Bornträger wrote:

>>If possible, can you remove the hard disc from the promise and attach it on
>>the VIA-Controller and test if the problem still occurs? (prepare a bootdisc
>>if you cannot boot. Propably, you have to pass a new root-partition to the
>>kernel)
>>I hardly believe that the promise controller has some problems with the new
>>VIA setup introduced in 2.4.3-ac7. Using the promise ports of the A7V133 is
>>the only correlation I see again and again...
>>
Yes, plugging the drive into the primary VIA IDE port, it seems to work 
perfectly. Am now on 2.4.5-ac14 with UDMA5 enabled and it seems quite happy.

Which would seem to indicate that yes, it *is* a Promise issue - or at 
least a Promise-on-VIA issue.

FWIW the Promise BIOS announces itself as version 2.01 build 35.

erk...

Thus far I've been presuming that the Promise IDE ports were 
UDMA100/66/33 and the VIA IDE ports were UDMA66/33, and thus naturally 
wanted to use the Promise ports to get better performance. Now, on more 
careful reading of the manual, it seems to be telling me that *all* of 
the IDE ports are UDMA100/66/33, the main benefit of the Promise chip 
besides being able to plug more IDE devices in, being the RAID 0 support 
(which I don't need [yet]). Then, on looking again at the bonnie 
*results* (rather than just noting that it hadn't *crashed*), I notice 
that the figures are about the same, possibly marginally better, than 
those I was getting out of the Promise ports.

And there I thought I'd have to be slumming it... Doh! :-} 

-- 
Rachel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Oops] 2.4.5-ac14/2.4.6-pre3+Athlon+gcc3-prerelease+VIAKT133A

[Michael]

On Sat, Jun 16, 2001 at 04:18:01PM +0800, Richard Chan wrote:
> Here's an oops from
> 
> 1. Athlon kernel, gcc3 prerelease 14 June compiled
> 2. Kernel version 2.4.5-ac14
> 3. Mobo: Soltek 75KAV (VT133A disaster??) with Athlon 1.2G C
> 
> Any ideas? Bad compiler or bad kernel?
> The problems occur in kmem_cache_.
> 
> On this mobo and chipset I have had no luck with locally compiled
> Athlon kernels at all (whether stock or -ac, RedHat gcc or gcc3-prerelease).
> Me thinks something is seriously wrong with this mobo/chipset or is it
> the Athlon code in gcc?

FWIW, I've got 2 of these boards (with duron 800 chips) 

I use gcc2.95.4 in debian sid.

Got it about the same time the 686b patch went
into ac1 and its run flawlessly with every ac version I've used since.

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

[PATCH] fix warning in tdfxfb.c

[Steven Walter]

This patch is obviously correct.  It doesn't appear that tdfxfb has a
maintainer, so I'm sending this patch to the list.  Nothing
earth-shattering, it just removes a warning during build.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell

--- tdfxfb.c~   Sat Jun 16 13:09:08 2001
+++ tdfxfb.cSat Jun 16 13:09:21 2001
@@ -1892,7 +1892,7 @@
((pdev->device == PCI_DEVICE_ID_3DFX_BANSHEE) ||
(pdev->device == PCI_DEVICE_ID_3DFX_VOODOO3) ||
(pdev->device == PCI_DEVICE_ID_3DFX_VOODOO5))) {
-  char *name;
+  char *name = NULL;
 
   fb_info.dev   = pdev->device;
   switch (pdev->device) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

max size of initrd image files

[Susumu Takuwa]

Hi, I have problem about booting Linux by using initrd which
I made originally.I have made original two initrd images,
that have *same* contents, but they have different size. ie,

first, creating image file.
$ dd if=/dev/zero of=/tmp/ramdisk1 bs=1024k count=48
$ dd if=/dev/zero of=/tmp/ramdisk2 bs=1024k count=64

second, copying files of initrd.img which is contained some
distro.
$ gzip -dc /boot/initrd.img > /tmp/initrd
$ losetup /dev/loop1 initrd
$ losetup /dev/loop0 ramdisk(1|2)
$ mount /dev/loop0 /loop0
$ mount /dev/loop1 /loop1
$ cp -a /loop1/* /loop0/

$ losetup -d ...
$ umount ...

$ gzip -c9 ramdisk(1|2) > /boot/ramdisk(1|2).img

third, booting kernel with initrd image under setting kernel
parameter ``ramdisk=131072''. My Linux Box have 384MB RAM
and 2.2.17 kernel.

Well, when I used ramdisk1.img, I could boot kernel with no
problem. But when I used ramdsisk2.img , I could not boot
kernel with following error message.

RAMDISK: could not determine device size

Is the 64MB initrd image compressed by gzip too big? Can I
solve the problem?


Susumu Takuwa



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2 yenta_socket problems on ThinkPad 240

[Jeff Garzik]

Alan Cox wrote:
> 
> > I would love to just define it unconditionally for x86, but I believe
> > Martin said that causes problems with some hardware, and the way the
> > BIOS has set up that hardware.  (details anyone?)
> 
> Im not sure unconditionally is wise. However turning it into a routine that
> walks the PCI bus tree and returns 1 if  a duplicate is found seems to be
> a little bit less likely to cause suprises

That would work, but is really a bandaid because we don't know what the
real problem is...  this still smells vaguely like yenta and pci bus
core should be more than just the kissing cousins they are now.  OTOH I
still don't like how much we trust firmware PCI bus setup on x86..

I am pretty lucky on Alpha, we already trust the kernel PCI code
implicitly by unconditionally defining pcibios_assign_all_busses to one.
:)

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Justin Guyett wrote:

>I remember seeing something about how some via ide chipsets (686b I think)
>and [some?] ide promise controllers had problems with data corruption on
>the IBM dtla-series udma drives, and that IBM stated the problem was with
>the controllers.  Is there a chance a problem like that could be screwing
>up the kernel?
>
It's a thought - but then why only with some kernel versions?

/me wonders if everyone who's having this problem is using IBM dtla 
drives...

-- 
Rachel


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

i386 hangs on 2.4.x kernels: DSL, reiserfs on md, ipfilter

[Daniel Wirth]

Dear kernel-hackers,

my gateway-system easily crashes while using limewire on a client in the
internal network. I've been testing kernels 2.4.3, 2.4.4, 2.4.5 and
currently 2.4.5-ac3 on a SuSE 7.1 System.

The system is connected to the internet via DSL and to the internal
network via eth1.

FW and Masq are working fine until starting Limewire on a client in the
internal net. At that point, the system hangs without any notice,
syslog or console-message. I can easlily reproduce the scenario.
I don't know the protocols Limewire uses.

I do use some "experimental" features: reiserfs on md and dsl.

Please find some info about the system attached below: lspci, ifconfig,
uname, interupts, ioports, mount, mdstat, ipfilter

I'd be grateful for any ideas and be happy to provide any more information
on request.

Best Regards,
Daniel


(19:05 102 dw@hal:~ ) lspci -v
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II]
(rev 01)
Flags: bus master, medium devsel, latency 32

00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton
II] (prog-if 80 [Master])
Flags: bus master, medium devsel, latency 32
I/O ports at 9000 [size=16]

00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS)
Flags: medium devsel, IRQ 11
I/O ports at 6000 [size=32]

00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev
10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at 6100 [size=256]
Memory at e400 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2

00:14.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
(rev 53) (prog-if 00 [VGA])
Flags: medium devsel, IRQ 9
Memory at e000 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at  [disabled] [size=64K]



(19:10 103 dw@hal:~ ) ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:00:B4:5A:F3:E4
  inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
  inet6 addr: fe80::200:b4ff:fe5a:f3e4/10 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:310 errors:0 dropped:0 overruns:0 frame:0
  TX packets:318 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  Interrupt:11 Base address:0x6000

eth1  Link encap:Ethernet  HWaddr 00:48:54:6C:01:81
  inet addr:192.168.99.10  Bcast:192.168.99.255
Mask:255.255.255.0
  inet6 addr: fe80::248:54ff:fe6c:181/10 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2957 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2205 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  Interrupt:10

ippp0 Link encap:Ethernet  HWaddr FC:FC:C0:A8:00:01
  inet addr:192.168.0.1  P-t-P:192.168.0.2  Mask:255.255.255.255
  inet6 addr: fe80::fefc:c0ff:fea8:1/10 Scope:Link
  UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:30

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:5024 errors:0 dropped:0 overruns:0 frame:0
  TX packets:5024 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0

ppp0  Link encap:Point-to-Point Protocol
  inet addr:213.23.60.38  P-t-P:145.253.1.223
Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1490  Metric:1
  RX packets:271 errors:0 dropped:0 overruns:0 frame:0
  TX packets:277 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:3

sit0  Link encap:IPv6-in-IPv4
  NOARP  MTU:1480  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0


(19:10 104 dw@hal:~ ) uname -a
Linux hal 2.4.5-ac3 #2 Mon May 28 21:28:47 MEST 2001 i586 unknown
(19:10 105 dw@hal:~ ) free
 total   used   free sharedbuffers cached
Mem: 94988  77592  17396  0  23784  23840
-/+ buffers/cache:  29968  65020
Swap:   202528  0 202528


(19:10 106 dw@hal:~ ) cat /proc/interrupts
   CPU0
  0:  44205  XT-PIC  timer
  1:  4  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3: 89  XT-PIC
  4:  4

Re: VIA KT133A crash *post* 2.4.3-ac6

[Justin Guyett]

I remember seeing something about how some via ide chipsets (686b I think)
and [some?] ide promise controllers had problems with data corruption on
the IBM dtla-series udma drives, and that IBM stated the problem was with
the controllers.  Is there a chance a problem like that could be screwing
up the kernel?


justin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-ac15

[Tom Vier]

mach_kbd_rate was changed to kbd_rate, but not defined.

vt.c: In function `vt_ioctl':
vt.c:504: `kbd_rate' undeclared (first use in this function)
vt.c:504: (Each undeclared identifier is reported only once
vt.c:504: for each function it appears in.)
vt.c:510: `kbd_rate' used prior to declaration
vt.c:510: warning: implicit declaration of function `kbd_rate'
make[3]: *** [vt.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_char] Error 2
make: *** [_dir_drivers] Error 2

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

irqtune in linux 2.4 (second try)

[tcm]

The last time I tried this, I didn't get any replies - at all. I don't
know why, so I request that anyone who wants to send me replies, send
directly to [EMAIL PROTECTED] - as it has been ten days since I last tried
to ask for help, I hope this isn't considered spam.

Note that I'm still having the same problems, this time with ac10, 
and I've still been completely unable to get anyone to tell me what
I'm either doing wrong, or is wrong with my programs/configuration.

Tim

On Wed, Jun 06, 2001 at 08:22:24PM -0400, tm wrote:
>   Hi. I will try to keep this as informative as possible, just in
> case I've missed something.
> 
> First off, I've already searched all the kernel archives I could,
> google, I've looked around on IRC for help in four different networks,
> I've emailed the debian hwtools package maintainer (who misdirected me
> to use /dev/irq to do what I wanted to do), and the irqtune
> author (I have not yet recieved a reply), and come up with absolutely
> no way to get this to work.
> 
> Problem: Irqtune is not working under any 2.4 kernel I've tried as it
> did in kernel 2.2.x, in fact it is not doing anything at all, despite
> the fact it says it's working fine. The symptoms of it not working are
> that whenever my hard disk writes, all serial and ethernet operations
> stop. As you can imagine, this generates quite a bit of packet loss,
> which is unacceptable, especially if I have to be writing/reading at the
> same time the modem is going.
> 
> Description of my configuration:
> Kernel: 2.4.5-ac7
> 
> irqtune: Debian unstable, using irqtune 0.6 from the hwtools package
> 
> hdparm: version v3.9 from the debian unstable hwtools package
> 
> Hardware: IBM PS/1 486 dx 50 with 16MB of ram, a add on ISA card
> which provides a 16550A uart for the external zoom 56K faxmodem, a
> NE2000 compatible ethernet card
> 
> irqtune -e 7 10 output:
> irqtune: version is 0.6
> irqtune: kernel version 0.0.0
> probe: irqtune must be invoked via the full path -- OK
> probe: /sbin in $PATH -- YES
> probe: insmod found in $PATH (/sbin) -- OK
> probe: insmod simple execution -- OK
> probe: insmod has version (2.4.6) -- YES
> probe: rmmod found in insmod directory -- OK
> probe: insmod version supports command line options -- OK
> probe: insmod version (2.4.6) compatible with kernel version (0.0.0) --
> OK
> probe: insmod version should be 2.1.34 (or better) -- OK
> probe: insmod and kernel compatible with CONFIG_MODVERSIONS -- OK
> probe: irqtune_mod loading will be tried -- OK
> probe: kernel version irqtune built under (1.0.0) matches current system
> -- NO
> probe: kernel IRQ handling is compatible -- OK
> probe: kernel has module support (CONFIG_MODULES) -- OK
> probe: kernel has symbols -- OK
> probe: kernel is using versions (CONFIG_MODVERSIONS) -- NO
> probe: kernel symbols are checksummed (CONFIG_MODVERSIONS) -- NO
> probe: kernel has /proc/interrupts -- OK
> irqtune: setting system IRQ priority to 7/10
> irqtune: trying command -- insmod -x -o irqtune_mod -f
> /usr/lib/hwtools/irqtune_mod.o priority=7,10
> Warning: kernel-module version mismatch
> /usr/lib/hwtools/irqtune_mod.o was compiled for kernel version
> 1.0.0
> while this kernel is version 2.4.5-ac7
> irqtune: trying command -- rmmod irqtune_mod
> tblread: SYNTAX 'ERR:  0'
> I00/P01:34152281  XT-PIC  timer
> I01/P02:   2  XT-PIC  keyboard
> I02/P03:   0  XT-PIC  cascade
> I03/P11:   1  XT-PIC  serial
> I07/P00: 5957335  XT-PIC  serial
> I10/P03:  202481  XT-PIC  NE2000
> I13/P06:   0  XT-PIC  fpu
> I14/P07: 8104967  XT-PIC  ide0
> I15/P08:   0  XT-PIC  ide1
> irqtune: complete
> 
> As you can imagine I'm slightly perturbed. I think the syntax error is
> OK, it's likely barfing on the new 'cpu 0' part of /proc/interrupts...
> However the misdetection of the kernel version is making we worry, as
> well as the fact that although it SAYS it has done something, in fact
> the problems I have been having since I upgraded to 2.4.x continue.
> (hard disk reads/writes cause all serial/eth0 operations to generate
> massive PL)
> 
> hdparm /dev/hda output:
> 
> /dev/hda:
>  multcount=  0 (off)
>  I/O support  =  0 (default 16-bit)
>  unmaskirq=  1 (on)
>  using_dma=  0 (off)
>  keepsettings =  1 (on)
>  nowerr   =  0 (off)
>  readonly =  0 (off)
>  readahead=  8 (on)
>  geometry = 4956/16/63, sectors = 4996476, start = 0
> 
> As you can see, I've enabled unmaskirq, as it has been reported to help
> in my situation... It does in fact, although I wish I had a way to get
> irqtune working again. Note that DMA is NOT available on this old
> system, and I will actually go back to a 2.2.x kernel rather than spend
> money on a dma compatible controller if irqtune or another solution
> cannot be found.
> 
> I will accept any ideas anyone has to offer. If irqtune is obsolete,
> please 

Re: [PATCH] to init/main.c

[Jeff Garzik]

Daniel Dickman wrote:
> Here is a small patch to main.c.
> 
> It does the following:
> - makes sure that asm/mtrr.h actually gets included, and

> --- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001
> +++ linux/init/main.c   Sat Jun 16 11:48:42 2001
> @@ -50,7 +50,7 @@
>  #endif
> 
>  #ifdef CONFIG_MTRR
> -#  include 
> +#include 
>  #endif

huh?

There is absolutely nothing wrong with that include line.

-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] to init/main.c

[Daniel Dickman]

Here is a small patch to main.c.

It does the following:
- makes sure that asm/mtrr.h actually gets included, and
- changes formatting in one place as per Documentation/CodingStyle

--- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001
+++ linux/init/main.c   Sat Jun 16 11:48:42 2001
@@ -50,7 +50,7 @@
 #endif
 
 #ifdef CONFIG_MTRR
-#  include 
+#include 
 #endif
 
 #ifdef CONFIG_NUBUS
@@ -292,8 +292,7 @@
ROOT_DEV = name_to_kdev_t(line);
memset (root_device_name, 0, sizeof root_device_name);
if (strncmp (line, "/dev/", 5) == 0) line += 5;
-   for (i = 0; i < sizeof root_device_name - 1; ++i)
-   {
+   for (i = 0; i < sizeof root_device_name - 1; ++i) {
ch = line[i];
if ( isspace (ch) || (ch == ',') || (ch == '\0') ) break;
root_device_name[i] = ch;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ps2 keyboard filter hook

[Andries . Brouwer]

>> One of these centuries we must replace the present keyboard
>> and console stuff, probably by something very similar to
>> Vojtech's input device stuff, and we must make sure that
>> the new code is powerful enough to last for a few years again.

> Why only something similar to the input suite and not the (full)
> input suite?

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

How to I prevent a 100 Mb program from swapping itself (with 512 Mb memory)

[thunder7]

I'm running linux-2.4.5-ac15, and I can't seem to make clear to Linux that I'd
rather use less cache than use swap for my active program. I can't run a 100 Mb
program in 512 Mb memory without swapping parts of the active program?

I start a slrn (newsreader) session on a very big newsgroup; 15 headers
that are read from disk, then sorted. The process takes about 100 Mb memory,
I have 512 Mb, so there should be enough to spare.
This is without any special values in /proc, BTW, just the defaults.

here we start (the logfile is "vmstat 2")

   procs  memoryswap  io system cpu
 r  b  w   swpd   free   buff  cache  si  sobibo   incs  us  sy  id
 0  1  0   8180 103364  86792 257804  15  16   109   156   85   151   6   6  88
 0  0  0   8180 103328  86792 257828   6   0 8 0  11381   0   1  99
 0  0  0   8152 102800  86792 257864   0   02468  11769   1   0  99
 1  0  0   8152  92976  88652 264304   0   0  1136 0  391   635   7   8  85
 1  0  0   8152  72700  93704 276452   0   0  2060  4260  701  1141  12  16  71
 1  0  0   8152  53348  97780 287576   0   0  1810  3594  608  1057  12  13  75
 1  0  0   8152  35516 101452 297956   0   0  1786  3594  616  1027   9  13  77
 0  1  1   8160  11376 107952 310756   0   0  2184  6452  731  1236  13  17  70
 2  0  1   8160   1588 109112 315664   0   0  1836  1798  597   964   9  32  59
 1  0  0   8160   2224 106436 318588   0   0  1578  3750  624   923  10  16  74
 3  0  0   8172   1956 109248 315820   0   0   986  3594  402   593   5  36  58
 0  1  0   8172   1588 108156 315932   0   0  1878  1996  590  1033  10  34  56
 0  1  0   8172   1592 104476 317924   0   0  1336  2580  514   785   7  17  76
 1  0  0   8172   1668 107912 313736   0   0  1096  3598  462   650   7  40  53
 1  0  0   8172   1780 108448 312740   0   0  1382  3680  520   796   7  39  53
 0  1  1   8172   1588 107212 312552   0   0  1778  3604  597   987   9  43  49
 1  0  2   8172   1748 104880 313196   0   0  1906  1234  613  1060  11  23  66
 0  1  1   8172   2432 107072 308980   0   0  1018  4570  443   695   6  39  55
 0  1  1   8172   1588 104880 310532   0   0  1828  1806  589   999  10  39  51
 1  0  1   8172   2032 104616 309316   4   0  1492  2570  548   925   8  19  74
 0  1  1   8172   1740 106308 306164   0   0  1082  3894  442   678   7  39  54
 0  1  1   8172   1588 106056 304992   0   0  1796  2656  603   989  11  45  44
 0  1  0   8172   1752 104732 305664   0   0  1310  3082  501   813   7  18  75
 0  1  1   8172   2112 104288 304576   0   0  1042  3808  475   703   9  33  57
 0  1  0   8140   1592 104400 304076   0   0  1174   514  488   694   5  16  79
 0  1  2   8200   1740 105144 302364   0   0  1252  2688  454   831   5  49  46
 1  0  0   8388   1596 104128 302276   0   0  1292  1008  478   876   7  51  42
 1  0  0   8388   1592 105004 301368   0   0   394  4410  380   434   2  16  82

free space is gone, so let's hit the buffers and start to swap. 

 0  3  2  11648   2976 105408 302268   0   0  1238  1730  594 15566   3  52  45
 0  1  0  33284  15572  87288 328872   0   8   846  1668  383   717   5  72  23
 0  1  0  34160   1560  91440 336572   0   0  1502  3596  558   896   7  11  82
 1  0  0  34116   1560  95112 329560   0   0  1572  3662  587   915   9  13  77
 0  1  0  34604   1560  98780 323048   0   0  1582  3602  586   894   9  13  77
 0  1  1  35112   1560 102448 315872   0   0  1832  3604  606  1002   8  17  75
 1  0  2  36244   1808 103312 316984   0   0  1834   442  620   999  11  33  56
 1  0  0  44836   1592 103132 327536   0   2  1364  4966  525   860   7  32  61
 1  0  0  44816   1588 103516 326796   0 166  1350  4282  546   925   8  38  54
 1  0  0  44772   2088 100884 327524   0  26  1868  1616  618  1095  12  46  42
 1  0  1  44772   1588 101784 326180   0   2  1418  2060  501   994   9  38  53
 1  0  0  44772   1768  99704 327772   0   2   700  4884  433   575   6  22  72
 0  1  1  44772   1588 100308 326276   0   6  1922  2096  611  1049  11  44  45
 1  0  1  44768   2656 102604 322084   0  10  1658  1786  567  1151   7  46  47
 1  0  1  44768   1876 101896 322604   0   0   940  5120  466   643   6  12  82
 1  0  0  44768   3000  99608 322388   0   0  1644  1480  533  1409   7  42  50
 1  0  1  44800   2480 100648 320656   0   6  1622  2304  566  1086   8  54  39
 1  0  1  46168   1700  99072 323320   0   0   958  4950  476   716   7  29  64
 1  0  0  50824   1592  99512 326356   0  48  1708  2196  583  1033   7  54  39
 0  1  1  55288   3044  98584 329060   0   2  1342  1728  495   854   9  59  32
 0  1  1  58612   1588  98408 332860  10   6   912  4818  485   764   6  40  54
 1  0  0  62768   2032  97168 336944   0 466  1116  1942  462   938   8  60  32
 1  0  0  65364   1872  98640 336960  26 574  1510  2246  541   997  11  49  41
 0  1  1  66552   1588  98256 337872   0  16   884  3844  478   708   6  36  58
 0  1  1  67228   1588  99456 336400   0 1090   962  3112  440 

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Thomas Molina wrote:

>I've tried most of the tests you all have been discussing, with a couple
>of exceptions.  I haven't tried bonnie ( don't even know where to get it
>or what it is supposed to test ).
>
Well, it's part of the SuSE distribution at least, and it tests hard 
disk performance - you need to give it a test size greater than your 
system's memory or all you're testing is Linux's ability to buffer reads 
and writes. :-) So for my 512Mb system I use "bonnie -s 1024"

>>as long as you're sure you do have DMA enabled that is - SuSE
>>at least leaves it disabled by default, under which conditions all
>>kernels are stable for me
>>
>
>Fairly certain.  I could be misinterpreting things, though.  Here is some
>output I'm seeing:
>
Compare:

>[root@localhost /root]# hdparm -tT /dev/hde
>
>/dev/hde:
> Timing buffer-cache reads:   128 MB in  0.70 seconds =182.86 MB/sec
> Timing buffered disk reads:  64 MB in  2.31 seconds = 27.71 MB/sec
>
root@hex:/home/rachel > hdparm -tT /dev/hde
 
/dev/hde:
 Timing buffer-cache reads:   128 MB in  0.66 seconds =193.94 MB/sec
 Timing buffered disk reads:  64 MB in  2.11 seconds = 30.33 MB/sec

>[root@localhost /root]# hdparm /dev/hde
>
>/dev/hde:
> multcount=  0 (off)
> I/O support  =  0 (default 16-bit)
> unmaskirq=  0 (off)
> using_dma=  1 (on)
> keepsettings =  0 (off)
> nowerr   =  0 (off)
> readonly =  0 (off)
> readahead=  8 (on)
> geometry = 3649/255/63, sectors = 58633344, start = 0
>

root@hex:/home/rachel > hdparm /dev/hde

/dev/hde:
 multcount= 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 79780/16/63, sectors = 80418240, start = 0

I have 32-bit IO (with sync) and multiple sector transfers enabled, 
where you don't. I don't expect that's the cause of the problem though - 
For instance, I can run reliably with any kernel with those enabled, as 
long as DMA is disabled.

>
>[root@localhost /root]# hdparm -i /dev/hde
>
>/dev/hde:
>
> Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1592536
> Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq
>}
> RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
> BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>
root@hex:/home/rachel > hdparm -i /dev/hde
 
/dev/hde:
 
 Model=IBM-DTLA-305040, FwRev=TW4OA60A, SerialNo=YJEYJLG3070
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
 BuffType=DualPortCache, BuffSize=380kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80418240
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
 Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
 Kernel Drive Geometry LogicalCHS=79780/16/63 PhysicalCHS=79780/16/63

. o O ( Dont' suppose any of this is useful to anyone... )

-- 
Rachel



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ps2 keyboard filter hook

[Michael Rothwell]

On 15 Jun 2001 16:03:32 -0400, [EMAIL PROTECTED] wrote:
> 
> IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the
> standard PS/2 specification in order to support addition hardware built into the
> keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys,
> -Dan

I'm facing a similar problem with the "Qoder" barcode scanner. I have to
have a keyboard hook. The "right" way seem to be to use the input api.
Unfortunately, this means that current kernels can't use the driver w/o
a patch (the input api patch). The ugly way is to patch the keyboard
driver. I'm doing both.

However, I wrote a REALLY SIMPLE hook tht supported exactly my needs,
since it's in the category of "ugly hack waiting for input api." Maybe
I'll write a version for your hook.

I wonder when the input api stuff for ps/2 devices will be a part of the
mainstream kernel...

--
Michael Rothwell
[EMAIL PROTECTED]


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

Re: VIA KT133A crash *post* 2.4.3-ac6

[Christian Bornträger]

> I'm certainly willing to provide any data it's decided is necessary to
> collect to make the correlations.  I'll even volunteer to be the
.
> bit different - I have the hard drive on the promise interface (ide2) and

If possible, can you remove the hard disc from the promise and attach it on
the VIA-Controller and test if the problem still occurs? (prepare a bootdisc
if you cannot boot. Propably, you have to pass a new root-partition to the
kernel)
I hardly believe that the promise controller has some problems with the new
VIA setup introduced in 2.4.3-ac7. Using the promise ports of the A7V133 is
the only correlation I see again and again...

--
PS: Sorry for using outlook, but sometimes you use an computer you doesn´t
own. :-)

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

Re: [ANNOUNCE] HotPlug CPU patch against 2.4.5

[Christoph Hellwig]

In article  you wrote:
> Hi all,
>
>   http://sourceforge.net/projects/lhcs/
>
>   Version 0.3 (untested) of the HotPlug CPU Patch is out, with
> ia64 and x86 support.  Bringing CPUs down and up is as simple as:
>
>   # Down...
>   echo 0 > /proc/sys/cpu/1
>   # Up...
>   echo 1 > /proc/sys/cpu/1

Wouldn't /proc/sys/cpu//enable be better?  This way other per-cpu
sysctls could be added more easily...



Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 KT133A crash *post* 2.4.3-ac6

[Thomas Molina]

On Sat, 16 Jun 2001, Rachel Greenham wrote:

> Thomas Molina wrote:
>
> >So is there no correlation from particular hardware to problems reported?
> >I'm running the A7V133 with a Western Digital WD300BB UDMA 5 drive on
> >kernel 2.4.5 with no trouble.
> >
> Well, I don't know. I'd guess there'd *have* to be some correlation, but
> we're not gathering enough information to see the pattern. ie: which
> BIOS version, what exact BIOS options are set, what processor/speed,
> what memory, what exact model of hard disk... We just may not have a big
> enough sample size. Even in my case the crashes aren't predictable in
> nature - 2.4.4 passed my bonnie test the first time, making me think the
> problem was introduced in 2.4.5, and only failed later in normal usage -
> next time I tested it it failed in the first minute or so. *Most* of the
> time failures occur during the bonnie test, but at all sorts of random
> times during the test.

I'm certainly willing to provide any data it's decided is necessary to
collect to make the correlations.  I'll even volunteer to be the
collection point for such data.  Beyond mainboard version, bios version,
and perhaps hard drive info I'm not sure what's appropriate.

I've tried most of the tests you all have been discussing, with a couple
of exceptions.  I haven't tried bonnie ( don't even know where to get it
or what it is supposed to test ).  I do create a number of CDs each week
so I am copying a moderate amount of data per session; my setup may be a
bit different - I have the hard drive on the promise interface (ide2) and
cdroms on the first ide interface (ide0) so I'm probably not testing the
same ide-to-ide copy problem that others are seeing.

> as long as you're sure you do have DMA enabled that is - SuSE
> at least leaves it disabled by default, under which conditions all
> kernels are stable for me

Fairly certain.  I could be misinterpreting things, though.  Here is some
output I'm seeing:

[root@localhost /root]# hdparm -tT /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  0.70 seconds =182.86 MB/sec
 Timing buffered disk reads:  64 MB in  2.31 seconds = 27.71 MB/sec
[root@localhost /root]# hdparm /dev/hde

/dev/hde:
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 3649/255/63, sectors = 58633344, start = 0
[root@localhost /root]# hdparm -i /dev/hde

/dev/hde:

 Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1592536
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq
}
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ps2 keyboard filter hook

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
> One of these centuries we must replace the present keyboard
> and console stuff, probably by something very similar to
> Vojtech's input device stuff, and we must make sure that
> the new code is powerful enough to last for a few years again.

Why only something similar to the input suite and not the (full)
input suite?  It works really nice here and unlike the current
keyboard cruft it is actually very clean.

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] HotPlug CPU patch against 2.4.5

[Rusty Russell]

Hi all,

http://sourceforge.net/projects/lhcs/

Version 0.3 (untested) of the HotPlug CPU Patch is out, with
ia64 and x86 support.  Bringing CPUs down and up is as simple as:

# Down...
echo 0 > /proc/sys/cpu/1
# Up...
echo 1 > /proc/sys/cpu/1

Apologies for the slow release, and *huge* kudos to the people
who did the real work for this release:

Kimio Suganuma (ia64)
Jason McMullan (x86)

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

Re: ps2 keyboard filter hook

[Andries . Brouwer]

>> patch to allow other drivers to register with the PS/2 driver as 'filters'

> Didn't we just conclude a discussion here on linux-kernel, which said
> that patches which simply add hooks allowing proprietary extensions are
> not accepted into the kernel?

There is a certain need for this kind of patches.
I have seen similar stuff for the blind, or for disabled
people who for example can use only one hand.
Also for people who use a combined keyboard/barcode reader.
Hooks for drivers that do something special have other uses
than for proprietary extensions.

It is good to see what people want.
One of these centuries we must replace the present keyboard
and console stuff, probably by something very similar to
Vojtech's input device stuff, and we must make sure that
the new code is powerful enough to last for a few years again.

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

No Subject

[Konstantin Volckov]

Hi!

There're a problem in . In this file included
, but this include is'nt ifdef'ed with __KERNEL__ and (for
example) samba can't be compiled with kernel 2.4 headers. Here is the
patch, that solve this problem.

-- 
Good luck,
Konstantin

 linux-2.4.5-ac15-lcap.patch

Re: Client receives TCP packets but does not ACK

[Mike Black]

OK guys -- how much money are you willing to be that TCP is guaranteed??
Since you don't want to talk OSI that's OK -- that's just to educate some
people.

Try this: (this is what I ran into years ago and had to argue to death).

#1 Client1 has tcp connection to Server1.  Both machines are setup to retry
connections if they fail.
#2 Server1 has power outage (note that Client1 has absolutely NO idea what
happens until Server1 is back up again no RST -- no nothin').
#3 Client1 finally times out and is able to reconnect to Server1 and thinks
everything is OK (as do all the programmers at our customer who think TCP is
a guaranteed protocol).
#4 Analysis shows numerous transacations have been lost (complete panic by
the customer).

Here's the big question.  Who's fault is it?  Our customer tried to claim
that the TCP stack was at fault on our server (a Windows 3.1 box) because it
"dropped packets" and didn't know about it.  Then they thought that the TCP
stack on their client was at fault because it never showed an error trying
to write to the socket.

After much argument I finally was able to show them (from the author of TCP
whom I emailed for support) that TCP is NOT guaranteed -- it's up to what
you guys are calling the "API" layer (OSI Layer 7) to ENSURE that data
ACTUALLY gets to it's intended target.  I was brought in late on this
contract but I never would've implemented the brain-dead protocol (or
actually complete lack of one) for sending transactions across a socket.

You're right in that TCP will work just fine AS LONG AS THERE ARE NO
PROBLEMS

You can write a program that just opens a socket and blasts data to the
recipient without an error.  And as long as your protocol is session
oriented you'll be fine.  If the session aborts you just resend the whole
thing.

But that does NOT make a robust solution for a transaction oriented protocol
(like the one that started this thread) (contrary to what many people think
AND code up).
P.S. My reference to TCP being at OSI layer 5 is because that's what the API
is for sockets -- Session Layer -- and that's all that people generally
think is needed.  Big mistake if you're transaction-oriented.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/VAX booting to a shell.

[Dave Airlie]

Hi all, (mind crossposts on follow ups..)

attached below is a bootlog from the Linux/VAX port, booting up, loading
up busybox/uClibc sh and cat /proc/cpuinfo, from my VAXStation 3100m38,

Thanks to the other two members of the core VAX porting team, Andy
Phillips and Kenn Humborg and others on the linux-vax list who've given
their help, this is the second major milestone for the project, (gcc
porting was the first) now to get it working on a few other systems and
move into userspace...

Regards,
Dave.

p.s. who said the Irish didn't hack kernels :-)

--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person


-ESA0
CPU type: KA42
Boot Head.S loaded at address 9600
rpb/bootr5/ap/sp    0348 8A00
relocated at phys address 001001B2
CPU type: 0A05 sidex: 04010102

Starting VM
Linux/VAX ([EMAIL PROTECTED])
IO mapped phys addr iomap_base 0x2008, 0x0001 pages at virt 0x80fe4000 (IOMAP PTE 
index 0x)
IO unmapping 0x0001 pages at PTE index 0x
IO mapped phys addr iomap_base 0x200a, 0x0001 pages at virt 0x80fe4000 (IOMAP PTE 
index 0x)
RPB info:  l_pfncnt: 7f1f, .l_vmb_version: 0a000400 .l_badpgs: 
Physical memory: 7f1f HW pagelets, 0fe3 pages  (16271KB)
CPU type: KA42, SID: 
calling start_kernel...
Linux version 2.4.2-20010307 (airlied@radon) (gcc version 2.95.2-linuxvax-20001231 
(release)) #622 Sat Jun 16 13:32:20 IST 2001
bootmap size = 0200
calling free_bootmem(start=0200, len=000ffe00)
calling free_bootmem(start=001f88b8, len=00dea748)
On node 0 totalpages: 4067
zone(0): 4067 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=/tftpboot/vaxroot console=/dev/ttyS
Calibrating delay loop... 5.42 BogoMIPS
max low pfn is   FE3000
VMALLOC_START is 810e4000
vmallocmap_base is 8020FE18, sbr 801EE198, diff  10E4000
Memory: 15000k/16268k available
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
kernel_thread: calling thread function at 80100824
IO mapped phys addr iomap_base 0x2008, 0x0001 pages at virt 0x80fe5000 (IOMAP PTE 
index 0x0001)
vsbus: interrupt mask 0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
kernel_thread: calling thread function at 8010d250
Starting kswapd v1.8
kernel_thread: calling thread function at 80118636
kernel_thread: calling thread function at 80120b00
kernel_thread: calling thread function at 80118790
kernel_thread: calling thread function at 80120c08
pty: 256 Unix98 ptys configured
block: queued sectors max/low 9685kB/3228kB, 64 slots per queue
Serial driver version 5.02 (2000-08-09) with no serial options enabled
DECstation DZ serial driver version 1.02
ttyS0 at 0x80fe4000 (irq = 176, 177)
ttyS1 at 0x80fe4000 (irq = 176, 177)
ttyS2 at 0x80fe4000 (irq = 176, 177)
ttyS3 at 0x80fe4000 (irq = 176, 177)
vaxlance.c: v0.008 by Linux Mips DECstation task force + [EMAIL PROTECTED]
IO mapped phys addr iomap_base 0x200e, 0x0001 pages at virt 0x80fe6000 (IOMAP PTE 
index 0x0002)
IO mapped phys addr iomap_base 0x2009, 0x0001 pages at virt 0x80fe7000 (IOMAP PTE 
index 0x0003)
Ethernet address in ROM: 08:00:2b:17:0a:7f
IO unmapping 0x0001 pages at PTE index 0x0003
Autoprobing LANCE interrupt vector... probed IRQ 148
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
Sending BOOTP requests OK
IP-Config: Got BOOTP answer from 192.168.2.15, my address is 192.168.2.55
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 13/2 on 192.168.2.15
Looking up port of RPC 15/2 on 192.168.2.15
kernel_thread: calling thread function at 80186ef8
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 28k freed
In CHRDEV_OPEN 5 1 80151fb6
dz opening line 3
page 80042d24, num 3964 ,pte_val A4C07BE0
k_platform is 76 61 78 00
u_platform is 76 61 78 00
starting thread14B10 7F80 80051F50


BusyBox v0.51 (2001.06.16-11:59+) Built-in shell (lash)
Enter 'help' for a list of built-in commands.

/ # mount -t proc none /proc
/ # cat /proc/cpuinfo
cpu : VAX
cpu type:
cpu sidex   : 0
page size   : 4096
BogoMIPS: 5.42
/ #



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

Re: 2.4.5-ac6 and 2.4.4-ac11 boot fails with APIC timer

[Mikael Pettersson]

On Sat, 16 Jun 2001 11:27:53 +0900, <[EMAIL PROTECTED]> wrote:

>> The message on the screen 
>>
>> calibrating APIC timer . 
>>  CPU clock speed is 1395.7390MHz 
>> ... host bus clock speed is 0. MHz 
>> cpu: 0, clocks: 0, slic: 0 
>>
>> Then nothing. I had to push the reset button at this point. 
>> ACPI and APM were disabled from the kernel config. 
>>
>> This boot failure messages was obtained from 
>> Pentium4 board GB-450(?) from Intel, NVIDIA M64 video. 
>> Sound Blaster 128 PCI. Netgear PNIC fast ethernet 
>>   
>> The same kernel was able to boot up the other Pentium 4 board from 
>> Gigabyte flawlessly. So, it depends on the motherboard manufacturers. 
>>
>> Regards to all. 
>>
>> G. Hugh Song 
>
>Replying to my own message:
>
>When I chose "No" to "APIC support on uniprocessors", the above error
>message disappeared and the machine booted up OK with 2.4.5-ac13.
>...
>I think that APIC thing was defined by Intel themselves.
>They should have implemented it the best.  How much penalty do I pay 
>by not choosing "yes" to "APIC support on uniprocessors"?

>From the part of the dmesg log you quoted I conclude that
(a) the NMI watchdog didn't kill you (good), but
(b) the calibration loop detects a 0MHz bus speed and then fails
to produce the "CPU0:" line, which means it hangs in
arch/i386/kernel/apic.c:setup_APIC_timer(), probably because
apic_read(APIC_TMCCT) always returns zero.

Anyway, you should disable CONFIG_X86_UP_APIC on your P4 for now.
You won't lose any performance due to this, only the possibility to
use the NMI watchdog.

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

VSTATUS and VDISCARD (^T and ^O) for linux

[Yedidya Bar-david]

Hello everyone,

The attached patch gives VSTATUS and VDISCARD characters recognition
to linux. In short, this means that pressing ^O will discard all
output to tty until another character is pressed, and ^T will output
a status line.

I use linux for 7+ years now, but this is my first kernel patch
(and first post to lkml), so it's not very polished (yet!), but it
works (at least for me). It's against 2.4.4+badmem patch, but
should apply cleanly to 2.4.5 too (I simply havn't yet checked
if there is badmem for 2.4.5, which I unfortunately need).

Some notes/questions:
1. Is there any special reason why such a thing isn't already in
linux? Or simply nobody needed it yet?
2. I was for 4 years a VMS sysmgr, and got used to ^T and ^O.
Only recently I found out these things are documented and work also
in some unices. The glibc docs say only BSD and GNU, but at
least VDISCARD is defined (but not implemented) in linux for
a long time.
3. There is no way (yet) to control these things from userland.
That is, libc and stty (maybe other). This will probably be
non-trivial and take me some more time, and worse, might need
a recompilation of many binaries. I looked at that only a bit.
4. In the status line, I wanted to see how much IO was done.
VMS prints the number of IO operations made, which, at least for
me, is not too much meaningful. BSD doesn't print any IO.
The patch counts the number of bytes that passed through sys_read
and sys_write, and keeps them in a new field I added to task_struct.
Is this a Bad Thing?
Of course, this is only a start. I should also count bytes going
through sys_send*, sys_recv*, maybe others. Still, it's already
very useful, as most progams use read/write even on sockets.
5. I copied some things from other files. e.g. LOAD_INT,LOAD_FRAC
from proc/proc_misc.c, vsize calculation from proc/array.c. Should
I have put them in public (include/linux/xxx.h) places?
6. I use a 64 byte buffer on the stack. I hope it is not considered
too big (I saw other functions do that). But it is too small for
e.g. the command name, so I print it directly, which can take a
long time on a slow tty (during which the task might finish?).
Should I task_lock/task_unlock around?
Or should I alloc a bigger buffer? and how (vmalloc, get_free_page)?
7. I currently based the output on that of *BSD, with changes.
It is:
 load: cmd: pid: u s \
vsz:k rss:k io:k
e.g.
pinky load:0.22 cmd:cat pid:1311 0.00u 0.00s vsz:1216k rss:384k io:1k
Comments, anyone?
8. It is currently only for i386. I don't mind patching all the
archs, but I can't test on most of them (I have some access to
mips and alpha, but havn't tried that on them).
I do not realy understand why should such things be arch specific.
And they are! e.g. NCCS is 19 for most archs, but 23 for mips and
mips64 and 17 for sparc and sparc64. Can anyone explain, please?


I hope people will find it useful (as I do), and when it matures will
make it into the official kernel.
It will also be available from .

Also, I am not subscribed to lkml, so please CC: me when you
reply. Thanks.

didi


diff -u -r linux-2.4.4-badmem/drivers/char/n_tty.c 
linux-2.4.4-badmem-ctrl-t/drivers/char/n_tty.c
--- linux-2.4.4-badmem/drivers/char/n_tty.c Fri Apr  6 10:42:55 2001
+++ linux-2.4.4-badmem-ctrl-t/drivers/char/n_tty.c  Fri Jun 15 22:51:18 2001
@@ -45,6 +45,8 @@
 #include 
 #include 
 
+#include 
+
 #define CONSOLE_DEV MKDEV(TTY_MAJOR,0)
 #define SYSCONS_DEV  MKDEV(TTYAUX_MAJOR,1)
 
@@ -502,9 +504,95 @@
wake_up_interruptible(&tty->read_wait);
 }
 
+#define LOAD_INT(x) ((x) >> FSHIFT)
+#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+
+static inline void echo_string(char *s, struct tty_struct *tty)
+{
+   while (*s)
+   echo_char(*(s++), tty);
+}
+
+static inline void n_tty_print_status(struct tty_struct *tty)
+{
+   int a;
+   char buf[64];
+   struct task_struct *p, *task=0;
+   struct mm_struct *mm;
+   unsigned long vsize = 0, rss = 0;
+
+   /* Hostname */
+   sprintf(buf, "%s", system_utsname.nodename);
+   echo_string(buf, tty);
+
+   /* Load average */
+   echo_string(" load:", tty);
+   a = avenrun[0] + (FIXED_1/200);
+   sprintf(buf, " %d:%02d", LOAD_INT(a), LOAD_FRAC(a));
+   echo_string(buf, tty);
+
+   /* Choose a task to print status about */
+   for_each_task(p) {
+   if (p->pgrp == tty->pgrp)
+   task = p;
+   }
+   if (!task) {
+   echo_string("Can't find task!", tty);
+   opost('\n', tty);
+   return;
+   }
+
+   /* Command name */
+   echo_string("  cmd: ", tty);
+   echo_string(task->comm, tty);
+
+   /* PID */
+   sprintf(buf, " %d ", task->pid);
+   echo_string(buf, tty);
+
+   /* User time */
+   sprintf(buf, " %ld.%02ldu", task->times.tms_utime / 100,
+   task->times.tms_utime % 100);
+   echo_s

Re: Changing CPU Speed while running Linux

[arjan]

In article <[EMAIL PROTECTED]> you wrote:
>> and does the right thing wrt udelay / bogomips etc..
>> I can dig it out if you want.. sounds like this should be a more generic
>> thing.

> Can you dig that out? I'd like to take a look.

> [Of course, problem is *not* solved: you still have short time when
> kernel runs with wrong bogomips.]

But the kernel controls that time . It's not perfect, and it might be
aleviated by going in small steps at a time.
Disabling interrupts isn't fun as the bogomips code kind of needs that ;)

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

Hi!

[Olga Georgieva]

Hi! Excuse me for my reference to you, I simply do not have other output from my
problem. My child dies, at him a heart disease and to him operation is urgently 
necessary,
but I do not have money for this operation. Please, help me though something. I shall 
be
glad even to the small sum of money, you see it will help to rescue life of my son. I 
hope
that with your help I shall collect the necessary sum of money. Beforehand to you it is
grateful!

Olga Georgieva

If you have decided to help me, let the smallest money, transfer them to my purse in
payment system WEBMONEY

Purse Z 207698943068

Once again excuse me, I hope you understand my emotional condition.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Thomas Molina wrote:

>So is there no correlation from particular hardware to problems reported?
>I'm running the A7V133 with a Western Digital WD300BB UDMA 5 drive on
>kernel 2.4.5 with no trouble.
>
Well, I don't know. I'd guess there'd *have* to be some correlation, but 
we're not gathering enough information to see the pattern. ie: which 
BIOS version, what exact BIOS options are set, what processor/speed, 
what memory, what exact model of hard disk... We just may not have a big 
enough sample size. Even in my case the crashes aren't predictable in 
nature - 2.4.4 passed my bonnie test the first time, making me think the 
problem was introduced in 2.4.5, and only failed later in normal usage - 
next time I tested it it failed in the first minute or so. *Most* of the 
time failures occur during the bonnie test, but at all sorts of random 
times during the test.

as long as you're sure you do have DMA enabled that is - SuSE 
at least leaves it disabled by default, under which conditions all 
kernels are stable for me

-- 
Rachel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Changing CPU Speed while running Linux

[Pavel Machek]

Hi

> > on my Elan410 based System it is very easy to change the CPU clock speed by
> > means od two outb commands.
> > 
> > I was wondering, if it does some harm to the Kernel if the CPU is
> > reprogrammed using a different CPU clock speed, while the system is up and
> > running.
> 
> I have a module for the K6 PowerNow which allows you to do
> 
> echo 450 > /proc/sys/cpu/0/frequency
> 
> and does the right thing wrt udelay / bogomips etc..
> I can dig it out if you want.. sounds like this should be a more generic
> thing.

Can you dig that out? I'd like to take a look.

[Of course, problem is *not* solved: you still have short time when
kernel runs with wrong bogomips.]

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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: SMP spin-locks

[Pavel Machek]

Hi!

> The 'read()' routine uses a spinlock when it modifies pointers.
> 
> I started to look into where all the CPU clocks were going. The
> SMP spinlock code is where it's going. There is often contention
> for the lock because interrupts normally occur at 50 to 60 kHz.
> 
> When there is contention, a very longjump occurs into
> the test.lock segment. I think this is flushing queues. 

On UP, there's *never* contention on the lock, because irqsave lock
disables interrupts. Right? Something else must be slowing you.

Pavel
PS: But that's bad. Performance should not come down twice --
this will bite you even on real SMP.

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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: APM, ACPI, and Wake on LAN - the bane of my existance

[Pavel Machek]

Hi!

> anything.  So I removed the three pin cross connect that connects the
> card to the WOL header on the motherboard.  That fixed it for a few
> days, but now it's doing it again, even without the cable installed. 
> the only fix is to unplug the ethernet cable when I turn it off.  

So turn it off by unplugging AC cord. If it comes up *without* AC plugged
in Welll... Call GhostBusters.
Pavel
PS: I is possible that machine comes up after powerfail. This might be
your proble. Without 3pin cable installed, it really should not come up
itself.
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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: Has it been done: User Script File System?

[Pavel Machek]

Hi!

> Is there any filesystem in Linux that uses user scripts/executables to
> implement the various function calls?  What I'm thinking of is something
> along the lines of a file system module that, when it receives a call
> from VFS, passes the information out to a user-mode daemon which could
> then run scripts or executables to answer the question.  The daemon
> would then return the answer to the module, and the module would answer
> VFS.

Take a look at uservfs.sourceforge.net. Its extfs module is basically what
you want. zipfs is already implemented using script...
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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: 3com Driver and the 3XP Processor

[Martin Moerman]

On Fri, 15 Jun 2001, Pekka Pietikainen wrote:

> On Fri, Jun 15, 2001 at 08:37:15AM -0700, David S. Miller wrote:
> > 
> > Pete Wyckoff writes:
> >  > We're currently working on using both processors
> >  > of the Tigon in parallel.
> > 
> > It is my understanding that on the Tigon2, the second processor is
> > only for working around hw bugs in the DMA controller of the board and
> > cannot be used for other tasks.
> > 
> > WRT. tigon3, it was mentioned on this list that it is a pair of arm9
> > cpus, one for rx and one for tx.
> > 
> Might be worth asking broadcom instead of 3com for the specs, 
> as they seem to be selling it as a chip (BCM5700/5701), whereas 3com sells a
> board (3c996).
> 

Guys,

To make it easier, Tell me exactly what you need in documentation and I
will try to get it for you. 

Martin Moerman
[EMAIL PROTECTED]




> -- 
> Pekka Pietikainen
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: 3com Driver and the 3XP Processor

[Martin Moerman]

Well nick, that is your choice.

/Martin
[EMAIL PROTECTED]

On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:

> Erm, that is going to be a problem.  Crypto benifits more from open source
> than any other market segment, and binary only drivers for linux are not
> the way to go.  I guess I need to get rid of my 5-10 3cr990s and replace
> them with someone else's product?
>   Nick
> 
> On Thu, 14 Jun 2001, Kip Macy wrote:
> 
> > IPsec support will be binary only.
> > 
> > -Kip
> > On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
> > 
> > > So what is the truth to the rumors 3com was throwing around about the
> > > "linux driver with ipsec support"?
> > >   Nick
> > > 
> > > On Thu, 14 Jun 2001, Martin Moerman wrote:
> > > 
> > > > 
> > > > 
> > > > On Thu, 14 Jun 2001, Brent D. Norris wrote:
> > > > 
> > > > > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT
> > > > > > donkey work... Just offloading DES isn't terribly useful, as Pavel says:
> > > > > > apart from anything else, DES is a bit elderly now - SSH using 3DES or
> > > > > > Blowfish etc... How dedicated is this card? Could it be used to offload
> > > > > > other work?
> > > > > 
> > > > > Sorry my bad it is 3DES that they have on it, but I don't know how
> > > > > in-grained it is in it.  Like I sad it just floated across my desk a few
> > > > > days ago and it sounded like a cool bit of hardware.
> > > > 
> > > > 
> > > > The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and
> > > > does IPSEC through the ARM9 proc.
> > > > 
> > > > I like the card. but no real real linux drivers yet. only basic network
> > > > card drivers for linux.
> > > > 
> > > > /Martin
> > > > [EMAIL PROTECTED]
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > Brent Norris
> > > > > 
> > > > > Executive Advisor -- WKU-Linux
> > > > > 
> > > > > System Administrator -- WKU-Center for Biodiversity
> > > > > Best Mechanical
> > > > > 
> > > > > W: 270-745-8864
> > > > > H: 270-563-9226
> > > > > 
> > > > > "The problem with the Linux learning curve is that it is _so_ steep once
> > > > >  at the top you can't see the people at the bottom"  --Doug Hagan
> > > > > 
> > > > > -
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > > the body of a message 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/
> > > > 
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message 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/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: psaux mouse driver + inland pro optical 100 mouse

[volodya]

Try commenting out the AUX_RECONNECT block on line 406 in pc_keyb.c

#ifdef CONFIG_PS2_KEYBOARD_SWITCH_COMPATIBILITY_MODE
else if(scancode == AUX_RECONNECT){
queue->head = queue->tail = 0;  /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
return;
}
#endif

and let me know what happens..  

 Vladimir Dergachev
PS please CC me as I read this list only occasionally (too much traffic).

On Fri, 15 Jun 2001, David Ashley wrote:

> Under linux 2.4.1 if I move the mouse slow enough it doesn't register at all
> in Xwindows. If I unplug the ps2 mouse and plug it back in, it works
> perfectly, no matter how slowly I move it the movement is registered. It
> is as if the linux kernel is imposing a threshold on the movement.
> 
> Under windows it works fine. The problem is in linux.
> 
> I've tried modifying pc_keyb.c code by sending an F6 byte to set defaults,
> using the aux_write_ack function in open_aux(), but that doesn't have any
> effect. Does anyone have a clue what the driver is doing to reduce the
> quality of the mouse? I'm not sure it is limited to this particular mouse,
> it is just the one I just bought at Fry's for $10.
> 
> I'm running an athlon 1 gig, /proc/version is
> Linux version 2.4.1 (root@dave) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 
>release)) #17 Fri Jun 15 20:15:45 PDT 2001
> 
> Thanks!
> -Dave
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: Few thoughts about CML2 and kernel configuration

[John R Lenton]

On Sat, Jun 16, 2001 at 11:22:27AM +0600, Anuradha Ratnaweera wrote:
> - The feeling is much similar to that of using lynx (especially using
>   left-arrow). It would be very nice if pressing right-arrow gives the
>   same effect as pressing enter.

that's what the help says it *should* do. Try this:


--- cmlconfigure.py~Sun Jun 10 13:05:58 2001
+++ cmlconfigure.py Sat Jun 16 05:10:32 2001
@@ -1478,7 +1478,7 @@
 cmd = self.help_popup("EXITCONFIRM", (lang["REALLY"],), beep=0)
 if cmd == ord('q'):
 break
-elif cmd in (curses.KEY_ENTER,ord(' '),ord('\r'),ord('\n')) :
+elif cmd in (curses.KEY_ENTER,curses.KEY_RIGHT,ord(' 
+'),ord('\r'),ord('\n')) :
 # Operate on the current object
 if sel_symbol.type == "message":
 curses.beep()


-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
This wasn't just plain terrible, this was fancy terrible.  This was terrible
with raisins in it.
-- Dorothy Parker

 PGP signature

[Oops] 2.4.5-ac14/2.4.6-pre3+Athlon+gcc3-prerelease+VIAKT133A

[Richard Chan]

Here's an oops from

1. Athlon kernel, gcc3 prerelease 14 June compiled
2. Kernel version 2.4.5-ac14
3. Mobo: Soltek 75KAV (VT133A disaster??) with Athlon 1.2G C

Any ideas? Bad compiler or bad kernel?
The problems occur in kmem_cache_.

On this mobo and chipset I have had no luck with locally compiled
Athlon kernels at all (whether stock or -ac, RedHat gcc or gcc3-prerelease).
Me thinks something is seriously wrong with this mobo/chipset or is it
the Athlon code in gcc?

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

CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010012
eax: 400a0006   ebx: 004da9ba   ecx: cff3f000   edx: 0180
esi: c1407ae0   edi: 0286   ebp: 0020   esp: cfd3ff18
ds: 0018   es: 0018   ss: 0018
Process minilogd (pid: 22, stackpage=cfd3f000)
Stack: cfd2e0c0  cff3f740 0001 c01167f7 c1407ae0 cff3f740 c14d8340 
   cfd3e000 0500 bd28 c0116d71 cff3f740    
        cf00 c01399ff 0286 
Call Trace: [] [] [] [] [] 
   [] 
Code: 89 44 99 18 8b 41 10 89 59 14 8d 50 ff 89 51 10 3b 46 14 74 

>>EIP; c0128246<=
Trace; c01167f7 
Trace; c0116d71 
Trace; c01399ff 
Trace; c01d0cbd 
Trace; c0116ece 
Trace; c0106edb 
Code;  c0128246 
 <_EIP>:
Code;  c0128246<=
   0:   89 44 99 18   mov%eax,0x18(%ecx,%ebx,4)   <=
Code;  c012824a 
   4:   8b 41 10  mov0x10(%ecx),%eax
Code;  c012824d 
   7:   89 59 14  mov%ebx,0x14(%ecx)
Code;  c0128250 
   a:   8d 50 ff  lea0x(%eax),%edx
Code;  c0128253 
   d:   89 51 10  mov%edx,0x10(%ecx)
Code;  c0128256 
  10:   3b 46 14  cmp0x14(%esi),%eax
Code;  c0128259 
  13:   74 00 je 15 <_EIP+0x15> c012825b 


 guring kernel pa<1>Unable to handle kernel paging request at virtual address d12a9704
c0128246
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010012
eax: 400a0006   ebx: 004da9bb   ecx: cff3f000   edx: 0180
esi: c1407ae0   edi: 0286   ebp: 0020   esp: cfd4df18
ds: 0018   es: 0018   ss: 0018
Process sysctl (pid: 23, stackpage=cfd4d000)
Stack: cff24bc0  cff3f900 0001 c01167f7 c1407ae0 cff3f900 c14d83c0 
   cfd4c000  bd68 c0116d71 cff3f900 40019000 1000  
    40019000 1000 c1407ba0 c0122795 c14d83c0 cfd644c0 40019000 
Call Trace: [] [] [] [] [] 
   [] 
Code: 89 44 99 18 8b 41 10 89 59 14 8d 50 ff 89 51 10 3b 46 14 74 

>>EIP; c0128246<=
Trace; c01167f7 
Trace; c0116d71 
Trace; c0122795 
Trace; c012f91e 
Trace; c0116ece 
Trace; c0106edb 
Code;  c0128246 
 <_EIP>:
Code;  c0128246<=
   0:   89 44 99 18   mov%eax,0x18(%ecx,%ebx,4)   <=
Code;  c012824a 
   4:   8b 41 10  mov0x10(%ecx),%eax
Code;  c012824d 
   7:   89 59 14  mov%ebx,0x14(%ecx)
Code;  c0128250 
   a:   8d 50 ff  lea0x(%eax),%edx
Code;  c0128253 
   d:   89 51 10  mov%edx,0x10(%ecx)
Code;  c0128256 
  10:   3b 46 14  cmp0x14(%esi),%eax
Code;  c0128259 
  13:   74 00 je 15 <_EIP+0x15> c012825b 


 rameters:  <1>Unable to handle kernel paging request at virtual address d12a96fc
c0128246
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010012
eax: 400a0006   ebx: 004da9b9   ecx: cff3f000   edx: 0180
esi: c1407ae0   edi: 0286   ebp: 0100   esp: cfd49f18
ds: 0018   es: 0018   ss: 0018
Process initlog (pid: 21, stackpage=cfd49000)
Stack: cff3f580  cff3f580 cfd96000 c01167f7 c1407ae0 cff3f580 c14d82c0 
   cfd48000 0b00 bd48 c0116d71 cff3f580 b710 cfd49f70 cfd49fa4 
   c011d105 cff240c0 ffea  0049 cff240c0 0049  
Call Trace: [] [] [] [] [] 
   [] 
Code: 89 44 99 18 8b 41 10 89 59 14 8d 50 ff 89 51 10 3b 46 14 74 

>>EIP; c0128246<=
Trace; c01167f7 
Trace; c0116d71 
Trace; c011d105 
Trace; c012fd93 
Trace; c0116ece 
Trace; c0106edb 
Code;  c0128246 
 <_EIP>:
Code;  c0128246<=
   0:   89 44 99 18   mov%eax,0x18(%ecx,%ebx,4)   <=
Code;  c012824a 
   4:   8b 41 10  mov0x10(%ecx),%eax
Code;  c012824d 
   7:   89 59 14  mov%ebx,0x14(%ecx)
Code;  c0128250 
   a:   8d 50 ff  lea0x(%eax),%edx
Code;  c0128253 
   d:   89 51 10  mov%edx,0x10(%ecx)
Code;  c0128256 
  10:   3b 46 14  cmp0x14(%esi),%eax
Code;  c0128259 
  13:   74 00 je 15 <_EIP+0x15> c012825b 


 net.ipv4.ip_forw<1>Unable to handle kern

Re: [patch] nonblinking VGA block cursor

[Erik Mouw]

On Sat, Jun 16, 2001 at 01:44:40AM +0200, Daniel Phillips wrote:
> IBM had lots of ideas about how computers should work.  Remember the keyboard 
> keys that when CLACK CLACK CLACK.  Thank god they turned out to be too 
> expensive to clone - nobody misses them now.

I actually like that kind of keyboards, they're extremely reliable and
are great to use.

Anyway, my point is that keyboards are a matter of taste, just like
blinking or non-blinking cursors are.


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: [OT] Re: Snowhite and the Seven Dwarfs - The REAL story!

[Anuradha Ratnaweera]

On 15 Jun 2001, Michael Peddemors wrote:

> (Personally, I block em at the mailer, to protect those poor
> unfortunates that haven't switched to Linux Yet)

Personally, I don't. If I do so, those poor unfortunates will have one
less reason to switch to Linux and will remain unfortunates forever ;)

Anuradha

--
http://www.bee.lk/people/anuradha/

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