Re: my first post to the list - newbie alert

[Chris \"_Shad0w_\" Crowther]

On Sat, 3 Mar 2001, Alan Cox wrote:

> > You might even score!
> 
> Of course its attitudes like that which leads them to have to set up their
> own mailing lists, and contribute to the rather low count of women on the
> kernel credits

And makes some men wish they weren't...guilt by association and
all that.

Hmm, I should probably catch up on my linuxchix folders actually.

-- 
Chris "_Shad0w_" Crowther
[EMAIL PROTECTED]
http://www.shad0w.org.uk/

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

Re: [prepatches] removal of console_lock

[Pierre Rousselet]

Andrew Morton wrote:

> This patch fixes it.  Interrupts are enabled across all console operations.
> 
> It's still somewhat a work-in-progress.

The patch applies OK against 2.4.3-pre1
At the end of make bzImage I got
kerne/kernel.o(.text+0xcd00): undefined reference to 'in_interrupt'

PR
-- 

 Pierre Rousselet <[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: [prepatches] removal of console_lock

[Andrew Morton]

Pierre Rousselet wrote:
> 
> Andrew Morton wrote:
> 
> > This patch fixes it.  Interrupts are enabled across all console operations.
> >
> > It's still somewhat a work-in-progress.
> 
> The patch applies OK against 2.4.3-pre1
> At the end of make bzImage I got
> kerne/kernel.o(.text+0xcd00): undefined reference to 'in_interrupt'

Thanks.  Add a

#include 

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

[Manfred Spraul]

> - Major revamp of printk(). The approach taken in printk() is to try 
>   to acquire the (new) console_sem. If we succeed, the output is 
>   placed into the log buffer and is printed to the consoles. If we fail 
>   to acquire the semaphore we just buffer the output in the log buffer 
>   and the current holder of the console_sem will do the printing for us 
>   prior to releasing console_sem. 

Is down_trylock reliable under load?

I remember 2 or 3 bug reports than disappeared after down_trylock was
removed.
The last one was this week.

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg31919.html

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

[CFT] Re: 2.4 VM question

[Mike Galbraith]

On Sat, 3 Mar 2001, David wrote:

> Is there a particular reason why 2.4 insists on stuffing as much as
> possible into swap?

Yes.. the VM is being tuned.  The latest changes result in overly
agressive caching with some work loads.

For people who are running into this, please edit mm/vmscan.c and
change DEF_PRIORITY from 6 to 2.  This change helps the performance
woes I see on my box quite a bit.  Report results to me (interested),
and the cc list (those who can ACT on it;) unless they say otherwise.

-Mike

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

[patch] perform reboot notification in process context

[Andrew Morton]

ctrl_alt_del() is called from hard interrupt context.
It traverses the reboot_notifier_list.  Many of the
callouts on that list are not designed to be called
in this context.

DAC960_Finalise()
Calls remove_proc_entry() within interrupt context.
remove_proc_entry uses spin_lock()s.
Can deadlock.

drivers/char/sbc60xxwdt.c:sbc60xxwdt_unload()
Calls misc_deregister which calls down().

drivers/i2o/i2o_core.c
calls i2o_post_wait()
calls i2o_reset_controller()

Both of these schedule().  Crashes every time.

drivers/scsi/gdth.c
gdth_halt()
calls gdth_do_cmd
does down().


This patch makes keventd do the callout.


--- linux-2.4.3-pre1/kernel/sys.c   Tue Oct 17 06:58:51 2000
+++ linux-akpm/kernel/sys.c Sun Mar  4 22:04:57 2001
@@ -330,6 +330,12 @@
return 0;
 }
 
+static void deferred_cad(void *dummy)
+{
+   notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
+   machine_restart(NULL);
+}
+
 /*
  * This function gets called by ctrl-alt-del - ie the keyboard interrupt.
  * As it's called within an interrupt, it may NOT sync: the only choice
@@ -337,10 +343,13 @@
  */
 void ctrl_alt_del(void)
 {
-   if (C_A_D) {
-   notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
-   machine_restart(NULL);
-   } else
+   static struct tq_struct cad_tq = {
+   routine: deferred_cad,
+   };
+
+   if (C_A_D)
+   schedule_task(&cad_tq);
+   else
kill_proc(1, SIGINT, 1);
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [prepatches] removal of console_lock

[Andrew Morton]

Manfred Spraul wrote:
> 
> > - Major revamp of printk(). The approach taken in printk() is to try
> >   to acquire the (new) console_sem. If we succeed, the output is
> >   placed into the log buffer and is printed to the consoles. If we fail
> >   to acquire the semaphore we just buffer the output in the log buffer
> >   and the current holder of the console_sem will do the printing for us
> >   prior to releasing console_sem.
> 
> Is down_trylock reliable under load?

I'm not aware of any problems.  It's only really used in one
place at present - when networking interrupt context wants to
acquire a socket's semaphore.  Oh.  That seems to have disappeared.

I've tested it pretty hard on SMP with zillions of printk()s from
interrupt context in parallel with `cat lots_of_stuff'.

> I remember 2 or 3 bug reports than disappeared after down_trylock was
> removed.
> The last one was this week.
> 
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg31919.html

That was different.  The parport code was leaving the semaphore in
a downed state when it shouldn't have.

But you're right - it's not well-proven code.  I'll go stare
angrily at it for a while.  Of course, there are about ten
different implementations...

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

[Pavel Machek]

Hi!

> > Transmit keycodes is AFAIK not implemented in official drivers.
> 
> Maybe I misunderstand what you mean, but the kernel has had a
> keycode mode since before 1.0.

I meant ability for application to simulate pressing "shift" or
"pageup". I do not believe we have that feature.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH 2.4.0 parisc PCI support

[Ivan Kokshaysky]

On Fri, Mar 02, 2001 at 11:32:35AM -0800, Grant Grundler wrote:
> Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800
> (133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support
> working. I'm quite certain PCI-PCI bridge configuration (ie BIOS
> didn't configure the bridge) support was broken.

I believe it isn't. ;-) It works on various alphas including
configurations with chained PCI-PCI bridges.
Some comments on the patch:

> +** If I/O or MEM ranges are overlapping, that's a BIOS bug.

No. As we reallocate everything, it is quite possible that we'll
have temporary overlaps during setup with resources allocated
by BIOS. I'm not sure if it is harmful though.

> +#ifdef __hppa__
> +/* XXX FIXME
> +** PCI_BRIDGE_CONTROL and PCI_COMMAND programming need to be revisited
> +** to support FBB.  Make all this crud "configurable" by the arch specific
> +** (ie "PCI BIOS") support and the ifdef __hppa__ crap can go away then.
> +*/

Agreed. Something like pcibios_set_bridge_control().

>   for (ln=bus->children.next; ln != &bus->children; ln=ln->next) {
>   struct pci_bus *b = pci_bus_b(ln);
>  
> - b->resource[0]->start = ranges->io_start = ranges->io_end;
> - b->resource[1]->start = ranges->mem_start = ranges->mem_end;
> -
> + ranges->io_start = ranges->io_end;
> + ranges->mem_start = ranges->mem_end;
>   pbus_assign_resources(b, ranges);
> -
> - b->resource[0]->end = ranges->io_end - 1;
> - b->resource[1]->end = ranges->mem_end - 1;
> -
>   pci_setup_bridge(b);
>   }

This change totally breaks PCI allocation logic.
Probably you assign PCI-PCI bridge windows in arch specific
code - why?
The only thing you need is to set up the root bus resources
properly and generic code will do the rest.

> +#ifndef __hppa__
>   /* PCI-PCI bridges may have I/O ports or
>  memory on the primary bus */
>   if (dev->class >> 8 == PCI_CLASS_BRIDGE_PCI &&
>   i >= PCI_BRIDGE_RESOURCES)
>   continue;
> +#endif

Same here.

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

Re: Question about IRQ_PENDING/IRQ_REPLAY

[Benjamin Herrenschmidt]

>In particular, if an edge-triggered interrupt comes in on an x86 IO-APIC
>while that interrupt is disabled, enabling the interrupt will have caused
>that irq to get dropped. And if it gets dropped, it will never ever happen
>again: the interrupt line is now active, and there will never be another
>edge again.

Ok, I see. We have a different issue with the old Apple IRQ controller that
can lose interrupts if they are active when re-enabled. We currently rely
on a hack to work aroud this that may re-send interrupts, but that involves
hacking into __sti() to check for lost interrupts, which is bad.

Basically, even a level interrupt, if active while re-enabled, will not be
sent by the pic to the CPU, and so further interrupts will be blocked too.
We have some code in enable_irq() that can detect this case, but re-triggering
the interrupt is not really simple and requires the __sti() hack for now. 

I beleive we may have a way to re-trigger the interrupt without having to
hack __sti() by using a fake timer interrupt. I'll look into this, but in
that case, the code can be mostly self-contained in enable_irq, we will
probably not need to play with IRQ_PENDING & IRQ_REPLAY flag at all.

>> I'd be glad if you could take the time to enlighten me about this as I'm
>> trying to make the PPC code as close as the i386, according to your
>> comment stating that it would be generic in 2.5, and I don't like having
>> code I don't fully understand ;)
>
>You likely don't have this problem at all. Most sane interrupt controllers
>are level-triggered, and won't show the problem. And others (like the
>i8259) will see a disabled->enabled transition as an edge if the interrupt
>is active (ie they have the edge-detection logic _after_ the disable
>logic), and again won't have this problem.

Well, Apple now uses OpenPICs, but all slightly older macs had a home-made
Apple controller that had the above issue :( In fact, it can happpen with
both and and level interrupts for us.

Regards,
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: Keyboard simulation

[Guest section DW]

On Sun, Mar 04, 2001 at 12:40:14PM +0100, Pavel Machek wrote:

> > > Transmit keycodes is AFAIK not implemented in official drivers.
> > 
> > Maybe I misunderstand what you mean, but the kernel has had a
> > keycode mode since before 1.0.
> 
> I meant ability for application to simulate pressing "shift" or
> "pageup". I do not believe we have that feature.

No. But we have TIOCSTI, which will do this in raw scancode mode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

DVD Problem

[Christian Hilgers]

Hi,

I'm trying to use the 2.4.1 Kernel but I have some troubles with my
ATAPI Matsushita UJDA510 DVD (Intel 82371AB/EP PCI Bus Master IDE
Controler).
It works perfekt with CD-Rom but when I try to read a ISO 9660 DVD I got
an error.

I can mount the DVD and I can list the complet content but I guess I
can't access any File behind 650 MB.

e.g.

mount /cdrom
$ cat /cdrom/blah/blah/INDEX
cat: INDEX.german: Input/output error

The kernel log
Mar  3 18:45:06 laptop kernel: VFS: Disk change detected on device
ide1(22,0)
Mar  3 18:45:10 laptop kernel: ISO 9660 Extensions: RRIP_1991A
Mar  3 18:46:05 laptop kernel: attempt to access beyond end of device
Mar  3 18:46:05 laptop kernel: 16:00: rw=0, want=2855480, limit=1052700

It also works well with a 2.2.14-SuSE Kernel.

Any hints.

Thanks
Christian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LILO error with 2.4.3-pre1...

[Alan Cox]

>LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
>'lba32' extensions Copyright (C) 1999,2000 John Coffman
> 
>Boot image: /boot/vmlinuz-2.4.3-pre1
>Fatal: geo_comp_addr: Cylinder number is too big (1274 > 1023)
> 
> I have no idea why the 1023 limit is coming up considering 2.4.2 and
> LILO were working just fine together and I have a newer BIOS that has
> not problems detecting the driver properly. Go ahead, call me idiot :).

You need to specify the lba32 option in your config

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

[Romain Chantereau]

Hi,

I didn't know where send this bug report, so I send it here as writen in
the Doc... Sorry if I mistake...

Ok, I have a Debian sid (sic), on a AMD K6-2 300, on a Asus P5A, I have
enabled AGP etc...
Ah ! My graphic card is a Riva TNT, and I use it with the Nvidia driver
0.9.6..

Ok, let's talk about the problem: That's it :

(fidel is my computer name)

fidel login: Unable to handle kernel paging request at virtual address
18297044
 printing eip:
 c6a9ed43
 *pde = 
 Oops: 0002
 CPU:0
 EIP:0010:[]
 EFLAGS: 00013246
 eax: 18297044   ebx: c58cfa1f   ecx:    edx: 0001
 esi: c14b8220   edi:    ebp: c1643e18   esp: c1643e0c
 ds: 0018   es: 0018   ss: 0018
 Process X (pid: 658, stackpage=c1643000)
 Stack: c14b83e0 cbb2f004 c1f96204 c1643e34 c6a9f0af cbb2f004 c14b8220
c58cfa20
c14b83e0 c58cf9f0 c1643e50 c6a9741a cbb2f004 c58cf9f0 c14b83e0

 c1643e74 c6a9c0df cbb2f004 c58cf9f0 0001 0101
c14b83e0
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   []

Code: 08 14 38 46 89 d8 4b 85 c0 75 e4 8d 65 f4 5b 5e 5f c9 c3 89


My computer use to crash a short time after if I don't reboot...

ouch !

Thanks for your reply, or return receipt, good luck,

vala

romain

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

[davidge]

On Sun, 4 Mar 2001, Christian Hilgers wrote:

So you need to compile the kernel with UDF support , which is the
filesystem used in DVDs. As you said, iso9660 works, but only for the
first 650 mb. And after it take a look at www.linuxvideo.org and
www.videolan.org.

> Hi,
> 
> I'm trying to use the 2.4.1 Kernel but I have some troubles with my
> ATAPI Matsushita UJDA510 DVD (Intel 82371AB/EP PCI Bus Master IDE
> Controler).
> It works perfekt with CD-Rom but when I try to read a ISO 9660 DVD I got
> an error.
> 
> I can mount the DVD and I can list the complet content but I guess I
> can't access any File behind 650 MB.
> 
> e.g.
> 
> mount /cdrom
> $ cat /cdrom/blah/blah/INDEX
> cat: INDEX.german: Input/output error
> 
> The kernel log
> Mar  3 18:45:06 laptop kernel: VFS: Disk change detected on device
> ide1(22,0)
> Mar  3 18:45:10 laptop kernel: ISO 9660 Extensions: RRIP_1991A
> Mar  3 18:46:05 laptop kernel: attempt to access beyond end of device
> Mar  3 18:46:05 laptop kernel: 16:00: rw=0, want=2855480, limit=1052700
> 
> It also works well with a 2.2.14-SuSE Kernel.
> 
> Any hints.
> 
> Thanks
> Christian
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What happened ? (No such file or directory)

[Jeremy Jackson]

" Frédéric L. W. Meunier" wrote:

> Correction. I can umount the partitions, but I get the
> following message:
>
> "can't link lock file /etc/mtab~: No such file or
> directory (use -n flag to override)"
>
> And /etc/mtab isn't updated.

Is your root filesystem mounted read-only at any point?
(check with 'mount' look for ro in line for / filesystem)
Check permissions on /etc, /etc/mtab, /etc/mtab~


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 on the Unisys ES7000 and CMP2 machines?

[Miles Lane]

http://www.nytimes.com/cnet/CNET_0-1003-200-5007472.html 


Hi,

I noticed that this article mentions that Unisys has
no plans to port Linux to it's "cellular multiprocessor"
machines.  So, I am wondering if anyone is working
on this independantly.

These systems seems to be selling well with Microsoft's
Windoze 2000 Datacenter installed.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 on the Unisys ES7000 and CMP2 machines?

[David Weinehall]

On Sun, Mar 04, 2001 at 08:45:43AM -0800, Miles Lane wrote:
> http://www.nytimes.com/cnet/CNET_0-1003-200-5007472.html 
> 
> 
> Hi,
> 
> I noticed that this article mentions that Unisys has
> no plans to port Linux to it's "cellular multiprocessor"
> machines.  So, I am wondering if anyone is working
> on this independantly.
> 
> These systems seems to be selling well with Microsoft's
> Windoze 2000 Datacenter installed.

Well, I bet that someone on this list would be happy to do a port
if you just sponsor with one or two of these machines... :^)


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel error..

[Arthur Pedyczak]

My personal experience strongly suggests that the NVdriver is the
culprit.
Try geting rid of it.

Arthur


On Sun, 4 Mar 2001, Romain Chantereau wrote:

> Hi,
>
> I didn't know where send this bug report, so I send it here as writen in
> the Doc... Sorry if I mistake...
>
> Ok, I have a Debian sid (sic), on a AMD K6-2 300, on a Asus P5A, I have
> enabled AGP etc...
> Ah ! My graphic card is a Riva TNT, and I use it with the Nvidia driver
> 0.9.6..
>
> Ok, let's talk about the problem: That's it :
>
> (fidel is my computer name)
>
> fidel login: Unable to handle kernel paging request at virtual address
> 18297044
>  printing eip:
>  c6a9ed43
>  *pde = 
>  Oops: 0002
>  CPU:0
>  EIP:0010:[]
>  EFLAGS: 00013246
>  eax: 18297044   ebx: c58cfa1f   ecx:    edx: 0001
>  esi: c14b8220   edi:    ebp: c1643e18   esp: c1643e0c
>  ds: 0018   es: 0018   ss: 0018
>  Process X (pid: 658, stackpage=c1643000)
>  Stack: c14b83e0 cbb2f004 c1f96204 c1643e34 c6a9f0af cbb2f004 c14b8220
> c58cfa20
> c14b83e0 c58cf9f0 c1643e50 c6a9741a cbb2f004 c58cf9f0 c14b83e0
> 
>  c1643e74 c6a9c0df cbb2f004 c58cf9f0 0001 0101
> c14b83e0
> Call Trace: [] [] [] []
> [] [] []
>[] [] [] [] []
> [] [] []
>[] [] [] [] []
> [] [] []
>[]
>
> Code: 08 14 38 46 89 d8 4b 85 c0 75 e4 8d 65 f4 5b 5e 5f c9 c3 89
>
>
> My computer use to crash a short time after if I don't reboot...
>
> ouch !
>
> Thanks for your reply, or return receipt, good luck,
>
> vala
>
> romain
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/

[TINY patch] VM compromise?

[Mike Galbraith]

Hi Rik,

Thoughts on the below?

2.4.2.ac11-virgin
real9m50.322s
user7m7.810s
sys 0m36.020s

2.4.2.ac11+limit kswap expectations and scan slightly heavier
real8m23.122s
user7m8.860s
sys 0m33.960s

At no time do I see cache collapse as in earlier kernels, nor do I see
cache bloat as in virgin ac >= 3.  I think this is a good compromise
candidate.  This is almost as good as my best by fiddling with I/O..
[8m3s] _without_ fiddling with I/O, and it only changes 2 lines instead
of nuking a large chunk of your [damn difficult] balancing work :)

Why do I think it works?

1. kswapd attempting to fix everything in one run doesn't take
into account that tasks not only allocate, they also free.  If
we try to fix everything, we're usually assuring an overreaction.

2. scanning a little more agressively brings the cache shrinkage
to swap ratio to something more realistic for this work load..
and I strongly suspect many others as well.


--- linux-2.4.2.ac11/mm/vmscan.c.orgSun Mar  4 17:28:54 2001
+++ linux-2.4.2.ac11/mm/vmscan.cSun Mar  4 17:15:23 2001
@@ -847,7 +847,7 @@
  * continue with its real work sooner. It also helps balancing when we
  * have multiple processes in try_to_free_pages simultaneously.
  */
-#define DEF_PRIORITY (6)
+#define DEF_PRIORITY (4)
 static int refill_inactive(unsigned int gfp_mask, int user)
 {
int count, start_count, maxtry;
@@ -858,7 +858,7 @@
maxtry = 6;
} else {
/* kswapd */
-   count = inactive_shortage() + free_shortage();
+   count = (inactive_shortage() + free_shortage()) >> 2;
maxtry = 1 << DEF_PRIORITY;
}


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

Re: VM balancing problems under 2.4.2-ac1

[Ingo Oeser]

On Sat, Mar 03, 2001 at 01:03:26AM +0100, Adrian Bunk wrote:
> > If anybody as a good idea to make this code auto-balancing,
> > please let me know.
> 
> I have no idea for auto-balancing but another idea: It's one possibility
> to let the user choose when doing "make *config" what he wants:
> 
> - A VM optimized for servers that swaps out applications in favor of
>   caching.
> or
> - A VM optimized for workstations that won't swap out applications in
>   favor of caching.

I thought about the same thing sometimes (but for other troughput
vs. latency decisions, too).

But I realized, that my very own workstation is also a server,
since it runs an httpd, mysqld, smbd, ftpd etc.

And somtimes the servers become very busy in our LAN[1].

IF we want that tuning, we should have it as a sysctl. Most of it
is already possible with /proc/sys/vm/*, but balancing decisions
are still missing.

And even for servers we need to reduce caching sometimes. Think
of an httpd serving _very_ dynamic content. Or any other
application (e.g. DMBS), that doesn't rely on file system
caching.

A anonymous/file-backed[2] ratio would be VERY handy ;-)

But maybe this will be implemented one day along the lines of QoS
in the VM...

Regards

Ingo Oeser

[1] >1500 possible clients for these servers.
[2] Not counting swaps as file backed. We have a special inode
   for the swapper anyway, right?
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How can I get promise FastTrak 66 work in kernel?

[Thomas Lau]

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

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

[Jeff Garzik]

Thomas Lau wrote:
> 
> anyone have idea?
> I am helping my friend to ask this question, Thanks
> I mean kernel 2.4.1

Read Documentation/SubmittingDrivers

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

Re: IO issues vs. multiple busses

[Geert Uytterhoeven]

On Sat, 3 Mar 2001, Benjamin Herrenschmidt wrote:
> With those two simple functions, we could at least
> 
>  - Have vgacon disable itself when there's no ISA memory (that can be
^^
> handled by
>reserving the region and thus preventing request_region from working
  ^^
Do you mean request_mem_region()?

> too, well,
>but that scheme would also simplify the various more/less hacked
> macros used
>on all non-x86 archs to access the VGA memory).

request_mem_region() for ISA memory is another problem point. The few drivers
that use it seem to assume that the ISA memory base is 0. This won't work on
non-PC machines, since ISA memory may be somewhere else in the address space,
and more important, there already may be something different at address 0,
which breaks request_mem_region(). On a PC the first 16 MB of RAM (with some
holes at e.g. 0xa) overlap with ISA memory space, but not on other
architectures.

For ioremap() we have a hack on PPC (PReP/CHRP) that adds isa_mem_base if the
bus address to map falls in the first 16 MB area, but this cannot work for
request_mem_region(). I do have my full memory map (RAM) marked in /proc/iomem.

So once again I vote for the introduction of
isa_{request,release}_mem_region(), just like we already have isa_readb() and
friends.

Gr{oetje,eeting}s,

Geert

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

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

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

Re: DVD Problem

[Christian Hilgers]

Von: <[EMAIL PROTECTED]>
>

>On Sun, 4 Mar 2001, Christian Hilgers wrote:
>
>So you need to compile the kernel with UDF support , which is the
>filesystem used in DVDs. As you said, iso9660 works, but only for the
>first 650 mb. And after it take a look at www.linuxvideo.org and
>www.videolan.org.

UDF was the first I tried, but it didn't work.

Christian

>> Hi,
>>
>> I'm trying to use the 2.4.1 Kernel but I have some troubles with my
>> ATAPI Matsushita UJDA510 DVD (Intel 82371AB/EP PCI Bus Master IDE
>> Controler).
>> It works perfekt with CD-Rom but when I try to read a ISO 9660 DVD I
got
>> an error.
>>
>> I can mount the DVD and I can list the complet content but I guess I
>> can't access any File behind 650 MB.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [TINY patch] VM compromise?

[Rik van Riel]

On Sun, 4 Mar 2001, Mike Galbraith wrote:

> Why do I think it works?
> 
> 1. kswapd attempting to fix everything in one run doesn't take
> into account that tasks not only allocate, they also free.  If
> we try to fix everything, we're usually assuring an overreaction.
> 
> 2. scanning a little more agressively brings the cache shrinkage
> to swap ratio to something more realistic for this work load..
> and I strongly suspect many others as well.

Looking great.

Alan, could you please include this in the next -ac kernel ?

regards,

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

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

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

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

[Thomas Lau]

On Sunday 04 March 2001 18:08, you wrote:
> > anyone have idea?
>
> it does work.
>
> > I mean kernel 2.4.1
>
> why?  use a more recent one, like 2.4.2-ac11.
Hi, well
he is using RAID card !
his 2.2.x promise hacked modules work fine, but I didn't install that old 
modules, it's not support SCSI emulator

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

[Slightly OT] x86 PROM project

[Matthew Fredrickson]

What does everybody think of the idea of trying to write a RISC PROM-like
BIOS for the x86 architecture?

I've been tossing the idea around in my head for a while, and after I got
my first SGI I realized that something like this would be fairly useful.
Basically, I'm wondering if anybody is already doing something like this
(not linuxBIOS, though the code for that could be a useful base).  Thanks.


Matthew Fredrickson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Slightly OT] x86 PROM project

[Erik Mouw]

On Sun, Mar 04, 2001 at 12:29:47PM -0600, Matthew Fredrickson wrote:
> What does everybody think of the idea of trying to write a RISC PROM-like
> BIOS for the x86 architecture?
> 
> I've been tossing the idea around in my head for a while, and after I got
> my first SGI I realized that something like this would be fairly useful.
> Basically, I'm wondering if anybody is already doing something like this
> (not linuxBIOS, though the code for that could be a useful base).  Thanks.

Have a look at OpenBIOS:

  http://www.freiburg.linux.de/OpenBIOS/

The project wants to create an IEEE 1275-1994 compliant firmware, like
used by SUN (for example).


Erik
[who likes SUN firmware even more than SGI firmware]

-- 
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: [Slightly OT] x86 PROM project

[Matthew Jacob]

On Sun, 4 Mar 2001, Erik Mouw wrote:

> On Sun, Mar 04, 2001 at 12:29:47PM -0600, Matthew Fredrickson wrote:
> > What does everybody think of the idea of trying to write a RISC PROM-like
> > BIOS for the x86 architecture?
> > 
> > I've been tossing the idea around in my head for a while, and after I got
> > my first SGI I realized that something like this would be fairly useful.
> > Basically, I'm wondering if anybody is already doing something like this
> > (not linuxBIOS, though the code for that could be a useful base).  Thanks.
> 
> Have a look at OpenBIOS:
> 
>   http://www.freiburg.linux.de/OpenBIOS/
> 
> The project wants to create an IEEE 1275-1994 compliant firmware, like
> used by SUN (for example).
> 

and apple && ibm
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Slightly OT] x86 PROM project

[Thomas Lau]

On Sunday 04 March 2001 19:08, Erik Mouw wrote:
> On Sun, Mar 04, 2001 at 12:29:47PM -0600, Matthew Fredrickson wrote:
> > What does everybody think of the idea of trying to write a RISC PROM-like
> > BIOS for the x86 architecture?
> >
> > I've been tossing the idea around in my head for a while, and after I got
> > my first SGI I realized that something like this would be fairly useful.
> > Basically, I'm wondering if anybody is already doing something like this
> > (not linuxBIOS, though the code for that could be a useful base). 
> > Thanks.
>
> Have a look at OpenBIOS:
>
>   http://www.freiburg.linux.de/OpenBIOS/
>
> The project wants to create an IEEE 1275-1994 compliant firmware, like
> used by SUN (for example).
>
>
> Erik
> [who likes SUN firmware even more than SGI firmware]


How can I install openbios ?
also, can I use it in x86 PC?
and is it better than my award BIOS?
last question, is it support windows if I want to change to windows again? M$ 
one I mean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO issues vs. multiple busses

[Benjamin Herrenschmidt]

>So once again I vote for the introduction of
>isa_{request,release}_mem_region(), just like we already have isa_readb() and
>friends.

Well, it's the same problem as the IO, there may be more than one ISA mem
region,
especially when you put 2 video cards on 2 different PCI hosts (even without a
PCI-ISA bridge).

In fact, with a PCI-ISA bridge, I can imagine a config where you need 2 ISA IO
regions and 2 ISA mem regions on the same PCI bus if that bridge does address 
translation.

My concern for now is mostly to get video cards fixed, I don't care much about
legacy ISA hardware as in those case, I guess we can limit ourselves to a
single
ISA bus and inb/oub beeing happy to cope with it.

The problem is that we use the same macros (inb/outb) to access that ISA bus,
and to access any PCI IO bus. Well, I would suggest the following:

 - inb/outb without offset -> the ISA bus if any, or the IO space of the
   first PCI host
 - inb/outb with offset (or encoded HBA number) -> IO space of an other bus
 - pci_get_bus_io_base() returns the IO offset for accessing the Nth PCI
   bus IO space so that the fb devs can do VGA IOs on the bus that holds
   their card.
 - pci_get_bus_isa_mem_base() returns the base address at which isa mem
   is available for a given PCI bus (that is the address that generates
   mem cycles in the range 0->64k). This is a physical address, the driver
   still have to ioremap it. Some PCI cards can have a BAR mapping the
   VGA memory elsewhere, drivers for those cards should prefer the BAR
   mapping of course.

All IO ranges can be mapped via kernel VM tricks into a single contiguous
space
with the offset beeing something like a 64k increment, or we can have the
inb/outb
do a lookup of the host bus like on parisc. That's an arch implementation
detail.

Is that ok ? I know it's not perfect, but it would allow to solve the most
important problem for now. The PCI cards in need of IOs (like PCI IDE cards)
can have their resources fixed up by the arch code in order to tap the correct
bus. Only the real legacy ISA drivers will be limited to the fixed (default)
ISA bus.

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: [Slightly OT] x86 PROM project

[Matthew Fredrickson]

On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote:
> Have a look at OpenBIOS:
> 
>   http://www.freiburg.linux.de/OpenBIOS/
> 
> The project wants to create an IEEE 1275-1994 compliant firmware, like
> used by SUN (for example).

I don't want to appear to be offensive in regards to this project
considering I have no prior knowledge about it other than what I've seen
at the web site just now, but it appears that there is a lot more talk
than coding occuring at this project.  It just appears that everybody has
wants but nobody is turning the wants into realities.  Maybe I'm wrong
(and I hope I am), but it just seems to be a bit vaporous.

> [who likes SUN firmware even more than SGI firmware]
[I was just using SGI as an example]

Matthew Fredrickson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Slightly OT] x86 PROM project

[Michal Jaegermann]

On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote:
> On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote:
> > Have a look at OpenBIOS:
> > 
> >   http://www.freiburg.linux.de/OpenBIOS/
> > 
> > The project wants to create an IEEE 1275-1994 compliant firmware, like
> > used by SUN (for example).
> 
> I don't want to appear to be offensive in regards to this project
> considering I have no prior knowledge about it other than what I've seen
> at the web site just now, but it appears that there is a lot more talk
> than coding occuring at this project.

Ok, so what about this one?

http://www.acl.lanl.gov/linuxbios/

The code is on sourceforge.

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

Can Linux 2.4.x boot from UDMA-100 disk ?

[Yuval Krymolowski]

Hello,

 I have a system with ABIT BX-133/RAID mother-board, and run
 Gentus Linux booted from /dev/hde, which is UDMA/100 IBM-DTLA-307030 drive.
 The following lines of the boot-log can provide information about
 the system (kernel version 2.2.15-3.0).

 Would it be possible to boot kernel 2.4.x from the UDMA/100 drive ?
 in http://www.linux-ide.org/ultra100.html it is not mentioned if
 the patches can help with boot.

  Thanks,
 Yuval Krymolowski, [EMAIL PROTECTED]
 (I will check the list but please CC me as well).

 kernel: Uniform Multi-Platform E-IDE driver Revision: 6.30
 kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
 kernel: PIIX4: IDE controller on PCI bus 00 dev 39
 kernel: PIIX4: not 100% native mode: will probe irqs later
 kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
 kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
 kernel: HPT370: IDE controller on PCI bus 00 dev 98
 kernel: HPT370: not 100% native mode: will probe irqs later
 kernel: HPT370: reg5ah=0x01 ATA-66 Cable Port0
 kernel: ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:pio, hdf:pio
 kernel: HPT370: reg5ah=0x01 ATA-66 Cable Port0
 kernel: ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pio
 kernel: hda: FX4820T, ATAPI CDROM drive
 kernel: hdc: SAMSUNG COMBO SM-304B, ATAPI CDROM drive
 kernel: hde: IBM-DTLA-307030, ATA DISK drive
 kernel: hdg: WDC WD136AA, ATA DISK drive
 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
 kernel: ide1 at 0x170-0x177,0x376 on irq 15
 kernel: ide2 at 0xd800-0xd807,0xdc02 on irq 11
 kernel: ide3 at 0xe000-0xe007,0xe402 on irq 11 (shared with ide2)
 kernel: hde: IBM-DTLA-307030, 29314MB w/1916kB Cache, CHS=3737/255/63, UDMA(100)
 kernel: hdg: WDC WD136AA, 12971MB w/2048kB Cache, CHS=1653/255/63, UDMA(33)
 kernel: hda: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33)
 kernel: md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
 kernel: raid5: measuring checksumming speed
 kernel: raid5: MMX detected, trying high-speed MMX checksum routines
 kernel:pII_mmx   :  1777.746 MB/sec
 kernel:p5_mmx:  1836.039 MB/sec
 kernel:8regs :  1376.172 MB/sec
 kernel:32regs:   783.336 MB/sec
 kernel: using fastest function: p5_mmx (1836.039 MB/sec)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 on the Unisys ES7000 and CMP2 machines?

[J Sloan]

Miles Lane wrote:

> http://www.nytimes.com/cnet/CNET_0-1003-200-5007472.html
>
> Hi,
>
> I noticed that this article mentions that Unisys has
> no plans to port Linux to it's "cellular multiprocessor"
> machines.  So, I am wondering if anyone is working
> on this independantly.
>
> These systems seems to be selling well with Microsoft's
> Windoze 2000 Datacenter installed.

My take on it is that unisys is an example of brain damage
and it's easiest to ignore/work around them rather than
trying to get them out of bed with microsoft. Nature will
eventually take it's course with unisys as it did with Dec.

jjs

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

eject weirdness on NEC disc changer, kernel 2.4.2

[Jim Breton]

Hi all, I've gotten a response from the "eject" author and he seems to
agree that this is something in the kernel causing this issue.

Anyone got any ideas?  Thanks.

(P.S. I am not subscribed currently, please copy me on responses.
Gracias.)

- Forwarded message from Jim Breton -

From: Jim Breton
Date: Sat, 3 Mar 2001 21:34:47 +
Subject: eject weirdness on NEC disc changer, kernel 2.4.2

Package: eject
Version: 2.0.2-1
Severity: wishlist

Hi Jeff and Martin, I'm running a Debian 2.2r2 potato box which has an
ATAPI NEC cd changer:

$ grep NEC /var/log/dmesg 
hdd: NEC CD-ROM DRIVE:251, ATAPI CD/DVD-ROM drive

I have 4 audio CDs in the drive.  When I run the following command:

eject -c 1

it switches to slot 2 (as it should), but when I play a track off the
CD, it starts several seconds into the track rather than at the
beginning.

When I do the following:

eject -c 2
eject -c 3

I get the following in syslog:

Mar  3 16:11:30 tarkin kernel: VFS: Disk change detected on device
ide1(22,64)
Mar  3 16:11:51 tarkin kernel: hdd: irq timeout: status=0xd0 { Busy }
Mar  3 16:11:51 tarkin kernel: hdd: ATAPI reset complete

and the drive switches me back to the first slot.

If I have a data CD in a slot, I do not see this problem.

Any idea what is going on?  I tried a copy compiled straight from the
source and the same thing happens.  Considering data CDs do not make
this happen, do you think the kernel is doing something odd?  Should the
kernel really care what kind of CD is in the drive before I try to read
it?  Or is this something caused by eject?

Thanks.

P.S. I just tried cdctl ( http://sourceforge.net/projects/cdctl/ ) and
apparently the same thing occurs, so it's looking like this may be a
kernel issue.  My former kernel was 2.2.19pre9 and I didn't have any
problems there (or on any of my other 2.2.x kernels).

- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO issues vs. multiple busses

[Geert Uytterhoeven]

On Sat, 3 Mar 2001, Grant Grundler wrote:
> Benjamin Herrenschmidt wrote:
> > Additionally, the same problem is true for ISA memory, when it exist
> > obviously.
> 
> Really? I expected ISA memory to look like reguler uncacheable memory
> and the drivers would simply dereference the address. But I'm not an
> expert on how ISA busses work...

Nope, it's like PCI memory, but different. You have to use isa_readb() and
friends to access it.

While ISA I/O space and PCI I/O space are the same on many machines with memory
mapped I/O (with a size limitation for ISA I/O), ISA memory space and PCI
memory space are different. Cfr. on my CHRP LongTrail:

| callisto$ cat /proc/iomem 
| -0800 : RAM
| c000-f6ff : GG2 PCI mem
|   c000-cfff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
|   c100-c107 : Apple Computer Inc. Hydra Mac I/O
|   c108-c108007f : Digital Equipment Corporation DECchip 21041 [Tulip Pass 3]
| c108-c108007f : eth0
|   c200-c2ff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
| c200-c2ff : atyfb
|   c300-c3ff : Symbios Logic Inc. (formerly NCR) 53c875
|   c3001000-c3001fff : Symbios Logic Inc. (formerly NCR) 53c875
|   c400-c7ff : S3 Inc. 86c764/765 [Trio32/64/64V+]
| f700-f7ff : GG2 ISA mem
|   f70e-f70e7fff : NVRAM
| f800-f8ff : GG2 PCI I/O
| fec0-fec7 : GG2 PCI cfg
| ff00-ff7f : ROM exp
| fff8- : Flash ROM
| callisto$ 

Gr{oetje,eeting}s,

Geert

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

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

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

Re: scsi vs ide performance on fsync's

[Douglas Gilbert]

There is definitely something strange going on here.
As the bonnie test below shows, the SCSI disk used
for my tests should vastly outperform the old IDE one:

  ---Sequential Output ---Sequential Input-- --Random--
Seagate   -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
ST318451LW MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
SCSI  200 21544 96.8 51367 51.4 11141 16.3 17729 58.2 40968 40.4 602.9  5.4

Quantum   ---Sequential Output ---Sequential Input-- --Random--
Fireball  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
ST3.2A MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
IDE   200  3884 72.8  4513 86.0  1781 36.4  3144 89.9  4052 95.3 131.5  0.9

I used a program based on Mike Black's "Blah Blah" test
(shown below) in which 200 write()+fdatasync()s are 
performed. Each write() outputs either 20 or 4096 bytes.

On my Celeron 533 Mhz 128 MB ram hardware with an ext2 fs,
the "block" size that is seen by the sd driver for each 
fdatasync() is 4096 bytes. lk 2.4.2 is being used. The 
fs/buffer.c __wait_on_buffer() routine waits for IO 
completion in response to fdatasync(). Timings have been 
done with Andrew Morton's timepegs (units are microseconds). 
Here are the IDE results:

IDE 20*200 Destination  Count   Min   Max   Average   Total
enter __wait_on_buffer:0 ->
  leave __wait_on_buffer:0  2001,037.23  6,487.72  1,252.19  250,439.80
leave __wait_on_buffer:0 ->
  enter __wait_on_buffer:0  1997.32 21.05  7.821,557.05

IDE 4096*200   Destination  Count   Min   Max   Average   Total
enter __wait_on_buffer:0 ->
  leave __wait_on_buffer:0  2001,037.06  7,354.21  1,243.78  248,756.64
leave __wait_on_buffer:0 ->
  enter __wait_on_buffer:0  199   23.01 67.32 37.037,370.51


So the size of each transfer doesn't matter to this IDE
disk. Now the same test for the SCSI disk:

SCSI(20*200)   Destination  Count Min   Max   Average   Total
enter __wait_on_buffer:0 ->
   enter sd_init_command:0  200  1.86 13.27  2.05  411.48
enter sd_init_command:0 ->
   enter rw_intr:0  200320.87  5,398.56  3,417.30  683,461.25
enter rw_intr:0 ->
  leave __wait_on_buffer:0  200  4.04 15.81  4.42  885.73
leave __wait_on_buffer:0 ->
  enter __wait_on_buffer:0  199  8.78 14.39  9.261,844.23

SCSI(4096*200) Destination  Count MinMax   Average   Total
enter __wait_on_buffer:0 ->
   enter sd_init_command:0  200  1.97  13.20  2.21  443.52
enter sd_init_command:0 ->
   enter rw_intr:0  200109.53  13,997.50  1,327.47  265,495.87
enter rw_intr:0 ->
  leave __wait_on_buffer:0  200  4.37  22.50  4.75  951.44
leave __wait_on_buffer:0 ->
  enter __wait_on_buffer:0  199 22.40  42.20 24.274,831.34

The extra timepegs inside the SCSI subsystem show that 
the IO transaction to that disk really did take that 
long. [Initially I suspected a "plugging" type
elevator bug, but that isn't supported by the above
and various other timepegs not shown.]
Since there is a wait on completion for every write,
tagged queuing should not be involved.

So writing more data to the SCSI disk speeds it up!
I suspect the critical point in the "20*200" test is
that the same sequence of 8 512 byte sectors are being 
written to disk 200 times. BTW That disk spins at
15K rpm so one rotation takes 4 ms and it has a
4 MB cache.

Even though the SCSI disk's "cache" mode page indicates
that the write cache is on, it would seem that writing 
the same sectors continually causes flushes to the medium 
(and hence the associated delay). Here is scu's output 
of the "cache" mode page:

$ scu -f /dev/sda show page cache
Cache Control Parameters (Page 0x8 - Current Values):

Mode Parameter Header:

  Mode Data Length: 31
   Medium Type: 0 (Default Medium Type)
 Device Specific Parameter: 0x10 (Supports DPO & FUA bits)
   Block Descriptor Length: 8

Mode Parameter Block Descriptor:

  Density Code: 0x2
  Number of Logical Blocks: 2289239 (1117.792 megabytes)
  Logical Block Length: 512

Page Header / Data:
 Page Code: 0x8
Parameters Savable: Yes
   Page Length: 18
  Read Cache Disable (RCD): No
Multiplication Factor (MF): Off
  Write Cache Enable (WCE): Yes
  Cache Segment Size Enable (SIZE): Off
  Discontinuity (DISC): On
  Caching Analysis Permitted (CAP): Disabled
Abort Pre-Fetch (ABPF): Off
 Initiator Control Enable (IC): Off
  Write Retention Priority: 0 (Not distiguished)
Demand Read Retention Priority: 0 (Not distiguished)
  Disable 

Re: Question about IRQ_PENDING/IRQ_REPLAY

[Benjamin Herrenschmidt]

>We do have broken interrupt controllers in this respect.  We already have a
>way of handling it.  Ben, take a look at set_lost().

Heh, I know, thanks ;)

However, our current scheme implies a hack to __sti() that I'd like to get
rid of since it adds an overhead allover the place that could probably be
localized if we managed to force an interrupt (using the DEC for example,
or using a mac-specific device as this controller only exist on macs anyway).

Also, we currently don't use the same mecanism as i386, and since Linus
expressed his desire to have irq.c become generic, I'm trying to make sure
I fully understand it before merging in PPC the bits that I didn't merge
them yet.

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: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)

[Ton Hospel]

Notice also that by default ssh opens stdin/stdout blocking, and can
relatively easily deadlock if the pipes it talks over really want to do
a write before a read or the other way round. 

You can try compile the following file, put it in the same directory
as ssh, and then run rsync over this instead of plain ssh (I use it in
fact in all places where I connect to ssh over pipes).

#include 
#include 
#include 
#include 
#ifndef HAVE_NO_UNISTD_H
# include 
#endif /* HAVE_NO_UNISTD_H */
#include 

static char ssh[] = "ssh";

int unblock(FILE *fp) {
int fd, rc, flags;

fd = fileno(fp);
if (isatty(fd)) return 0;

flags = fcntl(fd, F_GETFL, 0);
if (flags < 0) {
fprintf(stderr, "Could not query fd %d: %s\n", fd, strerror(errno));
return 1;
}
rc = fcntl(fd, F_SETFL, flags | O_NONBLOCK);
if (rc < 0) {
fprintf(stderr, "Could not unblock fd %d: %s\n", fd, strerror(errno));
return 1;
}
return 0;
}

int main(int argc, char **argv) {
int rc;
char *ptr, *work;

if (unblock(stdin))  return 1;
if (unblock(stdout)) return 1;
if (unblock(stderr)) return 1;

ptr = strrchr(argv[0], '/');
if (ptr == NULL) ptr = argv[0];
else ptr++;
work = malloc(ptr-argv[0]+sizeof(ssh));
if (!work) {
fprintf(stderr, "Out of memory. Buy more ?\n");
return 1;
}
memcpy(work, argv[0], ptr-argv[0]);
memcpy(work+(ptr-argv[0]), ssh, sizeof(ssh));
argv[0] = work;
rc = execvp(work, argv);
fprintf(stderr, "Could not exec %.300s: %s\n", work, strerror(errno));
return rc;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LILO error with 2.4.3-pre1...

[Mircea Damian]

On Sun, Mar 04, 2001 at 12:39:32PM +1100, Keith Owens wrote:
> On Sat, 03 Mar 2001 19:19:28 -0600, 
> "Steven J. Hill" <[EMAIL PROTECTED]> wrote:
> >I have no idea why the 1023 limit is coming up considering 2.4.2 and
> >LILO were working just fine together and I have a newer BIOS that has
> >not problems detecting the driver properly. Go ahead, call me idiot :).
> 
> OK, you're an idiot :).  It only worked before because all the files
> that lilo used just happened to be below cylinder 1024.  Your partition
> goes past cyl 1024 and your new kernel is using space above 1024.  Find
> a version of lilo that can cope with cyl >= 1024 (is there one?) or
> move the kernel below cyl 1024.  You might need to repartition your
> disk to get / all below 1024.

Call me idiot too but please explain what is wrong here:

# cat /etc/lilo.conf
boot = /dev/hda
timeout = 150
vga = 4
ramdisk = 0
lba32
append = "hdc=scsi"
prompt


image = /boot/vmlinuz-2.4.2
  root = /dev/hda2
  read-only
  label = Linux

other = /dev/hda3
  label = win
  table = /dev/hda

# fdisk -l /dev/hda

Disk /dev/hda: 255 heads, 63 sectors, 1650 cylinders
Units = cylinders of 16065 * 512 bytes

   Device BootStart   EndBlocks   Id  System
/dev/hda1 117136521   82  Linux swap
/dev/hda218  1165   9221310   83  Linux
/dev/hda3   *  1166  1650   3895762+   c  Win95 FAT32 (LBA)
root@taz:~# lilo -v
LILO version 21.7, Copyright (C) 1992-1998 Werner Almesberger
Linux Real Mode Interface library Copyright (C) 1998 Josh Vanderhoof
Development beyond version 21 Copyright (C) 1999-2001 John Coffman
Released 24-Feb-2001 and compiled at 18:31:02 on Mar  3 2001.

Reading boot sector from /dev/hda
Merging with /boot/boot.b
Boot image: /boot/vmlinuz-2.4.2
Added Linux *
Boot other: /dev/hda3, on /dev/hda, loader /boot/chain.b
Device 0x0300: Invalid partition table, 3rd entry
  3D address: 63/254/141 (2281229)
  Linear address: 1/0/1165 (18715725)


Mar  2 20:26:29 taz kernel: hda: IBM-DJNA-371350, ATA DISK drive 
Mar  2 20:26:29 taz kernel: hda: 26520480 sectors (13578 MB) w/1966KiB Cache, 
CHS=1650/255/63 


Is anybody able to explain the error?
That partition contains a valid VFAT partition with win98se installed on it (and it 
works fine,
ofc if I remove lilo from MBR).

-- 
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] tiny MM performance and typo patches for 2.4.2

[Ulrich Kunitz]

Hi folks,

this is a list of patches I collected while looking at the memory
management sources. Two patches might improve the performance of your
box. The others are more or less cosmetic. 

This mail is sent with a kernel using these patches.
Here is a list sorted with decreasing importance:

patch-uk2   makes use of the pgd, pmd and pte quicklists for x86 too;
risky: there might be a reason that 2.4.x doesn't use the
quicklists.

patch-uk6   In 2.4.x _page_hashfn divides struct address_space pointer
with a parameter derived from the size of struct
inode. Deriving this parameter from the size of struct
address_space makes more sense -- at least for me.

patch-uk5   cleans the bd_flush_param union.

patch-uk1   fixes a comment typo in asm-i386/highmem.h.

patch-uk3   fixes a comment typo in asm-i386/pgtable-3level.h.

Ciao,

Uli Kunitz

-- 
Ulrich Kunitz ([EMAIL PROTECTED])


--- linux-2.4.2/include/asm-i386/pgalloc.h  Thu Feb 22 01:09:57 2001
+++ linux/include/asm-i386/pgalloc.hSun Mar  4 20:14:50 2001
@@ -92,9 +92,9 @@
free_page((unsigned long)pte);
 }
 
-#define pte_free_kernel(pte)free_pte_slow(pte)
-#define pte_free(pte) free_pte_slow(pte)
-#define pgd_free(pgd) free_pgd_slow(pgd)
+#define pte_free_kernel(pte)free_pte_fast(pte)
+#define pte_free(pte) free_pte_fast(pte)
+#define pgd_free(pgd) free_pgd_fast(pgd)
 #define pgd_alloc() get_pgd_fast()
 
 extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
@@ -145,7 +145,7 @@
  * inside the pgd, so has no extra memory associated with it.
  * (In the PAE case we free the page.)
  */
-#define pmd_free(pmd) free_pmd_slow(pmd)
+#define pmd_free(pmd) free_pmd_fast(pmd)
 
 #define pmd_free_kernelpmd_free
 #define pmd_alloc_kernel   pmd_alloc


--- linux-2.4.2/include/linux/pagemap.h Thu Feb 22 01:10:01 2001
+++ linux/include/linux/pagemap.h   Sun Mar  4 20:14:50 2001
@@ -58,7 +58,8 @@
  */
 extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned 
long index)
 {
-#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode) 
- 1)))
+#define i (((unsigned long) mapping) / \
+   (sizeof(struct address_space) & ~ (sizeof(struct address_space) - 1)))
 #define s(x) ((x)+((x)>>PAGE_HASH_BITS))
return s(i+index) & (PAGE_HASH_SIZE-1);
 #undef i


--- linux-2.4.2/fs/buffer.c Fri Feb  9 20:29:44 2001
+++ linux/fs/buffer.c   Sun Mar  4 19:27:31 2001
@@ -112,19 +112,18 @@
  */
 union bdflush_param {
struct {
-   int nfract;  /* Percentage of buffer cache dirty to 
-   activate bdflush */
-   int ndirty;  /* Maximum number of dirty blocks to write out per
+   int nfract;   /* Percentage of buffer cache dirty to 
+activate bdflush */
+   int ndirty;   /* Maximum number of dirty blocks to write out per
wake-cycle */
-   int nrefill; /* Number of clean buffers to try to obtain
-   each time we call refill */
int dummy1;   /* unused */
+   int dummy2;   /* unused */
int interval; /* jiffies delay between kupdate flushes */
int age_buffer;  /* Time for normal buffer to age before we flush it */
int nfract_sync; /* Percentage of buffer cache dirty to 
activate bdflush synchronously */
-   int dummy2;/* unused */
-   int dummy3;/* unused */
+   int dummy3;   /* unused */
+   int dummy4;   /* unused */
} b_un;
unsigned int data[N_PARAM];
 } bdf_prm = {{30, 64, 64, 256, 5*HZ, 30*HZ, 60, 0, 0}};


--- linux-2.4.2/include/asm-i386/highmem.h  Thu Feb 22 01:09:58 2001
+++ linux/include/asm-i386/highmem.hSun Mar  4 20:14:50 2001
@@ -9,7 +9,7 @@
  *
  *
  * Redesigned the x86 32-bit VM architecture to deal with 
- * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * up to 16 Terabyte physical memory. With current x86 CPUs
  * we now support up to 64 Gigabytes physical RAM.
  *
  * Copyright (C) 1999 Ingo Molnar <[EMAIL PROTECTED]>


--- linux-2.4.2/include/asm-i386/pgtable-3level.h   Wed Oct 18 23:25:46 2000
+++ linux/include/asm-i386/pgtable-3level.h Sun Mar  4 19:25:00 2001
@@ -48,7 +48,7 @@
 /* Rules for using set_pte: the pte being assigned *must* be
  * either not present or in a state where the hardware will
  * not attempt to update the pte.  In places where this is
- * not possible, use pte_get_and_clear to obtain the old pte
+ * not possible, use ptep_get_and_clear to obtain the old pte
  * value and then use set_pte to update it.  -ben
  */
 static inline void set_pte(pte_t *ptep, pte_t pte)

Re: [PATCH] tiny MM performance and typo patches for 2.4.2

[David S. Miller]

Ulrich Kunitz writes:
 > patch-uk6In 2.4.x _page_hashfn divides struct address_space pointer
 >  with a parameter derived from the size of struct
 >  inode. Deriving this parameter from the size of struct
 >  address_space makes more sense -- at least for me.

The address_space is %99 of the time (unless swapping, and in that
case the address is constant :-)) inside of an inode struct so this
change actually makes the hash worse.  I looked at this one time
myself...

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

kmalloc() alignment

[Kenn Humborg]

Does kmalloc() make any guarantees of the alignment of allocated
blocks?  Will the returned block always be 4-, 8- or 16-byte
aligned, for example?

Later,
Kenn

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

[CaT]

On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout 
>with(0x70)!
> 
> Please try the attached patch.
> Actually, it's designed to solve another problem, but may be your one has the
> same origin as that other.

> Index: eepro100.c

Patch appears to have worked. After 2 weeks of actually using the right
module (*sheepish grin*) I've not had the card popup the above error
message. woo.

So thanks for that. :) Majorly happy about things now. :)

And now... to put ext3 on my laptop.

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

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

[Alan Cox]

> Does kmalloc() make any guarantees of the alignment of allocated
> blocks?  Will the returned block always be 4-, 8- or 16-byte
> aligned, for example?

There are people who assume 16byte alignment guarantees. I dont think anyone
has formally specified the guarantee beyond 4 bytes tho
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kmalloc() alignment

[Manfred Spraul]

>
> Does kmalloc() make any guarantees of the alignment of allocated 
> blocks? Will the returned block always be 4-, 8- or 16-byte 
> aligned, for example? 
>

4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on
64-bit cpus.

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

Re: [Slightly OT] x86 PROM project

[Rick Hohensee]

>
>What does everybody think of the idea of trying to write a RISC PROM-like
>BIOS for the x86 architecture?
>
>I've been tossing the idea around in my head for a while, and after I got
>my first SGI I realized that something like this would be fairly useful.
>Basically, I'm wondering if anybody is already doing something like this
>(not linuxBIOS, though the code for that could be a useful
>base).  Thanks.

Where this is on topic is in comp.lang.forth, since Open Firmware is a
Forth. One of the c.l.f elders recently said he was going to wander off
for a while and come back with what he could find out about this. I've
copied a post or two on this subject to c.l.f since then. 

Related stuff; the FreeBSD bootloader is a Forth based on FICL, which is a
Forth geared to be embedded in apps. In the hour or two I looked at that I
couldn't get my bearings in the FBSD sources. I believe Open Firmware is
bytecodes, and O.F. cards have actual drivers on them an O.F. host can
request and thread into the O.F. dictionary (compile, in other words.)
Most Forths are not bytecodes. Most Forths are address-threaded, or
subroutine threaded, i.e. native code but implementing a true 2-stack
virtual machine, or true 2-stack silicon. This is quite unlike Java, for
example, which has Forth-like stack operators that are
returnstack-frame-scoped, i.e. aren't an autonomous second stack.

Rick Hohensee
www.clienux.com


My 3-stack machine and other oddities are in 
ftp://ftp.gwdg.de/pub/linux/install/clienux/interim


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

sundance driver problem detecting DFE-550 card

[Georg Wittenburg]

Greetings.

I contacted Donald Becker (mainainer of sundance driver according to the 
comments) about this issue who told me that he wasn't in charge of the 2.4 
driver anymore and suggested to ask on the list.

My vanilla Linux 2.4.2 system has some trouble using the D-Link DFE-550TX
network adapter with the sundance driver that should support that card
according to the docs .

Until now I've used the dlh5x driver right from the D-Link homepage, but that
doesn't compile with Linux 2.4 and seems to be rather unsupported.

The symptoms are: sundance.c compiles to a module and is loaded over the
normal init scripts without problems. However asking for a "ping 192.168.1.1"
(our local server) doesn't yield anything (switching back to the old 2.2.17
kernel and dlh5x works). Furthermore, the ifconfig statistics remain empty
and also ifconfig reports a different base address than when using the old 
dlh5x driver. Also note the different memory addresses reported in /proc/pci.

I've gathered the following info which I hope will help track down the
problem:

ifconfig under 2.4.2 and sundance:

eth0  Link encap:Ethernet  HWaddr 00:50:BA:0F:5E:DD
  inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  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:100
  Interrupt:5 Base address:0xf000

/proc/pci under 2.4.2 and sundance:

  Bus  0, device  10, function  0:
Ethernet controller: PCI device 1186:1002 (D-Link System Inc) (rev 0).
  IRQ 5.
  Master Capable.  Latency=32.  Min Gnt=10.Max Lat=10.
  I/O at 0xa400 [0xa47f].
  Non-prefetchable 32 bit memory at 0xd480 [0xd480007f].

ifconfig under 2.2.17 and dlh5x:

eth0  Link encap:Ethernet  HWaddr 00:50:BA:0F:5E:DD
  inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:737286 errors:2868 dropped:2868 overruns:0 frame:0
  TX packets:118998 errors:2880 dropped:0 overruns:0 carrier:1968
  collisions:5760 txqueuelen:100
  Interrupt:5 Base address:0x6000

/proc/pci under 2.2.17and dlh5x:

  Bus  0, device  10, function  0:
Ethernet controller: Unknown vendor Unknown device (rev 0).
  Vendor id=1186. Device id=1002.
  Medium devsel.  IRQ 5.  Master Capable.  Latency=32.  Min Gnt=10.Max
Lat=10.
  I/O at 0xa400 [0xa401].
  Non-prefetchable 32 bit memory at 0xd480 [0xd480].

More (lengthy) output of Donald Becker's debugging tool (alta-diag) is 
available.

I'm not subscribed to the list, so please send me a CC. Thanks for your help.

Yours,
Georg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LILO error with 2.4.3-pre1...

[Guest section DW]

On Sun, Mar 04, 2001 at 11:32:44PM +0200, Mircea Damian wrote:

> Call me idiot too but please explain what is wrong here:

What is wrong is that this is the kernel list, not the LILO list.

> root@taz:~# lilo -v
> LILO version 21.7, Copyright (C) 1992-1998 Werner Almesberger
> Device 0x0300: Invalid partition table, 3rd entry
>   3D address: 63/254/141 (2281229)
>   Linear address: 1/0/1165 (18715725)

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

Re: scsi vs ide performance on fsync's

[Ishikawa]

Douglas Gilbert wrote:

> There is definitely something strange going on here.
> As the bonnie test below shows, the SCSI disk used
> for my tests should vastly outperform the old IDE one:

First thank you and others with my clueless investigation about
the module loading under Debian GNU/Linux. (I should have known
that Debian uses a very special module setup.)

Anyway, I used to think SCSI is better than IDE in general, and
the post was quite surprising.
So I ran the test on my PC.
On my systems too, the IDE beats SCSI hand down with the test case.

BTW, has anyone noticed that
the elapsed time of SCSI case is TWICE as long if
we let the previous output of the test program stay before
running the second test? (I suspect fdatasync
takes time proportional to the (then current)  file size, but
still why SCSI case is so long is beyond me.)

Eg.

ishikawa@duron$ ls -l /tmp/t.out
ls: /tmp/t.out: No such file or directory
ishikawa@duron$ time ./xlog /tmp/t.out fsync

real0m38.673s<=== my scsi disk is slow one to begin with...
user0m0.050s
sys 0m0.140s
ishikawa@duron$ ls -l /tmp/t.out
-rw-r--r--1 ishikawa users  112000 Mar  5 06:19 /tmp/t.out
ishikawa@duron$ time ./xlog /tmp/t.out fsync

real1m16.928s<=== See TWICE as long!
user0m0.060s
sys 0m0.160s
ishikawa@duron$ ls -l /tmp/t.out
-rw-r--r--1 ishikawa users  112000 Mar  5 06:20 /tmp/t.out
ishikawa@duron$ rm /tmp/t.out< REMOVE the file and try again.
ishikawa@duron$ time ./xlog /tmp/t.out fsync

real0m40.667s   < Half as long and back to original.
user0m0.040s
sys 0m0.120s
iishikawa@duron$ time ./xlog /tmp/t.out xxx

real0m0.012s  <=== very fast without fdatasync as it should be.
user0m0.010s
sys 0m0.010s
ishikawa@duron$


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

[CFT] maestro update vs 2.2.18

[Zach Brown]

I finally spent some time fixing up the maestro driver.  lots of
feature additions had backed up, and the source was rotting.  Its still
gross, but at least its cleaned up a bit.  "It works for me" on my
pentium with an ESS maestro2 engineering board, but laptops will be
another story entirely.  I'd love it if people could apply this patch to
vanilla 2.2.18 and let me know how it goes.  

The patch does a few things.  Most interestingly for the user, it moves
away from the model of having multiple /dev/dsp? files and instead allows
/dev/dsp to be opened concurrently.  It also adds some support for the
hardware volume buttons on laptops, but not all vendors wire this the same
way.  As I don't have a maestro-bearing laptop, this is totally untested.

The code is butchered, so the diff is almost illegible.  Perhaps I'll
learn and do things in stages next time, but I was on a roll :)  One
of the more notable changes involves using the kernel's ac97_codec
code rather than its own.  Hopefully this will result in better mixer
behaviour.

I'm particularly interested in hearing how suspend/resume functions,
whether or not the multi-open stuff works, and I'd like to get subvendor
IDs from people whose laptop's hardware volume buttons work.  See the
Documentation/sound/Maestro text for instructions on enabling multi-open
(channels=2 or 4) and hardware volume support (hw_vol=1).

Its an awfully large diff, so it can be fetched from:

http://www.zabbo.net/maestro/patches/2.2.18-mega-1.diff.gz

if this works I'll officially submit it and make the same sorts of
changes to 2.4.  

-- 
 zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 on the Unisys ES7000 and CMP2 machines?

[Gerhard Mack]

On Sun, 4 Mar 2001, J Sloan wrote:

> Miles Lane wrote:
> 
> > http://www.nytimes.com/cnet/CNET_0-1003-200-5007472.html
> >
> > Hi,
> >
> > I noticed that this article mentions that Unisys has
> > no plans to port Linux to it's "cellular multiprocessor"
> > machines.  So, I am wondering if anyone is working
> > on this independantly.
> >
> > These systems seems to be selling well with Microsoft's
> > Windoze 2000 Datacenter installed.
> 
> My take on it is that unisys is an example of brain damage
> and it's easiest to ignore/work around them rather than
> trying to get them out of bed with microsoft. Nature will
> eventually take it's course with unisys as it did with Dec.
>
 
Given Unisys' reputation you would think compaq and HP would leave
them alone to avoid being dirtied.

I think after the gif fiasco most people on the net hate that company.

Gerhard
 

 
--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-pre1 mkdep and symlinked $TOPDIR

[Keith Owens]

On Sun, 04 Mar 2001 16:24:57 +1100, 
Andrew Morton <[EMAIL PROTECTED]> wrote:
>I do builds in /usr/src/linux, which is a symlink
>to /usr/src/linux-akpm.  The recent `mkdep' changes
>have broken this practice most horridly.  When searching
>.hdepend, `make' doesn't recognise that nested headers
>have changed. This is because .hdepend has things like
>
>/usr/src/linux/include/asm/byteorder.h: \
>   /usr/src/linux-akpm/include/asm/types.h \

I do not see this problem in 2.4.3-pre2.

# ls -l linux 
lrwxrwxrwx   1 kaos ocs10 Mar  5 10:47 linux -> 2.4.3-pre2
# cd linux
# make dep
make dep
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c
make[1]: Entering directory `/usr/src/2.4.3-pre2/arch/i386/boot'
make[1]: Nothing to be done for `dep'.
make[1]: Leaving directory `/usr/src/2.4.3-pre2/arch/i386/boot'
scripts/mkdep -- init/*.c > .depend
scripts/mkdep -- `find /usr/src/2.4.3-pre2/include/asm 
/usr/src/2.4.3-pre2/include/linux /usr/src/2.4.3-pre2/include/scsi 
/usr/src/2.4.3-pre2/include/net -name SCCS -prune -o -follow -name \*.h ! -name 
modversions.h -print` > .hdepend

The find command is given the real pathname, not the symlink so the
.hdepend and .depend files all contain the real paths.  Your problem is
probably this line in the top level Makefile.

TOPDIR  := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi)

TOPDIR must be getting set to the symlink name instead of the real
pathname.  Can you confirm what TOPDIR is being set to and why?  This
may be a shell problem.

TOPDIR  := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi)
dummy   := $(shell echo PWD="$$PWD" pwd=$(shell pwd) TOPDIR=$(TOPDIR) >&2)

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

Re: kernel lock contention and scalability

[Anton Blanchard]

 
Hi,

> To discover possible locking limitations to scalability, I have collected 
> locking statistics on a 2-way, 4-way, and 8-way performing as networked
> database servers.  I patched the [48]-way kernels with Kravetz's multiqueue 
> patch in the hope that mitigating runqueue_lock contention might better 
> reveal other lock contention.

...

>   24.38%  23.93%15us(   218us)   4.3us(   111us) 744475 566289 
>178186  0  runqueue_lock
>   23.15%  38.78%28us(   218us)   6.2us(   108us) 376292 230381 
>145911  0schedule+0xe0

Tridge and I tried out the postgresql benchmark you used here and this
contention is due to a bug in postgres. From a quick strace, we found
the threads do a load of select(0, NULL, NULL, NULL, {0,0}). Basically all
threads are pounding on schedule().

Our guess is that the app has some form of userspace synchronisation
(semaphores/spinlocks). I'd argue that the app needs to be fixed not the
kernel, or a more valid test case is put forwards. :)

PS: I just looked at the postgresql source and the spinlocks (s_lock() etc)
are in a tight loop doing select(0, NULL, NULL, NULL, {0,0}). In samba
we have userspace spinlocks, but they cover small amounts of code and
offer an advantage over ipc semaphores. When you have to synchronise
large sections of code ipc semaphores are reasonably fast on linux and
would be a better fit.

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

IDE trouble under 2.2.19pre16 with Hedrick's IDE patch

[Shane Wegner]

Hi,

Whenever I write a substantial amount of data (200mb) to
disk, I get these messages.  The disks lock for about 10
seconds and then come back for about 10 seconds again. 
This continues until the data is successfully written.

ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: DMA disabled
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }

Does anyone happen to know what I can do to fix this?  It
happens on Linux 2.4.2 as well.  It's an HPT370 controler
on-board.  Here is the relevant information.

HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA,
hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA,
hdh:pio
hde: Maxtor 92720U8, ATA DISK drive
hdg: Maxtor 96147U8, ATA DISK drive
ide2 at 0xdc00-0xdc07,0xe002 on irq 10
ide3 at 0xe400-0xe407,0xe802 on irq 10
hde: Maxtor 92720U8, 25965MB w/2048kB Cache,
CHS=52755/16/63, UDMA(66)
hdg: Maxtor 96147U8, 58623MB w/2048kB Cache,
CHS=119108/16/63, UDMA(66)


continuum:~# cat /proc/ide/hpt366

HPT370 Chipset.
--- Primary Channel  Secondary
Channel -
 enabled  enabled
--- drive0 - drive1  drive0
-- drive1 --
DMA enabled:yes  no  yes
no
UDMA
DMA
PIO
continuum:~# cat /proc/ide/hde/settings
namevalue   min max
mode
-   --- ---

bios_cyl52755   0
65535   rw
bios_head   16  0   255
rw
bios_sect   63  0   63
rw
breada_readahead4   0   127
rw
bswap   0   0   1
r
current_speed   68  0   69
rw
file_readahead  124 0
2097151 rw
ide_scsi0   0   1
rw
init_speed  68  0   69
rw
io_32bit1   0   3
rw
keepsettings1   0   1
rw
lun 0   0   7
rw
max_kb_per_request  64  1   127
rw
multcount   8   0   8
rw
nice1   1   0   1
rw
nowerr  0   0   1
rw
number  0   0   3
rw
pio_modewrite-only  0   255
w
slow0   0   1
rw
unmaskirq   1   0   1
rw
using_dma   1   0   1
rw

-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-kernel 2.4.3-pre1

[TimO]

Alexander Viro wrote:
> 
> On Fri, 2 Mar 2001, TimO wrote:
> 
> > eax:   ebx:   ecx:   edx: 
> [snip]
> > >>EIP; c0142a52<=
> > Trace; c0142ca6 
> > Trace; c0145f01 
> > Trace; c014601a 
> > Trace; c01349a4 
> > Trace; c0134f7a 
> > Trace; c0107007 
> > Trace; c01074b8 
> > Code;  c0142a52 
> >  <_EIP>:
> > Code;  c0142a52<=
> [snip]
> 
> Lovely. sb->s_op == NULL in iget(). The thing being, proc_read_super()
> explicitly sets ->s_op to non-NULL. Oh, and that area hadn't changed since
> 2.4.2, so I'd rather suspect the b0rken build. Can you reproduce it?
> 
> Cheers,
> Al

Not anymore; rm -rf seems to have fixed it (make mrproper didn't). 
Guess
I should have tried that before posting.  Don't know how it got screwed
up; only 2 patches applied to this tree.

   Thanks,

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

Slight Time drift in linux by division fault

[Erwin Six]

Hello,

I'm a senior Student in electronic Engineering. A lot of my work takes
place inside the network-part of the kernel, but now I'm confronted with
time. I designed a hardware-board whitch trys to synchronize
network-monitors by GPS. Electronicly this board is tested, and it has an
hardware resolution of about 1 usec (in phase, so in relative time). Now
I'm writing the device-driver that synchronizes the Linux-time system. If
I interrupt the kernel at the exact GPS-zero-time. And I watch the
do_timeoftheday() the seconds increases, but there is also a extra
increase of +-16 usec each second. So it seams that a linux second takes 
16usec more than one GPS second. Can I explain this with math? 

the cristal inside the computer ticks with a frequency of 1193180 Hz this
16usec could be an fault of 16ppm whitch is rather big. But 2 diffrent
systems have the allmost drift (+-2). Or it can be caused by the division
inside the linux time-system (whitch is possible after you see this
calculations)

If HZ = 100 then the LATCH of the PIT = (1193180 + HZ/2) / HZ = 11932
so in 1 sec we have 1193200 ticks of the PIT which causes 100
timer-interrupts. 1193200 ticks instead of 1193180 means that there are 20
ticks to mutch inside of each second. or 20 * 1/1193180 = 16.7619 usec. or
1 second to mutch every 16.5 hours (or 8.8 minutes a year). I've looked
the PLL closely but I can't find a mechanisme that compensates for this
problem, maybe I'm looking over it? Indeed 8.8 minutes is mutch, but I
think if I hadn't use a GPS, I wouldn't notice it.

Why do I suppose the second option? If you play a little bit with the HZ
parameter, you can let your timeclock drift mutch faster just by taking a
HZ that has a big 1193180 % HZ. eg. 5000 Hz gives a latch of 291 which
causes 119500 instead of 1193180 or a drift of 1820 ticks = 1.525 ms!

I have some solutions in mind to compensate this problem, but I have to
be sure. 
Can somebody confirm this problem?

Erwin Six



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] tiny MM performance and typo patches for 2.4.2

[Rik van Riel]

On Sun, 4 Mar 2001, David S. Miller wrote:
> Ulrich Kunitz writes:
>  > patch-uk6  In 2.4.x _page_hashfn divides struct address_space pointer
>  >with a parameter derived from the size of struct
>  >inode. Deriving this parameter from the size of struct
>  >address_space makes more sense -- at least for me.
> 
> The address_space is %99 of the time (unless swapping, and in that
> case the address is constant :-)) inside of an inode struct so this
> change actually makes the hash worse.  I looked at this one time
> myself...

The other patches look fine to me. Alan, Linus, could
you please include Ulrich's other patches in the next
pre-kernel ?

thanks,

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

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Slightly OT] x86 PROM project

[Khyron]

http://playground.sun.com/1275/

http://www.firmworks.com/

If memory serves, you said...

> What does everybody think of the idea of trying to write a RISC PROM-like
> BIOS for the x86 architecture?
>
> I've been tossing the idea around in my head for a while, and after I got
> my first SGI I realized that something like this would be fairly useful.
> Basically, I'm wondering if anybody is already doing something like this
> (not linuxBIOS, though the code for that could be a useful base).  Thanks.
>
>
> Matthew Fredrickson
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


Khyron  mailto:[EMAIL PROTECTED]
Key fingerprint = 53BB 08CA 6A4B 8AF8 DF9B  7E71 2D20 AD30 6684 E82D
"Drama free in 2001!"


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

RE: 2.4 and 2GB swap partition limit

[Matt_Domsch]

> > > Linus has spoken, and 2.4.x now requires swap = 2x RAM.
> > 
> > I think I missed this.  What possible value does this have? 

A good write-up of the discussion can be found at:
http://kt.zork.net/kernel-traffic/kt20010126_104.html#2


My concern is that if there continues to be a 2GB swap partition/file size
limitation, and you can have (as currently #defined) 8 swap partitions,
you're limited to 16GB swap, which then follows a max of 8GB RAM.  We'd like
to sell servers with 32GB or 64GB RAM to customers who request such for
their applications.  Such customers generally have no problem purchasing
additional disks to be used for swap, likely on a hardware RAID controller.

We've also seen (anecdotal evidence here) cases where a kernel panics, which
we believe may have to do with having 0 < swap < 2x RAM.  We're
investigating further.

> Actually the deal is: either use enough swap (about 2x RAM) or use
> none at all. 

If swap space isn't required in all cases, great!  We'll encourage the use
of swap files as needed, rather than swap partitions.  But, if instead you
*require* swap = 2x RAM, then the 2GB swap size limitation must go.

Thanks,
Matt


-- 
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [CFT] maestro update vs 2.2.18

[Tom Sightler]

> Its an awfully large diff, so it can be fetched from:
>
> http://www.zabbo.net/maestro/patches/2.2.18-mega-1.diff.gz
>
> if this works I'll officially submit it and make the same sorts of
> changes to 2.4.

I'd love to test this on my Dell 5000e (Maestro 2E) but it's pretty
impractical for me to return to the 2.2.x kernels.  I know you said you'll
wait before making the changes to 2.4, but I think you'll get more testers
if you turn it out sooner rather than later.

Later,
Tom


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

Re: [Slightly OT] x86 PROM project

[Khyron]

Because the original question was:

"I've been tossing the idea around in my head for a while, and after
I got my first SGI I realized that something like this would be fairly
useful. Basically, I'm wondering if anybody is already doing something
like this (not linuxBIOS, though the code for that could be a useful
base). Thanks."

Note the _not_ linuxBIOS part.

If memory serves, you said...

> On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote:
> > On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote:
> > > Have a look at OpenBIOS:
> > >
> > >   http://www.freiburg.linux.de/OpenBIOS/
> > >
> > > The project wants to create an IEEE 1275-1994 compliant firmware, like
> > > used by SUN (for example).
> >
> > I don't want to appear to be offensive in regards to this project
> > considering I have no prior knowledge about it other than what I've seen
> > at the web site just now, but it appears that there is a lot more talk
> > than coding occuring at this project.
>
> Ok, so what about this one?
>
> http://www.acl.lanl.gov/linuxbios/
>
> The code is on sourceforge.
>
>Michal
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


Khyron  mailto:[EMAIL PROTECTED]
Key fingerprint = 53BB 08CA 6A4B 8AF8 DF9B  7E71 2D20 AD30 6684 E82D
"Drama free in 2001!"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What happened ? (No such file or directory)

[Fr=E9d=E9ric?= L. W. Meunier]

--- Jeremy Jackson <[EMAIL PROTECTED]> wrote:
> " Frédéric L. W. Meunier" wrote:
> 
> > Correction. I can umount the partitions, but I get
> the
> > following message:
> >
> > "can't link lock file /etc/mtab~: No such file or
> > directory (use -n flag to override)"
> >
> > And /etc/mtab isn't updated.
> 
> Is your root filesystem mounted read-only at any
> point?
> (check with 'mount' look for ro in line for /
> filesystem)
> Check permissions on /etc, /etc/mtab, /etc/mtab~

/dev/ide/host0/bus0/target0/lun0/part1 on / type ext2
(rw)
/dev/ide/host0/bus0/target0/lun0/part3 on
/usr/local/src type ext2 (rw)
proc on /proc type proc (rw)

But it's not only umount. Most applications can't find
files, I can't move directories with mc (but mv(1)
works), all symlinks I create point to the symlink,
not the existing file or directory...

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.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: Slight Time drift in linux by division fault

[Jeremy Jackson]

Erwin Six wrote:

> Hello,
>
> I'm a senior Student in electronic Engineering. A lot of my work takes
> place inside the network-part of the kernel, but now I'm confronted with
> time. I designed a hardware-board whitch trys to synchronize

I would study the xntpd daemon furthur before trying to reinvent the wheel.
PC clock oscillators are notoriously inaccurate, the ntp documentation
goes really in depth about the kernel and time, so try reading this first.

Good luck!

>
> network-monitors by GPS. Electronicly this board is tested, and it has an
> hardware resolution of about 1 usec (in phase, so in relative time). Now
> I'm writing the device-driver that synchronizes the Linux-time system. If
> I interrupt the kernel at the exact GPS-zero-time. And I watch the
> do_timeoftheday() the seconds increases, but there is also a extra
> increase of +-16 usec each second. So it seams that a linux second takes
> 16usec more than one GPS second. Can I explain this with math?
>
> the cristal inside the computer ticks with a frequency of 1193180 Hz this
> 16usec could be an fault of 16ppm whitch is rather big. But 2 diffrent
> systems have the allmost drift (+-2). Or it can be caused by the division
> inside the linux time-system (whitch is possible after you see this
> calculations)
>
> If HZ = 100 then the LATCH of the PIT = (1193180 + HZ/2) / HZ = 11932
> so in 1 sec we have 1193200 ticks of the PIT which causes 100
> timer-interrupts. 1193200 ticks instead of 1193180 means that there are 20
> ticks to mutch inside of each second. or 20 * 1/1193180 = 16.7619 usec. or
> 1 second to mutch every 16.5 hours (or 8.8 minutes a year). I've looked
> the PLL closely but I can't find a mechanisme that compensates for this
> problem, maybe I'm looking over it? Indeed 8.8 minutes is mutch, but I
> think if I hadn't use a GPS, I wouldn't notice it.
>
> Why do I suppose the second option? If you play a little bit with the HZ
> parameter, you can let your timeclock drift mutch faster just by taking a
> HZ that has a big 1193180 % HZ. eg. 5000 Hz gives a latch of 291 which
> causes 119500 instead of 1193180 or a drift of 1820 ticks = 1.525 ms!
>
> I have some solutions in mind to compensate this problem, but I have to
> be sure.
> Can somebody confirm this problem?

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

Re: Broken APM Support since 2.4.1-ac1

[John Fremlin]

 Boris Dragovic <[EMAIL PROTECTED]> writes:

> i have compaq presario 1245 and kernel 2.4.2 does not do power off on 
> shutdown although all necessary kernel options are compiled in..

Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves
feedback.

[...]

-- 

http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Broken APM Support since 2.4.1-ac1

[John Fremlin]

 Daniel Stutz <[EMAIL PROTECTED]> writes:

> APM support for Lifebook C 6185 is broken since 2.4.1-ac1.
> While trying to go in suspend mode the system hangs.

Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He likes
feedback.

[...]

-- 

http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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, virtual console problem in 2.4.0

[John Fremlin]

Joseph Pingenot <[EMAIL PROTECTED]> writes:

> When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to
> suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and
> then the system locks up hard (not even the power button works).  In

Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves
feedback.

[...]

-- 

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

USB problem, bug since 2.4.2-ac5

[David]

In ac5 the USB or related changes broke things for this system I 
upgraded, this bug still exists in ac11.

I get the following messages on the order of about 50/second.

usb-uhci.c: interrupt, status 20, frame# 0
usb-uhci.c: interrupt, status 30, frame# 0

They repeat forever evenly, 20-30-20-30..

Alan's announcment for -ac5 has listed in it:

Fix USB thread wakeup scheduling(Arjan van de Ven)

00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
   Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
   Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c001 Rev= 1.10
S:  Manufacturer=Logitech
S:  Product=USB-PS/2 Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms

# cat drivers
cpia
usbdevfs
hub
hid
48- 63: usbscanner
acm
  0- 15: usblp
audio
80- 95: dc2xx
ov511
dsbr100
bluetooth
pegasus
usb-storage

-d

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

2.4 mkdep and symlinked kernel source

[Keith Owens]

The recent changes to mkdep can create incorrect dependencies when
  (a) the kernel source is a symlink and
  (b) you cd to the symlink and
  (c) your shell exports PWD.

This one line patch against 2.4.3-pre2 gives consistent results.
Please report any problems to [EMAIL PROTECTED]

Index: 3-pre2.1/Makefile
--- 3-pre2.1/Makefile Mon, 05 Mar 2001 10:47:15 +1100 kaos (linux-2.4/T/c/50_Makefile 
1.1.2.15.1.2.2.2 644)
+++ 3-pre2.1(w)/Makefile Mon, 05 Mar 2001 13:19:33 +1100 kaos 
+(linux-2.4/T/c/50_Makefile 1.1.2.15.1.2.2.2 644)
@@ -10,7 +10,7 @@ ARCH := $(shell uname -m | sed -e s/i.86
 CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
  else if [ -x /bin/bash ]; then echo /bin/bash; \
  else echo sh; fi ; fi)
-TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi)
+TOPDIR := $(shell /bin/pwd)
 
 HPATH  = $(TOPDIR)/include
 FINDHPATH  = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net

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

Interesting fs corruption story

[Ettore Perazzoli]

Hello all,

I have been telling this story to a few people, and nobody seems to have a
clue about what is going on...  Alan suggested me to post a description of
the problem to this list, so this is what I am doing.

So, I had a Dell Inspiron 5000 which worked great for a while.  It was
running a more-or-less stock Red Hat 6.1 with the stock kernel from
it.  At some point, the hard drive in that machine was broken so I had to
buy a new one.  The new drive was an IBM Travelstar 20G.

I installed a Debian system on it, with a reiserfs root partition, which
was the only partition besides an ext2 /boot partition.  Everything seemed
to work fine, but after a while I started getting massive metadata
corruption on it.  Whenever I did an apt-get dist-upgrade, something weird
happened, such as files that couldn't be stat()ed nor unlink()ed and
directories that would make the kernel oops nicely if written to.

I could never figure out what was wrong with it.  The reiserfs people
seemed to have no clue about what was going there.

In the meantime, I got a new machine.  An IBM Thinkpad T21, which is now
my main machine.  After the previous experience, I decided to not trust
reiserfs this time, so I installed using ext2.  Again, I installed Debian
Woody.  I needed to rebuild the kernel myself as I needed the soundcard to
work, and the stock Debian one didn't even seem to have APM working, so I
installed the 2.2.18 source from Debian, configured it, and
compiled/installed using make-kpkg and dpkg.

Unfortunately, after importing 15k mail messages or so into Gnus (which is
a pretty disk-intensive activity -- I use nnml so every mail goes into a
separate file) and apt-get upgrading a couple of times, I started getting
file system corruption again.  /tmp/.X0-lock was turned into a weird file
with abnormal length and couldn't be removed, so I tried to manually force
a fsck and this resulted in a lot of problems being reported, and
lost+found getting 656 files into it.  (Some of which are files from the
Gnus mail repository, and other seem to come from TeX.)

So, this looks pretty interesting to me.  I got these metadata corruption
problems (no data corruption that I know of) on two different machines
with different hardware and different file systems.  Maybe it's a kernel
bug?

Another interesting thing is that both machines use a Travelstar 20G
drive.  Maybe the drive's firmware is to blame, but I know at least two
more people that are using that same drive on Thinkpads for quite a long
time and have had no problems at all with it.  (Using both XFS and ext2.)

Some system information: (I don't have the Ispiron at hand anymore, so I
can only be detailed about the Thinkpad)

milkplus:~# /sbin/lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03)
00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:03.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100]
(rev 09)00:03.1 Serial controller: Xircom: Unknown device 000c
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24
[CrystalClear SoundFusion Audio Accelerator] (rev 01)
00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03)
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/MX-/IX (rev
13)

milkplus:~# dmesg | grep hda
ide0: BM-DMA at 0x1850-0x1857, BIOS settings: hda:DMA, hdb:pio
hda: IBM-DJSA-220, ATA DISK drive
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=2584/240/63, UDMA
 hda: hda1 hda3 < hda5 hda6 > hda4

milkplus:~# hdparm /dev/hda
/dev/hda:
 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 = 2584/240/63, sectors = 39070080, start = 0

Any idea?  What am I doing wrong?

Thanks in advance,

-- 
Ettore
(I am not subscribed to the list, so please reply to my own address too.)

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

Index of Kernel Configuration Options

[AJF75]

Does anyone know whereabouts I could go to get an index of all
configurations options (i.e. drivers, etc.) that are available in the
latest Linux kernel? I am waiting on a kernel mode driver for my USB
digital camera, but I don't want to go ahead and download the full 24Mb
just to find out if the support is available yet.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Slightly OT] x86 PROM project

[John Jasen]

On Sun, 4 Mar 2001, Erik Mouw wrote:

> Have a look at OpenBIOS:
>
>   http://www.freiburg.linux.de/OpenBIOS/
>
> The project wants to create an IEEE 1275-1994 compliant firmware, like
> used by SUN (for example).

I'd like to see something like SRM; but with better support.

(SRM is the 'BIOS' for alphas, BTW).


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

[Jonathan Morton]

>milkplus:~# hdparm /dev/hda
>/dev/hda:
> 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 = 2584/240/63, sectors = 39070080, start = 0
>
>Any idea?  What am I doing wrong?

You could try turning off DMA (rebuild your kernel again, and turn off "use
DMA by default").  UDMA is known to work reliably only with a (reasonably
broad) subset of chipsets, and it is likely that laptop chipsets get the
least testing.  If turning off DMA fixes the problem for you, we at least
know where to start looking.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


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

[Ettore Perazzoli]

> You could try turning off DMA (rebuild your kernel again, and turn off "use
> DMA by default").  

Would this be in any way different from just `hdparm -d0 /dev/hda'?

> UDMA is known to work reliably only with a (reasonably
> broad) subset of chipsets, and it is likely that laptop chipsets get the
> least testing.  If turning off DMA fixes the problem for you, we at least
> know where to start looking.

Sure I can try this, although it's hard to safely say if the problem is
fixed or not, as it's not reliably reproduceable.

BTW, the Inspiron seemed to work just fine with DMA turned on, before the
drive was replaced, with the 2.2.16 kernel that Red Hat ships.  (I always
had DMA turned on, and that was for about six months, without any problems
ever.)

Also, I have some friends using T20s with the same drive without any
problems, with DMA turned on.

Is there any kind of IDE DMA test I could run to see if it works reliably?

-- 
Ettore

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

[Jonathan Morton]

>Does anyone know whereabouts I could go to get an index of all
>configurations options (i.e. drivers, etc.) that are available in the
>latest Linux kernel? I am waiting on a kernel mode driver for my USB
>digital camera, but I don't want to go ahead and download the full 24Mb
>just to find out if the support is available yet.

No idea, but if nobody else has a better idea, you could download one
kernel and inspect it, then simply monitor the *patches* (which are much
smaller) to see when your camera gets support.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


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

PROBLEM: ES1371 driver & high-pitched buzzing

[Jonathan Morton]

1) ES1371 driver in 2.4.2 produces high-pitched buzzing instead of sound.

2) AudioPCI/97 card in friend's Duron-based machine (very similar to mine,
but different soundcard) works fine under Mandrake 7.1 stock kernel
(2.2.15-4mdk), but produces only loud, high-pitched buzzing noises when
used under 2.4.2.  Driver is built into the kernel, appears to be detected
properly.  Problem easily reproduced from RealPlayer, XMMS and mpg123.

3) AudioPCI es1371 high-pitched buzzing

4) Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version
2.95.3 19991030 (prerelease)) #2 Sun Mar 4 20:59:55 MST 2001

5) No OOPS.

6) Playing any sound using, eg. XMMS, mpg123 or RealPlayer.

7.1)
Linux blueberry.wilee.chromatix.org.uk 2.4.2 #2 Sun Mar 4 20:59:55 MST 2001
i686 unknown
Kernel modules 2.3.10
Gnu C  2.95.3
Gnu Make   3.79
Binutils   2.9.5.0.31
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10h
Net-tools  1.55
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded
(none)

7.2)
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Duron(tm) Processor
stepping: 1
cpu MHz : 700.053
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1395.91

7.3) No modules loaded.

7.4)
[root@blueberry linux]# cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0778-077a : parport0
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
c000-cfff : PCI Bus #01
  c000-c0ff : ATI Technologies Inc Rage 128 RF
d000-d00f : VIA Technologies, Inc. Bus Master IDE
  d000-d007 : ide0
  d008-d00f : ide1
dc00-dc07 : US Robotics/3Com 56K FaxModem Model 5610
  dc00-dc07 : serial(auto)
e000-e03f : Ensoniq 5880 AudioPCI
  e000-e03f : es1371
e400-e47f : 3Com Corporation 3c905B 100BaseTX [Cyclone]
  e400-e47f : eth0

[root@blueberry linux]# cat /proc/iomem
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
  0010-0025aa21 : Kernel code
  0025aa22-002d3967 : Kernel data
d000-d3ff : VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
d400-d7ff : PCI Bus #01
  d400-d7ff : ATI Technologies Inc Rage 128 RF
d400-d7ff : aty128fb FB
d800-d9ff : PCI Bus #01
  d900-d9003fff : ATI Technologies Inc Rage 128 RF
d900-d9003fff : aty128fb MMIO
db00-db7f : 3Com Corporation 3c905B 100BaseTX [Cyclone]

7.5)
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR-  [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF
(prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0008
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=128K]
Capabilities: [50] AGP ve

Re: Question about IRQ_PENDING/IRQ_REPLAY

[Cort Dougan]

} Also, we currently don't use the same mecanism as i386, and since Linus
} expressed his desire to have irq.c become generic, I'm trying to make sure
} I fully understand it before merging in PPC the bits that I didn't merge
} them yet.

More generic in terms of using irq_desc[] and some similar structures I can
see.  Making do_IRQ() and enable/disable use the same names and structures
as x86 isn't sensible.  They're different ports, with different design
philosophies.

I don't believe that the plan is a common irq.c - lets stay away from that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Can Linux 2.4.x boot from UDMA-100 disk ?

[Bryan O'Sullivan]

y> Would it be possible to boot kernel 2.4.x from the UDMA/100 drive?

Yes.

y> in http://www.linux-ide.org/ultra100.html it is not mentioned if
y> the patches can help with boot.

You shouldn't need Andre's patches.

http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [prepatches] removal of console_lock

[Cort Dougan]

I still get huge over-runs with fbdev (much improved, though).

Andrew, are you still working on it?  If so, I'm happy to keep you
up-to-date on performance WRT Linux/PPC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.4.3-pre{1,2} md_autodetect_dev unresolved

[Mohammad A. Haque]

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=

--- linux/drivers/md/md.c.orig  Mon Mar  5 00:48:51 2001
+++ linux/drivers/md/md.c   Mon Mar  5 01:20:18 2001
@@ -3902,5 +3902,6 @@
 MD_EXPORT_SYMBOL(md_interrupt_thread);
 MD_EXPORT_SYMBOL(mddev_map);
 MD_EXPORT_SYMBOL(md_check_ordering);
+MD_EXPORT_SYMBOL(md_autodetect_dev);
 //MD_EXPORT_SYMBOL(name_to_kdev_t);
 

Re: Linux on the Unisys ES7000 and CMP2 machines?

[J. Dow]

From: "J Sloan" <[EMAIL PROTECTED]>

> My take on it is that unisys is an example of brain damage
> and it's easiest to ignore/work around them rather than
> trying to get them out of bed with microsoft. Nature will
> eventually take it's course with unisys as it did with Dec.

jjs, you can take that to the bank as collateral. Alas, my partner
has been with them since Burroughs days as an undegreed OS developer.
Finding the same level of pay in the "sane world" is proving rather
annoyingly difficult here in the San Berdoo County area. So he is
riding it out till he can retire. {o.o}

{^_^}Joanne Dow, [EMAIL PROTECTED]


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

Re: Linux on the Unisys ES7000 and CMP2 machines?

[J. Dow]

From: "Miles Lane" <[EMAIL PROTECTED]>

> I noticed that this article mentions that Unisys has
> no plans to port Linux to it's "cellular multiprocessor"
> machines.  So, I am wondering if anyone is working
> on this independantly.

Miles, if these babies are the 32 processor monsters that UniSys
has been making recently there IS interest to get Linux on it.
But the people I know who have mentioned "interest", mostly from
a curiosity standpoint, have their hands neatly tied by Microsoft.
Ya see, the developers at UniSys have NT source licenses so they
can develop the HALs for the monsters. Microsoft insists that they
spend a considerable time away from OS development before working
on another OS. So, no Linux port is in the offing, I suspect. The
people who KNOW the machine are not allowed to do it. And I can
guarantee you that the machines are not well documented at the
level a person making an NT port would need. (As an aside it seems
the UniSys guys know more about how to debug HALs without fancy
ICEs than the MS guys. At least the amount of travel between
Mission Viyoyo and Redmond suggests it.)

{^_^}   Joanne "Too many years in a DoD environment" Dow, who has
put a whole string of two's together to figure out the
above from clues laid by her HAL developer partner.
[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: VM balancing problems under 2.4.2-ac1

[Mike Galbraith]

On Sun, 4 Mar 2001, Ingo Oeser wrote:

> On Sat, Mar 03, 2001 at 01:03:26AM +0100, Adrian Bunk wrote:
> > > If anybody as a good idea to make this code auto-balancing,
> > > please let me know.
> >
> > I have no idea for auto-balancing but another idea: It's one possibility
> > to let the user choose when doing "make *config" what he wants:
> >
> > - A VM optimized for servers that swaps out applications in favor of
> >   caching.
> > or
> > - A VM optimized for workstations that won't swap out applications in
> >   favor of caching.
>
> I thought about the same thing sometimes (but for other troughput
> vs. latency decisions, too).
>
> But I realized, that my very own workstation is also a server,
> since it runs an httpd, mysqld, smbd, ftpd etc.
>
> And somtimes the servers become very busy in our LAN[1].
>
> IF we want that tuning, we should have it as a sysctl. Most of it
> is already possible with /proc/sys/vm/*, but balancing decisions
> are still missing.

I think sysctls for balancing knobs is a great idea.  The VM has no
clue concerning the cost of rebuilding cache eg but a human may.

Automatic tuning would be wonderful, but it requires information
which the VM flat doesn't have.. so it should ask the boss for help.

Three handy knobs I can think of off the top of my head are swap_size,
flush_size [for page_launder().. bdflush has that] and cache_stickiness.

-Mike

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

Re: [PATCH] tiny MM performance and typo patches for 2.4.2

[Mike Galbraith]

On Sun, 4 Mar 2001, Ulrich Kunitz wrote:

> patch-uk2 makes use of the pgd, pmd and pte quicklists for x86 too;
>   risky: there might be a reason that 2.4.x doesn't use the
>   quicklists.

I remember these being taken out (long ago), but not why.  Anyone?

-Mike

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

[PATCH] Documentation for bitops

[Matthew Wilcox]

This is just the kernel-doc parts; the .tmpl file entry is missing until
i get the chance to sync up with Alan again.

--- linux-2.4.2/include/asm-i386/bitops.h   Wed Feb 21 17:09:56 2001
+++ linux-willy/include/asm-i386/bitops.h   Mon Mar  5 00:39:28 2001
@@ -23,6 +23,16 @@
 
 #define ADDR (*(volatile long *) addr)
 
+/**
+ * set_bit - Atomically set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * This function is atomic and may not be reordered.  See __set_bit()
+ * if you do not require the atomic guarantees.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
 static __inline__ void set_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
@@ -31,7 +41,15 @@
:"Ir" (nr));
 }
 
-/* WARNING: non atomic and it can be reordered! */
+/**
+ * __set_bit - Set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Unlike set_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
 static __inline__ void __set_bit(int nr, volatile void * addr)
 {
__asm__(
@@ -40,11 +58,16 @@
:"Ir" (nr));
 }
 
-/*
- * clear_bit() doesn't provide any barrier for the compiler.
+/**
+ * clear_bit - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and may not be reordered.  However, it does
+ * not contain a memory barrier, so if it is used for locking purposes,
+ * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
+ * in order to ensure changes are visible on other processors.
  */
-#define smp_mb__before_clear_bit() barrier()
-#define smp_mb__after_clear_bit()  barrier()
 static __inline__ void clear_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
@@ -52,7 +75,18 @@
:"=m" (ADDR)
:"Ir" (nr));
 }
+#define smp_mb__before_clear_bit() barrier()
+#define smp_mb__after_clear_bit()  barrier()
 
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * change_bit() is atomic and may not be reordered.
+ * Note that @nr may be almost arbitrarily large; this function is not
+ * restricted to acting on a single-word quantity.
+ */
 static __inline__ void change_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
@@ -61,10 +95,13 @@
:"Ir" (nr));
 }
 
-/*
- * It will also imply a memory barrier, thus it must clobber memory
- * to make sure to reload anything that was cached into registers
- * outside _this_ critical section.
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.  
+ * It also implies a memory barrier.
  */
 static __inline__ int test_and_set_bit(int nr, volatile void * addr)
 {
@@ -77,7 +114,15 @@
return oldbit;
 }
 
-/* WARNING: non atomic and it can be reordered! */
+/**
+ * __test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.  
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
 static __inline__ int __test_and_set_bit(int nr, volatile void * addr)
 {
int oldbit;
@@ -89,6 +134,14 @@
return oldbit;
 }
 
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.  
+ * It also implies a memory barrier.
+ */
 static __inline__ int test_and_clear_bit(int nr, volatile void * addr)
 {
int oldbit;
@@ -100,7 +153,15 @@
return oldbit;
 }
 
-/* WARNING: non atomic and it can be reordered! */
+/**
+ * __test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.  
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail.  You must protect multiple accesses with a lock.
+ */
 static __inline__ int __test_and_clear_bit(int nr, volatile void * addr)
 {
int oldbit;
@@ -112,6 +173,14 @@
return oldbit;
 }
 
+/**
+ * test_and_change_bit - Change a bit and return its new value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is atomic and cannot be reordered.  
+ * It also implies a memory barrier.
+ */
 static __inline__ int test_and_change_bit(int nr, volatile void * addr)
 {
int oldbit;
@@ -123,9 +192,15 @@
return oldbit;
 }
 
-/*
- * Thi

RE: Intel-e1000 for Linux 2.0.36-pre14

[Ofer Fryman]

I finally managed to get the interrupt handler running successfully. The
problem was, if you run the driver in debug mode, the interrupt handler goes
crazy, this also happened to me on 2.2.x.

Now the driver appears to be running successfully, but I still cannot pass
traffic through, any clue of where to start looking?.

On Fri, 2 Mar 2001, Richard B. Johnson wrote:

> On Fri, 2 Mar 2001, Friedrich Steven E CONT CNIN wrote:
> 
> Okay. Thanks. I'm forwarding this info to the original persons
> who needed it.
> 
> > Perusing the Intel developer site, I found Linux source for a "base
driver".
> > 
> > 
> > Here's a link:
> >
http://appsr.intel.com/scripts-df/filter_results.asp?strOSs=39&strTypes=PLU%
> > 2CDRV%2CUTL&ProductID=415&OSFullName=Linux*&submit=Go%21
> >
 > %2CDRV%2CUTL&ProductID=415&OSFullName=Linux*&submit=Go%21> 
> > 
> > I read a file called e1000.txt and it's attached.  They seem to be
giving
> > away the source for Advanced Networking Services too!!
> > 
> > I prefer tech manuals too, and I can't seem to find one on their site.
But
> > the Linux community's constant refrain is "use the source, Luke". 8o)


>Thanks for the links. The source cannot tell you what chip errata you may
>stumble on. Oh well. Better than nothing indeed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]: What is 2.4 Linux networking performance like compared to BSD?

[linuxjob]

Hello Gregory,

Friday, March 02, 2001, 9:00:07 PM, you wrote:

GM> On Fri, Mar 02, 2001 at 09:02:13AM +, Henning P. Schmiedehausen wrote:
>> [EMAIL PROTECTED] (Hans Reiser) writes:
>> > If I can't get information about BSD v. Linux 2.4 networking code,
>> > then reiserfs has to get ported to BSD which will be both nice and a
>> > pain to do.
>> 
>> So we would get dual-licensed ReiserFS (BSD and GPL)? 
>> 
>> Are you aware of the legal implications, making your currently
>> GPL-only code BSD-licensed (status of third party patches for the GPL
>> code and so on)?

GM> There would be no reason to BSD licence ReiserFS.. The intent of the BSD
GM> licence is to let anyone who wants to lock it up with more restrictive
GM> licences do so, and if the result is more popular.. take over control of the
GM> software. 

GM> So Hans could easily release a GPLed copy of FreeBSD with reiserfs. This
GM> type of activity is encouraged by the BSD people.
GM> -
GM> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
GM> the body of a message to [EMAIL PROTECTED]
GM> More majordomo info at  http://vger.kernel.org/majordomo-info.html
GM> Please read the FAQ at  http://www.tux.org/lkml/

Yes, I have never heard a version -- FreeLinux. Linux is not free.
FreeBSD is true free.

Regards,
linuxjobmailto:[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/

2.4.2 broke in-kernel ide_cs support

[Pavel Machek]

Hi!

I do not yet know details, but it worked in 2.4.1 and it does not work
now:

Mar  5 09:12:05 bug cardmgr[69]: initializing socket 1
Mar  5 09:12:05 bug cardmgr[69]: socket 1: ATA/IDE Fixed Disk
Mar  5 09:12:05 bug cardmgr[69]: module //pcmcia/ide_cs.o not
available
Mar  5 09:12:06 bug cardmgr[69]: get dev info on socket 1 failed:
Resource temporarily unavailable
Pavel
((Module not available is okay, it should be compiled into kernel))
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/