Re: Cosmetic JFFS patch.

[Paul Mackerras]

Linus Torvalds writes:

> There's another side to "drumming your own drum": it is often seen as
> actively offensive to some people who don't want to do the same thing.

I agree.  What usually seems to end up happening is that someone
writes 95% and gets no credit, someone else does 5% and puts in a
printk announcing their contribution loudly every time the system
boots.  I recall that the old PPP driver used to print "PPP Dynamic
channel allocation code copyright 1995 Caldera, Inc." which always
annoyed me because it was a completely trivial piece of code that the
notice was referring to.

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

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)V3

[Andre Hedrick]

That is a legacy bit from ATA-2 but it is one of those things you can not
get rid of :-( even thou things are obsoleted, they are not retired.
This means that you have to go back into the past to see how it was used,
silly!  I hope you agree to that point.

This is the drive->ctrl register pointer.

outp(drive->ctl|0x02, IDE_CONTROL_REG);

typedef union {
unsigned all: 8;/* all of the bits together */
struct {
unsigned bit0   : 1;
unsigned nIEN   : 1;/* device INTRQ to host */
unsigned SRST   : 1;/* host soft reset bit */
unsigned bit3   : 1;/* ATA-2 thingy */
unsigned reserved456: 3;
unsigned HOB: 1;/* 48-bit address ordering */
} b;
} control_t;

This is a new struct that is to be added for 48-bit addressing and it will
reflect drive->ctl soon.  I have not decided how to use it best or at all,
but it has meaning and once I add-in the real def of bit3 then I will not
need to look it up again.

Cheers,

Andre Hedrick
ASL Kernel Development
Linux ATA Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

On Thu, 28 Jun 2001, Gunther Mayer wrote:

> Andre Hedrick wrote:
> > 
> > It fixes a BUG in CFA, but what will it do to the other stuff?
> > Parse it exclusive to CFA and there is not an issue.
> ...
> > Not all ./arch have a control register doing this randomly without know the
> > rest of the driver will kill more than it fixes.
> > 
> 
> Thanks for pointing out this implementation bug. Although I fixed another problem
> in ide-cs, where ctl_base could eventually be 0.
> 
> I would rather not add a special hwif->is_pcmcia flag, as
> the control register (if it exists) is well defined
> (bit2=softreset bit1=nIEN, others reserved; however there is
>  a hardcoded value of 0x08 somewhere in the ide code?).
> 
> -
> Gunther
> 
> 
> 
> --- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
> +++ linux/drivers/ide/ide-cs.c  Thu Jun 28 18:04:27 2001
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -223,6 +224,15 @@
>  #define CFG_CHECK(fn, args...) \
>  if (CardServices(fn, args) != 0) goto next_entry
>  
> +int idecs_register (int arg1, int arg2, int irq)
> +{
> +hw_regs_t hw;
> +ide_init_hwif_ports(, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
> +hw.irq = irq;
> +hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
> +return ide_register_hw(, NULL);
> +}
> +
>  void ide_config(dev_link_t *link)
>  {
>  client_handle_t handle = link->handle;
> @@ -326,10 +336,12 @@
>  
>  /* retry registration in case device is still spinning up */
>  for (i = 0; i < 10; i++) {
> -   hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
> +   if(ctl_base) outb(0x02, ctl_base); // Set nIEN = disable device interrupts
> +   hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
> if (hd >= 0) break;
> if (link->io.NumPorts1 == 0x20) {
> -   hd = ide_register(io_base+0x10, ctl_base+0x10,
> +   if(ctl_base) outb(0x02, ctl_base+0x10);
> +   hd = idecs_register(io_base+0x10, ctl_base+0x10,
>   link->irq.AssignedIRQ);
> if (hd >= 0) {
> io_base += 0x10; ctl_base += 0x10;
> --- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
> +++ linux/drivers/ide/ide-probe.c   Thu Jun 28 18:43:43 2001
> @@ -685,6 +685,9 @@
>  #else /* !CONFIG_IDEPCI_SHARE_IRQ */
> int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
>SA_INTERRUPT;
>  #endif /* CONFIG_IDEPCI_SHARE_IRQ */
> +
> +   if(hwif->io_ports[IDE_CONTROL_OFFSET])
> +   OUT_BYTE(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear 
>nIEN == enable irqs
> if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
> if (!match)
> kfree(hwgroup);
> --- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
> +++ linux/drivers/ide/ide.c Thu Jun 28 18:04:42 2001
> @@ -2181,6 +2181,7 @@
> memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
> hwif->irq = hw->irq;
> hwif->noprobe = 0;
> +   hwif->chipset = hw->chipset;
>  
> if (!initializing) {
> ide_probe_module();
> --- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
> +++ linux/include/linux/ide.h   Thu Jun 28 18:18:05 2001
> @@ -226,6 +226,19 @@
>  #endif
>  
>  /*
> + * hwif_chipset_t is used to keep track 

Re: NETDEV WATCHDOG with 2.4.5

[Tim Timmerman]

> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:

Andrew> Tim Timmerman wrote:
>> 
>> > "kees" == kees  <[EMAIL PROTECTED]> writes:
>> 
kees> Hi,
>> 
kees> I tried 2.4.5 but after a couple of hours I lost all network
kees> connectivety.  The log shows:
>> 
>> Can I just add a me too here ?
>> 
>> System: Abit BP6, Dual Celeron, Ne2k-pci, usb ohci and
>> scanner; 128 Mb Ram, Nvidia TNT2 graphics. Kernel 2.4.5


Andrew> Probable fixes include booting with the `noapic' option,
Andrew> running -ac kernels or applying Maciej's APIC workaround
Andrew> patch.  There's a copy at http://www.uow.edu.au/~andrewm/linux/apic.txt
Andrew> -
   Didn't check the patch, but went straight for 2.4.5-ac20... No hangs,
   and better performance than before.

   TimT. 
   

-- 
[EMAIL PROTECTED]  040-2683613
[EMAIL PROTECTED]   Voodoo Programmer/Keeper of the Rubber Chicken
Whatever happened to preparations A through G?

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

Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]

[Blesson Paul]

"This is almost always the result of flakiness in your hardware - either
RAM (most likely), or motherboard (less likely).  "
 
  I cannot understand this. There are many other
stuffs that I compiled with gcc without any problem. Again compilation is only
a application. It  only parse and gernerates object files. How can RAM or
motherboard makes different
  

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

gcc: internal compiler error: program cc1 got fatal signal 11

[Blesson Paul]

hi
  I am trying to compile the kernel2.4.5 source code. 
Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2.  Now when I
compile I will get the following error 
 gcc: Internel compiler error: program   cc1 got fatal signal 11
 make Error 1
 Leaving directory ...
 ..
 .
 Assembler messages 
 Warning: end of file not at end of file: newline inserted 
 cpp: output pipe has been closed 
  Error: suffix or operands invalid for mov   
Here  cofusion part is that, when I recompile, the same part where this
error occured will compile perfectly. But again after some compilation, the
same error will show in any other place. The last line in the error statement
may be different in the second time.   
 
   Moreover my cpu info in given below. I have given
processor i486. Is there any particular choice should be made to compile
kernel source code
 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 400.921117
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
bogomips: 799.54

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Announcing Journaled File System (JFS) release 1.0.0 available

[Yaacov Akiba Slama]

Steve Lord wrote:

>>Hi,
>>
> 
>>So I only hope that the smart guys at SGI find a way to prepare the 
>>patches the way Linus loves because now the file 
>>"patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel 
>>and not the new files) is about 174090 bytes which is a lot.
>>
>>YA
>>
>>
> 
> But that is not a patch intended for Linus, it is intended to enable all
> the XFS features. I have a couple of kernel patches which total 46298 bytes
> which get you a working XFS filesystem in the kernel, and I could do
> lots of things to make them smaller. When you hit header files in the
> correct manner for different platforms the size tends to mushroom.
> These lines are all in different fcntl.h files for example:
> 
> +#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0x8 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0x20 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0x20 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0x8 /* invisible I/O, for DMAPI/XDSM */
> +#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */
> 
> You make the patches look a lot bigger than they really are. There is
> a difference between a patch which is placing things in the correct
> places and one which is designed to be as short as possible.
> 

Agree.
But IMHO, you need to be more "visible" and to already propose those 
kernel modifications - even not the final ones - in lkml in order to let 
everyone see them and change the current think (even by Alan) that XFS 
is too intrusive for 2.4.
There are other people involved in the files you need to change and the 
more your patches are visibles, the more they are "credibles".
I didn't want to critisize XFS (or JFS and ext3) but to give some points 
about their integration in 2.4.
YA


> Steve
> 
> 
> 
> 



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

Re: artificial latency for a network interface

[Burkhard Daniel]

I had a similiar problem once, and wrote a module that overwrote the
loopback net device. Since it's loopback, the kernel won't care about
headers.

Yeah, I know: Quick & Dirty.

I made the new loopback put its packets in a queue and then deliver them
after a (adjustable) delay.

If I can still find the source for this, I'll post it here.

Burk.

On Fri, 29 Jun 2001, Andrew Morton wrote:

> Andreas Schuldei wrote:
> > 
> > to simulate a sattelite link, I need to add a latency to a
> > network connection.
> > 
> > What is the easiest and best way to do that?
> > 
> > I wanted to do that using two tun devices.
> > I had hoped to have a routing like this:
> > 
> >  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1
> 
> yes, that works very well.  A userspace app sits on top of the
> tun/tap device and pulls out packets, delays them and reinjects
> them.
> 
> The problem is routing: when you send the packet back to the
> kernel, it sends it straight back to you.  You need to rewrite
> the headers, which is a pain.
> 
> A simpler approach is to use policy routing - use the source
> and destination devices to override the IP addresses.  Works
> well.  The code is at
> 
>   http://www.uow.edu.au/~andrewm/packet-delay.tar.gz
> 
> It has its own variable bandwidth management as well
> as variable latency.  It's for simulating narrowband, high
> latency connections.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

ac20, ac21 make config error

[robs]

in "linux/drivers/net/Config.in"

 line 30 used to be:


if [ "$CONFIG_NET_ETHERNET" = "y" ]; then


It seems to have been deleted.  Putting it back, everything goes as it
should. :)

Thanks!!

Rob


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

Re: artificial latency for a network interface

[Andrew Morton]

Andreas Schuldei wrote:
> 
> to simulate a sattelite link, I need to add a latency to a
> network connection.
> 
> What is the easiest and best way to do that?
> 
> I wanted to do that using two tun devices.
> I had hoped to have a routing like this:
> 
>  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

yes, that works very well.  A userspace app sits on top of the
tun/tap device and pulls out packets, delays them and reinjects
them.

The problem is routing: when you send the packet back to the
kernel, it sends it straight back to you.  You need to rewrite
the headers, which is a pain.

A simpler approach is to use policy routing - use the source
and destination devices to override the IP addresses.  Works
well.  The code is at

http://www.uow.edu.au/~andrewm/packet-delay.tar.gz

It has its own variable bandwidth management as well
as variable latency.  It's for simulating narrowband, high
latency connections.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac21

[Dieter Nützel]

Am Freitag, 29. Juni 2001 03:59 schrieb Dieter Nützel:
> Hello Alan,
>
> you've missed the CONFIG_DRM_AGP thing.
> Some other config objects (Input -> joysticks , SMB file system) are
> broken, too.

Keith Owens patch fixed it of course.
http://marc.theaimsgroup.com/?l=linux-kernel=99378430115592=2

Thanks Keith!

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

Re: Cosmetic JFFS patch.

[Ian Stirling]

> 
> Linus Torvalds wrote:
> > Things like version strings etc sound useful, but the fact is that the
> > only _real_ problem it has ever solved for anybody is when somebody thinks
> > they install a new kernel, and forgets to run "lilo" or something. But
> > even that information you really get from a simple "uname -a".
> > 
> > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care
> > that we have quota version "dquot_6.4.0"? No. Do we want to get the
> > version printed for every single driver we load? No.

It would be nice to show driver version for every single non-stock
driver we load though.
Perhaps a list of versions in the stock kernel build, stored somewhere,
that shouldn't be patched by anyone, but only change with official releases.
At compile time, if the driver version string is different from the
'blessed' version, it prints it's version, and possibly more.


> As Alan said, driver versions are incredibly useful.  People use update
> their drivers over top of kernel drivers all the time.  Vendors do it
> too.  "Run dmesg and e-mail me the output" is 1000 times more simple for
> end users.

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

[mythos]

I have installed a second hard drive in my system in the second
channel of my controller.But when I try to enable DMA I get:
hdc: DMA disabled
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: DMA disabled
ide1: reset: success

I thought that there were problems only with Via VT82C686B.
Can anyone please help me?
My motherbord is an ASUS K7V with KX133 chipset.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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:Illegal instruction when mount nfs file systems using

[Frank Zhu (Shanghai)]

ok.
i just do another test.maybe meaningful.
1)no matter i select -march=i686 or -march=i386 the result are the same. 
2)the server 192.168.0.254 (netboot) ,client 192.168.0.3
there are /usr ,/usr/local/ ,/home, /lib, /bin ... on the server
on the client
A: mount -t nfs netboot:/usr  /usr
mount -t nfs netboot:/lib /lib
mount -t nfs netboot:/bin /bin
mount -t nfs netboot:/sbin /sbin
Illegal instruction (core dumped)

B:mount  -t nfs netboot:/usr /1
mount -t nfs netboot:/lib /2
mount -t nfs netboot:/bin /3
mount -t nfs netboot:/sbin /4
mount ...
ok

it seems that mount on the  same mount point(/usr/usr) error occurs
but on the different mount point(/usr--/1..) seems ok
then i install a machine with (lower version distribution kernel
2.2.13)Bluepoint 1.0. there are no mount problems above.

  

-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: 2001年6月29日 7:12
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: PROBLEM:Illegal instruction when mount nfs file systems using


> Here I have to disagree with you Alan. When you pass "-march=i686" to
> gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> "-march=i686" actually means "target an Intel P6 family chip, given
> what we currently know about them". The gcc info pages don't talk

Which is fine. The Pentium Pro manual explicitly states that cmov may go
away. So it is not based on what we know about the CPU, its based on not
reading the documentation. 

It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
It happens to work because the error in reading the docs was never triggered
by intel removing cmov from a cpu as the reserved the right to do

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: Linux and system area networks

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> We seem to have come full circle.  My original question was about
> providing a better way for sockets applications to take advantage of
> SAN hardware.  W2K Datacenter introduces "Winsock Direct," which will
> bypass the protocol stack when appropriate.  The Infiniband people are
> working on a "Sockets Direct" standard, which is a similar idea.  No
> one seems to care about this for Linux.

Well, there is some work done by the zero-copy folks and the sendfile()
function. Realy much more than a mmaped network socket is not needed.

Besides it looks like SAN will go all the way in the IP Direction sooner or
later anyway :)

There are some interesting Features like accessing MS SQL 7.0 Server via VIA
architecture interfaces over SAN, I am not sure o how open VIA is.

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

[Hacksaw]

Given that seeing as much as possible on a potentially small screen would be 
good, maybe tighter would be nice. In example:

kswapd:v1.8
ptyDevices: 256 Unix98 ptys configured
serial:v5.05b (2001-05-03) with 
   Options: MANY_PORTS SHARE_IRQ SERIAL_PCI
   Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
rtclock:   v1.10d
ide:   v6.31
net:   v4.0 for Linux 2.2, from Swansea University Computer Society 
NET3.039
   Unix domain sockets 1.0 for NET4.0.
   TCP/IP 1.0 for NET4.0
   IP Protocols: ICMP, UDP, TCP, IGMP
   TCP: Hash tables configured (ehash 524288 bhash 65536)
   IPv4 over IPv4 tunneling driver
   early initialization of device tunl0 is deferred
   AppleTalk 0.18 for NET4.0


My hope would be that the name at the extreme left column would be the name of 
the module that would be loaded if it were a module, and the name of the main 
code file of the driver in question. That way, those trying to debug stuff 
could go right to the appropriate file, and start reading the code or nearby 
documentation.

Of course, the spacing I have above is optimistic, but just making sure that a 
new driver prints it's version line against the left margin, and everything 
else a few spaces out would help readability.

You might note that I eliminated the word Linux in 5 or 6 places. We know the 
driver works with Linux if it is booting. On the other hand "vX.X for Linux 
2.X" is useful, since it's part of the version number.

Your opinion may vary.

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

Re: Linux 2.4.5-ac21

[Dieter Nützel]

Hello Alan,

you've missed the CONFIG_DRM_AGP thing.
Some other config objects (Input -> joysticks , SMB file system) are
broken, too.

Regards,
Dieter

can't read "CONFIG_DRM_AGP": no such variable
while executing
"list $CONFIG_DRM_AGP"
(procedure "writeconfig" line 2352)
invoked from within
"writeconfig .config include/linux/autoconf.h"
invoked from within
".f0.right.save invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tkButtonUp" line 7)
invoked from within
"tkButtonUp .f0.right.save
"
(command bound to event)

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@home: [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.5-ac21

[Garett Spencley]

> 2.4.5-ac21
> o Fix pnpbios compile failure and add docking (me)
>   station hotplug (/sbin/hotplug dock)

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
-fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe 
-mpreferred-stack-boundary=2 -march=athlon -DEXPORT_SYMTAB -c pnp_bios.c
pnp_bios.c: In function `pnp_dock_event':
pnp_bios.c:442: `hotplug_path' undeclared (first use in this function)
pnp_bios.c:442: (Each undeclared identifier is reported only once
pnp_bios.c:442: for each function it appears in.)
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:496: warning: `d' might be used uninitialized in this function
pnp_bios.c: At top level:
pnp_bios.c:597: warning: `pnp_bios_exit' defined but not used
{standard input}: Assembler messages:
{standard input}:64: Warning: indirect lcall without `*'
{standard input}:135: Warning: indirect lcall without `*'
{standard input}:188: Warning: indirect lcall without `*'
{standard input}:229: Warning: indirect lcall without `*'
make[3]: *** [pnp_bios.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/pnp'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/pnp'
make[1]: *** [_subdir_pnp] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2

I'm using gcc-2.95.6 (Mandrake 8.0) and binutils 2.10.1.0.2.

-- 
Garett

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

artificial latency for a network interface

[David McWherter]

I once solved this problem using the QoS qdisc facilites:

 http://edge.mcs.drexel.edu/GICL/people/udmcwher/dnt/DNT.html

It works on 2.2 kernels as well.

-david

Andreas Schuldei writes:
 > to simulate a sattelite link, I need to add a latency to a
 > network connection. 
 > 
 > What is the easiest and best way to do that?
 > 
 > I wanted to do that using two tun devices. 
 > I had hoped to have a routing like this:
 > 
 >  <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1
 > 
 > I need to do it this way and not with iptables help, because it
 > needs to work also on 2.2.x kernels.
 > 
 > Now I started experimenting with the tun0 interfaces and got
 > problems: till now I have not succeeded to get a tun0 interface
 > up. the example code (br_select.c) in the package (as found for
 > example on sourceforge) looks fishy and does not work too well. 
 > is it correct that only one /dev/tun file is necessary, but
 > /dev/tun0 and tun1 are opend for reading and writing?

--[=]
David T. McWherter[EMAIL PROTECTED]

My religion consists of a humble admiration of the illimitable superior
spirit who reveals himself in the slight details we are able to perceive
with our frail and feeble mind.
-- Albert Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mmap/munmap of physical address

[Christophe Beaumont]

Hi,

I am fighting with a little problem here.
I have reserved a chunk of physical memory for my personnal
use and out of the kernel scope (linux mem=1024M).
I have now to handle this reserved memory by myself with
a simple scheme (I need BIG contiguous memory chunks (over
64Megs, and only few of them).
My idea was to create a driver for that memory & mmap()
in it. So far so good, I can mmap() from user side, driver
works fine as far as remap_page_range() is concerned.
Now comes the freeing/unmapping of those regions. I have
implemented my personnal vm_operations_struct to take care
of house keeping
BUT
the close(struct vm_area_struct *vma) only gives me back
a virtual address, and a call to virt_to_phys(vma->start)
doesn't point back to the physical address I gave when mmaping.
As I have multiple processes, I cannot associate (virt addr,
phys addr) [2 processes could have the same virt addr pointing
to 2 different physical areas].

I am wondering if there is something totally obvious I am
missing there in the process (i.e., is there unmap_page_range
taking the virtual address as input... ;)  )

Thanks in advance...


Christophe Beaumont

Sr Software Engineer Phone: 626-744-2078
Paracel, Inc.  Fax: 626-744-2001
1055 East Colorado Blvd,   email: [EMAIL PROTECTED]
Pasadena, CA 91106-2341 www: www.paracel.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/

Configure and compile errors in 2.4.5ac20 and 1.4.5ac21

[Ignacio Monge]

Output ver_linux:

Gnu C  2.96
Gnu make   3.79.1
binutils   2.11.90.0.8
util-linux 2.11e
mount  2.11e
modutils   2.4.6
e2fsprogs  1.21
reiserfsprogs  3.x.0j
PPP2.4.1
Linux C Library2.2.3
Dynamic linker (ldd)   2.2.3
Procps 2.0.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   2.0.11
Modules Loaded ppp_async ppp_generic slhc es1371 ac97_codec
soundcore nfsd lockd sunrpc 8139too iptable_nat ip_conntrack ip_tables
reiserfs


ERRORS:
1.- Entering in "Network Device support"-->Ethernet (10 or 100Mbit) 
--->causes an error:
 Q> scripts/Menuconfig: MCmenu31: command not found

2.- PnP Bios compile errors:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=athlon -DEXPORT_SYMTAB -c
pnp_bios.c
pnp_bios.c: In function `pnp_dock_event':
pnp_bios.c:442: `hotplug_path' undeclared (first use in this function)
pnp_bios.c:442: (Each undeclared identifier is reported only once
pnp_bios.c:442: for each function it appears in.)
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:496: warning: `d' might be used uninitialized in this function
pnp_bios.c: At top level:
pnp_bios.c:597: warning: `pnp_bios_exit' defined but not used
{standard input}: Assembler messages:
{standard input}:64: Warning: indirect lcall without `*'
{standard input}:135: Warning: indirect lcall without `*'
{standard input}:188: Warning: indirect lcall without `*'
{standard input}:229: Warning: indirect lcall without `*'
make[3]: *** [pnp_bios.o] Error 1
make[3]: Saliendo directorio `/usr/src/linux/drivers/pnp'
make[2]: *** [first_rule] Error 2
make[2]: Saliendo directorio `/usr/src/linux/drivers/pnp'
make[1]: *** [_subdir_pnp] Error 2
make[1]: Saliendo directorio `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2


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

Configure and compile errors in 2.4.5ac20 and 2.4.5ac21

[Ignacio Monge]

Output ver_linux:

Gnu C  2.96
Gnu make   3.79.1
binutils   2.11.90.0.8
util-linux 2.11e
mount  2.11e
modutils   2.4.6
e2fsprogs  1.21
reiserfsprogs  3.x.0j
PPP2.4.1
Linux C Library2.2.3
Dynamic linker (ldd)   2.2.3
Procps 2.0.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   2.0.11
Modules Loaded ppp_async ppp_generic slhc es1371 ac97_codec
soundcore nfsd lockd sunrpc 8139too iptable_nat ip_conntrack ip_tables
reiserfs


ERRORS:
1.- Entering in "Network Device support"-->Ethernet (10 or 100Mbit) 
--->causes an error:
 Q> scripts/Menuconfig: MCmenu31: command not found

2.- PnP Bios compile errors:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=athlon -DEXPORT_SYMTAB -c
pnp_bios.c
pnp_bios.c: In function `pnp_dock_event':
pnp_bios.c:442: `hotplug_path' undeclared (first use in this function)
pnp_bios.c:442: (Each undeclared identifier is reported only once
pnp_bios.c:442: for each function it appears in.)
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:496: warning: `d' might be used uninitialized in this function
pnp_bios.c: At top level:
pnp_bios.c:597: warning: `pnp_bios_exit' defined but not used
{standard input}: Assembler messages:
{standard input}:64: Warning: indirect lcall without `*'
{standard input}:135: Warning: indirect lcall without `*'
{standard input}:188: Warning: indirect lcall without `*'
{standard input}:229: Warning: indirect lcall without `*'
make[3]: *** [pnp_bios.o] Error 1
make[3]: Saliendo directorio `/usr/src/linux/drivers/pnp'
make[2]: *** [first_rule] Error 2
make[2]: Saliendo directorio `/usr/src/linux/drivers/pnp'
make[1]: *** [_subdir_pnp] Error 2
make[1]: Saliendo directorio `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2


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

RE: Cosmetic JFFS patch.

[A. Melon]

Linus Torvalds hath spoken:
> I don't _have_ any instances of my name being printed out to annoy the
> user, so that's a very theoretical argument.

There is, of course, only one way to be fair about this.

And that is to apply this patch to init/main.c:

518a519
>   printk("Linux is a registered trademark of Linus Torvalds.\n");

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

Linux 2.4.5-ac21

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

 Intermediate diffs are available from
http://www.bzimage.org

This is the initial merge with 2.4.6pre - treat this one with care, it may
not be the most reliable 2.4.5ac release ever made

2.4.5-ac21
o   Fix pnpbios compile failure and add docking (me)
station hotplug (/sbin/hotplug dock)
o   Fix make xconfig failure(Keith Owens)
o   Fix cciss pci device table  (Marcus Meissner)
o   Fix bogus math.h include in iphase driver   (Arjan van de Ven)
o   Reiserfs vm deadlock fix(Chris Mason)
o   Make the i810 tco disable info clearer  (Andrey Panin)
o   Correct bzImage size limit check(Pavel Machek)
o   Next lvm patch  (Joe Thornber)
o   Fix toshoboe for pm api change  (me)

2.4.5-ac20
o   Commence resync with 2.4.6pre5
- Merge kernel doc tool changes
- Merge sunrpc printk check change
- Merge net core changes
- Merge Bluetooth stack
- Merge inet proto register
- Merge bridge updates
- Merge net/ipv4 and ipv6 changes
- Merge x86 arch support
- Merge m68k port changes
- Merge ppc port changes
- Merge sparc32/64 changes
- Merge ACPI
- Merge ll_rw_blk changes
- Merge miro rds changes
- Merge USB updates

Kept xtime volatile - pending verification drivers are safe with
 this change
Kept old atyfb code (someone needs to sort out which atyfb is the
one being worked on and get that tree into the kernel)

As with 2.4.6pre power management PCI interface changes
mean power management is likely to be broken somewhat

Also there is some kind of deadlock I suspect related to the
mm changes in 2.4.6pre/2.4.5ac14
o   Resync with 2.4.6pre6
o   Add macserial printk levels (Arnaldo Carvalho de Melo)
o   Add picturebook vaio wide console mode support  (Marcel Wijlaars)
o   Riscom8 driver printk/regions etc   (Arnaldo Carvalho de Melo)
o   ESP serial driver clean up  (Arnaldo Carvalho de Melo)
o   dz serial driver clean up   (Arnaldo Carvalho de Melo)
o   Fix hangs during heavy buffer I/O   (Arjan van de Ven)
(eg mke2fs)
o   Clean up doubletalk driver  (Arnaldo Carvalho de Melo)
o   Further imsttfb updates (Paul Mundt)
o   MTD missing export fixes(David Woodhouse)
o   MTD configure script fixes  (me)
o   MTD include fixes   (me)
o   Yamaha pci audio cleanup , longer delay (Pete Zaitcev)
o   i810 ioctl fix  (Damjan Lango)
o   Add printk levels to tty_io.c   (Arnaldo Carvalho de Melo)
and tty_ioctl.c
o   Small acm serial driver cleanup (Arnaldo Carvalho de Melo)
o   Printk levels for via-pmu   (Arnaldo Carvalho de Melo)
o   Improve kernel-doc parser   (Christian Kreibich)
o   Disable AMI megaraid 64bit mode (Martti Hyppänen)
| Seems the HP board firmware reports 64bit supported but
| it doesn't actually work reliably on them

2.4.5-ac19
o   Update Gareth Hughes contact info   (Gareth Hughes)
o   Make sure NFS atime is handled by server(Trond Myklebust)
o   Fix Configure.help glitch   (Geert Uytterhoeven)
o   Fix nfs readdir EIO and duplicates bug  (Trond Myklebust)
o   Fix netlink removal of proc directory   (Herbert Rosmanith)
o   Use skb_purge_queue in net stacks   (Arnaldo Carvalho de Melo)
| lapb, netrom, econet, rose, ax25, atm, sched,
| socket core, unix
o   Fix reference after free in eql driver  (Arnaldo Carvalho de Melo)
o   Fix reference after free in shaper  (Arnaldo Carvalho de Melo)
o   Gameport fixes for Alpha(Jeff Garzik)
o   Configure.help updates  (Eric Raymond)
o   JFFS copyright banner update(David Woodhouse)
o   Update docs on binfmt_misc java (Kurt Huwig)
o   Fix tty release_mem oops(Tachino Nobuhiro)
o   Pull nfs data out of inode struct   (Al Viro)
o   Assorted UML fixes  (Jeff Dike)
o   Improve missed tick handling on UML (Jeff Dike)
o   Fix hdc/hdd reporting on disks in /proc/stat(Martin Wilck)
o   Fix sign extension of dirent's in readdir   (Trond Myklebust)
o   Ensure LVM dropped snapshot is not reactivated  (Joe 

_syscall4, wake_up_interruptible(), and PID table questions

[Khyron]

Alright, since my last e-mail generated no interest, I thought
I'd refine my queries:

1. wake_up_interruptible()

I am reading
http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html
and the my question is what solution to the "thundering herd" problem
was eventually chosen and is implemented in the 2.4.x kernels? Where
can I find more specific information on this implementation? Source
code references are welcome.

2. _syscall4

After reading http://www.kegel.com/c10k.html, I have to wonder
how exactly sendfile() was implemented in the 2.4.x kernels?
Where in the source can I find information? Is there any published
documentation on this subject as well?

3. PID table resizing

I understand that it is possible to resize the PID table in the
2.4.x kernels? Is this true or misinformation? If true, what do
I need to do? Is this a source edit, a compile-time configuration
option or a runtime option? If a source edit, which file(s)?

Thanks in advance!


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




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

Re: 2.4.5-ac20, make menuconfig problem

[Dan Podeanu]

On Thu, 28 Jun 2001, f5ibh wrote:

> make[4]: Entre dans le répertoire
> `/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp'
> gcc -D__KERNEL__ -I/usr/src/kernel-sources-2.4.5-ac20/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6
> -DEXPORT_SYMTAB -c pnp_bios.c
> pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info'
> follows non-static
> pnp_bios.c:432: warning: no semicolon at end of struct or union

gcc -v?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Announcing Journaled File System (JFS) release 1.0.0 available

[Luigi Genoni]

On Thu, 28 Jun 2001, james rich wrote:

> On Fri, 29 Jun 2001, Luigi Genoni wrote:
>
> > On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote:
> >
> > > So it seems that even if JFS is less complete than XFS (no ACL, quotas
> > > for instance), and even if it is less robust (I don't know if it is, I
> > It is not less complete nor less robust, it's a different technology and a
> > totally different approach.
> > Remember XFS was designed thinking to a kind of HW totally different from
> > PC, and so was for jfs. But somehow JFS is a better choice if you
> > do not have the last fastest CPU, and the last fastest scsi disk.
>
> This is simply not true.  I run xfs on three systems - none of which have
> anything close to the latest cpu.  Each system runs faster after
> installing xfs.  Since linux-kernel is not the place for advocacy I
> suggest a comparison be for your particular setup to determine which is
> best for you.
Please,
I was not making any advocacy. I was saying that there are two different
approach, and incidentally refered my own experience. Then, telling
about jfs to be light, I was not
saying XFS is slow! probably my english was not good enought
to express my thought.

Luigi


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

[Jeff Garzik]

"Khachaturov, Vassilii" wrote:
> 
> On Wed, 27 Jun 2001, Jeff Garzik wrote:
> 
> > However, I think the driver (only going by your
> description) would be
> > more correct to use a pointer to struct pci_dev.  We have a
> token in the
> > kernel that is guaranteed 100% unique to any given PCI device:  the
> > pointer to its struct pci_dev.
> 
> Is it? With a hotplug device removed and another one added,
> isn't there a slight chance that the pci_dev pointer to the new device
> will get allocated in place of the old one?

If you want to get pedantic, yes ;-)  The pci_dev pointer is unique for
the lifetime of the PCI device, which works just as well in the example
used in the thread.

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

Re: Announcing Journaled File System (JFS) release 1.0.0 available

[james rich]

On Fri, 29 Jun 2001, Luigi Genoni wrote:

> On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote:
> 
> > So it seems that even if JFS is less complete than XFS (no ACL, quotas
> > for instance), and even if it is less robust (I don't know if it is, I
> It is not less complete nor less robust, it's a different technology and a
> totally different approach.
> Remember XFS was designed thinking to a kind of HW totally different from
> PC, and so was for jfs. But somehow JFS is a better choice if you
> do not have the last fastest CPU, and the last fastest scsi disk.

This is simply not true.  I run xfs on three systems - none of which have
anything close to the latest cpu.  Each system runs faster after
installing xfs.  Since linux-kernel is not the place for advocacy I
suggest a comparison be for your particular setup to determine which is
best for you.

James Rich
[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: RFC: Changes for PCI

[Khachaturov, Vassilii]

On Wed, 27 Jun 2001, Jeff Garzik wrote:
 
> However, I think the driver (only going by your 
description) would be
> more correct to use a pointer to struct pci_dev.  We have a 
token in the
> kernel that is guaranteed 100% unique to any given PCI device:  the
> pointer to its struct pci_dev.

Is it? With a hotplug device removed and another one added,
isn't there a slight chance that the pci_dev pointer to the new device
will get allocated in place of the old one?

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

[Alan Cox]

> 4002b000-4002c000 rw-s ec681000 03:01 181386 /dev/mem
> 4002c000-4002d000 rw-s 4000 03:01 185562 /dev/nvidia0

I'd suggest you talk to your proprietary driver and application provider. Who
knows what their driver does

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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:Illegal instruction when mount nfs file systems using

[Alan Cox]

> Here I have to disagree with you Alan. When you pass "-march=i686" to
> gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> "-march=i686" actually means "target an Intel P6 family chip, given
> what we currently know about them". The gcc info pages don't talk

Which is fine. The Pentium Pro manual explicitly states that cmov may go
away. So it is not based on what we know about the CPU, its based on not
reading the documentation. 

It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
It happens to work because the error in reading the docs was never triggered
by intel removing cmov from a cpu as the reserved the right to do

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: Announcing Journaled File System (JFS) release 1.0.0 available

[Luigi Genoni]

On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote:

> Hi,
>  From what I understand from Linus's mail to lkml, there is a difference
> between JFS and XFS:
> JFS doesn't require any modifications to existing code, its only an
> addition.
> XFS on the contrary is far more intrusive.
> So it seems that even if JFS is less complete than XFS (no ACL, quotas
> for instance), and even if it is less robust (I don't know if it is, I
It is not less complete nor less robust, it's a different technology and a
totally different approach.
Remember XFS was designed thinking to a kind of HW totally different from
PC, and so was for jfs. But somehow JFS is a better choice if you
do not have the last fastest CPU, and the last fastest scsi disk.
> only used so far XFS and ext3 -with success), its inclusion in current
> kernel is a lot easier and I don't see any (technical) reason for not
> including it.
I hope it will happen as soon.
ReiserFS is a good FS, probably is the best journaled FS you could find
out here, but how many memories with
the old dear jfs! And I have some pentium classic for non critical use
that would be so happy with it.
> I don't think ext3 will have difficulties to be included in the kernel
> because a) the guys working on it are lk veterans and b) Redhat (VA
> also) is already including it in its kernels (rawhide AND 7.1 update).
agree.
> So I only hope that the smart guys at SGI find a way to prepare the
> patches the way Linus loves because now the file
> "patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel
> and not the new files) is about 174090 bytes which is a lot.
mmm.
I doubt it will be easy.
I should check better, but i think it requires eavy changes to VFS.

oh, by the way.
On a 8 processor origin 2000, with a not so eavy I/O, I usually see
1 processor
totally used just for journaling. (different HW, different Unix )

Luigi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Is an outside module supposed to use page cache?

[Daniel Phillips]

On Thursday 28 June 2001 20:16, Ho Chak Hung wrote:
> Hi,
> I am trying to develop a module that makes use of the page cache(by
> allocating a LOT of pages use page_cache_alloc and then add_to_page_cache).
> However, I got some unresolved symbols error during insmod.(because the
> symbols related to lru_cache_add etc are not exported?) . I am just
> wondering if I am not building a file system but at the same time want to
> allocate a lot of pages of physical memory to store something that has no
> backup storage as a file, should I add it to the page cache? Any advice
> would be greatly appreciated

Why not use vmalloc?

If you must, just export the symbols you need, write your code, then either:

  a) Explain to Linus why the world needs those symbols exported
  b) Refine your approach to do it without those symbols

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

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Mikael Pettersson]

On Thu, 28 Jun 2001 20:42:09 +0100 (BST), Alan Cox wrote:

>> > Intel specifically state that you cannot use CMOV without checking
>> > for it. Its actually a gcc/binutils tool bug. The CPU is right.
>> 
>> How is that a gcc bug?  You tell the compiler to generate cmov, you run
>> it on a CPU that doesn't have it, you get what you deserve.  There's
>> really nothing the tools can do about that.
>
>I tell gcc to buld for the 'i686' architecture definition. It in fact builds
>for the i686 architecture assuming an optional feature.

Here I have to disagree with you Alan. When you pass "-march=i686" to
gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
"-march=i686" actually means "target an Intel P6 family chip, given
what we currently know about them". The gcc info pages don't talk
about CPUID family codes, they talk about specific chip families.

As for CMOV being optional, show me an Intel P6 without CMOV and I'll
volunteer to update gcc's docs to warn that "bastard CMOV-less P6 users
should not use the -march=i686 option".

Taking Alan's formal standpoint, there is _no_ compiler-usable difference
between family 4, 5, and 6 processors, since the changes are limited
to system-level code, or useless (gcc doesn't need UD2), or are conditional
on specific CPUID feature bits (which gcc cannot or should not test).
The only guaranteed and useful distinction is "386" and "486 or better",
since the 486 added BSWAP/CMPXCHG/XADD.
[IA-32 manual set, Volume 3, Section 17.7.1 in the revision I have.]

Furthermore, any interpretation of the CPUID family code _must_ be
conditionalised on the CPUID vendor field. The fact that Intel attaches
some semantics to "family 6" doesn't restrict other vendors, since Intel
also defines "vendor == Intel" while the other vendors obviously have
"vendor != Intel", a blatant deviation from the IA-32 manuals.

The real problem is that the kernel generates "uname -m" based only
on the CPUID family code, which is meaningless unless we also know
the vendor name. So "uname -m" ought to be "${FAMILY}86-${VENDOR}",
giving us "686-Intel", "686-AMD", "686-Centaur", and so on.

Unfortunately, changing the output of "uname -m" also breaks lots
of user-space configuration tools out there ... I'm not sure we want
to do that only because VIA in their infinite wisdom
decided to build a "family 6" chip without a CMOV instruction.

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

AGP Question

[Alan]

It there a way to limit how much memory is allocatable by the AGPGART code?

The reason I am asking is I am seeing some odd behaviour that I suspect is 
related to that code.

When I boot the machine, it says something like "200 megs maximum available 
for AGP memory.  X seems to grab 3/4 of that number and then never quite let 
go of it. (The memory map under /proc shows big blocks of memory allocated 
and marked "deleted" for the X PID.)

I used to have a memory leak in another library that would push the system 
into a rather bad state because of the big chunk o' memory that seems to be 
eaten by X.

I have looked at the code, but I did not see anything obvious for that 
function. I could just be going blind though...

Is AGP memory limatable or do I have to look at the X side of things?

Attached is a memory mapp for the X process...


08048000-0819a000 r-xp  03:01 4833355/usr/X11R6/bin/XFree86
0819a000-081c9000 rw-p 00151000 03:01 4833355/usr/X11R6/bin/XFree86
081c9000-0a5da000 rwxp  00:00 0
4000-40016000 r-xp  03:01 4243460/lib/ld-2.2.2.so
40016000-40017000 rw-p 00015000 03:01 4243460/lib/ld-2.2.2.so
40017000-40018000 rw-p  00:00 0
40018000-40028000 rw-s 000a 03:01 181386 /dev/mem
40028000-40029000 rw-s ec68 03:01 181386 /dev/mem
40029000-4002a000 rw-s ec601000 03:01 181386 /dev/mem
4002a000-4002b000 rw-s ec0c 03:01 181386 /dev/mem
4002b000-4002c000 rw-s ec681000 03:01 181386 /dev/mem
4002c000-4002d000 rw-s 4000 03:01 185562 /dev/nvidia0
4003-4003c000 r-xp  03:01 622887 /usr/lib/libz.so.1.1.3
4003c000-4003e000 rw-p b000 03:01 622887 /usr/lib/libz.so.1.1.3
4003e000-40061000 r-xp  03:01 6684678/lib/i686/libm-2.2.2.so
40061000-40062000 rw-p 00022000 03:01 6684678/lib/i686/libm-2.2.2.so
40062000-40069000 r-xp  03:01 4243533/lib/libpam.so.0.74
40069000-4006a000 rw-p 6000 03:01 4243533/lib/libpam.so.0.74
4006a000-4006d000 r-xp  03:01 4243473/lib/libdl-2.2.2.so
4006d000-4006e000 rw-p 2000 03:01 4243473/lib/libdl-2.2.2.so
4006e000-4007 r-xp  03:01 4243534/lib/libpam_misc.so.0.74
4007-40071000 rw-p 1000 03:01 4243534/lib/libpam_misc.so.0.74
40071000-40197000 r-xp  03:01 6684676/lib/i686/libc-2.2.2.so
40197000-4019d000 rw-p 00125000 03:01 6684676/lib/i686/libc-2.2.2.so
4019d000-401a2000 rw-p  00:00 0
401a2000-401ac000 r-xp  03:01 4243494/lib/libnss_files-2.2.2.so
401ac000-401ad000 rw-p 9000 03:01 4243494/lib/libnss_files-2.2.2.so
401ad000-40231000 rwxp 1000 03:01 1573394
/usr/X11R6/lib/modules/extensions/libglx.so.1.0.1251
40231000-40233000 rwxp  00:00 0
40233000-40579000 rwxp 1000 03:01 622757 /usr/lib/libGLcore.so.1.0.1251
40579000-405d7000 rwxp  00:00 0
405d7000-40607000 rw-p  00:00 0
40607000-42607000 rw-s e000 03:01 181386 /dev/mem
42607000-46607000 rw-s 1000 03:01 185562 /dev/nvidia0
46607000-46617000 rw-s 8000 03:01 185562 /dev/nvidia0
46617000-46627000 rw-s 0080 03:01 185562 /dev/nvidia0
46627000-4662f000 rw-s 4000 03:01 185562 /dev/nvidia0
4662f000-4673 rw-s  00:03 2057240576 /SYSV (deleted)
4673-4773 rw-s  03:01 185562 /dev/nvidia0
4773-4b73 rw-s 1000 03:01 185562 /dev/nvidia0
4b73-4b831000 rw-s  00:03 2057240576 /SYSV (deleted)
4b831000-4b891000 rw-s  00:03 2057404417 /SYSV (deleted)
4b891000-4b8f1000 rw-s  00:03 2058158082 /SYSV (deleted)
4b8f1000-4b951000 rw-s  00:03 2068709388 /SYSV (deleted)
4b951000-4b9b1000 rw-s  00:03 528941061  /SYSV (deleted)
4b9b1000-4ba11000 rw-s  00:03 2058289158 /SYSV (deleted)
4ba11000-4ba71000 rw-s  00:03 221806596  /SYSV (deleted)
4ba71000-4ba73000 rw-p  00:00 0
4ba73000-4ba8b000 rw-s  00:03 1488060424 /SYSV (deleted)
4ba8b000-4baa5000 rw-s  00:03 1488093195 /SYSV (deleted)
4baa5000-4baca000 rw-s  00:03 1488355346 /SYSV (deleted)
4bad1000-4bb31000 rw-s  00:03 2058551305 /SYSV (deleted)
4bb31000-4bbae000 rw-p  00:00 0
4bbc5000-4bc25000 rw-s  00:03 2068676611 /SYSV (deleted)
4bc2e000-4beaa000 rw-p 000ec000 00:00 0
4beaa000-4bf0a000 rw-s  00:03 1487929351 /SYSV (deleted)
4bf0e000-4bf66000 rw-p  00:00 0
4bf6a000-4c022000 rw-p  00:00 0
4c065000-4c0b9000 rw-p 000ec000 00:00 0
4c0d7000-4c353000 rw-p  00:00 0
4c35c000-4c482000 rw-p 000ec000 00:00 0
4c49e000-4c73e000 rw-p  00:00 0
4c73e000-4c7f9000 rw-s  00:03 1488257038 /SYSV (deleted)
4c825000-4c885000 rw-s  00:03 2090762268 /SYSV (deleted)
4c885000-4c996000 rw-p  00:00 0
4c9cc000-4cc78000 rw-p  00:00 0
4cc7b000-4dafc000 rw-p 00554000 00:00 0

Re: VM Requirement Document - v0.0

[John Fremlin]

[...]

>   immediate: RAM, on-chip cache, etc. 
>   fast:  Flash reads, ROMs, etc.
>   medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
>   slow:  Flash writes, floppy disks,  CD-WR burners
>   packeted:  Reads/write should be in as large a packet as possible
> 
> Embedded Case

[...]

> Desktop Case

I'm not sure there's any point in separating the cases like this.  The
complex part of the VM is the caching part => to be a good cache you
must take into account the speed of accesses to the cached medium,
including warm up times for sleepy drives etc.

It would be really cool if the VM could do that, so e.g. in the ideal
world you could connect up a slow harddrive and have its contents
cached as swap on your fast harddrive(!) (not a new idea btw and
already implemented elsewhere). I.e. from the point of view of the VM a
computer is just a group of data storage units and it's allowed to use
up certain parts of each one to do stuff

[...]

-- 

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

artificial latency for a network interface

[Andreas Schuldei]

to simulate a sattelite link, I need to add a latency to a
network connection. 

What is the easiest and best way to do that?

I wanted to do that using two tun devices. 
I had hoped to have a routing like this:

 <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

I need to do it this way and not with iptables help, because it
needs to work also on 2.2.x kernels.

Now I started experimenting with the tun0 interfaces and got
problems: till now I have not succeeded to get a tun0 interface
up. the example code (br_select.c) in the package (as found for
example on sourceforge) looks fishy and does not work too well. 
is it correct that only one /dev/tun file is necessary, but
/dev/tun0 and tun1 are opend for reading and writing?

I also did not manage to point any routes at tun0 or tun1. thoes
interfaces do not show up in the /proc/net/dev either.

only the module is loaded.

I seem to miss something. who has used those devices before and
got them working and could help me debug this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kernel bug at page_alloc.c:81

[Alan Cox]

> 1 After a 'shutdown -h now', I get a kernel bug at page_alloc.c:81
> 2 After being in X (only happens after being in X), I get out of X, and as root 
>I do a 'shutdown -h now'.  It goes through the shutdown process normally, and then 
>after it prints "Syncing hardware clock to system time [ OK ]", I get:
> Modules Loaded ipt_state ipt_limit iptable_filter ipt_LOG ipt_MASQUERADE 
>ipt_REDIRECT iptable_nat ip_conntrack ip_tables ppp_deflate au8820 ppp_async 
>ppp_generic slhc NVdriver
> 

You have binary modules loaded (nvdriver, au8820) that we can't debug and
have no reason to believe are correct. Take your bug report to these people
or duplicate it from a clean boot without loading eith NVdriver or au8820

They have our source, we dont have theirs, so only they can help you

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

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 28.06.01 in 
<[EMAIL PROTECTED]>:

> > > Linux NET4.0 for Linux 2.4
> > > Based upon Swansea University Computer Society NET3.039
> >
> > The later line is not something of interest to most people, and if it
> > happens to be they can research it rather than being force-fed history
> > on bootup.
>
> I've never met a single person who shared that opinion. In fact, quite the
> contrary. It's the main source of currency in this space. If you can't
> toot your own horn and/or share credit what's all of this open source
> stuff worth? We aren't all Mother Theresa now...

Does sed tell you who programmed it on startup?

Awk?

Perl?

Groff?

Gcc?

See a pattern here?

I might add that the most-used program I was one of several authors of  
*never* mentioned a single author in the program messages, with the single  
exception that the initials of the author actually compiling the source  
were part of the version string (in an attempt to control "just which  
patch to 7.53 are you talking about?" syndrome). I can't say this ever  
bothered me.

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

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 28.06.01 in 
<[EMAIL PROTECTED]>:

> On Thu, 28 Jun 2001, David Woodhouse wrote:
> >
> > I agree the messages can be ugly. But they don't do any harm either, and
> > sometimes they're useful.
>
> I consider them harmful when I start getting annoying patches that start
> adding more and more of them.

Or when there are enough boot messages that the dmesg buffer overflows. My  
current (2.2.19pre1 or so) system has that problem.

That *is* harm caused by these messages.

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

PROBLEM: kernel bug at page_alloc.c:81

[khan_55]

1   After a 'shutdown -h now', I get a kernel bug at page_alloc.c:81
2   After being in X (only happens after being in X), I get out of X, and as root 
I do a 'shutdown -h now'.  It goes through the shutdown process normally, and then 
after it prints "Syncing hardware clock to system time [ OK ]", I get:

Turning off swap:  kernel BUG at page_alloc.c:81!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010286
eax: 001f ebx: ecx: 001 edx: c026e0c8
esi: c1159dd4 edi:  ebp:  esp:c5e6bf3c
ds:0018 es:0018 ss:0018
Process swapoff (pid:11402,stackpage=c5e6b000
Stack:  c0227f86 c022801a 0051  c1159dd4 c1159dd4 c012884c c1159dd4
000 c1159dd4 0007d100 07d1 c012b899 c1159dd4 c02d1180 
c02d1180 65ef ffea c012ba93  c7ecb420 c1256ec0 c4051d3c
Call Trace: [] [] [] []
Code: 0f 0b 83 c4 0c 8b 46 18 83 e0 20 74 16 6a 53 68 1a 80 22 c0
/etc/rc0.d/S01halt: line 4: 11402 Segmentation fault $*

After that, it does the rest of the shutdown process normally.
3   kernel
4   /proc/version:  Linux version 2.4.5 (root@p450) (gcc version 2.96 2731 
(Red Hat Linux 7.1 2.96-85)) #1 Mon Jun 25 15:27:28 CDT 2001
5   no oops
6   no script
7   I am using a Pentium II 450Mhz box with 128mb of ram and 128mb of swap.  I 
have a Intel 440BX AGPset motherboard.  Turtle Beach sound with Aureal chipset, nVIDIA 
GeForce 256 DDR video (AGP).  3c905b NIC.  I think all the cards are PCI, modem might 
be ISA.  Hard drives are IDE.
7.1 ver_linux output:
Linux p450 2.4.5 #1 Mon Jun 25 15:27:28 CDT 2001 i686 unknown
 
Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.0.18
util-linux 2.10s
mount  2.10r
modutils   2.4.2
e2fsprogs  1.19
PPP2.4.1
Linux C Library> libc.2.2
Dynamic linker (ldd)   2.2
Procps 2.0.7
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded ipt_state ipt_limit iptable_filter ipt_LOG ipt_MASQUERADE 
ipt_REDIRECT iptable_nat ip_conntrack ip_tables ppp_deflate au8820 ppp_async 
ppp_generic slhc NVdriver

7.2 /proc/cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 5
model name  : Pentium II (Deschutes)
stepping: 2
cpu MHz : 448.069
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr
bogomips: 894.56
7.3 /proc/modules:
ipt_state864   3 (autoclean)
ipt_limit   1136  33 (autoclean)
iptable_filter  1952   0 (autoclean) (unused)
ipt_LOG 3568   1
ipt_MASQUERADE  1392   1
ipt_REDIRECT 992   0 (unused)
iptable_nat14800   0 [ipt_MASQUERADE ipt_REDIRECT]
ip_conntrack   13760   2 [ipt_state ipt_MASQUERADE ipt_REDIRECT iptable_nat]
ip_tables  10688   9 [ipt_state ipt_limit iptable_filter ipt_LOG 
ipt_MASQUERADE ipt_REDIRECT iptable_nat]
ppp_deflate41120   1 (autoclean)
au8820115856   2
ppp_async   6288   1
ppp_generic13232   3 [ppp_deflate ppp_async]
slhc4896   1 [ppp_generic]
NVdriver  659072  15
7.4 /proc/ioports:
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0778-077a : parport0
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
1000-107f : 3Com Corporation 3c905B 100BaseTX [Cyclone]
  1000-107f : eth0
1080-109f : Intel Corporation 82371AB PIIX4 USB
  1080-109f : usb-uhci
10a0-10af : Intel Corporation 82371AB PIIX4 IDE
  10a0-10a7 : ide0
  10a8-10af : ide1
10b0-10b7 : Aureal Semiconductor Vortex 1
10b8-10bf : Aureal Semiconductor Vortex 1
7000-701f : Intel Corporation 82371AB PIIX4 ACPI
8000-803f : Intel Corporation 82371AB PIIX4 ACPI
/proc/iomem:
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000e-000e : Extension ROM
000f-000f : System ROM
0010-040fdbff : System RAM
  0010-0021fc83 : Kernel code
  0021fc84-00281ff7 : Kernel data
040fdc00-040ff7ff : ACPI Tables
040ff800-040ffbff : ACPI Non-volatile Storage
040ffc00-07ff : System RAM
e800-e801 : Aureal Semiconductor Vortex 1
e802-e8020fff : Zoran Corporation ZR36120
e8021000-e802107f : 3Com Corporation 3c905B 100BaseTX [Cyclone]
e900-e9ff : PCI Bus #01
  e900-e9ff : 

Re: VIA 686B/Data Corruption

[Jussi Laako]

"Ryan W. Maple" wrote:
> 
> I remember hearing something about Red Hat disabling UDMA on VIA chips
> across the board.  Maybe that has something to do with it?

Dunno, if the kernel lies. There are four HDs on Promise and one HD and one
CDROM on VIA. This is from currently running 2.4.2-2:

--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge:   VIA vt82c686b
Revision:   ISA 0x40 IDE 0x6
BM-DMA base:0xb800
PCI clock:  33MHz
Master Read  Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:   No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush:  yes yes
End Sector FIFO flush: no  no
Prefetch Buffer:   no  no
Post Write Buffer: no  no
Enabled:  yes yes
Simplex only:  no  no
Cable Type:   40w 40w
---drive0drive1drive2drive3-
Transfer Mode:   UDMA   PIO   PIO   PIO

Address Setup:   30ns  30ns 120ns 120ns
Cmd Active:  90ns  90ns 480ns 480ns
Cmd Recovery:30ns  30ns 480ns 480ns
Data Active: 90ns  90ns 330ns 330ns
Data Recovery:   30ns  30ns 270ns 270ns
Cycle Time:  60ns  90ns  90ns  90ns
Transfer Rate:   33.3MB/s  22.2MB/s  22.2MB/s  22.2MB/s


PDC20265 Chipset.
--- General Status 
Burst Mode   : enabled
Host Mode: Normal
Bus Clocking : 33 PCI Internal
IO pad select: 10 mA
Status Polling Period: 0
Interrupt Check Status Polling Delay : 2
--- Primary Channel  Secondary Channel 
enabled  enabled 
66 Clocking enabled  enabled 
   Mode PCI Mode PCI   
FIFO Empty   FIFO Empty  
--- drive0 - drive1  drive0 -- drive1 -
DMA enabled:yes  yes yes   yes
DMA Mode:   UDMA 4   UDMA 4  UDMA 4UDMA 4
PIO Mode:   PIO 4PIO 4   PIO 4 PIO 4


 - Jussi Laako


-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Cosmetic JFFS patch.

[J . A . Magallon]

On 20010628 Troy Benjegerdes wrote:
>> >
>> > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer,
>> > Roman Weissgaerber
>> > > usb-uhci.c: USB Universal Host Controller Interface driver
>> >
>> > How about "usb-uhci.c: USB Universal Host Controller Interface
>> > driver v1.251"
>> > instead?
>> >

Sorry if this has appeared before in the thread...

I like the boot messages (as everyone running linus, I suppose) because you
know what is it doing really. But boot is now a real mesh. If toy want to
find something you have to read all.

Would't it be nice to give a template or a try to standarise the init or
module insertion messages ? Someone that can have a global view of what
kind of info a subsystem or a driver can print (name of driver, version,
devices detected

Say you can change:

Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI en
abled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
block: queued sectors max/low 169645kB/56548kB, 512 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later

To:

kswapd:
Version: 1.8
pty: 
Version: x
Devices: 256 Unix98 ptys configured
serial:
Version: 5.05b (2001-05-03) with 
Options: MANY_PORTS SHARE_IRQ SERIAL_PCI
Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A
 ttyS01 at 0x02f8 (irq = 3) is a 16550A
rtclock:
Version: 1.10d
ide:
Version: 6.31
..

Just an idea

-- 
J.A. Magallon   #  Let the source be with you...
mailto:[EMAIL PROTECTED]
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac19 #2 SMP Thu Jun 28 00:12:01 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: BIG PROBLEM

[Ralf Baechle]

On Thu, Jun 28, 2001 at 05:35:14PM -0400, Ryan W. Maple wrote:

> Check out:  http://bugs.debian.org/85478
> 
>   "When klogd's LogLine() function encounters a null byte in state
>PARSING_TEXT, it will loop infinitely.  More precisely, copyin()
>will treat the null byte as a delimiter - unlike LogLine(), which
>will invoke copyin() ever and ever again."
> 
> Kinda off-topic, but I just wanted to prove that the bug was in klogd and
> not the kernel. :)

The kernel definately shouldn't communicate with the user using NUL chars.

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

Re: VIA 686B/Data Corruption

[Alan Cox]

> > Interesting. They should be the same code for the VIA driver.
> 
> I remember hearing something about Red Hat disabling UDMA on VIA chips
> across the board.  Maybe that has something to do with it?

The RH 7.1 kernel disables VIA UDMA if the board has a DMI string indiciating
its a KT7 or KT7RAID. The errata kernel applies the fixups that people deduced
by hacking on the VIA stuff

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: Linux and system area networks

[Roland Dreier]

Pekka> If you used sockets, I believe the normal way to use SAN
Pekka> boards is to just make them look like network cards with a
Pekka> large MTU Sure it works, but it's not very efficient :) (I
Pekka> have to admit I've not played with that kind of toys at
Pekka> all, though)

We seem to have come full circle.  My original question was about
providing a better way for sockets applications to take advantage of
SAN hardware.  W2K Datacenter introduces "Winsock Direct," which will
bypass the protocol stack when appropriate.  The Infiniband people are
working on a "Sockets Direct" standard, which is a similar idea.  No
one seems to care about this for Linux.

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

Re: Cosmetic JFFS patch.

[Jeff Garzik]

Olaf Hering wrote:
> kde.o. 2.5?

Good idea!  Graphics needs to be in the kernel to be fast.  Windows
proved that.

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

Re: Cosmetic JFFS patch.

[Olaf Hering]

On Thu, Jun 28, Jeff Garzik wrote:

> John R Lenton wrote:
> > 
> > On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
> > >
> > > KERN_BANNER
> > 
> > cool, what about kbannerd ?
> 
> 
> I'm still pushing for a Perl interpreter in the kernel, let's not forget
> that too.

kde.o. 2.5?


Gruss Olaf

-- 
 $ man clone

BUGS
   Main feature not yet implemented...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Announcing Journaled File System (JFS) release 1.0.0 available

[Steve Lord]

> Hi,

> So I only hope that the smart guys at SGI find a way to prepare the 
> patches the way Linus loves because now the file 
> "patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel 
> and not the new files) is about 174090 bytes which is a lot.
> 
> YA
> 

But that is not a patch intended for Linus, it is intended to enable all
the XFS features. I have a couple of kernel patches which total 46298 bytes
which get you a working XFS filesystem in the kernel, and I could do
lots of things to make them smaller. When you hit header files in the
correct manner for different platforms the size tends to mushroom.
These lines are all in different fcntl.h files for example:

+#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0x8 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0x20 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0x20 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0100 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0x8 /* invisible I/O, for DMAPI/XDSM */
+#define O_INVISIBLE0200 /* invisible I/O, for DMAPI/XDSM */

You make the patches look a lot bigger than they really are. There is
a difference between a patch which is placing things in the correct
places and one which is designed to be as short as possible.

Steve



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

Re: VIA 686B/Data Corruption

[Ryan W. Maple]

On Thu, 28 Jun 2001, Alan Cox wrote:

> > Just tested RedHat's 2.4.3-12 and 2.4.5-ac19 on A7V133 mobo. RedHat's kernel
> > seems to work without lockups, but 2.4.5-ac19 doesn't (locks up at boot,
> > compiled w/o athlon optimization and ACPI), so no changes on that.
> 
> Interesting. They should be the same code for the VIA driver.

I remember hearing something about Red Hat disabling UDMA on VIA chips
across the board.  Maybe that has something to do with it?

-r

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

[Ryan W. Maple]

On Thu, 28 Jun 2001, Justin Guyett wrote:

> On Thu, 28 Jun 2001, Ralf Baechle wrote:
> 
> > Some versions of the 3c59x driver emit a NUL character on bootup which makes
> > klogd suck CPU.  This is fixed in 2.4.5, dunno about 2.4.4.
> 
> sysklogd 1.4.1 changelog lists a no busyloop fix.

Check out:  http://bugs.debian.org/85478

  "When klogd's LogLine() function encounters a null byte in state
   PARSING_TEXT, it will loop infinitely.  More precisely, copyin()
   will treat the null byte as a delimiter - unlike LogLine(), which
   will invoke copyin() ever and ever again."

Kinda off-topic, but I just wanted to prove that the bug was in klogd and
not the kernel. :)

-r

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

[Jeff Garzik]

John R Lenton wrote:
> 
> On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
> >
> > KERN_BANNER
> 
> cool, what about kbannerd ?


I'm still pushing for a Perl interpreter in the kernel, let's not forget
that too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[John R Lenton]

On Thu, Jun 28, 2001 at 05:25:33PM +0100, David Woodhouse wrote:
> 
> KERN_BANNER

cool, what about kbannerd ?


-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
A longo prazo, estaremos todos mortos.
-- John Maynard Keynes 

 PGP signature

Re: VIA 686B/Data Corruption

[Alan Cox]

> Just tested RedHat's 2.4.3-12 and 2.4.5-ac19 on A7V133 mobo. RedHat's kernel
> seems to work without lockups, but 2.4.5-ac19 doesn't (locks up at boot,
> compiled w/o athlon optimization and ACPI), so no changes on that.

Interesting. They should be the same code for the VIA driver.

> 2.4.3-12 although seems to have the reiserfs unmount lock race, so I can't
> use it... :(

Possibly.  If so file that in bugzilla so it gets fixed

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

Re: VIA 686B/Data Corruption

[Jussi Laako]

A little test report follows...

Just tested RedHat's 2.4.3-12 and 2.4.5-ac19 on A7V133 mobo. RedHat's kernel
seems to work without lockups, but 2.4.5-ac19 doesn't (locks up at boot,
compiled w/o athlon optimization and ACPI), so no changes on that.

2.4.3-12 also correctly detects cable connected to VIA controller as 40-w
while 2.4.5-ac19 still detects it as 80-w.

2.4.3-12 although seems to have the reiserfs unmount lock race, so I can't
use it... :(

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Announcing Journaled File System (JFS) release 1.0.0 available

[Alan Cox]

> JFS doesn't require any modifications to existing code, its only an 
> addition.

It depends how clean the interface is. It is possible to avoid changing
core code by writing your own clone of it - that isnt good and doesnt make
people happy sometimes.

> XFS on the contrary is far more intrusive.

Right - XFS I think is 2.5 material - for cleanup time, for the core changes
it wants to provide. Maybe as a 2.4 backport later


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

[Jeff Garzik]

Tom Gall wrote:
> Gérard Roudier wrote:
> > The driver checks against PCI bus+dev+func in 2 situations:
> >
> > 1) To apply the boot order that user can set up in the controller NVRAMs.
> > 2) To detect buggy double reporting of the same device by the kernel PCI
> >code (this made lot of troubles at some time).
> 
> Thanks much for the clarification. Do you still battle buggy double reporting?
> Has this been fixed? Is it a bug on some specific architecture?

I've seen it occur in 2.2.x in buggy drivers, but in 2.4 the driver
should -not- have to check for this.  The PCI core takes care of it.

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

Re: Tvmixer Oops

[Udo A. Steinberg]

Gerd Knorr wrote:
> 
> On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote:
> >
> > Hello,
> >
> > Attached is the trace of an oops which seems to be caused by the
> > tvmixer code. Tvmixer is compiled monolithically into the kernel,
> > the rest of bttv is compiled as modules.
> 
> Any hints on how to reproduce that one?

I just got another one, however I still cannot reliably reproduce it.

Regards,
Udo.


ksymoops 2.4.1 on i686 2.4.5-ac18.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5-ac18/ (default)
 -m /boot/System.map-2.4.5-ac18 (specified)
 
Unable to handle kernel NULL pointer dereference at virtual address 002c
c01b8faa
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax:    ebx: ccb16980   ecx: 0010   edx: 
esi: c02f7fc0   edi:    ebp: 0010   esp: cf351ef4
ds: 0018   es: 0018   ss: 0018
Process rat-4.2.19-medi (pid: 5876, stackpage=cf351000)
Stack: c028b580  c01cfa68 c5c0dc40 c85162c0  c85162c0 c5c0dc40
   c14a82c0 c028ab60 c85162c0 c5c0dc40 c14a82c0 c5c0dc40 ffeb 0002
   c013900a c5c0dc40 c012febe c5c0dc40 c85162c0 c85162c0 c5c0dc40 
Call Trace: [] [] [] [] []
   [] []
Code: 83 78 2c 00 74 09 50 8b 40 2c ff d0 83 c4 04 31 c0 5b 5e c3

>>EIP; c01b8faa<=
Trace; c01cfa68 
Trace; c013900a 
Trace; c012febe 
Trace; c012ef5d 
Trace; c012ee92 
Trace; c012f186 
Trace; c0106bfb 
Code;  c01b8faa 
 <_EIP>:
Code;  c01b8faa<=
   0:   83 78 2c 00   cmpl   $0x0,0x2c(%eax)   <=
Code;  c01b8fae 
   4:   74 09 je f <_EIP+0xf> c01b8fb9 
Code;  c01b8fb0 
   6:   50push   %eax
Code;  c01b8fb1 
   7:   8b 40 2c  mov0x2c(%eax),%eax
Code;  c01b8fb4 
   a:   ff d0 call   *%eax
Code;  c01b8fb6 
   c:   83 c4 04  add$0x4,%esp
Code;  c01b8fb9 
   f:   31 c0 xor%eax,%eax
Code;  c01b8fbb 
  11:   5bpop%ebx
Code;  c01b8fbc 
  12:   5epop%esi
Code;  c01b8fbd 
  13:   c3ret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: BIG PROBLEM

[Justin Guyett]

On Thu, 28 Jun 2001, Ralf Baechle wrote:

> Some versions of the 3c59x driver emit a NUL character on bootup which makes
> klogd suck CPU.  This is fixed in 2.4.5, dunno about 2.4.4.

sysklogd 1.4.1 changelog lists a no busyloop fix.


justin

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

Re: Microsoft and Xenix.

[Thomas Dodd]

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

And ATARI goofed by not including more than GEM in the ST(e).
Should have used the whole system like the TT and Falcon did.

> Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line

If you see them, tell them an old STe user thanks them for there
work. Without them I might never have headed to Unix :)

Vielen Dank Herren.

> shell and desktop replacement for the Atari that was fairly successful
> shareware for a while ... now how was it called? The CLI was Mupfel
> (German for shell is Muschel, and there was a kid's TV character who
> pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another

I still have Gemini on a Disk for my STe. The SCSI adaptor died,
so I don't know if the data is still good though.

Then I tried the Minix port MinT (Mint is not TOS :)
and was hooked on Unix. If I could get my SCSI adaptor
fixed/replaced I'd still have my STe running, maybe
even get a memory card (for > 4Meg) and a CPU upgrade
(68000 is slow, get 68030 or 40 like the Falcon)

Then I could run Linux on it (it need that math co-proc)

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

[Tom Gall]

Gérard Roudier wrote:
> 
> On Wed, 27 Jun 2001, Jeff Garzik wrote:
> 
> > Tom Gall wrote:
> > > Well you have device drivers like the symbios scsi driver for instance that
> > > tries to determine if it's seen a card before. It does this by looking at the
> > > bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> > > on the same bus number, same dev number etc yet they are in different PCI
> > > domains.
> > >
> > > Is this a device driver bug or feature?
> >
> > I hesitate to call it a device driver bug, because that was likely the
> > best decision Gerard could make at the time.
> >
> > However, I think the driver (only going by your description) would be
> > more correct to use a pointer to struct pci_dev.  We have a token in the
> > kernel that is guaranteed 100% unique to any given PCI device:  the
> > pointer to its struct pci_dev.
> 
> The driver checks against PCI bus+dev+func in 2 situations:
> 
> 1) To apply the boot order that user can set up in the controller NVRAMs.
> 2) To detect buggy double reporting of the same device by the kernel PCI
>code (this made lot of troubles at some time).

Thanks much for the clarification. Do you still battle buggy double reporting?
Has this been fixed? Is it a bug on some specific architecture?
 
> The great bug is to invent useless abstractions that don't match reality.
> Such brain masturbation leads to confusion (hence subtle bugs)  and
> useless software bloatage (thus _real_ resource wastage).

Agreed. (A couple of my posts last night didn't make it through... appears that
us.ibm.com isn't set up entirely right for ENC)

> If we want to handle _real_ PCI bus domains, we just have to add a domain
> number to identify a _real_ PCI device. Anything that wants to hide such
> reality in some opaque data looks like brain masturbation to me.

Again also agreed. Now I'm REALLY anxious for 2.5 8-)

>   Gérard.

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announcing Journaled File System (JFS) release 1.0.0 available

[Yaacov Akiba Slama]

Hi,
 From what I understand from Linus's mail to lkml, there is a difference 
between JFS and XFS:
JFS doesn't require any modifications to existing code, its only an 
addition.
XFS on the contrary is far more intrusive.
So it seems that even if JFS is less complete than XFS (no ACL, quotas 
for instance), and even if it is less robust (I don't know if it is, I 
only used so far XFS and ext3 -with success), its inclusion in current 
kernel is a lot easier and I don't see any (technical) reason for not 
including it.
I don't think ext3 will have difficulties to be included in the kernel 
because a) the guys working on it are lk veterans and b) Redhat (VA 
also) is already including it in its kernels (rawhide AND 7.1 update).
So I only hope that the smart guys at SGI find a way to prepare the 
patches the way Linus loves because now the file 
"patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel 
and not the new files) is about 174090 bytes which is a lot.

YA


*Kervin Pierre* (/ [EMAIL PROTECTED]/  ) wrote :

Hello,

Question.

Are there plans to include JFS and XFS in the kernel?

Both those projects have been declared stable by their development
teams, and I'm guessing they can now be included as experimental, just
as reiser has been.

Just curious,
-Kervin

Steve Best wrote:
/> /
/> June 28, 2001:/
/> /
/> IBM is pleased to announce the v 1.0.0 release of the open source/
/> Journaled File System (JFS), a high-performance, and scalable file/
/> system for Linux./
/> /
/> http://oss.software.ibm.com/jfs /
/> /
/> JFS is widely recognized as an industry-leading high-performance file/
/> system, providing rapid recovery from a system power outage or crash/
/> and the ability to support extremely large disk configurations. The/
/> open source JFS is based on proven journaled file system technology/
/> that is available in a variety of operating systems such as AIX and/
/> OS/2./
/> /
/> JFS was open sourced under the GNU General Public License with release/
/> v 0.0.1 on February 2. 2000 and has matured with help and support of the/
/> open source community and its "Enterprise ready" release today is due/
/> to joint work between the JFS team and the community. Following the/
/> development style of "Release Early, Release Often" the JFS open source/
/> project has seen 37 interim releases as part of the process./
/> /
/> The open source JFS for Linux v 1.0.0 is released for the Linux 2.4.x/
/> kernel and offers the following advanced features:/
/> /
/> * Fast recovery after a system crash or power outage/
/> /
/> * Journaling for file system integrity/
/> /
/> * Journaling of meta-data only/
/> /
/> * Extent-based allocation/
/> /
/> * Excellent overall performance/
/> /
/> * 64 bit file system/
/> /
/> * Built to scale. In memory and on-disk data structures are designed to/
/> scale beyond practical limit/
/> /
/> * Designed to operate on SMP hardware and also a great file system for/
/> your workstation/
/> /
/> * Completely free of prerequisite kernel changes (easy integration path/
/> into the kernel source tree)/
/> /
/> * Detailed Howto for creating a system with JFS as the /boot and /root/
/> file system using lilo/
/> /
/> * Complete set of file system utilities/
/> /
/> * On-disk compatibility with OS/2 JFS file systems/
/> /
/> The JFS Team (Barry Arndt, Steve Best, Dave Kleikamp)/
/> /
/> -/
/> To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in/
/> the body of a message to [EMAIL PROTECTED]/
/> More majordomo info at http://vger.kernel.org/majordomo-info.html /
/> Please read the FAQ at http://www.tux.org/lkml/ /
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

Re: RFC: Changes for PCI

[Jeff Garzik]

Gérard Roudier wrote:
> The driver checks against PCI bus+dev+func in 2 situations:
> 
> 1) To apply the boot order that user can set up in the controller NVRAMs.
> 2) To detect buggy double reporting of the same device by the kernel PCI
>code (this made lot of troubles at some time).

Cool.  The premise of the thread was that you merely were checking for
uniqueness, not order.  That changes our answer...


> The great bug is to invent useless abstractions that don't match reality.
> Such brain masturbation leads to confusion (hence subtle bugs)  and
> useless software bloatage (thus _real_ resource wastage).
> 
> If we want to handle _real_ PCI bus domains, we just have to add a domain
> number to identify a _real_ PCI device. Anything that wants to hide such
> reality in some opaque data looks like brain masturbation to me.

I think all of us agree on this:  in 2.5, our solution is to have a
system domain number, which increases from zero each time you add sbus,
pci bus, isa bus, etc.

For 2.4, non-x86 arches first had to deal with PCI domains, so the
solution was to stick "arch-specific data" into pci_dev->sysdata, which
in some cases was the PCI domain number.

So, you have an ugly solution in drivers for 2.4 if you need to know PCI
domain for what reason, and a clean solution in 2.5.

Jeff


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

Re: BIG PROBLEM

[Ralf Baechle]

On Thu, Jun 28, 2001 at 06:49:46PM -, james bond wrote:

> 1-systeme hangs when i try ton compile anything
> 
> i've  compiled the kernel 2.4.4 , once i finish and boot the first time on 
> 2.4.4 everything goses ok ,
> only too problemes
> 1st-  klogd takes 100%  CPU time

Some versions of the 3c59x driver emit a NUL character on bootup which makes
klogd suck CPU.  This is fixed in 2.4.5, dunno about 2.4.4.

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

[Gérard Roudier]

On Wed, 27 Jun 2001, Jeff Garzik wrote:

> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> > on the same bus number, same dev number etc yet they are in different PCI
> > domains.
> >
> > Is this a device driver bug or feature?
>
> I hesitate to call it a device driver bug, because that was likely the
> best decision Gerard could make at the time.
>
> However, I think the driver (only going by your description) would be
> more correct to use a pointer to struct pci_dev.  We have a token in the
> kernel that is guaranteed 100% unique to any given PCI device:  the
> pointer to its struct pci_dev.

The driver checks against PCI bus+dev+func in 2 situations:

1) To apply the boot order that user can set up in the controller NVRAMs.
2) To detect buggy double reporting of the same device by the kernel PCI
   code (this made lot of troubles at some time).

The great bug is to invent useless abstractions that don't match reality.
Such brain masturbation leads to confusion (hence subtle bugs)  and
useless software bloatage (thus _real_ resource wastage).

If we want to handle _real_ PCI bus domains, we just have to add a domain
number to identify a _real_ PCI device. Anything that wants to hide such
reality in some opaque data looks like brain masturbation to me.

  Gérard.

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

Re: AMD thunderbird oops

[Tim Moore]

[EMAIL PROTECTED] wrote:
> 
> Well considering the other night the power supply went dead, I think that is part of 
>the problem.  It is brand new, and I am being sent another one (free of course).
> 
> I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, 
>Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it 
>may be a kt7a thing.
> 
> Several people said that random (keyword here) oopses are more often a hardware 
>thing.  I wonder if the kt7a is going to be able to perform  fully loaded..
> 
> is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 
>6pci, agp, 512MEG+ RAM?
> 
> Joe

Similar board (KA7) had non-heat related lockups with 133MHz FSB (1756
BogoM).  100MHz FSB + 4 way interleave has been fast and stable (1690
BogoM).

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.00 seconds =128.00 MB/sec

Abit KA7 (VT82C686a, rev 22), Athlon 850, 2x256MB PC133@CL2, 2 ide,
CR-RW, Colorado Travan, linux 2.2.20p6+ide.2.2.19.04092001, SPI 300W
power, PCI: Firewire, Netgear FA310TX, Turtle Beach Santa Cruz audio,
AGP: 32MB TNT2.

CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_1GB=y
CONFIG_MTRR=y

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5-ac20, make menuconfig problem

[f5ibh]

Hi Alan and others,

I'm trying to build 2.4.5-ac20, I get the following error when entering the
submenu  "Ethernet (10 or 100Mbit)  --->"  of "[*] Network device support"


Menuconfig has encountered a possible error in one of the kernel's
configuration files and is unable to continue.  Here is the error
report:

 Q> scripts/Menuconfig: MCmenu31: command not found

 Please report this to the maintainer <[EMAIL PROTECTED]>.  You may also
 send a problem report to <[EMAIL PROTECTED]>.

 Please indicate the kernel version you are trying to configure and
 which menu you were trying to enter when this error occurred.

 make: *** [menuconfig] Erreur 1



If I try to compile this kernel with the .config from -ac19, I get the
following errors :

make[4]: Entre dans le répertoire
`/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp'
gcc -D__KERNEL__ -I/usr/src/kernel-sources-2.4.5-ac20/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6
-DEXPORT_SYMTAB -c pnp_bios.c
pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info'
follows non-static
pnp_bios.c:432: warning: no semicolon at end of struct or union
pnp_bios.c:432: parse error before `u16'
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:442: warning: function declaration isn't a prototype
pnp_bios.c:442: warning: extern declaration of `daemonize' doesn't match global
one
pnp_bios.c:445: parse error before `struct'
pnp_bios.c:445: warning: unused variable `err'
pnp_bios.c: At top level:
pnp_bios.c:435: storage size of `dock' isn't known
pnp_bios.c:435: warning: `dock' defined but not used
pnp_bios.c:440: warning: `pnp_dock_thread' defined but not used
{standard input}: Assembler messages:
{standard input}:63: Warning: indirect lcall without `*'
{standard input}:144: Warning: indirect lcall without `*'
{standard input}:202: Warning: indirect lcall without `*'
{standard input}:240: Warning: indirect lcall without `*'
make[4]: *** [pnp_bios.o] Erreur 1
make[4]: Quitte le répertoire `/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp'
make[3]: *** [first_rule] Erreur 2
make[3]: Quitte le répertoire `/usr/src/kernel-sources-2.4.5-ac20/drivers/pnp'
make[2]: *** [_subdir_pnp] Erreur 2
make[2]: Quitte le répertoire `/usr/src/kernel-sources-2.4.5-ac20/drivers'
make[1]: *** [_dir_drivers] Erreur 2
make[1]: Quitte le répertoire `/usr/src/kernel-sources-2.4.5-ac20'
make: *** [stamp-build] Erreur 2

--
Regards
Jean-Luc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Cosmetic JFFS patch.

[Craig Milo Rogers]

>Print all copyright, config, etc. as KERN_DEBUG.

How about a new level, say "KERN_CONFIG", with a "show-config"
parameter to enable displaying KERN_CONFIG messages?

Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A signal fairy tale

[Daniel R. Kegel]

Jamie wrote:
> Daniel R. Kegel wrote:
> > Christopher Smith <[EMAIL PROTECTED]> wrote:
> > > Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > > > Btw, this functionality is already available using sigaction().  Just
> > > > search for a signal whose handler is SIG_DFL.  If you then block that
> > > > signal before changing, checking the result, and unblocking the signal,
> > > > you can avoid race conditions too.  (This is what my programs do).
> > > 
> > > It's more than whether a signal is blocked or not, unfortunately. Lots of 
> > > applications will invoke sigwaitinfo() on whatever the current signal mask 
> > > is, which means you can't rely on sigaction to solve your problems. :-(
> > 
> > As Chris points out, allocating a signal by the scheme Jamie
> > describes is neccessary but not sufficient.  The problem Chris
> > ran into is that he allocated a signal fair and square, only to find
> > the application picking it up via sigwaitinfo()!
> 
> I check that the handler is not SIG_DFL, but perhaps my assumption that
> any sigwaitinfo() user of a signal would set SA_SIGINFO and set the
> handler to non-SIG_DFL is mistaken?
 
I think your assumption is correct.  The problem is that the
application in question (Sun's JDK 1.4 beta) does something like this:
sigprocmask(0, NULL, );
sigwaitinfo(, );
So even though Chris did set the handler for his signal to non-SIG_DFL,
the application didn't care, and sucked all his signal notifications
away from him.

> > Yes, this is a bug in the application -- but it's interesting that this
> > bug only shows up when you try to integrate a new, well-behaved, library 
> > into the app.  It's a fragile part of the Unix API.  sigopen() is
> > a way for libraries to defend themselves against misuse of sigwaitinfo()
> > by big applications over which you have no control.
> > 
> > So sigopen() is a technological fix to a social problem, I guess.
> 
> Requiring all libraries to use the sigopen() as you specified it just
> isn't going to work, because you would have to make big changes to the
> libraries.

I didn't mean to require any library to change at all.  This is
an optional thing; a library can use this technique if it wants to
insulate itself from badly behaved applications.

> Sometimes you actually do need SIGRTxxx signals to be delivered using
> signal handlers!

No objection there, I agree.
 
> Also as it was specified, you are reduced to reading one type of signal
> at a time, or using select().  Often you wish to check several signals.
> For example, in my programs sigwaitinfo() calls check for SIGIO, SIGURG
> and SIGRTxxx at least.  Therefore siginfo(), if implemented, should take
> a sigset_t, not a signal number.
 
I have no objection to sigopen() taking a sigset_t *.

> The problem of when you actually want to receive an allocated signal
> through a handler is, IMHO, best solved by permitting sigaction() and
> signal delivery on signals that have been opened with sigopen().

sigopen() essentially installs a special signal handler (say, SIG_OPEN).
If sigaction() can override that, it should probably close the file descriptor, too.

I can buy that, perhaps, even though it makes libraries using sigopen()
somewhat more vulnerable to poorly behaved applications.  I think the
present application doesn't misbehave badly enough that it would try to
install a signal handler over Chris's.
 
> However, it would be ok to require a flag SA_SIGOPEN to sigaction() to
> prevent it from returning EBUSY.

That'd be ok.

Another issue someone raised: 

> would read() on this fd require the kernel to copy every byte of the siginfo_t?  

IMHO no; read() would leave undefined any bytes that would not have been set by 
sigwaitinfo().  The kernel could set them to zero or leave them untouched,
as desired.

Another issue:

AFAIK, there's no 'read with a timeout' system call for file descriptors, so
if you needed the equivalent of sigtimedwait(),
you might end up doing a select on the sigopen fd, which is an extra
system call.  (I wish Posix had invented sigopen() and readtimedwait() instead of 
sigtimedwait...)

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

Re: TCP/IP stack

[Matti Aarnio]

  Richard, should there be (is there?)  linux-networking-faq, or can this
  be put into the  linux-kernel  faq ?

On Thu, Jun 28, 2001 at 10:33:46AM -0400, Michael J Clark wrote:
> hey guys,
> 
> I have been reading through TCP/IP Illustrated Vol 2 and the linux 
> source.

   That book describes  BSD  implementation.

   Linux code has been written completely independently, and using
   fundamentally different base structure -- instead of PCBs containing
   chains of segments, Linux has  SKBs  with entire segment contiguous
   in it.

   Function, and structure names are different, naturally.

> Mike

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

Re: AMD thunderbird oops

[Tim Moore]

> Some ASUS boards (mostly P3B-F) would either freeze or self reboot when using
> PhotoShop 5. Everything else would run perfectly.
> 
> Disabling MMX optimizations in this software would "solve" the problem. Another
> solution found on the web (sorry, I don't have the URL at hand) is to add two
> or three additionnal capacitors on the back of the board, to solve the electric
> instabilities that cause the reboots.

This is incorrect information.  Abit BP6 early revs suffered under load
from a 100uF cap (EC10, between the CPU sockets) that should have been
1500uF.  This was compounded by a weak or otherwise inadequate power
supply.

Having run literally 7 P3F-Fs and 6 of their P2B-F predecessors, not a
single one had any problems.  They were the premiere overclocking boards
of their day.

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/

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Alan Cox]

> > Intel specifically state that you cannot use CMOV without checking
> > for it. Its actually a gcc/binutils tool bug. The CPU is right.
> 
> How is that a gcc bug?  You tell the compiler to generate cmov, you run
> it on a CPU that doesn't have it, you get what you deserve.  There's
> really nothing the tools can do about that.

I tell gcc to buld for the 'i686' architecture definition. It in fact builds
for the i686 architecture assuming an optional feature. Intel's own PPro doc
is quite explicit that cmov could go away again in future chips.

So cmov should not have been in the 686 machine definition.

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: Asus CUV4X-DLS

[J. Nick Koston]

   It seems to be ok with 2.4.5-ac19, so I guess I'll just wait for
2.4.6 and hope that resolves it for good.

 Nick

On Thu, Jun 28, 2001 at 08:27:17AM -0400, John Cavan wrote:
> Envelope-to: [EMAIL PROTECTED]
> Delivery-date: Thu, 28 Jun 2001 08:26:20 -0400
> Date: Thu, 28 Jun 2001 08:27:17 -0400
> From: John Cavan <[EMAIL PROTECTED]>
> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.5-ac18 i686)
> X-Accept-Language: en
> To: "J. Nick Koston" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Asus CUV4X-DLS
> 
> John Cavan wrote:
> > I have an AIC7 based SCSI card in my machine as well, hooked up to a
> > Jaz. I haven't actually used it in ages, but I'll test it to see of the
> > problem is apparent on CUV4X-D board as well.
> 
> First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the
> same commands you did, also no problem...
> 
> That would imply, at least, that the SCSI drivers are not at fault here.
> 
> John

-- 

BurstNET -  The Speed the Internet Travels

To place an order, or for more info, contact;
BurstNET Technologies, Inc. - BurstNET
Toll Free 24/7/365 Support: 1-877-BURSTNET
Phone (570) 389-1100 - Fax (570) 389-1855=20
http://www.burst.net - [EMAIL PROTECTED]
P.O. Box #400  Bloomsburg, PA 17815-0400 USA
A World Wide Leader in Web Hosting & Internet Solutions
The Best Value For Your Dollar On The Net!

Copyright 1996-2000 ©
BurstNET Technologies, Inc.
All Rights Reserved.

 PGP signature

Re: Cosmetic JFFS patch.

[Jeff Garzik]

Linus Torvalds wrote:
> Especially as "dmesg" will output even the debugging messages
> that do not actually end up being printed on the screen unless explicitly
> asked for.

Nifty, I did not know that.  Makes all kinds of sense, though.  Silly
me...


> I'd also like to acknowledge the fact that at bootup it's usually very
> nice to see "what was the last message it printed before it hung", and
> that there's a fair reason for drivers to print out a single line of "I
> just registered myself" for that reason. If that line happens to contain a
> version string, all the better.

Excellent.

Jeff


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

Re: BIG PROBLEM

[Ryan W. Maple]

On Thu, 28 Jun 2001, Alan Cox wrote:

> > i've  compiled the kernel 2.4.4 , once i finish and boot the first time on 
> > 2.4.4 everything goses ok ,
> > only too problemes
> > 1st-  klogd takes 100%  CPU time
> 
> Old old versions of klogd had bugs where they would do that. If there is
> a continuous problem it may also do so - does 'dmesg' show anything ?

I don't think it's limited to "old old" versions.  Version 1.3 would hit
100% CPU (DoS-style) when it received NULL bytes IIRC.

  http://lists.jammed.com/owl-users/2001/05/.html

>From what I remember, this happened with some of the 3com ethernet drivers
(the NULL bytes).  Maybe this is his problem wrt klogd...

Ryan

 +-- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --+
   Ryan W. Maple  "I dunno, I dream in Perl sometimes..."  -LW
   Guardian Digital, Inc. [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: Cosmetic JFFS patch.

[Jeff Garzik]

Gerhard Mack wrote:
> 
> On Thu, 28 Jun 2001, Jeff Garzik wrote:
> 
> > Linus Torvalds wrote:
> > > Things like version strings etc sound useful, but the fact is that the
> > > only _real_ problem it has ever solved for anybody is when somebody thinks
> > > they install a new kernel, and forgets to run "lilo" or something. But
> > > even that information you really get from a simple "uname -a".
> > >
> > > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care
> > > that we have quota version "dquot_6.4.0"? No. Do we want to get the
> > > version printed for every single driver we load? No.
> > >
> > > If people care about version printing, it (a) only makes sense for modules
> > > and (b) should therefore maybe be done by the module loader. And modules
> > > already have the MODULE_DESCRIPTION() thing, so they should NOT printk it
> > > on their own.  modprobe can do it if it wants to.
> >
> > As Alan said, driver versions are incredibly useful.  People use update
> > their drivers over top of kernel drivers all the time.  Vendors do it
> > too.  "Run dmesg and e-mail me the output" is 1000 times more simple for
> > end users.
> 
> Why not a generic way to query the drivers for version info from
> userspace?

For NICs at least, there's already a generic way... :)

Sigh, in my technically correct heart I know putting driver versions in
dmesg is probably not the best thing, but it makes support -so- -much-
easier that I am not inclined to change the existing code.

FWIW, all the NIC drivers I mess with (most originated from Becker)
should print out:


eth0: short product name, base addr, MAC addr, irq
eth1: ...
eth2: ...

I grant you there are tons of exceptions even in NIC drivers, but that
is the goal I am striving for.  One line version, plus one line per
registered netif.

FWIW I find usb and parport messages exceptionally verbose, but some of
that is probably related to KERN_DEBUG being set in the bootloader or
kernel/printk.c or somewhere...

Jeff


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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Thu, 28 Jun 2001, Jeff Garzik wrote:
>
> As Alan said, driver versions are incredibly useful.  People use update
> their drivers over top of kernel drivers all the time.  Vendors do it
> too.  "Run dmesg and e-mail me the output" is 1000 times more simple for
> end users.

Fair enough. Especially as "dmesg" will output even the debugging messages
that do not actually end up being printed on the screen unless explicitly
asked for.

I'd also like to acknowledge the fact that at bootup it's usually very
nice to see "what was the last message it printed before it hung", and
that there's a fair reason for drivers to print out a single line of "I
just registered myself" for that reason. If that line happens to contain a
version string, all the better.

And if the user has to boot with "debug" to see all the information when
the machine hangs at bootup (when you can't just mail dmesg), that's
probably acceptable.

Linus

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

[Gerhard Mack]

On Thu, 28 Jun 2001, Jeff Garzik wrote:

> Linus Torvalds wrote:
> > Things like version strings etc sound useful, but the fact is that the
> > only _real_ problem it has ever solved for anybody is when somebody thinks
> > they install a new kernel, and forgets to run "lilo" or something. But
> > even that information you really get from a simple "uname -a".
> > 
> > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care
> > that we have quota version "dquot_6.4.0"? No. Do we want to get the
> > version printed for every single driver we load? No.
> > 
> > If people care about version printing, it (a) only makes sense for modules
> > and (b) should therefore maybe be done by the module loader. And modules
> > already have the MODULE_DESCRIPTION() thing, so they should NOT printk it
> > on their own.  modprobe can do it if it wants to.
> 
> As Alan said, driver versions are incredibly useful.  People use update
> their drivers over top of kernel drivers all the time.  Vendors do it
> too.  "Run dmesg and e-mail me the output" is 1000 times more simple for
> end users.

Why not a generic way to query the drivers for version info from
userspace?
 
Gerhard

--
Gerhard Mack

[EMAIL PROTECTED]

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

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

bzImage > 0xefff0 will not boot from floppy

[Pavel Machek]

Hi!

...it will loop forever. I have fix that allows up-to 0x0
bzImages, but it is *ugly*. This seems better; please apply.

Pavel
Index: build.c
===
RCS file: /home/cvs/Repository/linux/arch/i386/boot/tools/build.c,v
retrieving revision 1.2
diff -u -u -r1.2 build.c
--- build.c 2001/04/20 00:59:29 1.2
+++ build.c 2001/06/26 15:13:34
@@ -154,7 +154,7 @@
if (sys_size > (is_big_kernel ? 0x28000 : DEF_SYSSIZE))
die("System is too big. Try using %smodules.",
is_big_kernel ? "" : "bzImage or ");
-   if (sys_size > 0x)
+   if (sys_size > 0xefff)
fprintf(stderr,"warning: kernel is too big for standalone boot "
"from floppy\n");
while (sz > 0) {

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

Re: Linux and system area networks

[Pekka Pietikainen]

On Thu, Jun 28, 2001 at 07:28:20PM +0200, Bogdan Costescu wrote:
> On Wed, 27 Jun 2001, Pekka Pietikainen wrote:
> 
> I'm sorry, but I don't understand your reference to MPI here. MPI is a
> high-level API; MPI can run on top of whatever communication features
> exists: TCP/IP, shared memory, VI, etc.

Well, the way I understood the discussion was about how you can
utilize your new $$$ SAN boards well with your existing applications.
If you used something like MPI you just switch to a new implementation
optimized for your network (and hope the new one is compatible
with your code ;) )

Of course you can use some lower-level API and get better 
performance, but your programs will undoubtedly be more complicated
and probably need to be rewritten for new APIs every now and then.

If you used sockets, I believe the normal way to use SAN boards
is to just make them look like network cards with a large MTU 
Sure it works, but it's not very efficient :) (I have to admit 
I've not played with that kind of toys at all, though)

-- 
Pekka Pietikainen



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

Re: [PATCH 2.4.5-ac12] New Sony Vaio Motion Eye camera driver

[volodya]

Sorry for replying a couple of weeks late - I don't check linux-kernel
that often.

On Wed, 13 Jun 2001, Stelian Pop wrote:

> > I got just the YUV code from Gatos, and a few months ago it took less than
> > an hour to merge just that part (and most of that was compiling and
> > testing).
> 
> Me too. After some days playing with it it seems that the Rage Mobility
> Card (from the Vaio Picturebook C1VE <- that's where we started the
> discussion):
>   - has almost no acceleration in XFree, including the 4.1.0 release
>   - has Xv YUV->RGB acceleration in Gatos (but that's all, no direct
> video input etc).

it has, but it is disabled as normally notebooks don't have video in. 
Well, some do but this is a grey area. ATI says there supposed to be a
multimedia table that says if you have a decoder on board - but some
manufacturers don't include it. In this case the driver cannot know
whether the decoder is present and disables the interface to avoid
lockups.

I imagine it is either using ZV port or VIP/MPP connector - I'll be happy
to help you to get it to work, provided you know the part that produces
video stream.

> 
> > The rest of Gatos is obviously more experimental, but the YUV code looks
> > quite sane.
> 
> Well, not quite... I've had several X lockups while using the YUV 
> acceleration code. Let's say one lockup per half an hour.

That's not supposed to happen - let me know what causes it.. what you are
using, etc..

> 
> Even the performances are controversial: with 320x240, I achieve 
> great performance with xawtv/meye driver, I can even use the hardware
> scaling facilities (well, the xawtv sources need a little hacking for
> that), but in 640x480 the framerate achieved with Xv is below the
> one I get by converting YUV->RGB in software...

You have to be careful here - you can't write to the framebuffer without 
waiting for engine to go idle. Otherwise it'll lockup.

> 
> But the main question remains: does the MotionEye camera support
> overlay or not ? It could be that it is connected to the feature
> connector of the ATI board for doing direct video input/output
> (but no X driver recognizes this connector today). The motion jpeg
> chip this camera is based on definately has a video output.

I can help you get this to work.

> 
> Or it could just be the application who gets YUV data from the chip
> then send it directly to the video board. Today this works, almost
> (because we need a patched X - read gatos - and a patched xawtv - in
> order to do scaling).

Try using xv_stream from ati_xv branch on gatos.

   Vladimir Dergachev

> 
> Stelian.
> -- 
> Stelian Pop <[EMAIL PROTECTED]>
> | Free Software Engineer -|
> | Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
> |- Alcôve, liberating software ---|
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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

Re: Cosmetic JFFS patch.

[Dan Podeanu]

Ok, my two cents.

Print all copyright, config, etc. as KERN_DEBUG. Then use a 'verbose' or
similar parameter to lilo/kernel to enable console printing of KERN_DEBUG,
to be used when the system fails to boot, etc.

Dan.


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

Re: BIG PROBLEM

[Alan Cox]

> i've  compiled the kernel 2.4.4 , once i finish and boot the first time on 
> 2.4.4 everything goses ok ,
> only too problemes
> 1st-  klogd takes 100%  CPU time

Old old versions of klogd had bugs where they would do that. If there is
a continuous problem it may also do so - does 'dmesg' show anything ?

> 2nd- cat /proc/cpuinf --guives me too CPU'S  without putin any info about 
> the CPU 1

Im not sure I follow the description - can you explain more.

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

Re: [PATCH] Bug in 2.4.5 in proc_pid_make_inode ()

[Alexander Viro]

On Thu, 28 Jun 2001, Martin Wilck wrote:

> Hi,
> 
> I have recently experienced a number of kernel OOPSes
> in "top" under heavy load. Kernel is 2.4.5 (IA64, but
> this has nothing to do the IA64 patch).
> 
> The OOPS happens in the call tree
> 
> open () system call
> [...]
> real_lookup ()
> proc_base_lookup ()
> proc_pid_make_inode ()
> iput ()
> proc_delete_inode () -> OOPS in __MOD_DEC_USE_COUNT

Known, had been already fixed in 2.4.6-pre3.

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

[Ulrich Weigand]

Martin Wilck wrote:

>I have recently experienced a number of kernel OOPSes
>in "top" under heavy load. Kernel is 2.4.5 (IA64, but
>this has nothing to do the IA64 patch).

Same here; I just debugged these on S/390 ...

>I have seen 2.4.6-pre6 contains changes to this subroutine as well,
>but they seem to be attacking a different problem.
>Having analyzed the stack trace and the kernel code with objdump,
>I am pretty certain that the changes in 2.4.6-pre6 do not fix my problem
>(if they did, I would see a crash in proc_pid_delete_inode rather
>than in proc_delete_inode).

I think the -pre6 code should be OK.  Note that the crash in
proc_delete_inode() occurs because the pointer to the parent
proc_dir_entry (which is taken from inode->u.generic_ip) is
non-zero.

In 2.4.5, this is the case because proc_pid_make_inode
assigns a value to inode->u.proc_i.task before calling iput().
That field overlays inode->u.generic_ip ...

In the 2.4.6-pre patches, the test for a zero pid is moved to
*before* assigning to inode->u.proc_i.task.  Therefore, when
iput calls proc_delete_inode(), the 'de' pointer will be
zero, and nothing will happen.

Whether this is particularly pretty is debateable, but it
appears to be correct.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: [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: Cosmetic JFFS patch.

[Jeff Garzik]

Linus Torvalds wrote:
> Things like version strings etc sound useful, but the fact is that the
> only _real_ problem it has ever solved for anybody is when somebody thinks
> they install a new kernel, and forgets to run "lilo" or something. But
> even that information you really get from a simple "uname -a".
> 
> Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care
> that we have quota version "dquot_6.4.0"? No. Do we want to get the
> version printed for every single driver we load? No.
> 
> If people care about version printing, it (a) only makes sense for modules
> and (b) should therefore maybe be done by the module loader. And modules
> already have the MODULE_DESCRIPTION() thing, so they should NOT printk it
> on their own.  modprobe can do it if it wants to.

As Alan said, driver versions are incredibly useful.  People use update
their drivers over top of kernel drivers all the time.  Vendors do it
too.  "Run dmesg and e-mail me the output" is 1000 times more simple for
end users.


> So let's simply disallow versions, author information, and "good status"
> messages, ok? For stuff that is useful for debugging (but that the driver
> doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end
> up printed on the screen normally.

Note that KERN_DEBUG appears in dmesg by default in 2.4, AFAICS.  This
may be a big source of complaints, right there...

Jeff


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

RE: PATCH: cciss small pci id table patch

[White, Charles]

Yes, I agree...  pci.txt says it should end in a zero..   

I will include that change in my future updates as well... 

-Original Message-
From:   Marcus Meissner [mailto:[EMAIL PROTECTED]]
Sent:   Thursday, June 28, 2001 10:34 AM
To: White, Charles; [EMAIL PROTECTED]; Alan
Cox; Arrays
Subject:PATCH: cciss small pci id table patch

Hi,

The cciss driver in 2.4.5-ac19 is missing the terminating
{0,}.

Ciao, Marcus

Index: drivers/block/cciss.c

===
RCS file:
/build/mm/work/repository/linux-mm/drivers/block/cciss.c,v
retrieving revision 1.23
diff -u -r1.23 cciss.c
--- drivers/block/cciss.c   2001/05/27 18:05:54 1.23
+++ drivers/block/cciss.c   2001/06/28 15:27:34
@@ -63,6 +63,7 @@
 0x0E11, 0x4080, 0, 0, 0},
{ PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_CISSB,
 0x0E11, 0x4082, 0, 0, 0},
+   {0,}
 };
 MODULE_DEVICE_TABLE(pci, cciss_pci_device_id);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Cosmetic JFFS patch.

[Jeff Garzik]

Miquel van Smoorenburg wrote:
> 
> In article <[EMAIL PROTECTED]>,
> Tommy Reynolds  <[EMAIL PROTECTED]> wrote:
> >Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
> >
> >> If they are shut off, then where's the drumming? Because if people start
> >> making copyright printk's normal, I will make "quiet" the default.
> >
> >Amen.  This is like editing a program to remove the "harmless" compiler warning
> >messages.  If I don't get a useless message, I don't have to decide to ignore
> >it.  Describing what's happening is OK; don't gush.
> 
> Yep - a driver should print out that it loaded and what hardware it
> found. Nothing else.
> 
> You know what I hate? Debugging stuff like BIOS-e820, zone messages,
> dentry|buffer|page-cache hash table entries, CPU: Before vendor init,
> CPU: After vendor init, etc etc, PCI: Probing PCI hardware,
> ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc
> 
> That's stuff that noone cares about. If the system fails to boot
> boot it with a debug flag. If it does boot, _fine_.

Actually this [IMHO] a bug that should be fixed in 2.4:  The default
logging level for the production 2.4 kernel includes KERN_DEBUG, which
is why you see a lot of this crap.

> arch/i386/kernel/setup.c:   printk(KERN_DEBUG "CPU: Common caps: 
>%08x %08x %08x %08x\n",

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

BIG PROBLEM

[james bond]

1-systeme hangs when i try ton compile anything

i've  compiled the kernel 2.4.4 , once i finish and boot the first time on 
2.4.4 everything goses ok ,
only too problemes
1st-  klogd takes 100%  CPU time
2nd- cat /proc/cpuinf --guives me too CPU'S  without putin any info about 
the CPU 1
like that  approximatively



processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 498.672
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips : 992.87

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name :
stepping : 3
cpu MHz :
cache size :
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags   :
bogomips  :



at the second boot it detects correctly CPU0 and CPU1



cat /proc/cpuinfo -->
---
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 498.672
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov
pat pse36 mmx fxsr sse
bogomips: 992.87

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 498.672
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 3
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov
pat pse36 mmx fxsr sse
bogomips: 996.14

cat /proc/version -->

Linux version 2.4.4 (root@seraka) (gcc version 2.95.3 20010315 (release)) #2 
SMP Thu Jun 28 07:04:06 CEST 2001

cat /proc/modules --> nothing   cause im no using modules

cat /proc/ioports
----001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
02f8-02ff : serial(auto)
03c0-03df : vga+
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
d000-dfff : PCI Bus #01
e000-e01f : Intel Corporation 82371AB PIIX4 USB
e400-e4ff : Adaptec 7892A-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000cc000-000d25ff : Extension ROM
000d3000-000d87ff : Extension ROM
000f-000f : System ROM
0010-0ffe : System RAM
  0010-00245892 : Kernel code
  00245893-002ca41f : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
d800-dbff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
dc00-dfff : PCI Bus #01
  dc00-dc003fff : Matrox Graphics, Inc. MGA G400 AGP
  dd00-dd7f : Matrox Graphics, Inc. MGA G400 AGP
e000-e1ff : PCI Bus #01
  e000-e1ff : Matrox Graphics, Inc. MGA G400 AGP
e500-e5007fff : Yamaha Corporation YMF-724
e5008000-e5008fff : Adaptec AHA-2940U2/W
  e5008000-e5008fff : aic7xxx
e5009000-e5009fff : Adaptec 7892A
  e5009000-e5009fff : aic7xxx
fec0-fec00fff : reserved
fee0-fee00fff : reserved
- : reserved

e800-e8ff : Adaptec AHA-2940U2/W
ec00-ec1f : 3Com Corporation 3c595 100BaseTX [Vortex]
ec00-ec1f : eth0
f000-f00f : Intel Corporation 82371AB PIIX4 IDE
---
cat /proc/iomem  --->-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000cc000-000d25ff : Extension ROM
000d3000-000d87ff : Extension ROM
000f-000f : System ROM
0010-0ffe : System RAM
  0010-00245892 : Kernel code
  00245893-002ca41f : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
d800-dbff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
dc00-dfff : PCI Bus #01
  dc00-dc003fff : Matrox Graphics, Inc. MGA G400 AGP
  dd00-dd7f : Matrox Graphics, Inc. MGA G400 AGP
e000-e1ff : PCI Bus #01
  e000-e1ff : Matrox Graphics, Inc. MGA G400 AGP
e500-e5007fff : Yamaha Corporation YMF-724
e5008000-e5008fff : 

[PATCH] Config variable scripts

[Riley Williams]

Hi Alan.

The enclosed patch was originally developed for the ELKS kernel, but
will apply equally well against any Linux kernel as it only adds new
scripts to the scripts subdirectory. The new scripts are as follows:

 1. renvar  Renames configuration variables in all files
they occur in in the entire source tree.

 2. varlist Lists all configuration variables currently
in use, together with the number of files
in which they occur.

Can you apply this against both the 2.2 and 2.4 trees please?

Best wishes from Riley.

 Config variable scripts

Re: PROBLEM:Illegal instruction when mount nfs file systems usingcyr ixIII

[Bernd Schmidt]

On Wed, 27 Jun 2001, Alan Cox wrote:

> > The problem is that VIA Cyrix III announces itself (via CPUID)
> > as a "family 6" processor, i.e. i686 compatible. This is not
> > completely accurate, since it doesn't implement the conditional
> > move instruction. [Yeah, I know there's a CPUID feature flag for
>
> Intel specifically state that you cannot use CMOV without checking
> for it. Its actually a gcc/binutils tool bug. The CPU is right.

How is that a gcc bug?  You tell the compiler to generate cmov, you run
it on a CPU that doesn't have it, you get what you deserve.  There's
really nothing the tools can do about that.


Bernd

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

kernel 2.4.5 Ooops

[Ted Gervais]

I am getting an Oops/kernel panic with kernel 2.4.5.
Here is what the panic notice says in part:

The panic notice said:

Unable to handle kernel paging request at virtual address 846ea4e6
*pde = 0
Oops: 0 0 0 0
cpu: 0
EIP: 0010:[]
EFLAGS: 00010286
Process ax25ipd (pid:270,stackpage=c54a700)
call trace:
CODE: 8a 40 40 25 ff 00 00 00 83 c0 02 8d 14 c5 00 00 00 00 29 c2
Kernel panic: Aiee, Killing interrupt handler!
In interrupt handler - not syncing..


Not sure what to do now other than to go back to a previous release.
Is anyone else having this problem?  Is there a solution?  Or 
maybe I haven't provided enough info..

The above is all that the Oops notice reported other than some numbers for
call trace, etc.. Its all there otherwise..

---
It's never too late to have a happy childhood.

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


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

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Tommy Reynolds  <[EMAIL PROTECTED]> wrote:
>Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
>
>> If they are shut off, then where's the drumming? Because if people start
>> making copyright printk's normal, I will make "quiet" the default.
>
>Amen.  This is like editing a program to remove the "harmless" compiler warning
>messages.  If I don't get a useless message, I don't have to decide to ignore
>it.  Describing what's happening is OK; don't gush.

Yep - a driver should print out that it loaded and what hardware it
found. Nothing else.

You know what I hate? Debugging stuff like BIOS-e820, zone messages,
dentry|buffer|page-cache hash table entries, CPU: Before vendor init,
CPU: After vendor init, etc etc, PCI: Probing PCI hardware, 
ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc

That's stuff that noone cares about. If the system fails to boot
boot it with a debug flag. If it does boot, _fine_.

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] Bug in 2.4.5 in proc_pid_make_inode ()

[Martin Wilck]

Hi,

I have recently experienced a number of kernel OOPSes
in "top" under heavy load. Kernel is 2.4.5 (IA64, but
this has nothing to do the IA64 patch).

The OOPS happens in the call tree

open () system call
[...]
real_lookup ()
proc_base_lookup ()
proc_pid_make_inode ()
iput ()
proc_delete_inode () -> OOPS in __MOD_DEC_USE_COUNT

proc_pid_make_inode () calls iput () if it finds a task PID of 0
(jump to label out_unlock). If (PID == 0), the statement

inode->i_ino = fake_ino(task->pid, ino);

setsinode->i_ino = ((0 << 16) | ino) = ino.

Thus if (ino < (1 << 16)), the test

if (PROC_INODE_PROPER(inode))

in proc_delete_inode () will fail, and proc_delete_inode will
erroneously assume this is a non-PID inode and
look for a proc_dir_entry struct which is of course bogus
(the OOPS happens when it tries to decrement the module use counter).

Therefore I propose the following patch:

--- 2.4.5mw/fs/proc/base.c.org  Wed Jun 27 12:36:18 2001
+++ 2.4.5mw/fs/proc/base.c  Thu Jun 28 20:52:22 2001
@@ -672,6 +672,8 @@
return inode;

 out_unlock:
+   /* Make sure proc_delete_inode does the right thing */
+   inode->i_ino |= (1 << 16);
iput(inode);
return NULL;
 }

This will tell proc_delete_inode that this is a PID entry.

PS:
I have seen 2.4.6-pre6 contains changes to this subroutine as well,
but they seem to be attacking a different problem.
Having analyzed the stack trace and the kernel code with objdump,
I am pretty certain that the changes in 2.4.6-pre6 do not fix my problem
(if they did, I would see a crash in proc_pid_delete_inode rather
than in proc_delete_inode).

The two patches are not in conflict.

Regards,
Martin

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




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

Re: Cosmetic JFFS patch.

[Pekka Pietikainen]

On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote:
> 
> 
> [EMAIL PROTECTED] said:
> > Things like version strings etc sound useful, but the fact is that the
> > only _real_ problem it has ever solved for anybody is when somebody
> > thinks they install a new kernel, and forgets to run "lilo" or
> > something.
> 
> I can give counter-examples of times when it's been extremely useful to 
> know exactly what version the user is running, and the info messages
> included in their first bug report have told me exactly what I needed to 
> know.
> 
> Only for code which is always distributed as part of the kernel, and where 
> there are never any more up to date versions in the maintainer's tree, even 
> temporarily.
Indeed, and even if you're talking about kernel x.y.z the
user might in fact be running a vendor-patched kernel with a newer
version of the driver (and the author would still have to find out
what version of the driver was included).

For other things the version string is pretty useless as it isn't ever
updated (e.g. networking), and there the kernel version is enough
information.

What I'd propose is a recommendation that modules in 
addition to the "useful" information a module should print
a maximum of one line (80 chars), and the author gets to
choose what they want in there, version information, driver homepage,
copyright, sponsor, whatever.

I just hope we never get to the point of having a "Memory leak removal
sponsored by Tampax" boot message ;)

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

Re: [PATCH] User chroot

[Albert D. Cahalan]

Sean Hunter writes:
> On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:

>> ln /dev/zero /tmp/zero
>> ln /dev/hda ~/hda
>> ln /dev/mem /var/tmp/README
>
> None of these (of course) work if you use mount options to
> restrict device nodes on those filesystems.

In which case, you can't boot. Think about it.

Never mind the method. One way or another, it is very often
possible for a normal users to set up a chroot environment
with the device files that are needed. Maybe they do something
obscene with the admin. :-) So chroot() is useful for users.

In my case, I _am_ the admin and I just don't want to run
every damn little test program and hack as root.

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

[Christoph Zens]

> Also, in printk's, you waste run-time memory, and you bloat up the need
> for the log size. Both of which are _technical_ reasons not to do it.
> 
> Small is beuatiful.

I totally agree. If you want to use Linux for a small and low cost
embedded system, you can't afford loads of RAM and FLASH space.
Small is the _key_ for those systems.

> 
>   Linus
> 
> 
> To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
> the body of a message to [EMAIL PROTECTED]
> 

-- 
Christoph Zens
[EMAIL PROTECTED]
(415)-289-7765

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

[Tommy Reynolds]

Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:

> If they are shut off, then where's the drumming? Because if people start
> making copyright printk's normal, I will make "quiet" the default.

Amen.  This is like editing a program to remove the "harmless" compiler warning
messages.  If I don't get a useless message, I don't have to decide to ignore
it.  Describing what's happening is OK; don't gush.

-- 

Tommy Reynolds   |
Red Hat, Inc. (Embedded Development) | Join my presentation at:
307 Wynn Drive NW, Huntsville, AL 35805 USA  | Red Hat TechWorld Brussels
mailto:[EMAIL PROTECTED]   | http://www.redhat-techworld.com
Phone:  +1.256.704.9286  |
Mobile: +1.919.641.2923  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is an outside module supposed to use page cache?

[Ho Chak Hung]

Hi, 
I am trying to develop a module that makes use of the page cache(by allocating a LOT 
of pages use page_cache_alloc and then add_to_page_cache). However, I got some 
unresolved symbols error during insmod.(because the symbols related to 
lru_cache_add etc are not exported?) .
I am just wondering if I am not building a file system but at the same time want to 
allocate a lot of pages of physical memory to store something that has no backup 
storage as a file, should I add it to the page cache?
Any advice would be greatly appreciated
Thanks 
__
Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[David Woodhouse]

[EMAIL PROTECTED] said:
>  I consider them harmful when I start getting annoying patches that
> start adding more and more of them.

> Which is how this whole thread started. 

Sort of. The point of the patch which started this thread was as a wake-up
call to a company who had taken the code, renamed it to appear as their own,
commented out the version and copyright printk, and shipped it to their
customers in an RPM which claimed it was proprietary code.

That wake-up call served its primary purpose quite effectively.

The new line was added simply to ensure that if such a thing happens again,
the newly-named copyright holder will be in a position to do something about
it.

Take them all out if you must. I stand by my prediction.

--
dwmw2


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