Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Ben Ford]

Arjan van de Ven wrote:

>"Eric S. Raymond" wrote:
>
>>
>>an old interface in amber do anything to explore new UI possibilities?
>>
>
>kernel != GUI
>

UI != GUI

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan



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

[Ben Ford]

Charles Cazabon wrote:

>Eric S. Raymond <[EMAIL PROTECTED]> wrote:
>
>>Arjan van de Ven <[EMAIL PROTECTED]>:
>>
>>>Aunt Tillie doesn't even know what a kernel is, nor does she want
>>>to. I think it's fair to assume that people who configure and
>>>compile their own kernel (as opposed to using the distribution
>>>supplied ones) know what they are doing.
>>>
>>I'd like to break these assumptions.  Or at the very least see how far
>>they can be bent.  I know this sounds crazy to a lot of hackers, but 
>>I think there's a certain amount of unhelpful elitism and self-puffery
>>in the "kernels are hard to configure and they *should* be hard to 
>>configure* attitude.  Let's give Aunt Tillie a chance to surprise us.
>>
>
>Whether this is desirable or not is debatable.  The big question is:  why on
>earth would Aunt Tillie _want_ to compile a kernel at all, let alone
>re-configure one?  If she's using Linux, she's installing her distribution's
>pre-compiled kernel, and has no need for anything else.
>
>Simplifying the configuration interface so that "anyone" can use it seems like
>a waste of effort.  If there's an interested novice out there who wants to
>learn how to configure a kernel, they'll be sufficiently interested to invest
>an hour or two in learning how the whole process works.  Make it as simple as
>it needs to be, and no simpler.
>
>Charles
>
Because, for example, a kernel compile can be a part of the standard 
install now, and you will end up with a kernel built specifically for 
your machine that doesn't print 50 initialization failed messages on boot.

Libranet (Debian offshoot) does that already.  It is the only distro 
that I know of that does this.  This also makes it about a thousand 
times easier for distributions.  They don't have to write huge (have you 
ever looked at Redhat scripts??) init scripts to cover every single 
possibility and load any module you might need.  It's built into the 
kernel, the way it should be!

And you can also now run a kernel built for your shiny new Athlon, not 
the old piece of shit that was hot stuff in '92.

-b

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan



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

Using Parallel Port to Receive Signals

[antonpoon]

I am trying to use the data port of parallel port to receive data, so I set the bit 5 
of the control port to enable the bi-directional port, but it doesn't work.  My 
parallel supports SPP/EPP/ECP mode, does it support bi-directional mode?  if yes, how 
can I config it?

I wish to be personally CC'ed the answers/comments posted to the list in response to 
my posting. Thank you.

Best Regards,
Anton
--
 Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î
 Thank you for using hongkong.com Email system

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

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Stephen C. Tweedie wrote:

> Hi,
>
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
>
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what would need to be
> > tunable and how it would help.
>
> It's worse than that.  The workload on most typical systems is not
> static.  The VM *must* be able to cope with dynamic workloads.  You
> might twiddle all the knobs on your system to make your database run
> faster, but end up in such a situation that the next time a mail flood
> arrives for sendmail, the whole box locks up because the VM can no
> longer adapt.
>
> That's the main problem with static parameters.  The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)

Yup.  The problems are dynamic even with my static test load.

Off the top of my head, if I could make a suggestion to the vm it
would be something like "don't let dirty pages lay idle any longer
than this" and maybe "reclaim cleaned pages older than that".

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

Problem! kernel: TCP: too many of orphaned sockets

[Dworf]

Hello all.

I have a little problem, I have an Pentium 266Mhz linux box with kernel 2.4.2 
with 64mb of memory, After about an 1 day of running i get this msg loged in

/var/log/messages

kernel: TCP: too many of orphaned sockets

after that noone can telnet to the box or anything couse of the sockets 
beeing all used. I have to reboot then its ok again for about a day, and Im 
not running many processes

if i do netstat i get about 100 connections...

why are all the sockets used?

If i do the

cat /proc/net/socketstat
sockets: used 405
TCP: inuse 102 orphan 0 tw 0 alloc 156 mem 2
UDP: inuse 12
RAW: inuse 0
FRAG: inuse 0 memory 0


So if i look at socketstats more often the "sockets: used XXX" the XXX number 
is going only up! and never down.

What should i do to fix this?
Where is the problem?

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

Noticeable latency problems after upgrade from 2.4.3 to 2.4.4

[Josh Green]

I'm experiencing nasty latency problems (stalls X cursor, Maelstrom
arcade game :), etc) with Linux kernel 2.4.4. I did not have this
problem with 2.4.3. I have Mandrake 8.0. I made sure that I compiled the
2.4.4 kernel with the older egcs 1.1.2 (although I did try it with the
controversial gcc 2.96 with the same results). 
Both kernels were downloaded off of kernel.org (not Mandrake modified)
and I used the same .config.
Heres a description of my system:

I'm using reiserfs
Linux version 2.4.4 (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2
release / Linux-Mandrake 8.0))
XFree86 4.0.3
CPU: AMD K6 550 MHZ
Memory: 128 MB
HD: WDC WD300BB-00AUA1, ATA IDE DISK drive
Chipset: VIA VT82C586

Both kernels had the following hard disk tuning parameters (excerpt from
hdparm):
/dev/hda:
 multcount=  0 (off)
 I/O support  =  1 (32-bit)
 unmaskirq=  1 (on)
 using_dma=  1 (on)

I even set the multcount to 8 with a slight increase in hdparm -t read
performance, but still bad latency.
The latency issues mainly occur with compiling programs. Compiling my
autoconf based program and running Maelstrom at the same time served as
a crude test. 2.4.4 would have large skip outs in sound and pauses in
gameplay, whereas 2.4.3 runs very smooth. I also did an hdparm -t while
running tests, I did not perceive the problem in this case though,
suggesting something besides hard disk access.

If anyone has any info on what could be causing this, please let me
know. CC me as I'm not on the list. If there isn't any knowledge of this
problem, I will try to track it down myself. I guess perhaps narrowing
it down to a particular pre version and maybe doing some kernel
profiling (I have no idea how) if all else fails. Lates..
Josh Green
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: alpha iommu fixes

[Tom Vier]

maybe this third window stuff in cia_enable_broken_tbia() is why i can't
seem to get the third window to open up. from my reading of the 21174 docs,
my code should work. since T2_BASE is at 0x4000 for 1gig, i'd think
T3_BASE should be at 0x8000. am i missing something?

hose->sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768);
*(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1;
*(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) & 0xfff0;
*(vip)CIA_IOC_PCI_T3_BASE = 0x8000 >> 2;


On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote:
> - *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBI_TRY2_BASE | 3;
> - *(vip)CIA_IOC_PCI_W3_MASK = (PAGE_SIZE - 1) & 0xfff0;
> + *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3;
> + *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
> + & 0xfff0;
>   *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2;
>  }


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

Re: Linux 2.4.4-ac10

[Mike Castle]

On Fri, May 18, 2001 at 11:12:32PM -0300, Rik van Riel wrote:
> Basic rule for VM: once you start swapping, you cannot
> win;  All you can do is make sure no situation loses
> really badly and most situations perform reasonably.

Do you mean paging in general or thrashing?

I always thought: paging good, thrashing bad.

A good effecient paging system, always moving data between memory and disk,
is great.  It's when you have the greater than physical memory working set
that things go to hell in a hand basket.

Did Linux ever do the old trick of "We've too much going on!  You!
(randomly points to a process) take a seat!  You're not running for a
while!" and the process gets totatlly swapped out for a "while," not even
scheduled?

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
> 
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what would need to be
> > tunable and how it would help.
> 
> It's worse than that.  The workload on most typical systems is not
> static.  The VM *must* be able to cope with dynamic workloads.  You
> might twiddle all the knobs on your system to make your database run
> faster, but end up in such a situation that the next time a mail flood
> arrives for sendmail, the whole box locks up because the VM can no
> longer adapt.

That's another problem, indeed ;)

Ingo, Mike, please keep this in mind when designing
tunables or deciding which test you want to run today
in order to look how the VM is performing.


Basic rule for VM: once you start swapping, you cannot
win;  All you can do is make sure no situation loses
really badly and most situations perform reasonably.

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

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

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

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

Re: [reiserfs-list] reiserfs, xfs, ext2, ext3 (simple benchmarks)

[Hans Reiser]

Steve Lord, please work with Yura to resolve the bug that mongo triggers in
XFS.  I assume you will be as eager as we usually are for any script that can
reproduce a bug.

Yura's benchmarks don't really show off the strengths of XFS, just as the
spanish benchmark didn't show off the strengths of reiserfs.  I expect that once
mongo works there will be areas where XFS has clear advantages, probably in
large file IO and for reads.  We look forward to measuring reiser4 against XFS
during linux 2.6, though I suspect there will always be (changing) areas where
the two filesystems each offer the users different advantages.

Hans

"Yury Yu. Rupasov" wrote:
> 
> "Yury Yu. Rupasov" wrote:
> >
> > Hans Reiser wrote:
> > >
> > > Andrey Tulenev wrote:
> > >
> > > > Hello reiserfs-list,
> > > >
> > > > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/0358.html
> > > > http://bulma.lug.net/body.phtml?nIdNoticia=626
> > > >
> > > > --
> > > > Best regards,  [Team òõäîÉË]
> > > >  Andrey  mailto:[EMAIL PROTECTED]
> > > > Pager: 913-5353 ab.17403   or  [EMAIL PROTECTED]
> > >
> > > I don't understand why you all didn't run more serious benchmarks.
> > > We'll try mongo.pl from the benchmarks section of www.namesys.com, and
> > > report on the results.
> > >
> > > Hans
> >
> > Yes, we have some results : ext2 vs. reiserfs on our web page :
> > http://www.namesys.com/benchmarks/benchmark-results.html
> >
> > But yes, now when xfs is released, it would be not bad to check
> > it performance too. The results will be ready a bit later.
> >
> 
> I have some results now : bonnie++ for ext2, reiserfs and xfs :
> 
> ftp://ftp.botik.ru/rented/namesys/ftp/pub/linux+reiserfs/gif/a.html
> 
> Linux-2.4.2+xfs-1.0-patches,
> 
> There was no problems to apply the next xfs patches
> to pure linux-2.4.2 :
> 
> linux-2.4-xfs-1.0.patch
> linux-2.4.2-core-xfs-1.0,patch
> 
> Test Machine : Celeron 500, 128 MB RAM,
>8 GB test partition of 36 GB IDE HDD.
> 
> The bonnie++ results show that reiserfs is much more faster
> in case of big amount of files (3 files here).
> 
> Here are also dbench results :
> 
>   ext2   xfs  reiserfs
> -
> dbench  1   15.606219.073223.1156mb/sec
> dbench  58.449011.678111.8350mb/sec
> dbench 109.3481 6.1847 8.9247mb/sec
> dbench 207.3631 2.6893 6.9256mb/sec
> 
> Unfortunately, I have no mongo.pl results, because the system
> hangs during performing mongo test on xfs system.
> 
> I had to press "reset" button to reboot system, because all
> others ways did not work.
> 
> There was no any error messages in the system log.
> 
> Thanks,
> Yura.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RFC] Signal-per-fd for RT signals

[Vitaly Luban]

Hi,

I'm sorry, the previous message slipped out w/o subj.

Attached patch is an implementation of "signal-per-fd"
enhancement to kernel RT signal mechanism, AFAIK first
proposed by A. Chandra and D. Mosberger :

http://www.hpl.hp.com/techreports/2000/HPL-2000-174.html

which should dramatically increase linux based network
servers scalability.

Patch is made against 2.4.4 tree.

This patch allows to set signal-per-fd mode per each
file descriptor by introducing new fcntls "F_SETAUXFL"
and "F_GETAUXFL" with one possible argument "O_ONESIGFD"
to F_SETAUXFL defined.

When set, no additional siginfo will be queued for an
RT signal, generated by event on file descriptor, while
there is already one queued, though event report field
in already queued struct siginfo - "si_band" is updated.

I'd also like to hear an opinion on the signal filtering
capability. I.e, it's relatively easy to filter signals
upon an interest mask, supplied by the same F_SETAUXFL in
the form of POLL_... This will bring functionality of RT
signals event notification on the level with 'select' or
'poll' one, while more efficient and scalable. If there's
an interest in such a feature, I'd be eager to publish a
patch.

Thanks,
Vitaly.
 one-sig-perfd-2.4.4.patch.gz

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Aaron Lehmann]

On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?

I don't know about the rest of the world, but I _much_ prefer the old
menuconfig to CML2's menuconfig. While I haven't spent much time playing
with CML2, I'm familiar with cml1's tools and see no reason why they
need changes, which IMHO (so far) are detrimental.

That's not even to mention python issues, speed, or anything else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] videodev_init() -> initcall

[Randy.Dunlap]

Al's patch gives me:

videodev.c:550: warning: static declaration for `videodev_init' follows
non-static
videodev.c: In function `videodev_exit':
videodev.c:579: warning: implicit declaration of function
`videodev_proc_destroy'

Patch to use after Al's patch is attached.

~Randy


Alexander Viro wrote:
> 
> Alan, drivers/media/videodev.c is your code. See if you are OK
> with the patch below - it switches the thing to use of module_init()
> and removes the call of videodev_init() from chr_dev_init(). I.e. the
> only ordering change is that videodev_init() is postponed until immediately
> before the media/video/* drivers.
> Linus, if you are OK with that and Alan will ACK the thing - please,
> consider applying it.
> Al
> 
> diff -urN S5-pre3/drivers/char/mem.c S5-pre3-videodev/drivers/char/mem.c
> --- S5-pre3/drivers/char/mem.c  Wed May 16 16:26:36 2001
> +++ S5-pre3-videodev/drivers/char/mem.c Fri May 18 16:46:37 2001
> @@ -29,9 +29,6 @@
>  #ifdef CONFIG_I2C
>  extern int i2c_init_all(void);
>  #endif
> -#ifdef CONFIG_VIDEO_DEV
> -extern int videodev_init(void);
> -#endif
>  #ifdef CONFIG_FB
>  extern void fbmem_init(void);
>  #endif
> @@ -647,9 +644,6 @@
>  #endif
>  #if defined(CONFIG_ADB)
> adbdev_init();
> -#endif
> -#ifdef CONFIG_VIDEO_DEV
> -   videodev_init();
>  #endif
> return 0;
>  }
> diff -urN S5-pre3/drivers/media/video/videodev.c 
>S5-pre3-videodev/drivers/media/video/videodev.c
> --- S5-pre3/drivers/media/video/videodev.c  Sun Apr  1 23:56:57 2001
> +++ S5-pre3-videodev/drivers/media/video/videodev.c Fri May 18 16:48:34 2001
> @@ -546,7 +546,7 @@
>   * Initialise video for linux
>   */
> 
> -int __init videodev_init(void)
> +static int __init videodev_init(void)
>  {
> struct video_init *vfli = video_init_list;
> 
> @@ -573,13 +573,7 @@
> return 0;
>  }
> 
> -#ifdef MODULE
> -int init_module(void)
> -{
> -   return videodev_init();
> -}
> -
> -void cleanup_module(void)
> +static void __exit videodev_exit(void)
>  {
>  #if defined(CONFIG_PROC_FS) && defined(CONFIG_VIDEO_PROC_FS)
> videodev_proc_destroy ();
> @@ -588,7 +582,8 @@
> devfs_unregister_chrdev(VIDEO_MAJOR, "video_capture");
>  }
> 
> -#endif
> +module_init(videodev_init)
> +module_exit(videodev_exit)
> 
>  EXPORT_SYMBOL(video_register_device);
>  EXPORT_SYMBOL(video_unregister_device);
> 
> -

--- linux/include/linux/videodev.h.org  Fri May 18 15:56:32 2001
+++ linux/include/linux/videodev.h  Fri May 18 16:45:03 2001
@@ -33,7 +33,6 @@
devfs_handle_t devfs_handle;
 };
 
-extern int videodev_init(void);
 #define VIDEO_MAJOR81
 extern int video_register_device(struct video_device *, int type);
 
--- linux/drivers/media/video/videodev.c.orgFri May 18 16:18:45 2001
+++ linux/drivers/media/video/videodev.cFri May 18 16:37:44 2001
@@ -575,8 +575,10 @@
 
 static void __exit videodev_exit(void)
 {
+#ifdef MODULE  
 #if defined(CONFIG_PROC_FS) && defined(CONFIG_VIDEO_PROC_FS)
videodev_proc_destroy ();
+#endif
 #endif

devfs_unregister_chrdev(VIDEO_MAJOR, "video_capture");

[OT] IBM offers 6% ThinkPad linux discount on phone

[Tim Moore]

While browsing IBM ThinkPads online I noticed only one high-end
model with linux.  I called 1-888-SHOP-IBMx7000 (phone sales)
to inquire how to get a ThinkPad without Windows given I would
be immediately installing linux.

I was offered 6% off the online price for any Thinkpad which in
my case was $118 US. That sounded about right for a per unit
bundle deal between IBM and MS.

I called from the US and the phone rep was in Canada.

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

[PATCH][RFC]

[Vitaly Luban]

Attached patch is an implementation of "signal-per-fd"
enhancement to kernel RT signal mechanism, AFAIK first
proposed by A. Chandra and D. Mosberger :

http://www.hpl.hp.com/techreports/2000/HPL-2000-174.html

which should dramatically increase linux based network
servers scalability.

Patch is made against 2.4.4 tree.

This patch allows to set signal-per-fd mode per each
file descriptor by introducing new fcntls "F_SETAUXFL"
and "F_GETAUXFL" with one possible argument "O_ONESIGFD"
to F_SETAUXFL defined.

When set, no additional siginfo will be queued for an
RT signal, generated by event on file descriptor, while
there are already one queued, though event report field
in already queued struct siginfo - "si_band" is updated.

I'd also like to hear an opinion on the signal filtering
capability. I.e, it's relatively easy to filter signals
upon an interest mask, supplied by the same F_SETAUXFL in
the form of POLL_... This will bring functionality of RT
signals event notification on the level with 'select' or
'poll' one, while more efficient and scalable. If there's
an interest in such a feature, I'd be eager to publish a
patch.

Thanks,
Vitaly.


 one-sig-perfd-2.4.4.patch.gz

Q: procfs entry.

[Anders Peter Fugmann]

Hi again.

I have a question about the function parsed for reading a procfs entry.

I've used the skeleton from drivers/char/misc.c, and all works 
perfectly, but I see a potential flaw.



static int misc_read_proc(char *buf, char **start, off_t offset,
   int len, int *eof, void *private)
{
.
.
written=0;
 for (p = misc_list.next; p != _list && written < len;
p = p->next) {

 written += sprintf(buf+written, "%3i %s\n",p->minor,
p->name ?: "");
 if (written < offset) {
 offset -= written;
 written = 0;
 }
 }
.
.


As I see it, there is a possibility to write beyond buf+len.
(if len<5)
If so is it ok, or should this be avoided at all cost?

TIA
Anders Fugmann



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

[Daniel Stone]

On Sat, May 19, 2001 at 12:00:28AM +0200, mirabilos wrote:
> netfilter: I _liked_ ipfwadm
> because I hate to always re-learn when a new kernel comes out.

Netfilter is going to stay. Rusty knew from early on in ipchains development
that the whole concept was wrong, but Alan told him to continue on, get it
into 2.2, and then do a new one for 2.4. There's a document detailing this
somewhere, I just can't forget where.

> our company will soon ship a product still using ipfwadm (I
> started with 2.0.33, going to .36 and 2.4.0-testX).
> It's a pity this M$ism to not support it forever (they just
> stopped supporting DOS! and GW-BASIC *snief*)

This is entirely incorrect and FUD. If enable Netfilter, look in the
Netfilter options, disable conntrack and IP tables support, you have
(*gasp!*) ipchains compatability, as well as (*ohmygod!*) ipfwadm
compatability.
 
> -mirabilos
> 
> PS: Don't answer plz as I'll be offline for a time.
> _And_ I mean this honest, even it might considered sp.m

The FUD has to be corrected.

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

Re: Linux 2.4.4-ac10

[Stephen C. Tweedie]

Hi,

On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:

> This is the core of why we cannot (IMHO) have a discussion
> of whether a patch introducing new VM tunables can go in:
> there is no clear overview of exactly what would need to be
> tunable and how it would help.

It's worse than that.  The workload on most typical systems is not
static.  The VM *must* be able to cope with dynamic workloads.  You
might twiddle all the knobs on your system to make your database run
faster, but end up in such a situation that the next time a mail flood
arrives for sendmail, the whole box locks up because the VM can no
longer adapt.

That's the main problem with static parameters.  The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic numbers tend to suck in the VM.)

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

Re: ReiserFS 2.4.4/3.x.0k-pre2

[Hans Reiser]

Samium Gromoff wrote:
> 
>   Hello,
>  I`m still experiencing file tail corruptions
>   on subj.
>  And more: after i had restored bblocked patrition
>   (by relying on drive`s ability to remap bblks on
>   write by wroting small modification of debugreiserfs
>   which zeroified all bblks), i had _runtime_ tail
>corruptions of the mc`s dir hotlist which i tried
>to rewrite again and again.
>   i found, that "sync"ing after modifying helps to keep
>   file fine, so it does until now.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
we would be very eager to receive any testing method that could incurr tail
corruption on a disk drive other than the one that you have that is known
unreliable.


Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wayne . Brown]

On 05/18/2001 at 03:56:50 PM Mike Castle <[EMAIL PROTECTED]> wrote:

>On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
>> 1.  Some of us are perfectly satisfied with the existing tools and don't want
>>   them to be yanked out from under us.
>
>Then stay with 2.4.x
>

Since doing kernel upgrades is my whole reason for using the tools, that's not a
very helpful suggestion.  It's a little like saying, "If you don't like the way
the air smells, just stop breathing."

>> 2.  Some of us have no interest in Python and don't like being forced to deal
>>   with installing/upgrading it just for CML2.
>
>
>Some don't like installing/upgrading the following just for a kernel:
>
>gcc
>binutils
>modutils
>mount
>Not to mention netfilter.

I don't especially like upgrading these things, either, and don't do it unless I
absolutely have to (that's why I'm still on egcs-2.91.66), but the kernel is
important enough to be worth the trouble.  If I have to use CML2 to move into
2.5.x, then I will.  However, upgrading a programming language I don't use, just
so I can replace a perfectly good tool with one I don't want, in order to do a
job that's always been easy to accomplish with the existing tools... well, that
seems a lot like a solution in search of a problem.

Fortunately, Alan's response about someone re-writing CML2 in C offers hope for
at least part of the issue.

Wayne


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

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Mike Galbraith wrote:

> While I'd love to have more control, I can't say I have a clear
> picture of exactly how I'd like those knobs to look.  I always
> start out trying to get it to seek the right behavior.. :) and
> end up fighting so many different fires I get lost in the smoke.

This is the core of why we cannot (IMHO) have a discussion
of whether a patch introducing new VM tunables can go in:
there is no clear overview of exactly what would need to be
tunable and how it would help.

When you and Ingo have something more specific to talk about,
I guess we can decide on that; but deciding on something like
this isn't really possible without at least knowing what should
be tunable ;)

regards,

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

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

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

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

Unresolved symbol compiling a standalone module?

[Torrey Hoffman]

I'm compiling a standalone kernel module outside the kernel tree.  
The compile completes fine, but when I try to insmod it, I get:

unresolved symbol printk_R1b7d4074
unresolved symbol __const_udelay_Reae3dfd6

This is very strange, because a quick grep of some of the regular,
loaded modules, like /lib/modules/2.2.19/net/eepro100.o, shows that 
they contain those exact symbols!  So why are they "unresolved" in
mine?

CONFIG_MODVERSIONS = 1, kernel is 2.2.19 + reiserfs, and I have
checked my standalone module's makefile to ensure that it uses 
_exactly_ the same gcc options as the normal kernel modules.

My /usr/include/linux directory is a symbolic link to 
/usr/src/linux/include, and /usr/src/linux is the kernel I'm running.

What am I doing wrong?  

Torrey Hoffman
[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: java/old_mmap allocation problems...

[Aaron Denney]

On  Fri, 18 May 2001 08:33:05 +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> i'm having problems to convince java (1.3.1) to allocate more
> than 1.9gb of memory on 2.4.2-ac2 (SMP/6gb phys mem) or more
> than 1.1gb on 2.2.18 (SMP/2gb phys mem)...
> 
> modifing /proc/sys/vm parameters didn't help either... the fact
> that i can allocate more memory under 2.4 than under 2.2 lets
> me hope that there is some possible kernel/vm tweaking that
> would increase those limits...

Part of it is the way the kernel set's up the processes VM space.  mmaps
that don't ask for a specific address get mapped starting at 0x4000,
and the stack bottom is at 0xC000 - 1 page, and 0xC000-0x
is reserved for kernel pointers.  This only leaves 2 GB (- mapped in
shared libraries, - stack space) for your mmapping.  Both lowering the
0x4000, and raising the 0xC00 are fairly easy to do though.
(I would suggest 0x100, and 0xE000.  Note that ELF executables
get mapped in around 0x0800, and that shrinking the kernel address
space too much will make it unhappy.)

In include/asm-i386/page.h, change __PAGE_OFFSET, which also changes 
PAGE_OFFSET, and TASK_SIZE 
In include/asm-i386/processor.h 
TASK_UNMAPPED_BASE
In arch/i386/vmlinux.lds, the def'n of _start (or . in recent kernels) should
be changed to __PAGE_OFFSET + 0x10.

Part of it is undoubtedly the Java implementation.  I haven't run across
one that will let me use more than 2 GB, even with the above kernel
tweaks, (or on solaris / UltraSparc).

-- 
Aaron Denney
-><-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Quality Database on Newsforge

[Jeff Garzik]

"Michael D. Crawford" wrote:
> 
> chromatic has written a very nice article on the Linux Quality database
> at Newsforge:
> 
> Linux Quality Database: One man's quest for kernel quality
> http://www.newsforge.com/article.pl?sid=01/05/17/204213=thread
> 
> The site itself is at http://linuxquality.sunsite.dk/
> 
> You will see it is still in the planning stages.  Life has been quite
> hectic these last months, but I am making slow progress and I'm starting
> to get more time now.  I have written a couple of articles you may find
> useful, one on testing the kernel and the other on testing web
> applications.  The kernel testing article is at:
> 
> Using Test Suites to Validate the Linux Kernel
> http://linuxquality.sunsite.dk/articles/testsuites/

You should definitely link to Cerberus (search for it on sourceforge, I
think the project is "vt-ctcs" but not sure), and also RedHat's
stress-kernel rpms.

The stress-kernel rpms are Cerberus++, ie. with extra goodies that
haven't made it to cerberus yet.

-- 
Jeff Garzik  | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft |  step-daughter, but other than that, yes."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CML2 design philosophy heads-up

[Pete Zaitcev]

> > As for the language CML2 is written in, surely C would work just as well as
> > Python if the config-ruleset file is in a known format.  GCC is required
> > for the kernel to build, I don't see why anything else should be required
> > simply to configure it.
> 
> Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
> a configurator which doesn't require something more than gcc is there?

I always do "vi .config", then "make oldconfig", because it is very
convinient, simple, and flexible way to do it. For instance, it is
very easy to store a pile of configs for different kernels, very
easy do diff them (with -u and without).

I do not have Python installed on any of my machines.

The right way to handle the CML2 problem, IMHO, is to have a
C implementation of Python part without curses, tcl, and other crap.
Half of ESR's justification is "dynatic loading of components and
recovery from failure to load them", which goes away if we
do not support extras like curses. Another half was GC, which
is just a convinience for a project of CML's size.

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

Linux Quality Database on Newsforge

[Michael D. Crawford]

chromatic has written a very nice article on the Linux Quality database
at Newsforge:

Linux Quality Database: One man's quest for kernel quality
http://www.newsforge.com/article.pl?sid=01/05/17/204213=thread

The site itself is at http://linuxquality.sunsite.dk/

You will see it is still in the planning stages.  Life has been quite
hectic these last months, but I am making slow progress and I'm starting
to get more time now.  I have written a couple of articles you may find
useful, one on testing the kernel and the other on testing web
applications.  The kernel testing article is at:

Using Test Suites to Validate the Linux Kernel
http://linuxquality.sunsite.dk/articles/testsuites/

Best,

Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

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

CML 1 is ok

[mirabilos]

Sorry, no gpm, so handquoting:
- CML 1 works ok
for me too
- menuconfig is great
it requires ncurses, but _this_ piece of software almost
anyone has. and if not I use make [old]config.
- xconfig
I never tested.

- python
what's that?
- upgrading
gcc - 2.7.2.3 was ok, egcs and 2.9x I dont like.
So I wait for 3.0 (which seems better).

netfilter: I _liked_ ipfwadm
because I hate to always re-learn when a new kernel comes out.
our company will soon ship a product still using ipfwadm (I
started with 2.0.33, going to .36 and 2.4.0-testX).
It's a pity this M$ism to not support it forever (they just
stopped supporting DOS! and GW-BASIC *snief*)

-mirabilos

PS: Don't answer plz as I'll be offline for a time.
_And_ I mean this honest, even it might considered sp.m

-- 
by telnet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Delivery reports about your email [FAILED(1)] (fwd)

[kees]

Hi

I've send them a notice. Sorry for the disturbance, want happen again.

Kees

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] minor crapectomy in drivers/char/misc.c

[Alexander Viro]

% find . -type f -print | xargs grep -nwC1 radio_init  
./drivers/char/misc.c-75-extern int ds1286_init(void);
./drivers/char/misc.c:76:extern int radio_init(void);
./drivers/char/misc.c-77-extern int pmu_device_init(void);
--
./drivers/char/misc.c-265-#ifdef CONFIG_MISC_RADIO
./drivers/char/misc.c:266:  radio_init();
./drivers/char/misc.c-267-#endif
% find . -type f -print | xargs grep -nw CONFIG_MISC_RADIO 
./drivers/char/misc.c:265:#ifdef CONFIG_MISC_RADIO
% 

IOW, radio_init() is never defined and CONFIG_MISC_RADIO is never set.

Proposed fix:
vi -c'/radio_init/d|/CONFIG_MISC_RADIO/|,+2d|x' drivers/char/misc.c

Al

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

Re: [OT] Re: Linux scalability?

[J Sloan]

Peter Rival wrote:

> "David S. Miller" wrote:
>
> > J Sloan writes:
> >  > Microsoft finally managed to get a better result using
> >  > an all-out, "bet the farm", "benchmark buster" setup
> >  > with a special web cache in front of iis.
> >
> > I haven't heard anyone talk about the fact that their 8-cpu numbers
> > got disqualified and aren't even mentioned on the SPEC site on the
> > main tables anymore.
> >
>
> Really?  I just checked and it's still there from what I see.  We're talking
> about the Dell 8450/700 w/ IIS & SWC 3.0 result, right?  I'm hoping that
> they're deemed NC, but I don't see it yet...
>

IIRC they did have some results disqualified, but
them these latest results have been submitted
since then - perhaps they will be disqualified as
well, once the facts come to light...

cu

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/

Re: Delivery reports about your email [FAILED(1)] (fwd)

[Erik Mouw]

On Fri, May 18, 2001 at 06:59:03PM +0200, kees wrote:
> Why?

Because your mail server (ams8uucp0.ams.ops.eu.uu.net) is in ORBS, i.e.
it is an open mail relay, probably used before to relay spam. Read
http://www.orbs.org/ for instructions on how to get removed from ORBS.


Erik

> -- Forwarded message --
> Date: Fri, 18 May 2001 14:50:30 +
> From: The Post Office <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Delivery reports about your email [FAILED(1)]
> 
> This is a collection of reports about email delivery
> process concerning a message you originated.
> 
> Some explanations/translations for these reports
> can be found at:
>   http://www.zmailer.org/reports.html
> 
> FAILED:
>   Original Recipient:
> rfc822;[EMAIL PROTECTED]
>   Control data:
> smtp lxorguk.ukuu.org.uk [EMAIL PROTECTED] 65534
>   Diagnostic texts:
> ...\
> <<- MAIL From:<[EMAIL PROTECTED]> SIZE=10123
> ->> 250 <[EMAIL PROTECTED]> is syntactically correct
> <<- RCPT To:<[EMAIL PROTECTED]>
> ->> 550-Open relay - see http://www.orbs.org/verify.php3?address=212.153.111.69
> ->> 550 mail from 212.153.111.69 rejected: administrative prohibition (host is 
>blacklisted)

-- 
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: FIC AD11(AMD 761/VIA 686B) AGP port not supported [fixed]

[Joseph Carter]

On Sat, May 19, 2001 at 02:31:40AM +0800, Joshua Corbin wrote:
> Ok, so appending agp_try_unsupported at boot gets the agp working (at
> least tolerably).  The problem now appears to be with the DRI part of
> X/Radeon driver, because after adding the line:
> Option "noaccel" "true"
> to my XF86Config, all is well.
> 
> Without it all that shows up on the screen is a bunch of boxes, from
> which you are then forced to C-A-Backspace, and C-A-Del, since the
> terminal is screwed.  So as long as I don't need 3D-accel, I'm once
> again Winblows free.  Thank-you all for the attention :-)

FWIW, I have similar problems with the Radeon 64 VIVO (retail) with my
Abit KT7A.  The DRI people are aware that it's broken but so far it works
for some people and not others, and nobody is exactly sure what the
problem is.  Your best bet is to avoid accelleration for now.

Since you have an AMD chipset, it appears the problem is not limited to
VIA.  That's too bad, I was considering upgrading to an AMD board to get
around this problem (and several others too..)

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

Steal this tagline.  I did.


 PGP signature

Re: Linux scalability?

[Rodger Donaldson]

On Fri, May 18, 2001 at 09:17:11AM +0100, Sean Hunter wrote:

[Discussion of SPECWeb results]

> Why would you want to run a web server with 8 processors rather than four
> webservers with 2 each?

Because you want to win benchmarketing exercises, not demonstrate that your
architecture has any value in the real world whatsoever.  Because you know
that you can induce people with financial approval to make stupid and
irrational decisions based on irrelevant data.

-- 
Rodger Donaldson[EMAIL PROTECTED]
Klingons do *not* make good programmers.  They make good PFWs and abuse
staff, though.  "You have dishonoured our Ascend!  I should kill you
where you stand!"   -- Malcolm Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote:
> 1.  Some of us are perfectly satisfied with the existing tools and don't want
>   them to be yanked out from under us.

Then stay with 2.4.x

> 2.  Some of us have no interest in Python and don't like being forced to deal
>   with installing/upgrading it just for CML2.


Some don't like installing/upgrading the following just for a kernel:

gcc
binutils
modutils
mount
Not to mention netfilter.
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] videodev_init() -> initcall

[Alexander Viro]

Alan, drivers/media/videodev.c is your code. See if you are OK
with the patch below - it switches the thing to use of module_init()
and removes the call of videodev_init() from chr_dev_init(). I.e. the
only ordering change is that videodev_init() is postponed until immediately
before the media/video/* drivers.
Linus, if you are OK with that and Alan will ACK the thing - please,
consider applying it.
Al


diff -urN S5-pre3/drivers/char/mem.c S5-pre3-videodev/drivers/char/mem.c
--- S5-pre3/drivers/char/mem.c  Wed May 16 16:26:36 2001
+++ S5-pre3-videodev/drivers/char/mem.c Fri May 18 16:46:37 2001
@@ -29,9 +29,6 @@
 #ifdef CONFIG_I2C
 extern int i2c_init_all(void);
 #endif
-#ifdef CONFIG_VIDEO_DEV
-extern int videodev_init(void);
-#endif
 #ifdef CONFIG_FB
 extern void fbmem_init(void);
 #endif
@@ -647,9 +644,6 @@
 #endif
 #if defined(CONFIG_ADB)
adbdev_init();
-#endif
-#ifdef CONFIG_VIDEO_DEV
-   videodev_init();
 #endif
return 0;
 }
diff -urN S5-pre3/drivers/media/video/videodev.c 
S5-pre3-videodev/drivers/media/video/videodev.c
--- S5-pre3/drivers/media/video/videodev.c  Sun Apr  1 23:56:57 2001
+++ S5-pre3-videodev/drivers/media/video/videodev.c Fri May 18 16:48:34 2001
@@ -546,7 +546,7 @@
  * Initialise video for linux
  */
  
-int __init videodev_init(void)
+static int __init videodev_init(void)
 {
struct video_init *vfli = video_init_list;

@@ -573,13 +573,7 @@
return 0;
 }
 
-#ifdef MODULE  
-int init_module(void)
-{
-   return videodev_init();
-}
-
-void cleanup_module(void)
+static void __exit videodev_exit(void)
 {
 #if defined(CONFIG_PROC_FS) && defined(CONFIG_VIDEO_PROC_FS)
videodev_proc_destroy ();
@@ -588,7 +582,8 @@
devfs_unregister_chrdev(VIDEO_MAJOR, "video_capture");
 }
 
-#endif
+module_init(videodev_init)
+module_exit(videodev_exit)
 
 EXPORT_SYMBOL(video_register_device);
 EXPORT_SYMBOL(video_unregister_device);

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

Re: ReiserFs: Cosmetic problem in linux/Documentation/Changes[2.4.x]

[Chris Mason]

On Friday, May 18, 2001 01:26:01 PM +0200 "Martin.Knoblauch"
<[EMAIL PROTECTED]> wrote:

> "Martin.Knoblauch" wrote:
>> 
>> Hi,
>> 
>>  I submitted this a short while ago, only to realize later that the
>> subject line was not very informative. Sorry.
>> 
>>  As a suggestion: maybe the reiser-tools should support the common
>> -V/--version flag
>> 

Newer verions (at least 3.x.0j) have a -V.

-chris

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

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Kurt Roeckx]

On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
> > What I'm seeing however in an other program is that select says I
> > can read from the socket, and that read returns 0, with errno set
> > to EGAIN.  I call select() again, with returns and says I can read
> 
> No no no. If the read does not return -1 it does not change errno. EOF isnt
> an error.

Of course, how stupid of me.


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote:
> >But the real question is whether the old tools have enough value to be
> >worth the effort.  What problem are you trying to solve here?
> 
> How about:
> 1.  Some of us are perfectly satisfied with the existing tools and don't want
>   them to be yanked out from under us.

> 2.  Some of us have no interest in Python and don't like being forced to deal
>   with installing/upgrading it just for CML2.

Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case
of bolting alternative ui's onto the parser 

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

Re: Linux 2.4.4-ac10: Oops -> 2.4.4

[Alan Cox]

> Anyway, the bug is in 2.4.4, not in 2.4.4-ac10: I am really sorry for
> having loosing your time. With 2.4.4-ac9 with my fdomain, everything is
> also working great ;-)

Great.

[Crosses another bug off]

Alan

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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> But the real question is whether the old tools have enough value to be
> worth the effort.  What problem are you trying to solve here?

Im just playing with ideas and writing a CML1 parser for amusement while I
ponder single pass computation of the entire dependancy graph from a CML1
rule base 8)

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

Framebuffer drivers and start options

[Otto Wyss]

I've used an ATI RageII card with frame buffer driver atyfb compiled
into the kernel and specified 'append = "video=atyfb:800x600@72"' in
lilo.conf. I've just gotten a second computer with a ATI RagePro128 card
(frame buffer driver aty128fb) and compiled both driver as modules. Now
the 'append...' doesn't work any more with any driver. It seems as if
the kernel parameters don't get propagated to the driver modules. Okay I
specified the options for the modules in modules.conf (i.e. options
atyfb 800x600@72) but it didn't help. Both modules use an resolution of
80x30 (characters), regardless what I specify. Afterwards I can switch
the resolution with fbset 800x660-72. When I use modinfo at both drivers
no options where shown. But when I look into the source it seems both
drivers have these options.

Now how can the kernel switch the resolution (append...) if the drivers
doesn't have these options? I's it true that these options won't get
propagated to the drivers if compiled as modules?

How can I figure out which options where allowed? How does/doesn't
modinfo get this information (i.e. matrox frame buffer)?

Is there another solution to get the modularized drivers working besides
compiling into the kernel?

I'm using kernel 2.4.3 with kernel module loader, etc. on i386.

O. Wyss

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

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Ingo Oeser wrote:

> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> > On Fri, 18 May 2001, Ingo Oeser wrote:
> >
> > > Rik: Would you take patches for such a tradeoff sysctl?
> >
> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point out that
> > up to now nobody has described exactly WHAT tradeoff
> > they'd like to make tunable and why...
>
> Amount of pages reclaimed from swapout_mm() versus amount of
> pages reclaimed from caches.

I don't know if this'll make sense, but I think this has to
be a ~fuzzy suggestion to the kernel.  There are so many
variables that you can't predict what the kernel will run
into.  For example, with my favorite test, sometimes tasks
do something nasty, like all deciding to do the same things
at once and thereby jerking a _knot_ in the vm's tail.

-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 2.4.5.3 (try 2): quota initcall

[Jeff Garzik]

Doh!  I should really turn on that quota compile options... 

Much better patch attached.

-- 
Jeff Garzik  | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft |  step-daughter, but other than that, yes."

Index: linux_2_4/fs/dquot.c
diff -u linux_2_4/fs/dquot.c:1.1.1.50 linux_2_4/fs/dquot.c:1.1.1.50.4.2
--- linux_2_4/fs/dquot.c:1.1.1.50   Tue May 15 04:36:48 2001
+++ linux_2_4/fs/dquot.cFri May 18 13:18:36 2001
@@ -1343,13 +1343,12 @@
 }
 
 
-void __init dquot_init_hash(void)
+static int __init dquot_init(void)
 {
printk(KERN_NOTICE "VFS: Diskquotas version %s initialized\n", 
__DQUOT_VERSION__);
-
-   memset(dquot_hash, 0, sizeof(dquot_hash));
-   memset((caddr_t), 0, sizeof(dqstats));
+   return 0;
 }
+__initcall(dquot_init);
 
 /*
  * Definitions of diskquota operations.
Index: linux_2_4/init/main.c
diff -u linux_2_4/init/main.c:1.1.1.62 linux_2_4/init/main.c:1.1.1.62.4.2
--- linux_2_4/init/main.c:1.1.1.62  Tue May 15 04:37:56 2001
+++ linux_2_4/init/main.c   Fri May 18 13:18:36 2001
@@ -108,9 +108,6 @@
 #if defined(CONFIG_SYSVIPC)
 extern void ipc_init(void);
 #endif
-#if defined(CONFIG_QUOTA)
-extern void dquot_init_hash(void);
-#endif
 
 /*
  * Boot command-line arguments
@@ -579,9 +576,6 @@
 #endif
 #if defined(CONFIG_SYSVIPC)
ipc_init();
-#endif
-#if defined(CONFIG_QUOTA)
-   dquot_init_hash();
 #endif
check_bugs();
printk("POSIX conformance testing by UNIFIX\n");

Announcing Journaled File System (JFS) release 0.3.2 available

[Steve Best]

Release 0.3.2 of JFS was made available today.

Drop 32 on May 18, 2001 (jfs-0.3.2-patch.tar.gz) includes fixes to the
file system and utilities.

Function and Fixes in release 0.3.2

- Remove the warning message from fsck when partition is mounted read-only
- Fix for assert(mp->count) jfs_metapage.c 675! report as hardlink problem
  in drop 31 (dtDeleteUp was discarding the wrong metapage_t.)
- Fix seg fault problem while creating hard links.
- Fixed dbench hang, do to transaction locks not being freed.
- Added support to correctly handle read-only and remounting the file
system.

For more details about the problems fixed, please see the README.

Steve
JFS for Linux http://oss.software.ibm.com/developerworks/opensource/jfs

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

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Ingo Oeser wrote:
> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:

> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point out that
> > up to now nobody has described exactly WHAT tradeoff
> > they'd like to make tunable and why...
>
> Amount of pages reclaimed from swapout_mm() versus amount of
> pages reclaimed from caches.
>
> A value that says: "use XX% of my main memory for RSS of
> processes, even if I run heavy disk loadf now" would be nice.
>
> For general purpose machines, where I run several services but
> also play games, this would allow both to survive.
>
> The external services would go slower. Who cares, if some CVS
> updates or NFS services go slower, if I can play my favorite game
> at full speed? ;-)

Remember that the executable and data of that game reside
in the filesystem cache. This "double counting" makes it
quite a bit harder to actually implement what seems like
a simple tradeoff.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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/

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

Re: [OT] Re: Linux scalability?

[Peter Rival]

"David S. Miller" wrote:

> Peter Rival writes:
>  > Really?  I just checked and it's still there from what I see.  We're talking
>  > about the Dell 8450/700 w/ IIS & SWC 3.0 result, right?  I'm hoping that
>  > they're deemed NC, but I don't see it yet...
>
> Sorry, they are there in the table, but marked as NC.
>
> Maybe you need to hit reload in your browser :-)
>

Yup, one of them is marked as NC.  But the other one is still there (and I hit
reload and even shift-reload).  So either you're missing the second one or
something is not behaving nicely with our web proxies here.  While I'd probably be
more inclined to believe the latter... ;)

 - Pete

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

Re: [Panic] skb problems in 2.4.5-pre3 (repeatable)

[Matti Aarnio]

On Fri, May 18, 2001 at 01:02:08PM -0700, David S. Miller wrote:
> Tomlinson, Edward writes:
>  > This does not seem to be making it to the from my sympatico account...
>  > Is lkml blocking sympatico.ca? 
> 
> Not that I know of, Matti?

   Not at the MTA level.  If the message appears to go inside,
   but does not make it to the list, it is possibly rejected
   by the Majordomo taboo-filter.

 http://vger.kernel.org/majordomo-info.html

   in which case it probably (I don't know the beast that well)
   goes to list owner, who already gets lots of junk...

> (btw, [EMAIL PROTECTED] is much better place to send issues
>  like this).
> 
> Later,
> David S. Miller
> [EMAIL PROTECTED]

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

00_rwsem-11, 2.4.4-ac11 and gcc-3(2001-05-14)

[mirabilos]

Andrea,
I applied rwsem-11 (a bit by hand) to -ac11 and tried to
compile. By changing CFLAGS_sys.o to -O (instead of -O2)
as I read earlier I nearly could compile, it only barfed
when it came to assemble the xaddl procedure by itself:

static inline long rwsem_xchgadd(long value, long * count)
{
__asm__ __volatile__(LOCK "xaddl %0,%1"
 : "+r" (value), "+m" (*count));
return value;
}

changing from "inline" to "" yields a kernel which stops just
before mounting root (sysrq still works, but nothing else).
I now try again with GENERIC, and it actually is compiling...
lets look whether it works.
I hope a non-generic will solve the sound freeze :)

-mirabilos
-- 
by telnet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Panic] skb problems in 2.4.5-pre3 (repeatable)

[David S. Miller]

Tomlinson, Edward writes:
 > This does not seem to be making it to the from my sympatico account...  Is 
 > lkml blocking sympatico.ca? 

Not that I know of, Matti?

(btw, [EMAIL PROTECTED] is much better place to send issues
 like this).

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

Re: Q: missing or broken mmap().

[Alan Cox]

> I'm wondering what it may mean - something to be implemented in linux,
> of poorly configured system:

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

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Rik van Riel wrote:

> On Fri, 18 May 2001, Ingo Oeser wrote:
>
> > Rik: Would you take patches for such a tradeoff sysctl?
>
> "such a tradeoff" ?
>
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT tradeoff
> they'd like to make tunable and why...

While I'd love to have more control, I can't say I have a clear
picture of exactly how I'd like those knobs to look.  I always
start out trying to get it to seek the right behavior.. :) and
end up fighting so many different fires I get lost in the smoke.

-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: Kernel bug with UNIX sockets not detecting other end gone?

[Alan Cox]

> What I'm seeing however in an other program is that select says I
> can read from the socket, and that read returns 0, with errno set
> to EGAIN.  I call select() again, with returns and says I can read

No no no. If the read does not return -1 it does not change errno. EOF isnt
an error.


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

[Jeff Garzik]

IMHO this is an obvious change, but it is untested...  dquot_hash and
dqstats are correctly declared static and in BSS, and thus are
automatically cleared at kernel startup.

Since quota init now just printk's a startup message, we can safely make
it an initcall.

-- 
Jeff Garzik  | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft |  step-daughter, but other than that, yes."

Index: linux_2_4/fs/dquot.c
diff -u linux_2_4/fs/dquot.c:1.1.1.50 linux_2_4/fs/dquot.c:1.1.1.50.4.1
--- linux_2_4/fs/dquot.c:1.1.1.50   Tue May 15 04:36:48 2001
+++ linux_2_4/fs/dquot.cFri May 18 12:55:25 2001
@@ -1343,13 +1343,11 @@
 }
 
 
-void __init dquot_init_hash(void)
+static int __init dquot_init(void)
 {
printk(KERN_NOTICE "VFS: Diskquotas version %s initialized\n", 
__DQUOT_VERSION__);
-
-   memset(dquot_hash, 0, sizeof(dquot_hash));
-   memset((caddr_t), 0, sizeof(dqstats));
 }
+__initcall(dquot_init);
 
 /*
  * Definitions of diskquota operations.
Index: linux_2_4/init/main.c
diff -u linux_2_4/init/main.c:1.1.1.62 linux_2_4/init/main.c:1.1.1.62.4.1
--- linux_2_4/init/main.c:1.1.1.62  Tue May 15 04:37:56 2001
+++ linux_2_4/init/main.c   Fri May 18 12:55:25 2001
@@ -108,9 +108,6 @@
 #if defined(CONFIG_SYSVIPC)
 extern void ipc_init(void);
 #endif
-#if defined(CONFIG_QUOTA)
-extern void dquot_init_hash(void);
-#endif
 
 /*
  * Boot command-line arguments

Re: Linux 2.4.4-ac10: Oops -> 2.4.4

[FAVRE Gregoire]

Thus spake Alan Cox ([EMAIL PROTECTED]):

> Can you boot a kernel without fdomain.c compiled in next

Yes, but I am too stupid: there were a faillure in my
patch-2.4.4-ac10.bz2, which is 0 bits so I have bunzip -c
patch-2.4.4-ac10.bz2|patch -p1 -s with an empty file :-((

That mean I compiled a 2.4.4 kernel, and not a 2.4.4-ac10 one.

I know that becauseause I reemoved my fdomain SCSI controller and put an
Adaptec 2940 at the same place, and it booted very well...

So the problem is ME: I am too stupid!!!

Anyway, the bug is in 2.4.4, not in 2.4.4-ac10: I am really sorry for
having loosing your time. With 2.4.4-ac9 with my fdomain, everything is
also working great ;-)

If I can do anything, just let me know ;-)

Thanks you very much,

Greg

http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]

 PGP signature

Re: CML2 design philosophy heads-up

[Alan Cox]

> Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
> a configurator which doesn't require something more than gcc is there?

Configure only requires shell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 blockdevice buffers

[Eduard Hasenleithner]

On Fri, May 18, 2001 at 09:25:31PM +0200, Jens Axboe wrote:
> On Fri, May 18 2001, Eduard Hasenleithner wrote:
> > I have a problem with the buffering mechanism of my blockdevice,
> > namely a ide_scsi DVD-ROM drive. After inserting a DVD and reading
> > data linearly from the DVD, an excessive amount of buffer memory gets
> > allocated.
> > 
> > This can easily be reproduced with
> > cat /dev/sr0 > /dev/null
> > 
> > Remember, nearly the same task is carried out when playing a DVD.
> > 
> > As a result the system performance goes down. I'm still able to use
> > my applications, but es every single piece of unused memory is swapped
> > out, and swapping in costs a certain amount of time.
> 
> That's why streaming media applications like a dvd player should use raw
> I/O -- to bypass system cache. See /dev/raw*
> 

Oh, thank you. That was very fast!

I use xine. To be honest, the procedure of how to create a raw device
is described in their FAQ. But it is not described, what the raw device
does, only that it provides a speed improvement.

Until today, I didn't know what rawio actually does. Strange that I didn't
come across on some information about it.

Was there a official announcement of the availability of this feature?
Is some more detailled information about the rawio existing?

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

Re: [OT] Re: Linux scalability?

[David S. Miller]

Peter Rival writes:
 > Really?  I just checked and it's still there from what I see.  We're talking
 > about the Dell 8450/700 w/ IIS & SWC 3.0 result, right?  I'm hoping that
 > they're deemed NC, but I don't see it yet...

Sorry, they are there in the table, but marked as NC.

Maybe you need to hit reload in your browser :-)

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

Re: [OT] Re: Linux scalability?

[Peter Rival]

"David S. Miller" wrote:

> J Sloan writes:
>  > Microsoft finally managed to get a better result using
>  > an all-out, "bet the farm", "benchmark buster" setup
>  > with a special web cache in front of iis.
>
> I haven't heard anyone talk about the fact that their 8-cpu numbers
> got disqualified and aren't even mentioned on the SPEC site on the
> main tables anymore.
>

Really?  I just checked and it's still there from what I see.  We're talking
about the Dell 8450/700 w/ IIS & SWC 3.0 result, right?  I'm hoping that
they're deemed NC, but I don't see it yet...

 - Pete

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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <[EMAIL PROTECTED]>:
> Being able to turn CML2 into CML1 might be the more useful exercise.

That's...not a completely crazy idea.  Hmmm...

It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it.  The resulting config.in would be huge
and nasty, and would only work in forward sequence with no side-effect
computation, but you just might be able to get the old tools to parse it.

Again there's a technical problem with derivations.   Probably solvable.

But the real question is whether the old tools have enough value to be
worth the effort.  What problem are you trying to solve here?
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

This would be the best of all possible worlds, if there were
no religion in it.
-- John Adams, in a letter to Thomas Jefferson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: DMA support for toshiba IDE controllers

[Bruce Harada]

On Fri, 18 May 2001 11:15:09 -0700 (PDT)
Alex Deucher <[EMAIL PROTECTED]> wrote:

> Does anyone know if there is any DMA support for the
> toshiba IDE controller's in many of their portable
> models such as the older porteges and librettos?  The
> controllers support DMA, but not in linux.  I'm not
> sure what toshiba's policy is on documentation.  They
> used to be pretty stingy, but I heard they have
> recently opened up of lot of their doc's, like the
> oboe IR controller for instance. 


Well, Toshiba Japan has a Linux developers' page (in Japanese):

http://linux.toshiba-dme.co.jp/linux/jpn/develop.php3

According to that page, their mail address for requests from developers is:

[EMAIL PROTECTED]

so if you don't get any satisfaction from Toshiba USA/Europe/wherever you're
living, try asking Toshiba Japan (they do ask that you be specific, so if you
send them a request, make sure to state exactly which models/chipsets, etc.,
you're interested in, and remember that they might take a while to reply to
email in English). They do seem to be quite good lately about releasing
documentation - Dag Brattli got some info on the IrDA hardware they use, and
the Japan Linux Association has got docs for the ToPIC PC Card controller out
of them, too. The only time they've actually turned someone down (according to
that page, anyway) is when the hardware in question included third-party
technology.


Bruce


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

Re: [OT] Re: Linux scalability?

[David S. Miller]

J Sloan writes:
 > Microsoft finally managed to get a better result using
 > an all-out, "bet the farm", "benchmark buster" setup
 > with a special web cache in front of iis.

I haven't heard anyone talk about the fact that their 8-cpu numbers
got disqualified and aren't even mentioned on the SPEC site on the
main tables anymore.

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

Re: DVD blockdevice buffers

[Jens Axboe]

On Fri, May 18 2001, Eduard Hasenleithner wrote:
> I have a problem with the buffering mechanism of my blockdevice,
> namely a ide_scsi DVD-ROM drive. After inserting a DVD and reading
> data linearly from the DVD, an excessive amount of buffer memory gets
> allocated.
> 
> This can easily be reproduced with
>   cat /dev/sr0 > /dev/null
> 
> Remember, nearly the same task is carried out when playing a DVD.
> 
> As a result the system performance goes down. I'm still able to use
> my applications, but es every single piece of unused memory is swapped
> out, and swapping in costs a certain amount of time.

That's why streaming media applications like a dvd player should use raw
I/O -- to bypass system cache. See /dev/raw*

-- 
Jens Axboe

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

[OT] Re: Linux scalability?

[J Sloan]

Ronald Bultje wrote:

> On 18 May 2001 10:12:34 +0200, reiser.angus wrote:
> > > However, taking a closer look, it turns out, that the above statement
> > > holds true only for 1 and 2 processor machines. Scalability already
> > > suffers at 4 processors, and at 8 processors, TUX 2.0 (7500) gets beaten
> > > by IIS 5.0 (8001), and these were measured on the same kind of box!
> > not really the same box
> > look at the disk subsystem
> > 7 x 9GB 10KRPM Drives and 1 x 18GB 15KRPM (html+log & os) for Win2000
> > 5 x 9GB 10KRPM Drives (html+log+os) for TUX 2.0
> >
> > this is sufficient for a such difference
>
> I read an article about TUX in the dutch C'T a few months ago (nov/dec
> 2000, I think) - the real difference (according to the article) was the
> 2.2.x kernel used in TUX. Look at the stats of the website, they used
> Redhat 7.0 as base, with kernel 2.2.16. In the C'T, they also used a
> 2.4-test kernel for TUX, and this one didn't have these "scalibility
> problems". The problem seemed to be SMP problems with systems with more
> than two cpus in the 2.2.x-based kernel series. 2.4.x kernels didn't
> seem to have this problem.

All Tux webservers have run on a 2.4 or 2.4-pre kernel.

> And as far as I know, TUX with 2.4.x kernel was faster than win2k on all
> SMP-combinations.

Tux held the record for most of the time since last
summer, when Linux vaulted into 1st place

Microsoft finally managed to get a better result using
an all-out, "bet the farm", "benchmark buster" setup
with a special web cache in front of iis.

However, they haven't heard the last of Linux either.

cu

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/

2.4.x: Bogus ARP packets containing NFS file data

[Frank van Maarseveen]

To recap:

The machine is an NFSv3 client. The header of outgoing NFS UDP/IP packets
is sometimes corrupted, such that network sniffers on unrelated systems
report bogus ARP packets. AFAIK there is no data corruption on the
file level because the request is no longer recognized by the NFS
server. The symptom is also recorded in /var/log/messages on the client:

May 18 20:24:21 espoo kernel: nfs: server xxx not responding, still trying 
May 18 20:24:21 espoo kernel: nfs: server xxx OK 

In userland a short stall is experienced by the program which caused the
NFS traffic.

At most the first 196 bytes of a packet are corrupted (maybe some link
layer header must be added -- I'm not sure). In one incident the file
data of what was most likely an NFSv3 WRITE request was not altered but
a lot of the packaging was (not investigated any further but see earlier
mails). The bogus ARP packet contained the first 1304 bytes of a VIM swap
file just made by VIM, completely intact including the magic header "b0VIM".

A sniffer on the system itself is able to see the modified outgoing packets.

This problem is present in at least the following kernels:

2.4.0
2.4.2
2.4.4
2.4.5-pre1
2.4.5-pre2

This kernel configuration makes the difference:

no problem  problem
---
CONFIG_X86=yCONFIG_X86=y
CONFIG_ISA=yCONFIG_ISA=y
CONFIG_UID16=y  CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y   CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=yCONFIG_MODULES=y
CONFIG_M586TSC=yCONFIG_M586TSC=y
CONFIG_X86_WP_WORKS_OK=yCONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=yCONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y  CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y   CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y   CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=yCONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y  CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y   CONFIG_MTRR=y
CONFIG_NET=yCONFIG_NET=y
CONFIG_PCI=yCONFIG_PCI=y
CONFIG_PCI_GOANY=y  CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y   CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y  CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=yCONFIG_HOTPLUG=y
CONFIG_SYSVIPC=yCONFIG_SYSVIPC=y
CONFIG_SYSCTL=y CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y  CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=yCONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=yCONFIG_BINFMT_MISC=y
CONFIG_PM=y CONFIG_PM=y
CONFIG_ACPI=y   CONFIG_ACPI=y
CONFIG_PNP=yCONFIG_PNP=y
CONFIG_ISAPNP=y CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y   CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=yCONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=409 CONFIG_BLK_DEV_RAM_SIZE=409
CONFIG_BLK_DEV_INITRD=y CONFIG_BLK_DEV_INITRD=y
CONFIG_MD=y CONFIG_MD=y
CONFIG_BLK_DEV_LVM=yCONFIG_BLK_DEV_LVM=y
CONFIG_LVM_PROC_FS=yCONFIG_LVM_PROC_FS=y
CONFIG_PACKET=y CONFIG_PACKET=y
CONFIG_NETLINK=yCONFIG_NETLINK=y
CONFIG_RTNETLINK=y  CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=yCONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y  CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=yCONFIG_NETFILTER_DEBUG=y
CONFIG_FILTER=y CONFIG_FILTER=y
CONFIG_UNIX=y   CONFIG_UNIX=y
CONFIG_INET=y   CONFIG_INET=y
CONFIG_IP_MULTICAST=y   CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y  CONFIG_RTNETLINK=y
CONFIG_NETLINK=yCONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=yCONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y   CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y   CONFIG_IP_ROUTE_VERBOSE=y
 >  CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y  CONFIG_IP_NF_MATCH_LIMIT=y
 >  CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_FILTER=y   CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT= CONFIG_IP_NF_TARGET_REJECT=
 >  CONFIG_IP_NF_NAT=y
 >  CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_LOG=y   CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IDE=yCONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y  

DVD blockdevice buffers

[Eduard Hasenleithner]

I have a problem with the buffering mechanism of my blockdevice,
namely a ide_scsi DVD-ROM drive. After inserting a DVD and reading
data linearly from the DVD, an excessive amount of buffer memory gets
allocated.

This can easily be reproduced with
cat /dev/sr0 > /dev/null

Remember, nearly the same task is carried out when playing a DVD.

As a result the system performance goes down. I'm still able to use
my applications, but es every single piece of unused memory is swapped
out, and swapping in costs a certain amount of time.

So, what wents wrong? I tried to find some information on this with
google and geocrawler, but i didn't have a success :(

Kernel: linux-2.4.4

hoping for some tips ...

-- 
Eduard Hasenleithner
student of
Salzburg University of Applied Sciences and Technologies
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: DMA support for toshiba IDE controllers

[Alex Deucher]

Just to clarify, this is a custom Toshiba chipset.  It
includes IDE, PCI controller, etc.  I believe the IDE
controller may be on the ISA bus as it does not show
up with lspci, etc. I'm not sure of the exact chip,
perhaps someone with a better knowledge of toshiab
products does.

Thanks,

Alex


> Does anyone know if there is any DMA support for the
> toshiba IDE controller's in many of their portable
> models such as the older porteges and librettos? 
The
> controllers support DMA, but not in linux.  I'm not
> sure what toshiba's policy is on documentation. 
They
> used to be pretty stingy, but I heard they have
> recently opened up of lot of their doc's, like the
> oboe IR controller for instance. 
> 
> Thanks,
> 
> Alex
> 

__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.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: APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

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

 JAM> That is not the problem. The problem is that the registers have
 JAM> to lay in a defined way, transcribed to a C struct, and that
 JAM> pgcc lays badly that struct.

 WJP> Yes, I understand that.  I was showing a way to find the value
 WJP> of padding needed to align the register store in the structure.
 WJP> Perhaps I should have shown a mod to asm/processor.h,
[snip]
 WJP> I was describing a way to make things independent of the
 WJP> compiler layout of the structs.  However, this complicates the
 WJP> build process, and people might not like the padding due to
 WJP> cache alignment details.

Sorry,  they would obviously declare it as such if the kernel developers
wanted to.

/* floating point info */
unsigned char fpAlign[0] __attribute__ ((aligned (16)));
union i387_unioni387;

This is a much simpler way of achieving what I was trying to explain
previously.  I think that this syntax has been in the GCC extensions
for some time.

regards,
Bill Pringlemeir.


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

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> For CML1 and CML2 to handle the same language, we would either have
> to live with the CML1 language's limitations or retrofit the old tools
> to speak CML2 language.  The chance of the latter happening is, I think
> we can agree, effectively zero.

Being able to turn CML2 into CML1 might be the more useful exercise.

Alan

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

Re: CML2 design philosophy heads-up

[frank]

On Fri, 18 May 2001, Eric S. Raymond wrote:

> Tom Rini <[EMAIL PROTECTED]>:
> > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
> > > > layer code but no SCSI hardware drivers.  It is a realistic case for an
> > > > embedded CD-RW appliance.
> > > 
> > > Or alternatively, you want to enable SCSI code, with no hardware driver,
> > > because you are going to build pcmcia, which builds the scsi drivers only
> > > if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or
> > > 1480 scsi card into your pcmcia slot.
> > 
> > Both of these 'problems' assume that you can have IDE or PCMCIA on these
> > particular boxes.  Does anyone know if that's actually true?
> 
> The answer is: no, you can't.  
> 
> I found a feature list for the MVME147 on the web at
> .  It
> confirmed what thought I remembered from the Motorola site; no PCMCIA,
> no IDE/ATAPI.  As a matter of fact neither of these technologies
> existed yet when the board was being designed in the mid-1980s.

But it is a VME board. That means you can put a SCSI controller on the VME
bus (and these do exist, I have one right here). 

Frank

> 
> (The article I found is kind of interesting.  It's a dissection of the
> MVME147's design and history...narrated in first person.)
> 
> In any case, if this *had* been a problem, the right fix IMO would have
> been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have
> constraints that would make SCSI and the presence of any SCSI card 
> imply SCSI_DRIVERS.
> -- 
>   http://www.tuxedo.org/~esr/;>Eric S. Raymond
> 
> The prestige of government has undoubtedly been lowered considerably
> by the Prohibition law. For nothing is more destructive of respect for
> the government and the law of the land than passing laws which cannot
> be enforced. It is an open secret that the dangerous increase of crime
> in this country is closely connected with this.
>   -- Albert Einstein, "My First Impression of the U.S.A.", 1921
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

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

Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> On Fri, 18 May 2001, Ingo Oeser wrote:
> 
> > Rik: Would you take patches for such a tradeoff sysctl?
> 
> "such a tradeoff" ?
> 
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT tradeoff
> they'd like to make tunable and why...

Amount of pages reclaimed from swapout_mm() versus amount of
pages reclaimed from caches.

A value that says: "use XX% of my main memory for RSS of
processes, even if I run heavy disk loadf now" would be nice.

For general purpose machines, where I run several services but
also play games, this would allow both to survive.

The external services would go slower. Who cares, if some CVS
updates or NFS services go slower, if I can play my favorite game
at full speed? ;-)

> I'm not against making things tunable, but I would like
> to at least see the proponents of tunable things explain
> WHAT they want tunable and exactly WHY.

Ideally: Every value that the kernel decides by heuristics,
   because heuristics can fail to get even close to an optimal
   result. 

But this is too much. Some tunables from refill_inactive would be
nice. Also the patch for honouring the soft rss limit is good (is
it in?).

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 8139too on 2.2.19 doesn't close file descriptors

[Jens David]

Hi,

On Thursday 17 May 2001 23:04, you wrote:
> Hi!
>
> I was tracking down a problem with Debian installation freezing when doing
> the ifconfig of the 8139too driver on 2.2.19 kernel, and found that this
> was caused by 8139too for 2.2.19 not closing it's file descriptors.
>
> The original code by Jeff for the 2.4 series is ok, and searching for the
> cause of the problem I have found a difference in the way rtl8139_thread
> exits on both versions:
>
> 2.2 version:
> up (>thr_exited);
> return 0;
>
> 2.4 version:
> up_and_exit (>thr_exited, 0);
>
> I think the problem must be there, not doing the do_exit on the 2.2
> version, but I may be wrong, can anybody look this up?

I added the exit_files(current) to the version in my source repository. Will 
be contained in the next releases. Thanks!
Btw.: CC'ing me was a good idea, I'm not on linux-kernel, only on linux-net
due to mail volume.

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

[announce] Linux 2.4 x86 init.

[rddunlap]

Hi,

I've documented x86/i386/IA-32 Linux kernel init
(after loaders).  It's fairly large, so there may be
too much detail here and I may cut back on it some if
that seems to be needed.

Comments, feedback, corrections, and additions are
welcome.  As I say in the intro, hopefully some of you
(or us) will find this useful/helpful.

It's viewable at
http://rddunlap.home.att.net/linit/lin240_init_x86.html

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

Re: APIC, AMD-K6/2 -mcpu=586...

[Bill Pringlemeir]

 On 05.18 Bill Pringlemeir wrote:

 >> Why don't the build scripts run a dummy file to determine where
 >> the floating point registers should be placed?
 >> 
 >> ...  const int value = offsetof(struct task_struct,
 >> thread.i387.fxsave) & 15; ...

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

 JAM> That is not the problem. The problem is that the registers have
 JAM> to lay in a defined way, transcribed to a C struct, and that
 JAM> pgcc lays badly that struct.

Yes, I understand that.  I was showing a way to find the value of padding
needed to align the register store in the structure.  Perhaps I should have
shown a mod to asm/processor.h,

...
/* floating point info */
#if PAD_SIZE  /* not needed if gcc accepts zero size arrays? */
unsigned char fpAlign[PAD_SIZE];
#endif
union i387_unioni387;
...

Before compiling the `real source', the dummy file would be compiled
with PAD_SIZE set to zero.  Then objdump (or some other tool) can find
out what the value is.  Then when the task_struct is compiled in the
kernel, PAD_SIZE is set to the appropriate value to align the
structure.

I was describing a way to make things independent of the compiler layout
of the structs.  However, this complicates the build process, and people
might not like the padding due to cache alignment details.

I am pretty sure what I am saying works... It might not be right though.

regards,
Bill Pringlemeir.


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

Re: problem: reading from (rivafb) framebuffer is really slow

[James Simmons]

> When benchmarking DirectFB, I found that a typical software alpha
> blending rectangle fill is completely dominated (I'm talking 90% of the
> CPU cycles here) by the time it takes to read pixels from the
> framebuffer.

Note the SOFTWARE alpha blending rectangle fill. You are passing alot of
data over the bus. So slow. If you implement a accelerated
function you will not have 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: java/old_mmap allocation problems...

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

>i'm having problems to convince java (1.3.1) to allocate more
>than 1.9gb of memory on 2.4.2-ac2 (SMP/6gb phys mem) or more
>than 1.1gb on 2.2.18 (SMP/2gb phys mem)...

Take a look at a thread from January starting at this point:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.1/0407.html

Basically the constraint you see is due to how Linux sets up the 4GB
address space on 32-bit i386 hardware.  If you need more than 1.9GB on
2.4.x, it's not too hard to change a couple constants in the kernel to
allow somewhat more.  Feel free to email me for more details if it is
not clear after reading the above thread.

Cheers, Wayne

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

[James Simmons]

> > They might also be exactly the same channel, except with certain magic
> > bits set. The example peter gave was fine: tty devices could very usefully
> > be opened with something like
> > 
> > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > 
> > where we actually open up exactly the same channel as if we opened up
> > /dev/cua00, we just set the speed etc at the same time. Which makes things
> 
> Hmm, there might be problem with this. How do you change speed without
> reopening device? [Remember: your mice knows when you close device]

If you implement it as a filesystem you coould have a settings file in the
tty filesystem. Something like this:

echo "115200" >  /dev/tty/settings


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

Re: APIC, AMD-K6/2 -mcpu=586...

[J . A . Magallon]

On 05.18 Bill Pringlemeir wrote:
> 
> Why don't the build scripts run a dummy file to determine where the 
> floating point registers should be placed?
> 
> ...
> const int value = offsetof(struct task_struct, thread.i387.fxsave) & 15;
> ...
> 

That is not the problem. The problem is that the registers have to lay
in a defined way, transcribed to a C struct, and that pgcc lays badly that
struct.

-- 
J.A. Magallon   #  Let the source be with you...
mailto:[EMAIL PROTECTED]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686

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

Re: FIC AD11(AMD 761/VIA 686B) AGP port not supported [fixed]

[Joshua Corbin]

Ok, so appending agp_try_unsupported at boot gets the agp working (at least 
tolerably).  The problem now appears to be with the DRI part of X/Radeon driver, 
because after adding the line:
Option "noaccel" "true"
to my XF86Config, all is well.

Without it all that shows up on the screen is a bunch of boxes, from which you are 
then forced to C-A-Backspace, and C-A-Del, since the terminal is screwed.  So as long 
as I don't need 3D-accel, I'm once again Winblows free.  Thank-you all for the 
attention :-)

Josh

-- 

Get your free email from www.linuxmail.org 


Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

Christoph Hellwig wrote:


> That's ok as long as she doesn't add backstreet boys songtexts as long as your
> signature to her mails.


In fact, they aren't so long once you cut out the repetitions.

 
> On the other hand she should _really_ learn how to do it - like we all did.


Hey, nothing stops you from buying a used front panel and toggling in
Linux in octal.  Oughta work the first time, too.

 

-- 
There is / one art || John Cowan <[EMAIL PROTECTED]>
no more / no less  || http://www.reutershealth.com
to do / all things || http://www.ccil.org/~cowan
with art- / lessness   \\ -- Piet Hein

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

[Mark H. Wood]

On Wed, 16 May 2001 [EMAIL PROTECTED] wrote:
> > The same situation appears when using bonding.o. For several years,
> > Don Becker's (and derived) network drivers support changing MAC address
> > when the interface is down. So Al's /dev/eth//MAC has different
> values
> > depending on whether bonding is active or not. Should /dev/eth//MAC
> > always have the original value (to be able to uniquely identify this
> card)
> > or the in-use value (used by ARP, I believe) ? Or maybe have a
> > /dev/eth//MAC_in_use ?
>
> Token ring has the same problem as well, most token ring adapters support
> setting a LAA.

Ethernet cards have both a fixed "hardware" address and the mutable
"physical" address.  How about TR?  And how many cards give you no access
to the hardware address?

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Make a good day.

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

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Ingo Oeser wrote:

> Rik: Would you take patches for such a tradeoff sysctl?

"such a tradeoff" ?

While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make tunable and why...

I'm not against making things tunable, but I would like
to at least see the proponents of tunable things explain
WHAT they want tunable and exactly WHY.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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/

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

Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Fri, May 18, 2001 at 07:45:15PM +0200, Mike Galbraith wrote:
> Yes, ~exactly!  I chose 30 tasks because they almost do (tool/userland
> dependant.. must recalibrate often) fit.  The bitch is to get the vm
> to automagically detect the rss/cache munch tradeoff point without all
> the manual help.

What about a sysctl for that? Choose decent steps and let 0
(which is an insane value) mean "let's kernel decide" and make
this default.

In the past we could do this by adjusting some watermarks in
/proc/sys/vm but now, we can't do anything but trust the genius
kernel developers.

I doubt that we can test all kinds of workload and even imagine
what pervert stuff some people do with their machines.

Tuning _is_ manual work. Always has been and always will be.

This countinously "I know it better then you" is what I hated
about Windows and now this comes more and more into Linux :-(

Rik: Would you take patches for such a tradeoff sysctl?

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

FW: About swapper_page_dir and processes' page directory

[Hua Ji]

 
Folks,

Get a question today. Thanks in advance.

As we know, vmalloc and other memory allocation/de-allocation will
change/update
the swapper_page_dir maintain by the kernel. 

I am wondering when/how the kernel synchronzie the change to user level
processes' page
directory entries from the 768th to the 1023th.

Those entries get copied from swapper_page_dir when a user process get
forked/created. Does the kernel
frequently update this information every time when the swapper_page_dir get
changed?

Regards,

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/

Oops

[Andreas Bergen]

Hi, this is an oops-file I "created" today.

Attached is the original version as found in /var/log/messages as well
as the ksymoops-ed version.

Hope, it helps. If you need further info, don't hesitate to contact me.

My machine is a Cyrix 6x68 166+; 96 MB RAM.

Yours
  Andreas Bergen
-- 
Andreas Bergen
E-Mail: [EMAIL PROTECTED]
PGP-Key on keyservers.
"Freuet euch in dem Herrn allewege, und abermals sage ich: Freuet euch!" Phi 4,4


May 18 17:27:20 erde kernel: Unable to handle kernel paging request at virtual address 
0696f974
May 18 17:27:20 erde kernel: current->tss.cr3 = 044e, %cr3 = 044e
May 18 17:27:20 erde kernel: *pde = 
May 18 17:27:20 erde kernel: Oops: 
May 18 17:27:20 erde kernel: CPU:0
May 18 17:27:20 erde kernel: EIP:0010:[ext2_getblk+30/540]
May 18 17:27:20 erde kernel: EFLAGS: 00010246
May 18 17:27:20 erde kernel: eax: c5f95a00   ebx: fff4   ecx: c1a5be60   edx: 
0400
May 18 17:27:20 erde kernel: esi:    edi: c2a6ecc0   ebp: c2a6ecc0   esp: 
c1a5bdfc
May 18 17:27:20 erde kernel: ds: 0018   es: 0018   ss: 0018
May 18 17:27:20 erde kernel: Process ksysguard (pid: 6625, process nr: 91, 
stackpage=c1a5b000)
May 18 17:27:20 erde kernel: Stack: c2a6ecc0 c5a897c0 c2bbb000 0010 0014 
0400 0001 0001
May 18 17:27:20 erde kernel:c027363c c0145e09 c2a6ecc0   
c1a5be60 fff4 c4546340
May 18 17:27:20 erde kernel:c2a6ecc0 c5a897c0 c1ea1ef8 c1a5be68 c1a5be84 
  1000
May 18 17:27:20 erde kernel: Call Trace: [ext2_find_entry+129/784] 
[process_timeout+14/20] [timer_bh+644/928] [ext2_lookup+48/140] [do_IRQ+65/72] 
[real_lookup+91/180] [common_interrupt+24/32]
May 18 17:27:20 erde kernel:[lookup_dentry+304/504] [getname+95/156] 
[__namei+49/104] [do_8259A_IRQ+143/156] [sys_access+143/268] [system_call+52/64] 
[startup_32+43/285]
May 18 17:27:20 erde kernel: Code: 24 1c 8b 98 08 01 00 00 c7 01 fb ff ff ff 85 f6 7d 
0c 83 c4


ksymoops 0.7c on i586 2.2.17.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.17/ (default)
 -m /boot/System.map.2.2.17 (specified)

May 18 17:27:20 erde kernel: Unable to handle kernel paging request at virtual address 
0696f974
May 18 17:27:20 erde kernel: current->tss.cr3 = 044e, %cr3 = 044e
May 18 17:27:20 erde kernel: *pde = 
May 18 17:27:20 erde kernel: Oops: 
May 18 17:27:20 erde kernel: CPU:0
May 18 17:27:20 erde kernel: EIP:0010:[ext2_getblk+30/540]
May 18 17:27:20 erde kernel: EFLAGS: 00010246
May 18 17:27:20 erde kernel: eax: c5f95a00   ebx: fff4   ecx: c1a5be60   edx: 
0400
May 18 17:27:20 erde kernel: esi:    edi: c2a6ecc0   ebp: c2a6ecc0   esp: 
c1a5bdfc
May 18 17:27:20 erde kernel: ds: 0018   es: 0018   ss: 0018
May 18 17:27:20 erde kernel: Process ksysguard (pid: 6625, process nr: 91, 
stackpage=c1a5b000)
May 18 17:27:20 erde kernel: Stack: c2a6ecc0 c5a897c0 c2bbb000 0010 0014 
0400 0001 0001
May 18 17:27:20 erde kernel:c027363c c0145e09 c2a6ecc0   
c1a5be60 fff4 c4546340
May 18 17:27:20 erde kernel:c2a6ecc0 c5a897c0 c1ea1ef8 c1a5be68 c1a5be84 
  1000
May 18 17:27:20 erde kernel: Call Trace: [ext2_find_entry+129/784] 
[process_timeout+14/20] [timer_bh+644/928] [ext2_lookup+48/140] [do_IRQ+65/72] 
[real_lookup+91/180] [common_interrupt+24/32]
May 18 17:27:20 erde kernel: Code: 24 1c 8b 98 08 01 00 00 c7 01 fb ff ff ff 85 f6 7d 
0c 83 c4
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   24 1c and$0x1c,%al
Code;  0002 Before first symbol
   2:   8b 98 08 01 00 00 mov0x108(%eax),%ebx
Code;  0008 Before first symbol
   8:   c7 01 fb ff ff ff movl   $0xfffb,(%ecx)
Code;  000e Before first symbol
   e:   85 f6 test   %esi,%esi
Code;  0010 Before first symbol
  10:   7d 0c jge1e <_EIP+0x1e> 001e Before first symbol
Code;  0012 Before first symbol
  12:   83 c4 00  add$0x0,%esp


 PGP signature

DMA support for toshiba IDE controllers

[Alex Deucher]

Does anyone know if there is any DMA support for the
toshiba IDE controller's in many of their portable
models such as the older porteges and librettos?  The
controllers support DMA, but not in linux.  I'm not
sure what toshiba's policy is on documentation.  They
used to be pretty stingy, but I heard they have
recently opened up of lot of their doc's, like the
oboe IR controller for instance. 

Thanks,

Alex

__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.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: cmpci sound chip lockup

[Arnaldo Carvalho de Melo]

Em Fri, May 18, 2001 at 03:02:18PM -0300, Rik van Riel escreveu:
> On Thu, 17 May 2001, Ingo Oeser wrote:
> > On Wed, May 16, 2001 at 08:02:06PM -0300, Rik van Riel wrote:
> > > I'm seeing a similar thing on 2.4.4-pre[23], but in a far less
> > > serious way. Using xmms the music stops after anything between
> > > a few seconds and a minute, I suspect a race condition somewhere.
> > >
> > > Using mpg123 everything works fine...
> >
> > Your xmms uses esd[1]?
> 
> Nope. I also get this with xmms directly to /dev/dsp.

Can you try this patch? some parts are just some cleanups, but there are
two bugs fixed, this was just a quick look, maybe there are other bugs.

- Arnaldo

--- linux-2.4.4-ac11/drivers/sound/cmpci.c  Fri May 18 00:04:23 2001
+++ linux-2.4.4-ac11.acme/drivers/sound/cmpci.c Fri May 18 01:03:22 2001
@@ -70,6 +70,12 @@
  * (8738 only)
  * Fix bug cause x11amp cannot play.
  *
+ *Fixes:
+ *Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
+ *18/05/2001 - .bss nitpicks, fix a bug in set_dac_channels where it
+ *was calling prog_dmabuf with s->lock held, call missing
+ *unlock_kernel in cm_midi_release
+ *
  */
 
 /*/
@@ -335,9 +341,9 @@
 
 /* - */
 
-static struct cm_state *devs = NULL;
-static struct cm_state *devaudio = NULL;
-static unsigned long wavetable_mem = 0;
+static struct cm_state *devs;
+static struct cm_state *devaudio;
+static unsigned long wavetable_mem;
 
 /* - */
 
@@ -862,8 +868,10 @@
maskb(s->iobase + CODEC_CMI_MISC_CTRL + 2, ~0, 0xC0);
s->status |= DO_DUAL_DAC;
// prepare secondary buffer
+   spin_unlock_irqrestore(>lock, flags);
ret = prog_dmabuf(s, 1);
if (ret) return ret;
+   spin_lock_irqsave(>lock, flags);
// copy the hw state
fmtm &= ~((CM_CFMT_STEREO | CM_CFMT_16BIT) << CM_CFMT_DACSHIFT);
fmtm &= ~((CM_CFMT_STEREO | CM_CFMT_16BIT) << CM_CFMT_ADCSHIFT);
@@ -2578,6 +2586,7 @@
if (file->f_flags & O_NONBLOCK) {
remove_wait_queue(>midi.owait, );
set_current_state(TASK_RUNNING);
+   unlock_kernel();
return -EBUSY;
}
tmo = (count * HZ) / 3100;
@@ -2710,10 +2719,8 @@
outb(5, s->iosynth+2);
outb(arg & 1, s->iosynth+3);
return 0;
-
-   default:
-   return -EINVAL;
}
+   return -EINVAL;
 }
 
 static int cm_dmfm_open(struct inode *inode, struct file *file)
@@ -2859,22 +2866,22 @@
 #ifdef CONFIG_SOUND_CMPCI_MIDI
 static int mpu_io = CONFIG_SOUND_CMPCI_MPUIO;
 #else
-static int mpu_io = 0;
+static int mpu_io;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_FM
 static int fm_io = CONFIG_SOUND_CMPCI_FMIO;
 #else
-static int fm_io = 0;
+static int fm_io;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_SPDIFINVERSE
 static int spdif_inverse = 1;
 #else
-static int spdif_inverse = 0;
+static int spdif_inverse;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_SPDIFLOOP
 static int spdif_loop = 1;
 #else
-static int spdif_loop = 0;
+static int spdif_loop;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_SPEAKERS
 static int speakers = CONFIG_SOUND_CMPCI_SPEAKERS;
@@ -2884,17 +2891,17 @@
 #ifdef CONFIG_SOUND_CMPCI_LINE_REAR
 static int use_line_as_rear = 1;
 #else
-static int use_line_as_rear = 0;
+static int use_line_as_rear;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_LINE_BASS
 static int use_line_as_bass = 1;
 #else
-static int use_line_as_bass = 0;
+static int use_line_as_bass;
 #endif
 #ifdef CONFIG_SOUND_CMPCI_JOYSTICK
 static int joystick = 1;
 #else
-static int joystick = 0;
+static int joystick;
 #endif
 MODULE_PARM(mpu_io, "i");
 MODULE_PARM(fm_io, "i");
@@ -2935,7 +2942,8 @@
return;
if (pcidev->irq == 0)
return;
-   if (!(s = kmalloc(sizeof(struct cm_state), GFP_KERNEL))) {
+   s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (!s) {
printk(KERN_WARNING "cm: out of memory\n");
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cmpci sound chip lockup

[Rik van Riel]

On Thu, 17 May 2001, Ingo Oeser wrote:
> On Wed, May 16, 2001 at 08:02:06PM -0300, Rik van Riel wrote:
> > I'm seeing a similar thing on 2.4.4-pre[23], but in a far less
> > serious way. Using xmms the music stops after anything between
> > a few seconds and a minute, I suspect a race condition somewhere.
> >
> > Using mpg123 everything works fine...
>
> Your xmms uses esd[1]?

Nope. I also get this with xmms directly to /dev/dsp.

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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/

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

[Dan Kegel]

Sasi Peter <[EMAIL PROTECTED]> wrote:
> I am just writing an essay, an have mentioned TUX as a performance and 
> scalability linearity recort holder with TUX, referencing the specweb99 
> website summary page: 
> 
> http://www.spec.org/osg/web99/results/web99.html 
> 
> However, taking a closer look, it turns out, that the above statement 
> holds true only for 1 and 2 processor machines. Scalability already 
> suffers at 4 processors, and at 8 processors, TUX 2.0 (7500) gets beaten 
> by IIS 5.0 (8001), and these were measured on the same kind of box! 
>
> How come, TUX is s good at the lowend (1 and 2 CPUs), and scales this 
> bad? 

Let's look at the scores.  (BTW, SPECweb99 gets harder
as the scores get better; the document tree required to achieve a score of
3222 is twice as large as that required to achieve a score of 1438.)

  SPECweb99 result summary:
date#cpu  #nics L2 cache/cpu  RAM  tree score  sw   modelMHz
1/2001  1 1 256K  2G5G  1438   tux2 Compq Proliant DL320 800
6/2000  1 1 256K  2G4G  1270   tux1 Dell Poweredge 6400  667
6/2000  2 2 256K  4G7G  2200   tux1 Dell Poweredge 4400  800
3/2001  2 4 256K  4G10G 3222   tux2 Dell Poweredge 2500  1000

2/2001  1 3 2M8G9G  2700   tux2 IBM xSeries 370  900
2/2001  2 4 2M16G   13G 3999   tux2 IBM xSeries 370  900
6/2000  4 4 2M8G14G 4200   tux1 Dell Poweredge 6400  700
7/2000  8 8 2M32G   21G 6387   tux1 Dell Poweredge 8450  700
11/2000 8 8 2M32G   24G 7500   tux2 Dell Poweredge 8450  700
12/2000 8 8 2M32G   21G 6407   tux1 IBM Netfinity 8500R  700

3/2001  2 3 256K  4G8G  2499   IIS5/SWC HP NetserverLP2000r  1000
4/2001  8 8 2M32G   26G 8000   IIS5/SWC Dell Poweredge 8450  700

IIS5/SWC only has two results on record, at 2 and 8 CPUs.  They're hard
to compare, because they have different cache and RAM sizes and CPU speeds,
but it's safe to say that it performs poorly at 2 CPUs (compared to the 3/2001 
results from Dell) and scales nearly linearly to perform comparatively well at 8 CPUs.

Looking at the IBM 1 and 2 CPU results, twice the CPU only got 1.4 times
the performance.  Not sure TUX is scaling especially well even at 2 CPU's.
(And you can't blame this on disk drives, please don't try.)

So I agree, Tux doesn't seem to scale as well to multiple CPUs as does IIS5/SWC.

About comparing the Tux and IIS/SWC results on the Dell 8 CPU box:
the Tux measurement is 5 months older than the IIS/SWC measurement.
It's interesting to speculate how tux2 would do if tested today; 
It looks like tux2 is about 12% faster than tux1 on 8-CPU machines.
In other words, 5 months of further development on tux and the 2.4 kernel yielded 
a 12% speedup.  Since IIS was only 4% faster than TUX, If Tux were measured today, 
it might have improved enough to beat IIS/SWC, who knows.

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

alpha iommu fixes

[Ivan Kokshaysky]

The most interesting thing here is the pyxis "tbia" fix.
Whee! I can now copy files from SCSI to bus-master IDE, or
between two IDE drives on separate channels, or do other nice
things without hanging lx/sx164. :-)
The pyxis "tbia" turned out to be broken in a more nastier way
than one could expect - tech details are commented in the patch.

Another problem, I think, is that we need extra locking in
pci_unmap_xx(). It seems to be possible that after the scatter-gather
table "wraps" and some SG ptes get free, these ptes might be
immediately allocated and next_entry pointer advanced by pci_map_xx()
from interrupt or another CPU *before* the test for mv_pci_tbi().
In this case we'd have stale TLB entries.

Also small compile fix for 2.4.5-pre3.

Ivan.

--- 2.4.5p3/arch/alpha/kernel/core_cia.cFri Mar 30 19:02:39 2001
+++ linux/arch/alpha/kernel/core_cia.c  Fri May 18 13:50:51 2001
@@ -297,106 +297,82 @@ struct pci_ops cia_pci_ops = 
  * It cannot be invalidated.  Rather than hard code the pass numbers,
  * actually try the tbia to see if it works.
  */
-
-void
-cia_pci_tbi(struct pci_controller *hose, dma_addr_t start, dma_addr_t end)
-{
-   wmb();
-   *(vip)CIA_IOC_PCI_TBIA = 3; /* Flush all locked and unlocked.  */
-   mb();
-   *(vip)CIA_IOC_PCI_TBIA;
-}
-
-/*
- * Fixup attempt number 1.
- *
- * Write zeros directly into the tag registers.
+/* Even if the tbia works, we cannot use it. It effectively locks the
+ * chip (as well as direct write to the tag registers) if there is a
+ * SG DMA operation in progress. This is true at least for PYXIS rev. 1.
  */
-
-static void
-cia_pci_tbi_try1(struct pci_controller *hose,
-dma_addr_t start, dma_addr_t end)
-{
-   wmb();
-   *(vip)CIA_IOC_TB_TAGn(0) = 0;
-   *(vip)CIA_IOC_TB_TAGn(1) = 0;
-   *(vip)CIA_IOC_TB_TAGn(2) = 0;
-   *(vip)CIA_IOC_TB_TAGn(3) = 0;
-   *(vip)CIA_IOC_TB_TAGn(4) = 0;
-   *(vip)CIA_IOC_TB_TAGn(5) = 0;
-   *(vip)CIA_IOC_TB_TAGn(6) = 0;
-   *(vip)CIA_IOC_TB_TAGn(7) = 0;
-   mb();
-   *(vip)CIA_IOC_TB_TAGn(0);
-}
-
-#if 0
 /*
- * Fixup attempt number 2.  This is the method NT and NetBSD use.
+ * This is the method NT and NetBSD use.
  *
  * Allocate mappings, and put the chip into DMA loopback mode to read a
  * garbage page.  This works by causing TLB misses, causing old entries to
  * be purged to make room for the new entries coming in for the garbage page.
  */
 
-#define CIA_BROKEN_TBI_TRY2_BASE   0xE000
+#define CIA_BROKEN_TBIA_BASE   0xE000
+#define CIA_BROKEN_TBIA_SIZE   1024
 
-static void __init
-cia_enable_broken_tbi_try2(void)
+static inline void
+cia_enable_broken_tbia(void)
 {
unsigned long *ppte, pte;
long i;
 
-   ppte = __alloc_bootmem(PAGE_SIZE, 32768, 0);
+   /* Use minimal 1K map. */
+   ppte = __alloc_bootmem(CIA_BROKEN_TBIA_SIZE, 32768, 0);
pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
-   for (i = 0; i < PAGE_SIZE / sizeof(unsigned long); ++i)
+   for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
ppte[i] = pte;
 
-   *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBI_TRY2_BASE | 3;
-   *(vip)CIA_IOC_PCI_W3_MASK = (PAGE_SIZE - 1) & 0xfff0;
+   *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3;
+   *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
+   & 0xfff0;
*(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2;
 }
 
-static void
-cia_pci_tbi_try2(struct pci_controller *hose,
+void
+cia_pci_tbi(struct pci_controller *hose,
 dma_addr_t start, dma_addr_t end)
 {
-   unsigned long flags;
unsigned long bus_addr;
int ctrl;
-   long i;
 
-   __save_and_cli(flags);
+/* __save_and_cli(flags);  Don't need this -- we're called from
+   pci_unmap_xx() or iommu_arena_alloc()
+   with IPL_MAX after spin_lock_irqsave() */
 
/* Put the chip into PCI loopback mode.  */
mb();
ctrl = *(vip)CIA_IOC_CIA_CTRL;
*(vip)CIA_IOC_CIA_CTRL = ctrl | CIA_CTRL_PCI_LOOP_EN;
mb();
-   *(vip)CIA_IOC_CIA_CTRL;
-   mb();
 
/* Read from PCI dense memory space at TBI_ADDR, skipping 32k on
   each read.  This forces SG TLB misses.  NetBSD claims that the
   TLB entries are not quite LRU, meaning that we need to read more
   times than there are actual tags.  The 2117x docs claim strict
   round-robin.  Oh well, we've come this far...  */
-
-   bus_addr = cia_ioremap(CIA_BROKEN_TBI_TRY2_BASE);
-   for (i = 0; i < 12; ++i, bus_addr += 32768)
-   cia_readl(bus_addr);
+   /* Even better - as seen on the PYXIS rev 1 the TLB tags 0-3 can
+  be filled by the TLB misses *only once* after being invalidated
+  (by tbia or direct write). Next misses won't update them even
+  though the 

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Rik van Riel wrote:

> On Fri, 18 May 2001, Mike Galbraith wrote:
> > On Thu, 17 May 2001, Rik van Riel wrote:
> > > On Thu, 17 May 2001, Mike Galbraith wrote:
> > >
> > > > Only doing parallel kernel builds.  Heavy load throughput is up,
> > > > but it swaps too heavily.  It's a little too conservative about
> > > > releasing cache now imho. (keeping about double what it should be
> > > > with this load.. easily [thump] tweaked;)
> > >
> > > "about double what it should be" ?
> >
> > Do you think there's 60-80mb of good cachable data? ;-)  The "double"
> > is based upon many hundreds of test runs.  I "know" that performance
> > is best with this load when the cache stays around 25-35Mb.  I know
> > this because I've done enough bend adjusting to get throughput to
> > within one minute of single task times to have absolutely no doubt.
> > I can get it to 30 seconds with much obscene tweaking, and have done
> > it with zero additional overhead for make -j 30 ten times in a row.
> > (that kernel was.. plain weird. perfect synchronization.. voodoo!)
>
> Ahhh, I see.  Remember that the "cached" figure you are
> seeing also includes swap-cached data from the gccs, which
> results from kswapd scanning the processes, clearing the
> PTE and, a bit later, the process grabbing the page again.

Yes.

> I suspect that if the gccs _just_ fit in memory, you can
> get some extra performance by mercilessly eating from the
> cache and keeping the ggcs in memory. However, I also have
> the sneaking suspicion that this is not the best tactic for
> all workloads ;)

Yes, ~exactly!  I chose 30 tasks because they almost do (tool/userland
dependant.. must recalibrate often) fit.  The bitch is to get the vm
to automagically detect the rss/cache munch tradeoff point without all
the manual help.

-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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <[EMAIL PROTECTED]>:
> > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > > Aunt Tillie shouldn't try to manually configure a kernel.
> > 
> > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel  After
> > all, all of us at one point in time were newbies in terms of configuring
> > kernels, etc.
> 
> And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
> the one with the unicorn appliques and the pink scrunchies and the Back Street
> Boys posters in her bedroom?

That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.

On the other hand she should _really_ learn how to do it - like we all did.

> Dammit, if we're serious about empowering people with free software we can't
> limit ourselves with the attitude that configuring kernels (or anything
> else) is the sacred preserve of a geek elite.

I see _no_ reason to give up my control for people with an attitude that
configuring kernels will not need knowledge of what one is doing.

Your point is basically:

Lets rewrite the kernel in VBA to make every word user
capable of driver hacking.

That doesn't work.

Christoph
--
Auch der Dumme hat manchmal einen gescheiten Gedanken.
Er merkt es nur nicht.  -- Danny Kaye
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <[EMAIL PROTECTED]>:
> What I am trying to say is that if you can infer probable configuration
> categories that are relevant then instead of automatically filling the other
> areas in and blocking changing them without using vi you can put the other
> options as a submenu. That guides the less expert user and also helps rather
> than hinders the expert

OK, that's useful input.  Noted.

There's a bit of a technical problem with the distinction between 
derivations (which are like macros) and question symbols (which can
be suppressed or unsuppressed depending on their visibility predicate
But perhaps I can think up a solution to that one over lunch.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
-- Lyndon Johnson, former President of the U.S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CML2 design philosophy heads-up

[Mike Galbraith]

On Fri, 18 May 2001, Jonathan Morton wrote:

> As for the language CML2 is written in, surely C would work just as well as
> Python if the config-ruleset file is in a known format.  GCC is required
> for the kernel to build, I don't see why anything else should be required
> simply to configure it.

Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
a configurator which doesn't require something more than gcc is there?

OTOH, python here says: Python 1.3 (Dec 19 1995)  [GCC 2.7.2]. I didn't
have it built at all during the years prior to 1995, so I'm sure you can
imagine how enthusiastic I am about upgrading that old turd ;-)

-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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?

Do you really believe anyone would be dumb enough to delete them out of spite
or to further your political machinations if they could both handle the same
configuration language.

CML1 has had no official maintainer for about 4 years. People contribute bits
and it works. So as it stands there would be no reason to remove 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/

Re: CML2 design philosophy heads-up

[Alan Cox]

> I want to understand what you're driving at here and I don't get it.  What's

What I am trying to say is that if you can infer probable configuration
categories that are relevant then instead of automatically filling the other
areas in and blocking changing them without using vi you can put the other
options as a submenu. That guides the less expert user and also helps rather
than hinders the expert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
> On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
>> Christoph Hellwig wrote:

[my voice was snipped here]

>> Yes, I should have limited myself to pre-egcs versions.
>
> Huh?
>
> It's been possible to have multiple versions of gcc installed for a very
> long time.  At least since 2.0 came out.
>
> Thu Dec 19 15:54:29 1991  K. Richard Pixley  (rich at cygnus.com)
>
> * configure: added -V for version number option.

But with at least the combination of gcc2.7.2.x and egcs1.x it did not
work for me (and others).

Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Johannes Erdfelt]

On Thu, May 17, 2001, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > But no, I don't actually like sockets all that much myself. They are hard
> > > to use from scripts, and many more people are familiar with open/close and
> > > read/write.
> > 
> > Agreed.
> > 
> > It would be nice to use open/close/read/write for control and bulk and
> > sockets for interrupt and isochronous.
> 
> What makes interrupt so different? Last time I checked int pipes were very
> similar to bulk pipes... Do you care about "packet boundaries"? You can
> somehow emulate with read, too...

We probably could. It would have interesting semantics however. We would
have to have an ioctl or something else to specify period, and if it's
one shot, etc.

We could probably shoehorn isochronous semantics onto read/write as
well, but I don't want to begin to think how ugly that'll be.

The reason I don't favor the read/write idea for interrupt and
isochronous are the fact that they are so different. We could shoehorn
the semantics onto it, but we'd just be moving the problem from one
place to somewhere else.

A completely ioctl solution would work better in that case since it's
cleaner. The only problem would be the fact it's called ioctl.

JE

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

Q: missing or broken mmap().

[Bohdan Vlasyuk]

Hi !!

I'm wondering what it may mean - something to be implemented in linux,
of poorly configured system:

---
$ gdb -m dummy -q --batch

warning: mapped symbol tables are not supported on this machine;
missing or broken mmap().
---

When I was reading info, I've seen that "this feature is supported on
chosen platforms", however, I was thinking Linux is the Chosen one
:-)).

Can anyone explain it ??

-- 
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: Storage - redundant path failover / failback - quo vadis linux?

[Jonathan Lundell]

At 9:03 AM +0200 2001-05-18, [EMAIL PROTECTED] wrote:
>  >My question is which way is the more probable solution for future linux
>  >kernels?
>  >The low-level-approach of the "T3"-patch requires changes to the
>  >scsi-drivers and the hardware-drivers but provides optimal communication
>  >between the driver and the hardware
>
>Thinking about it: if there would be some sort of 'available' flag 
>in the gendisk structure, that would be updated by the low-level 
>drivers. This could the used by a high-level design to use or skip a 
>failed device/path... In the S/390 (or zSeries) environment the 
>device drivers are even able to detect a failing connection even if 
>there is no data going to a device. That way the device would be 
>disabled even _before_ anybody tries to write...
>
>  >The high-level-approach of the "multipath"-personality is
>  >hardware-independant but works very slowly. On the other hand I see no
>  >clear way how to check for availability of the (previously failed) primary
>  >channel to automate a fail-back.
>
>Well, slower, but I think there will be many that take that 
>performance loss already by using lvm or md (for the benefit of 
>flexible/large filesystems) this approach would add failover while 
>beeing IMHO only a little less performant.

The flag idea, or some equivalent way for the low-level driver to 
communicate to the multi-pathing level, seems exactly right. I'm 
guessing that provision needs to be made for some 
external-device-dependent means of signalling both failure and 
recovery. There are potentially side-channel/out-of-band means to 
communicate this kind of status from specific devices.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote:
> It's been an ugly, nasty, horrible job -- *much* nastier, by an order
> of magnitude, than designing and writing the CML2 engine.  Going the
> other direction would be worse.  "Like chewing razor blades" is the
> simile that leaps to mind.

And you hope this will not be razorblades if Linus decides he likes CML2 ?

 
> (And no, dropping back to CML1 format for the masters wouldn't be an
> option; it doesn't have the semantic strength to enable CML2's new
> capabilities.)

Right now, it's now a dropping back. You seem to take for granted that CML2
and your python2 frontend to it are 2.5.0 material. I don't right now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/