[2.4.0-test12-pre8] plip error.

[Edward C. Lang]

gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
/usr/local/src/linux/include/linux/modversions.h   -c -o plip.o plip.c
plip.c: In function `plip_init_dev':
plip.c:352: structure has no member named `next'
plip.c:357: structure has no member named `next'
plip.c:363: structure has no member named `next'
{standard input}: Assembler messages:
{standard input}:18: Warning: Ignoring changed section attributes for
.modinfo
make[3]: *** [plip.o] Error 1


-- 

Edward C. Lang   woot on various channels on irc.openprojects.net
[EMAIL PROTECTED] - Normal mail. Most stuff ends up here anyway.
[EMAIL PROTECTED]  - Debian mail. Finger this address for keys.
[EMAIL PROTECTED] [EMAIL PROTECTED] - Other email addresses.TINC.


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

Re: Dropping chars on 16550

[Chad Schwartz]

You'll find that there is a problem with 2.2.12, on down - with losing a
few bytes here and there.

The bug is in the tty subsystem - in that when you pass off chars to the
ldisc - from the driver, the ldisc doesn't actually write them.  (I could
get into the details, but you probably don't care.)

upgrade to 2.2.17.

It takes care of that bug.

Now. You *NEED* to understand that the way cdrecord does things, is by
sending control codes (lots of them) to your tty, to achieve the "oOoOo"
effect.

9600bps should be okay - on any reasonable system, to NEVER flow control.

But the *MOMENT* you bank on that, you'll get burned.

Set up flow control. if you don't, you're asking for trouble.

Chad

> Hi folks
>
> What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI
> CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550-
> enhanced serial port, without handshake, with full-duplex load of 115200 bps?
> About 1 of 320 bytes is miscommunicated.
>
> The kernel is 2.2.12.
>
> Clock
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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]
Please read the FAQ at http://www.tux.org/lkml/

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Andre Hedrick]

On Sun, 10 Dec 2000, Hakan Lennestal wrote:

> In message <[EMAIL PROTECTED]>, And
> re Hedrick writes:
> > On Sun, 10 Dec 2000, Hakan Lennestal wrote:
> > 
> > > The problem being that the kernel hangs after a dma timeout in the
> > > partition detection phase during bootup for speeds higher than udma 44.
> > > This is an IBM-DTLA-307030 connected to a hpt366 pci card on a BH6
> > > motherboard.
> > 
> > Well try the latest out there...test12-pre7.
> 
> Hi !
> 
> This is with test12-pre7 and HPT-bios 1.27.

test12-pre8 and 2.2.18 is out and I do not chase BIOS revs in general.
I work off the originals HPT366 1.07 this is because the lowest comman
variable must be addressed and hope that the new stuff will not fail the
backwards compatablity issue.

Cheers,


Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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

Re: [2*PATCH] alpha I/O access and mb()

[Abramo Bagnara]

Before of all I want to publicly apologize with Richard as never my
intention was to exacerbate him.

> 
> On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote:
> > asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is
> > defined, otherwise it uses (take writel as an example) __raw_writel that
> > IMHO need to be defined in core_t2.h.
> 
> Perhaps you should _show_ an actual failure rather than just guessing.

I've not access to this specific hardware but I was trying to fix the
alpha case wrt write[bwlq] function as I've had a lot of trouble with
ALSA drivers and 2.2 (that still now is broken wrt mb() and I've sent a
patch to Alpha Processor guys). This is the reason why I've given a look
to 2.4.

> 
> You are wildly incorrect asserting that out of line functions are used
> only with CONFIG_ALPHA_GENERIC.  You should examine
> 
> #ifndef __raw_writel
> # define __raw_writel(v,a)  ___raw_writel((v),(unsigned long)(a))
> #endif
> 
> and suchlike definitions.

Now I understand, thanks.

I see that some core*.h leaves out of line some functions because they
are more complex than a choosen threshold.

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com

It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Unable to compile the 2.2.18 kernel

[Anthony Barbachan]

Thanks.  I missed that this time when I modified the Makefile.  I didn't pay
close attention to the new script code in there to check for the kernel
compiler.


- Original Message -
From: "Peter Samuelson" <[EMAIL PROTECTED]>
To: "Anthony Barbachan" <[EMAIL PROTECTED]>
Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linux Kernel Mailing List"
<[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 1:17 AM
Subject: Re: Unable to compile the 2.2.18 kernel


>
> [Anthony Barbachan]
> > I am unable to compile the latest kernel.  I have attached my kernel
> > configuration and a copy of the output of where the compile fails.  I
> > am looking into what is causing the compile failure, but have not
> > been able to figure it out yet.  Still looking though.
>
> It looks like you overrode the 'CC' make variable, either by editing
> the toplevel Makefile or at the command line.  This works fine in 2.4,
> but in 2.2 you need to pass extra flags to the compiler:
>
>   make zImage
CC="/usr/local/gcc-2.7.2.3/bin/gcc -I$(pwd)/include -D__KERNEL__"
>
> ...for example.
>
> Peter
>


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

2.4.0test11: "nanoseconds patch" (prerelease) available

[Ulrich Windl]

Hi,

related to my question about having nanoseconds in xtime for Linux 2.5, 
two (or three) people were interested, or at least managed to route 
their message to me. As promised I have made an early release patch 
against 2.4.0test11 available at

ftp.kernel.org:/pub/linux/daemons/ntp/PPS/pps-2.4-pre1.tar.bz2 (63kB, 
patch + digital signature)

The modified sources compile, link and boot (for arch/i386), but 
consider this code as alpha quality, and don't use it for production 
use. It is possible that it works perfectly, but I simply don't have 
the experience.

Fixes for any architectures are appreciated. Finally I want to get rid 
of gettimeoffset() and a lot of redundant code.

I noticed that the ATM drivers access xtime directly. If jiffies are 
not fine enough, do_gettimeofday() has to be called for now. If that's 
too slow, we have to think about an alternative.

Regards,
Ulrich

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

Re: [linux-fbdev] [PATCH] aty128fb & >8bit

[Geert Uytterhoeven]

On Sun, 10 Dec 2000, Tom Rini wrote:
> Hello.  I just noticed that in 2.2.18pre27 you can only use the aty128fb
> driver at 8 bit, because of some missing bits to drivers/video/Config.in.
> w/o this you can't use console at > 8 bit nor X.  I would consider this to
> be a good thing to squash for 2.2.18 final because 2.2.18 is the 1st release
> in a while that works well on PPC, and lots of PPCs have a rage128.

You mean the FBCON_CFBx options with x > 8? You're correct that you need them
for a text console, but you don't need them for X.

Gr{oetje,eeting}s,

Geert

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

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

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

Re: hotplug mopup

[Andrew Morton]

"Albert D. Cahalan" wrote:
> 
> Marcus Meissner writes:
> 
> >> - On the unregister/removal path, the netdevice layer ensures that
> >>   the interface is removed from the kernel namespace prior to launching
> >>   `/sbin/hotplug net unregister eth0'.
> >>
> >>   This means that when handling netdevice unregistration
> >>   /sbin/hotplug cannot and must not attempt to do anything with eth0!
> >>   Generally it'll fail to find an interface with this name.  If it does
> >>   find eth0, it'll be the wrong one due to a race.
> >
> > I always thought I should have to do "/sbin/ifdown eth0" here.
> > (Just as I do /sbin/ifup eth0 on register.)
> 
> Yes, definitely. Otherwise, how can one replace the eth0 hardware
> without messing up the network settings? This is supposed to be
> hot plug and all... to me that means I can rip out one network
> card and pop in another without breaking my ssh connections.

Let's see...

You pull the card (let's suppose it's Cardbus).  That causes an
interrupt which eventually gets fed to the PCI layer's
pci_remove_device().

The PCI layer calls the netdevice's pci_driver.remove() method.

Typically, xxx_remove() calls unregister_netdevice().

unregister_netdevice() downs the interface, then removes the
netdevice from the kernel namespace and then runs
'/sbin/hotplug net unregister eth0' asynchronously.

When we return from unregister_netdevice() we can guarantee
that the driver's module refcount is zero if this was the
last matching device.

We then wind all the way back to the PCI layer, whizzing gaily
back through the driver whose module refcount is now zero.  Sigh.

The PCI layer runs '/sbin/hotplug pci remove' asynchronously.  The
driver can be unloaded.

So where in all of this can you read the interface's network
settings?  Nowhere, I'm afraid.  They're released in
unregister_netdevice().

Isn't this a userspace tool problem?

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

Re: 2.2.18pre25, S3, AMD K6-2, and MTRR....

[Julian Anastasov]

Hello,

On Sun, 10 Dec 2000, Victor J. Orlikowski wrote:

> You appear to be right, sir.
> The SVGA xserver was what I was using. Changing over to use the S3
> server, and then adding back in MTRRs, seems to have solved the

Hm, I have to see whether GX2 works with the S3V server. May
be GX2 is not supported.

> trouble. I'll let you know if it returns, but for now, all appears
> well.

I'm using XF86_SVGA and it seems the s3v driver in 3.3.* and
may be 4.0.* (as mentioned in the xfree-xpert list) has problem with
the right usage of the accel FIFO for the GX2 cards. Not sure for
your S3Trio32/64 card. It seems the faster CPU and the AGP speed hits the
problem. I see some problems in the image (some dots are missing from
different letters, sometimes).

regs3v.h approximates the loop to 6 seconds:
#define MAXLOOP 0xff /* timeout value for engine waits, ~6 secs */

For my CPU the lockup takes 4.8 seconds. Not sure why they are
sometimes infinite.

So, I'm leaving this mail list, it seems this is a s3v driver
problem.

> Victor

References:
http://marc.theaimsgroup.com/?l=xfree-xpert&r=1&w=2


Regards

--
Julian Anastasov <[EMAIL PROTECTED]>

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

make modules exits on test12-pre8

[Norbert Breun]

Hallo,

tried to compile test12-pre8 and make modules exits with:


>make[2]: Entering directory `/usr/src/linux-2.4.0.12pre8/fs/smbfs'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i586 -DMODULE -DMODVERSIONS -include 
/usr/src/linux/include/linux/modversions.h -DSMBFS_PARANOIA  -c -o sock.o 
sock.c
>sock.c: In function `smb_data_ready':
>sock.c:166: structure has no member named `next'
>make[2]: *** [sock.o] Error 1
>make[2]: Leaving directory `/usr/src/linux-2.4.0.12pre8/fs/smbfs'
>make[1]: *** [_modsubdir_smbfs] Error 2
>make[1]: Leaving directory `/usr/src/linux-2.4.0.12pre8/fs'
>make: *** [_mod_fs] Error 2

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

PATCH: linux-2.4.0-test12pre8: 17 files with compiler errors due to tq_struct->list.

[Adam J. Richter]

I believe the following patch should complete the
conversion of tq_struct->next to tq_struct->list, at least for x86
platforms.  There were seventeen files in 2.4.0-test12pre8 for x86 that
needed to be updated.

Please integrate with caution.  I had never looked at the
contents of struct tq_struct before this.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/gamma_dma.c 
linux-2.4.0-test12pre8.ygg/drivers/char/drm/gamma_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/gamma_dma.cTue Oct  3 
16:29:08 2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/gamma_dma.c Sun Dec 10 19:34:25 
+2000
@@ -651,7 +651,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = gamma_dma_schedule_tq_wrapper;
dev->tq.data  = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/i810_dma.c 
linux-2.4.0-test12pre8.ygg/drivers/char/drm/i810_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/i810_dma.c Tue Oct  3 16:29:09 
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/i810_dma.c  Sun Dec 10 19:35:01 
+2000
@@ -924,7 +924,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = i810_dma_task_queue;
dev->tq.data  = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/mga_dma.c 
linux-2.4.0-test12pre8.ygg/drivers/char/drm/mga_dma.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/drm/mga_dma.c  Mon Dec  4 03:35:45 
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/drm/mga_dma.c   Sun Dec 10 19:35:44 
+2000
@@ -818,7 +818,7 @@
dev->dma->next_buffer = NULL;
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = mga_dma_task_queue;
dev->tq.data  = dev;
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/char/n_r3964.c 
linux-2.4.0-test12pre8.ygg/drivers/char/n_r3964.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/char/n_r3964.c  Wed May  3 05:34:57 
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/char/n_r3964.c   Sun Dec 10 19:30:17 2000
@@ -1157,12 +1157,12 @@
 * Add 'on_timer' to timer task queue
 * (will be called from timer bh)
 */
-   pInfo->bh_1.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_1.list);
pInfo->bh_1.sync = 0;
pInfo->bh_1.routine = &on_timer_1;
pInfo->bh_1.data = pInfo;

-   pInfo->bh_2.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_2.list);
pInfo->bh_2.sync = 0;
pInfo->bh_2.routine = &on_timer_2;
pInfo->bh_2.data = pInfo;
@@ -1174,7 +1174,7 @@
 
 static void r3964_close(struct tty_struct *tty)
 {
-   struct tq_struct *tq, *prev;
+   struct list_head *tq, *next;
struct r3964_info *pInfo=(struct r3964_info*)tty->disc_data;
struct r3964_client_info *pClient, *pNext;
struct r3964_message *pMsg;
@@ -1190,14 +1190,13 @@
 save_flags(flags);
 cli();
 
-for (tq=tq_timer, prev=0; tq; prev=tq, tq=tq->next) {
- if ((tq == &pInfo->bh_1) || (tq==&pInfo->bh_2)) {
- if (prev)
- prev->next = tq->next;
- else
- tq_timer = tq->next;
- break;
- }
+tq = &tq_timer;
+while (tq != NULL) {
+ next = tq->next;
+ if ((tq == (struct list_head*) &pInfo->bh_1) ||
+(tq == (struct list_head*) &pInfo->bh_2))
+   list_del(tq);
+tq = next; 
 }
 restore_flags(flags);
 
diff -u -r linux-2.4.0-test12pre8.ygg.orig/drivers/i2o/i2o_lan.c 
linux-2.4.0-test12pre8.ygg/drivers/i2o/i2o_lan.c
--- linux-2.4.0-test12pre8.ygg.orig/drivers/i2o/i2o_lan.c   Wed Dec  6 23:36:42 
2000
+++ linux-2.4.0-test12pre8.ygg/drivers/i2o/i2o_lan.cSun Dec 10 19:40:09 2000
@@ -113,7 +113,10 @@
 static int lan_context;
 
 static struct tq_struct i2o_post_buckets_task = {
-   0, 0, (void (*)(void *))i2o_lan_receive_post, (void *) 0
+   list: LIST_HEAD_INIT(i2o_post_buckets_task.list),
+   sync: 0,
+   routine: (void (*)(void *))i2o_lan_receive_post,
+   data: (void *) 0
 };
 
 /* Functions to handle message failures and transaction errors:
@@ -1401,7 +1404,7 @@
atomic_set(&priv->tx_out, 0);
priv->tx_count = 0;
 
-   priv->i2o_batch_send_task.next= NULL;
+   INIT_LIST_HEAD(&priv->i2o_batch_send_task.list);

Re: Unable to compile the 2.2.18 kernel

[Peter Samuelson]

[Anthony Barbachan]
> I am unable to compile the latest kernel.  I have attached my kernel
> configuration and a copy of the output of where the compile fails.  I
> am looking into what is causing the compile failure, but have not
> been able to figure it out yet.  Still looking though.

It looks like you overrode the 'CC' make variable, either by editing
the toplevel Makefile or at the command line.  This works fine in 2.4,
but in 2.2 you need to pass extra flags to the compiler:

  make zImage CC="/usr/local/gcc-2.7.2.3/bin/gcc -I$(pwd)/include -D__KERNEL__"

...for example.

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

PATCH - use submit_bh in brw_kiovec

[Neil Brown]

Linus,
  the new submit_bh function provides functionality that is better
  suited for brw_kiovec to use than generic_make_request.

  This patch replaced generic_make_request with submit_bh in
  brw_kiovec and removed some field initialisation which is no longer
  required.

 patch against 2.4.0-test12-pre8

NeilBrown

--- ./fs/buffer.c   2000/12/10 23:51:16 1.1
+++ ./fs/buffer.c   2000/12/10 23:55:35 1.2
@@ -2040,7 +2040,6 @@
int pageind;
int bhind;
int offset;
-   int sectors = size>>9;
unsigned long   blocknr;
struct kiobuf * iobuf = NULL;
struct page *   map;
@@ -2092,9 +2091,8 @@
tmp->b_this_page = tmp;
 
init_buffer(tmp, end_buffer_io_kiobuf, iobuf);
-   tmp->b_rdev = tmp->b_dev = dev;
+   tmp->b_dev = dev;
tmp->b_blocknr = blocknr;
-   tmp->b_rsector = blocknr*sectors;
tmp->b_state = (1 << BH_Mapped) | (1 << BH_Lock) | (1 
<< BH_Req);
 
if (rw == WRITE) {
@@ -2108,7 +2106,7 @@
 
atomic_inc(&iobuf->io_count);
 
-   generic_make_request(rw, tmp);
+   submit_bh(rw, tmp);
/* 
 * Wait for IO if we have got too much 
 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] 2.2.18 i815 AGPGART Support

[Robert M. Love]

this patch is against final 2.2.18, hopefully for inclusion in 2.2.19pre.

the current '440LX/BX/GX and 840' agp driver supports the i815, but does
not detect it. this patch allows the driver to detect it correctly.

the current '810/815' driver is only for when the i815 is using its built
in video, not its AGP slot. the configure help is updated to reflect this
and show that the above driver now supports i815.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]


diff --new-file -u --recursive linux~/CREDITS linux/CREDITS
--- linux~/CREDITS  Sun Dec 10 19:49:40 2000
+++ linux/CREDITS   Mon Dec 11 00:29:36 2000
@@ -1335,6 +1335,13 @@
 S: Niwot, Colorado 80503
 S: USA
 
+N: Robert M. Love
+E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+D: misc. kernel hacking and debugging
+S: Gainesville, Florida 32608
+S: USA
+
 N: H.J. Lu
 E: [EMAIL PROTECTED]
 D: GCC + libraries hacker
diff --new-file -u --recursive linux~/Documentation/Configure.help 
linux/Documentation/Configure.help
--- linux~/Documentation/Configure.help Sun Dec 10 19:49:41 2000
+++ linux/Documentation/Configure.help  Mon Dec 11 00:31:22 2000
@@ -10476,8 +10476,8 @@
 
 Intel 440LX/BX/GX support
 CONFIG_AGP_INTEL
-  This option give you AGP support for the GLX component of the
-  "soon to be released" XFree86-4 on Intel 440LX/BX/GX chipsets.
+  This option gives you AGP support for the GLX component of
+  XFree86 4.x on Intel 440LX/BX/GX, 815, and 840 chipsets.
 
   For the moment, most people should say no, unless you want to
   test the GLX component which can be downloaded from
@@ -10485,9 +10485,9 @@
 
 Intel I810/I810 DC100/I810e support
 CONFIG_AGP_I810
-  This option give you AGP support for the Xserver for the intel
-  810 chipset boards. This is required to do any useful video
-  modes.
+  This option gives you AGP support for XFree86 on the Intel 810
+  and 815 chipsets for their on-board integrated graphics. This
+  is required to do any useful video modes with these boards.
 
 VIA VP3/MVP3/Apollo Pro support
 CONFIG_AGP_VIA
diff --new-file -u --recursive linux~/drivers/char/Config.in 
linux/drivers/char/Config.in
--- linux~/drivers/char/Config.in   Sun Dec 10 19:49:41 2000
+++ linux/drivers/char/Config.inMon Dec 11 00:32:22 2000
@@ -128,8 +128,8 @@
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate '/dev/agpgart (AGP Support) (EXPERIMENTAL)' CONFIG_AGP n
if [ "$CONFIG_AGP" != "n" ]; then
-  bool '   Intel 440LX/BX/GX support' CONFIG_AGP_INTEL
-  bool '   Intel I810/I810 DC100/I810e support' CONFIG_AGP_I810
+  bool '   Intel 440LX/BX/GX and I815/820 support' CONFIG_AGP_INTEL
+  bool '   Intel I810/I815 (on-board video) support' CONFIG_AGP_I810
   bool '   VIA VP3/MVP3/Apollo Pro support' CONFIG_AGP_VIA
   bool '   AMD Irongate support' CONFIG_AGP_AMD
   bool '   Generic SiS support' CONFIG_AGP_SIS
diff --new-file -u --recursive linux~/drivers/char/agp/agp_backend.h 
linux/drivers/char/agp/agp_backend.h
--- linux~/drivers/char/agp/agp_backend.h   Sun Dec 10 19:49:41 2000
+++ linux/drivers/char/agp/agp_backend.hMon Dec 11 00:33:32 2000
@@ -45,6 +45,7 @@
INTEL_BX,
INTEL_GX,
INTEL_I810,
+   INTEL_I815,
INTEL_I840,
VIA_GENERIC,
VIA_VP3,
diff --new-file -u --recursive linux~/drivers/char/agp/agpgart_be.c 
linux/drivers/char/agp/agpgart_be.c
--- linux~/drivers/char/agp/agpgart_be.cSun Dec 10 19:49:41 2000
+++ linux/drivers/char/agp/agpgart_be.c Mon Dec 11 00:34:40 2000
@@ -2026,6 +2026,13 @@
"Intel",
"440GX",
intel_generic_setup },
+   /* could we add support for PCI_DEVICE_ID_INTEL_815_1 too ? */
+   { PCI_DEVICE_ID_INTEL_815_0,
+   PCI_VENDOR_ID_INTEL,
+   INTEL_I815,
+   "Intel",
+   "i815",
+   intel_generic_setup },
{ PCI_DEVICE_ID_INTEL_840_0,
PCI_VENDOR_ID_INTEL,
INTEL_I840,
diff --new-file -u --recursive linux~/include/linux/agp_backend.h 
linux/include/linux/agp_backend.h
--- linux~/include/linux/agp_backend.h  Sun Dec 10 19:49:44 2000
+++ linux/include/linux/agp_backend.h   Mon Dec 11 00:32:46 2000
@@ -45,6 +45,7 @@
INTEL_BX,
INTEL_GX,
INTEL_I810,
+   INTEL_I815,
INTEL_I840,
VIA_GENERIC,
VIA_VP3,

Re: Dropping chars on 16550

[Mark Orr]

On 11-Dec-2000 Igmar Palsenberg wrote:
> On Sun, 10 Dec 2000 [EMAIL PROTECTED] wrote:
> 
>> Hi folks
>> 
>> What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI
>> CD thru mp3 encoder) and get a continuous dropping of characters, on a
>> 16550-
>> enhanced serial port, without handshake, with full-duplex load of 115200
>> bps?
>> About 1 of 320 bytes is miscommunicated.
> 
> Use handshaking

Heh...do what I did.  Go on eBay and pick up a Hayes ESP card.

I have a fairly weak system by todays standards, and I found that
even with a 16550 serial port, I'd get tcp/ip errors in my logs
(and lots of 'em).

They never wrote decent ESP drivers for Windows, but the
Linux drivers are superb.   I popped it in, configured it,
and the tcp errors vanished...not a single one in the 10 months
I've owned it.

It bugs me that they're making PC's w/o ISA cards now, because
I dont wanna give up my Hayes ESP.   Based on what I saw, a 16550
with it's tiny 16-byte buffer, isnt enough.

(yes, I'm stuck with POTS+PPP.  Cable modems are available...
but the ISP is @Hoax.  Yuck.   The only DSL grade I can get is
IDSL -- $70/month.  Double yuck.)

--
Mark Orr
[EMAIL PROTECTED]

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

Re: kapm-idled : is this a bug?

[Robert M. Love]

On Mon, 11 Dec 2000 [EMAIL PROTECTED] hissed:
>  I've recently begun testing my laptop on the latest 2.4.0-test12-pre[78]
>  kernels. When freshly booted and nothing producing a load on the system,
>  top reports a process called 'kapm-idled' consuming between 60% an 85%
>  of CPU cycles. [...]

its supposed to do this - its taking up the idle thread. its not actually
using those cpu cycles, dont worry.

yes, i agree -- its cpu usage shouldnt be shown as normal but integrated
under the idle thread.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

Bad behavior of recv on already closed sockets.

[Denis Perchine]

Hello,

there was a small thread in PostgreSQL list about behavior of recv syscall on 
Linux 2.2.16. Does anyone have similar expirience? Why such things can 
happend? And how to workaround/fix this?

--  Forwarded Message  --
Subject: [HACKERS] Strange behavior of PostgreSQL on Linux
Date: Sun, 10 Dec 2000 12:51:46 +0600
From: Denis Perchine <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]


Hello,

I have quite strange problem. It's lsof -i -n -P
postmaste 20018  postgres6u  IPv4 12241380   TCP
127.0.0.1:5432->127.0.0.1:6651 (CLOSE)

And there is no pair for it.

Backtrace of the backend shows:
(gdb) bt
#0  0x40198ba2 in recv () from /lib/libc.so.6
#1  0x80ab2c5 in pq_recvbuf ()
#2  0x80ab395 in pq_getbytes ()
#3  0x80eaa7c in SocketBackend ()
#4  0x80eab13 in ReadCommand ()
#5  0x80ebb9c in PostgresMain ()
#6  0x80d69a2 in DoBackend ()
#7  0x80d6581 in BackendStartup ()
#8  0x80d593a in ServerLoop ()
#9  0x80d53c4 in PostmasterMain ()
#10 0x80abbb6 in main ()
#11 0x400fe9cb in __libc_start_main () at ../sysdeps/generic/libc-start.c:122

[root@mx /root]# ps axwfl|grep 20018
040   507 20018 21602   0   0 152920 tcp_re SW   pts/0  0:00  \_
[postmaster]

[root@mx /root]# uname -a
Linux mx.xxx.com 2.2.16-3 #1 Mon Jun 19 19:11:44 EDT 2000 i686 unknown

Looks like it tries to read on socket which is already closed from other
side. And it seems like recv did not return in this case. Is this OK, or
kernel bug?

On the other side I see entries like this:
httpd  4260  root4u  IPv4 12173018   TCP
127.0.0.1:3994->127.0.0.1:5432 (CLOSE_WAIT)

And again. There is no any corresponding postmaster process. Does anyone has
such expirience before? And what can be the reason of such strange things.

--
Sincerely Yours,
Denis Perchine

--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--

---


--  Forwarded Message  --
Subject: Re: [HACKERS] Strange behavior of PostgreSQL on Linux
Date: Sun, 10 Dec 2000 13:18:17 -0500
From: Tom Lane <[EMAIL PROTECTED]>
To: Denis Perchine <[EMAIL PROTECTED]>


Denis Perchine <[EMAIL PROTECTED]> writes:
> Looks like it tries to read on socket which is already closed from other
> side. And it seems like recv did not return in this case. Is this OK, or
> kernel bug?

Sounds like a kernel bug --- recv() should *always* return immediately
if the socket is known closed.  I'd think the kernel didn't believe the
socket was closed, if not for your lsof evidence.  That's certainly
pointing a finger at the kernel...

We've heard (undetailed) reports before of backends hanging around when
the client was long gone.  I always assumed that the client machine had
failed to disconnect properly, but now I wonder.  A kernel bug might
explain those reports.

regards, tom lane

---

-- 
Sincerely Yours,
Denis Perchine

--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

kapm-idled : is this a bug?

[stewart]

 I've recently begun testing my laptop on the latest 2.4.0-test12-pre[78]
 kernels. When freshly booted and nothing producing a load on the system,
 top reports a process called 'kapm-idled' consuming between 60% an 85%
 of CPU cycles. If I induce a load on the machine (by recompiling kernel
 modules, for example), this process slowly loses priotity and stops
 consuming cycles. Once the compilation is complete, it climbs back up to
 the top of the stack again. Here are top snapshots taken at about 90
 second intervals:

  PID USER PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
3 root  20   0 00 0 SW  0 81.7  0.0   1:14 kapm-idled
3 root  20   0 00 0 SW  0 76.8  0.0   1:41 kapm-idled
*   3 root   9   0 00 0 SW  0  0.0  0.0   3:09 kapm-idled
3 root  14   0 00 0 SW  0 60.5  0.0   3:39 kapm-idled
3 root  20   0 00 0 SW  0 85.7  0.0   5:15 kapm-idled

* during re-compilation of kernel modules, kapm-idled was de-prioritized
  and took up no CPU cycles. after the compilation completed, the task
  priority increased until it was again consuming hi percentages.

 I've consistently re-produced this on my Dell Latitude CS laptop. I'm
 wondering if this will reduce battery life since the CPU is constantly
 being loaded instead of properly idled.

 Stewart

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

Re: INIT_LIST_HEAD marco audit

[Mohammad A. Haque]

Does this look right to people?

--- linux-2.4.0-test12.old/drivers/pcmcia/tcic.cSun Nov 19 21:56:30
2000
+++ linux-2.4.0-test12/drivers/pcmcia/tcic.cSun Dec 10 23:00:07 2000
@@ -548,8 +548,9 @@
}
 }
 
-static struct tq_struct tcic_task = {
-   routine:tcic_bh
+DECLARE_TASK_QUEUE(tcic_task);
+struct tq_struct run_tcic_task = {
+   routine:(void (*)(void *)) tcic_bh
 };
 
 static void tcic_interrupt(int irq, void *dev, struct pt_regs *regs)
--- linux-2.4.0-test12.old/drivers/pcmcia/i82365.c  Sun Nov 19 21:56:30
2000
+++ linux-2.4.0-test12/drivers/pcmcia/i82365.c  Sun Dec 10 23:06:01 2000
@@ -877,8 +877,9 @@
}
 }
 
-static struct tq_struct pcic_task = {
-   routine:pcic_bh
+DECLARE_TASK_QUEUE(pcic_task);
+struct tq_struct run_pcic_task = {
+   routine:(void (*)(void *)) pcic_bh
 };
 
 static void pcic_interrupt(int irq, void *dev,

Miles Lane wrote:
> Would someone who knows what to do send out a patch for
> these two drivers?
> 
> drivers/pcmcia/i82365.c
> drivers/pcmcia/tcic.c

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

APM-Bios Hang at Boot-up 2.2.16 2.2.17 2.2.18pre26

[Eddy]

I can't seem to get my A&T 486 to boot-up. 
If I disable APM from the above kernels my computer resets and re-boots 
automatically immediately following the kernel message "Ok booting the kernel" 

 
With APM enabled in the kernel config the system 
boots and gets to the kernel message. 
ne.c:v1.10 9/23/94 Donald 
Becker ([EMAIL PROTECTED])NE*000 
ethercard probe at 0x280: 00:40:05:3f:20:d6
eth0: NE2000 found at 0x280, 
using IRQ 9._
and then hangs.
 
Probing with magic-sysreq-P led me to 
APM-Code.
 
After turning on APM_DEBUG in 
arch/i386/kernel/apm.c I now get the continuous message 
"apm: received normal resume 
notify"
 
How can I get around this. I've tried different 
APM-BIOS settings and different kernel configurations to no avail. I really 
don't understand what is really going on here to be able to fix it.
 
I have 66Mhz Intel-486-D2 with AMIBIOS Date 
12/15/93
AMIBIOS 1993 release 07/08/1994
40-E300-001473-0011-GREEN-H
Rom Label = AI.8-1 
AB7130565

Re: INIT_LIST_HEAD marco audit

[Miles Lane]

"Mohammad A. Haque" wrote:
> 
> The follwing files probably need to be patched to use the
> DECLARE_TASK_QUEUE() macro and new tq_struct, but I don't have time
> right now to go through them.

Would someone who knows what to do send out a patch for
these two drivers?

drivers/pcmcia/i82365.c
drivers/pcmcia/tcic.c

Thanks!

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

Unable to compile the 2.2.18 kernel

[Anthony Barbachan]

Hi,

I am unable to compile the latest kernel.  I have attached my kernel
configuration and a copy of the output of where the compile fails.  I am
looking into what is causing the compile failure, but have not been able to
figure it out yet.  Still looking though.




begin 666 make-zImage-errors.txt
M+W5S"]P"]P"]P"]P"]P"]P"]P7!E"B]U"]P7!E"B]U"]P"]P7!E"B]U"]P"]P2!O
M;F-E"B]U"]PF5O9B!A<'!L:65D
M('1O(&%N(&EN8V]M<&QE=&4@='EP90HO=7-R+VEN8VQU9&4O;&EN=7@O<')O
M8U]F"]P"]P"]P"]P7!E(&]R('-T
M;W)A9V4@8VQA"]P
M"]P"]P"]P5]D7!E"B]U"]B:6YF;71S+F@Z-2P*(" @(" @(" @(" @(" @("!F"]S8VAE9"YH.C@L"B @(" @(" @(" @(" @(" @9G)O
M;2 O=7-R+VEN8VQU9&4O;&EN=7@O8FQK9&5V+F@Z-2P*(" @(" @(" @(" @
M(" @("!F"]B;&LN:#HT+ H@(" @(" @
M(" @(" @(" @(&9R;VT@:6YI="]M86EN+F,Z,C,Z"B]U"]T>7!E"]B;&LN:#HT
M+ H@(" @(" @(" @(" @(" @(&9R;VT@:6YI="]M86EN+F,Z,C,Z"B]U"]B;&MD978N:#HY-#H@
M<&%R"]B;&MD978N:#HY-CH@<&%R"]L;V-K"]P86=E;6%P+F@Z($EN(&9U;F-T:6]N(&!?<&%G95]H87-H9FXG
M.@HO=7-R+VEN8VQU9&4O;&EN=7@O<&%G96UA<"YH.C8Q.B!S:7IE;V8@87!P
M;&EE9"!T;R!A;B!I;F-O;7!L971E('1Y<&4*+W5S7!E"B]U"]P86=E;6%P+F@Z($EN(&9U;F-T
M:6]N(&!?7V9I;F1?<&%G92"]P86=E;6%P
M+F@Z-S(Z(&1E7!E"B]U"]P86=E;6%P+F@Z
M.#(Z(&1E7!E"B]U"]P
M86=E;6%P+F@Z($EN(&9U;F-T:6]N(&!R96UO=F5?<&%G95]F7!E"B]U"]P86=E;[EMAIL PROTECTED](&1E7!E"B]U"]P86=E;[EMAIL PROTECTED]@Z(&1E7!E"B]U"]P86=E;6%P+F@Z($EN(&9U;F-T:6]N(&!?7V%D9%]P86=E7W1O7VAA
M"]P
M86=E;6%P+F@Z,3(P.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP
M;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(R.B!D
M97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(S.B!D97)E9F5R96YC:6YG('!O
M:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P
M86=E;6%P+F@Z,3(T.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP
M;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(U.B!D
M97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(U.B!D97)E9F5R96YC:6YG('!O
M:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P
M86=E;6%P+F@Z,3(V.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP
M;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(W.B!D
M97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(W.B!D97)E9F5R96YC:6YG('!O
M:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P
M86=E;6%P+F@Z,3(X.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP
M;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(Y.B!D
M97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3(Y.B!D97)E9F5R96YC:6YG('!O
M:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P
M86=E;6%P+F@Z,3,P.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP
M;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3,Q.B!D
M97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z($EN(&9U;F-T:6]N(&!A9&1?<&%G
M95]T;U]I;F]D95]Q=65U92"]P86=E;6%P
M+F@Z,3,V.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T
M>7!E"B]U"]P86=E;6%P+F@Z,3,X.B!D97)E9F5R
M96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,3,Y.B!D97)E9F5R96YC:6YG('!O:6YT97(@
M=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P
M+F@Z,30P.B!D97)E9F5R96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T
M>7!E"B]U"]P86=E;6%P+F@Z,30Q.B!D97)E9F5R
M96YC:6YG('!O:6YT97(@=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P+F@Z,30R.B!D97)E9F5R96YC:6YG('!O:6YT97(@
M=&\@:6YC;VUP;&5T92!T>7!E"B]U"]P86=E;6%P
M+F@Z($EN(&9U;F-T:6]N(&!W86ET7V]N7W!A9V4G.@HO=7-R+VEN8VQU9&4O
M;&EN=7@O<&%G96UA<"YH.C$T.3H@=V%R;FEN9SH@:6UP;&EC:70@9&5C;&%R
M871I;VX@;V8@9G5N8W1I;VX@8%!A9V5,;V-K960G"B]U"]L;V-K"]L;V-K"]L;V-K7!E"B]U"]L;V-K"]L;V-K"]L;V-K7!E
M"B]U"]L;V-K2!L979E;"!O<'1I
M;VYS"B,*0T].1DE'7T584$5224U%3E1!3#UY"@HC"B,@4')O8V5S0HC($-/3D9)1U]--C@V(&ES(&YO="!S970*
M0T].1DE'7U@X-E]74%]73U)+4U]/2SUY"D-/3D9)1U]8.#9?24Y63%!'/7D*
M0T].1DE'7U@X-E]"4U=!4#UY"D-/3D9)1U]8.#9?4$]0041?3TL]>0I#3TY&
M24=?6#@V7U130SUY"D-/3D9)1U]-24-23T-/1$4];0I#3TY&24=?6#@V7TU3
M4CUM"D-/3D9)1U]8.#9?0U!5240];0I#3TY&24=?,4="/7D*(R!#3TY&24=?
M,D="(&ES(&YO="!S970*(R!#3TY&24=?34%42%]%355,051)3TX@:7,@;F]T
M('-E= I#3TY&24=?35124CUY"B,@0T].1DE'7U--4"!I0I#3TY&24=?4$-)
M7U%525)+4SUY"D-/3D9)1U]00TE?3U!424U)6D4]>0I#3TY&24=?4$-)7T],
M1%]04D]#/7D*(R!#3TY&24=?34-!(&ES(&YO="!S970*(R!#3TY&24=?5DE3
M5U,@:7,@;F]T('-E= I#3TY&24=?4UE35DE00SUY"D-/3D9)1U]"4T1?4%)/
M0T534U]!0T-4/7D*0T].1DE'7U-94T-43#UY"D-/3D9)1U]"24Y&351?04]5
M5#UM"D-/3D9)1U]"24Y&351?14Q&/7D*0T].1DE'7T))3D9-5%]-25-#/6T*
M0T].1DE'7T))3D9-5%]*059!/6T*0T].1DE'7U!!4E!/4E0];0I#3TY&24=?
M4$%24$]25%]00SUM"B,@0T].1DE'7U!!4E!/4E1?3U1(15(@:7,@;F]T('-E
M= HC($-/3D9)1U]!4$T@:7,@;F]T('-E= HC($-/3D9)1U]43U-(24)!(&ES
M(&YO="!S970*"B,*(R!0;'5G(&%N9"!0;&%Y('-U<'!O0HC
M($-/3D9)1U]"3$M?1$567TA$7TE$12!I0I#3TY&24=?0DQ+7T1%5E])1$5#1#UM"D-/3D9)1U]"
M3$M?1$567TE$151!4$4];0I#3TY&24=?0DQ+7T1%5E])1$5&3$]04%D];0I#
M3TY&24=?0DQ+7T1%5E])1$530U-)/6T*0T].1DE'7T),2U]$159?0TU$-C0P
M/7D*0T].1DE'7T),2U]$159?0TU$-C0P7T5.2$%.0T5$/7D*0T].1DE'7T),
M2U]$159?4EHQ,# P/7D*0T].1DE'7T),2U]$159?241%4$-)/7D*0T].1DE'
M7T),2U]$159?241%1$U!/7D*(R!#3TY&24=?0DQ+7T1%5E]/1D9"3T%21"!I
M0I#3TY&24=?3D543$E.2U]$158]>0I#3TY&24=?
M1DE215=!3$P]>0I#3TY&24=?1DE,5$52/7D*0T].1DE'7U5.25@]>0I#3TY&
M24=?24Y%5#UY"D-/3D9)1U])4%]-54Q424-!4U0]>0HC($-/3D9)1U])4%]!
M1%9!3D-%1%]23U5415(@:7,@;F]T('-E= HC($-/3D9)1U])4%]03E @:7,@
M;F]T('-E= I#3TY&24=?25!?1DE215=!3$P]>0I#3TY&24=?25!?1DE215=!

Re: eepro100 driver update for 2.4

[Udo A. Steinberg]

Ion Badulescu wrote:

> This is an i82559 C-step. What kind of switch is it attached to?

It's a 3Com FDDI/Ethernet Linkswitch 2200 Rev 2.8

> Also, if you feel like experimenting, edit speedo_interrupt() and change
> outw(status & 0xfc00, ioaddr + SCBStatus);
> to
> outw(status & 0xff00, ioaddr + SCBStatus);

[rest snipped]

Ok, I'll try that this afternoon and post the results, since it's 4:30am
now and I have yet to try the sleep thing.

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

Re: INIT_LIST_HEAD marco audit

[Mohammad A. Haque]

Add drivers/i2o/i2o_lan.c to the list. My patch does patch this file but
I did a copy paste and didn't replace run_task_queue with
i2o_lan_receive_post.

"Mohammad A. Haque" wrote:
> 
> The follwing files probably need to be patched to use the
> DECLARE_TASK_QUEUE() macro and new tq_struct, but I don't have time
> right now to go through them.
> 
> (grep for "static struct tq_struct.*=")
> 
> drivers/net/wan/sdlamain.c
> drivers/block/paride/pseudo.h
> drivers/scsi/atari_NCR5380.c
> drivers/scsi/mac_NCR5380.c
> drivers/scsi/oktagon_esp.c
> drivers/scsi/sun3_NCR5380.c
> drivers/isdn/hisax/foreign.c
> drivers/isdn/hisax/foreign.c
> drivers/isdn/hisax/foreign.c
> drivers/acorn/block/mfmhd.c
> drivers/pcmcia/i82365.c
> drivers/pcmcia/tcic.c
> drivers/s390/block/dasd.c

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: eepro100 driver update for 2.4

[Ion Badulescu]

On Mon, 11 Dec 2000, Udo A. Steinberg wrote:

> Anton Altaparmakov wrote:
> 
> The problem here only ever happens at initialisation/first packets. Once the
> network interface has been initialised properly it never produces those
> messages anymore. Usually it helps to shut the NIC down with ifconfig and
> bringing it back up afterwards to properly initialise it.

Actually I'm beginning to suspect that you might have a different problem
after all.

Bear with me for another couple of days, until I get near my Linux boxes
and can actually look more closely at things..

Anton Altaparmakov wrote:

> > My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557
> > [Ethernet Pro 100] (rev 04) 

So it's an i82558 A-step. That's interesting, the patch shouldn't have
made any difference on an i82558, at least according to the documentation.

Also according to the documentation (which I only realized later on), the
bit I'm turning off in the advertising word is supposed to be read-only..

This shows how much one can trust the docs, I guess. :)

> > and lspci -n gives: class 0200: 10b7:9004

Umm.. I don't think so. :) This a 3Com 3c900B. You probably got the wrong
entry, in case you have multiple cards in that box.

> Mine's a rev 08.
> 
> 00:0d.0 Class 0200: 8086:1229 (rev 08)

This is an i82559 C-step. What kind of switch is it attached to?

Also, if you feel like experimenting, edit speedo_interrupt() and change
outw(status & 0xfc00, ioaddr + SCBStatus);
to
outw(status & 0xff00, ioaddr + SCBStatus); 

and see if the complete hangs when disconnecting the cable go away. The
docs say that the device deasserts the interrupt line only when all
interrupt sources have been acked -- so if we don't ack the FCP interrupt
but do somehow get one, we end up with an un-ending stream of interrupts.

You could also try to make the printk() right next to that line *not*
depend on the debug level, and see what you get when the card barfs. Be
aware though that it will print one log line for each interrupt received,
so at the very least make your syslogd log kernel messages asynchronously
(without sync'ing after each line). On the other hand, since your problem
occurs as soon as the device is initialized, it shouldn't be too much of a
flood -- I hope.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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

Re: INIT_LIST_HEAD marco audit

[Mohammad A. Haque]

The follwing files probably need to be patched to use the
DECLARE_TASK_QUEUE() macro and new tq_struct, but I don't have time
right now to go through them.

(grep for "static struct tq_struct.*=")

drivers/net/wan/sdlamain.c
drivers/block/paride/pseudo.h
drivers/scsi/atari_NCR5380.c
drivers/scsi/mac_NCR5380.c
drivers/scsi/oktagon_esp.c
drivers/scsi/sun3_NCR5380.c
drivers/isdn/hisax/foreign.c
drivers/isdn/hisax/foreign.c
drivers/isdn/hisax/foreign.c
drivers/acorn/block/mfmhd.c
drivers/pcmcia/i82365.c
drivers/pcmcia/tcic.c
drivers/s390/block/dasd.c

Frank Davis wrote:
> 
> Hello all,
> It looks like we need to perform an audit of test12-pre8 and find all the 
>changes where INIT_LIST_HEAD should now be used.  Does anyone have a complete list of 
>all the problem drivers, as well as a list of the ones that have already been fixed? 
>If so, please post it to l-k . I don't mind maintaining a list of those patches..Just 
>send them to [EMAIL PROTECTED] .

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: more compile errors, test12-pre8 and reiserfs

[Steven Cole]

David Ford wrote:
>journal.c: In function `reiserfs_journal_commit_thread':
>journal.c:1816: invalid operands to binary !=

Just before that error, I also got this:

journal.c: In function `setup_commit_task_arg':
journal.c:1765: structure has no member named `next'

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

Re: pdev_enable_device no longer used ?

[davej]

On Mon, 11 Dec 2000, Jamie Lokier wrote:

> Here are a few more:
> 
>  net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,

Acenic is at least setting it to the correct values, not hardcoding it.

>  net/gmac.c: PCI_CACHE_LINE_SIZE, 8);

Ick.

>  scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n",

**vomit**
On the plus side, they made it arch independant. Shame it's incomplete.
If you look at the x86 path, its missing Pentium 4 support (x86==15).
It also screws up on Athlon where it should be set to 16, but gets 8.
I wouldn't be surprised if the other arch's were missing some definitions
too.  The fact that this driver is a port of FreeBSD driver may be the
reason why SMP_CACHE_BYTES wasn't used instead, and the author opted
for that monster. But still, the whole thing is completely unnecessary.

>  video/pm2fb.c: WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00);

Icky.

IMO, these fixups should all get nuked. In a majority of cases, we have
half-arsed solutions that are doing just as much badness on some archs
as the goodness they were intending to provide on others.

Let the PCI layer handle all of these quirks on startup, and be done.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Re: hotplug mopup

[Albert D. Cahalan]

Marcus Meissner writes:

>> - On the unregister/removal path, the netdevice layer ensures that
>>   the interface is removed from the kernel namespace prior to launching
>>   `/sbin/hotplug net unregister eth0'.
>>
>>   This means that when handling netdevice unregistration
>>   /sbin/hotplug cannot and must not attempt to do anything with eth0!
>>   Generally it'll fail to find an interface with this name.  If it does
>>   find eth0, it'll be the wrong one due to a race.
>
> I always thought I should have to do "/sbin/ifdown eth0" here.
> (Just as I do /sbin/ifup eth0 on register.)

Yes, definitely. Otherwise, how can one replace the eth0 hardware
without messing up the network settings? This is supposed to be
hot plug and all... to me that means I can rip out one network
card and pop in another without breaking my ssh connections.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test12-pre8

[Peter Samuelson]

[Linus]
>  - pre8:

Small thinko in arch/mips64/Makefile, looks like.

--- 2.4.0test12pre8/arch/mips64/Makefile~   Sun Dec 10 20:07:02 2000
+++ 2.4.0test12pre8/arch/mips64/MakefileSun Dec 10 20:13:07 2000
@@ -33,7 +33,7 @@
 # machines may also.  Since BFD is incredibly buggy with respect to
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
-CFLAGS += -I $(TOPDIR)/include/asm $(CFLAGS)
+CFLAGS := -I $(TOPDIR)/include/asm $(CFLAGS)
 CFLAGS += -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
 LINKFLAGS  += -G 0 -static # -N
 MODFLAGS   += -mlong-calls


But that brings up the question: why does mips64 need to specify the
'-I $(TOPDIR)/include/asm-mips64' at all?  A quick grep through
arch/mips64 and include/asm-mips64 does not reveal any reason.

So AFAICS it should actually be

--- 2.4.0test12pre8/arch/mips64/Makefile~   Sun Dec 10 20:07:02 2000
+++ 2.4.0test12pre8/arch/mips64/MakefileSun Dec 10 20:13:07 2000
@@ -33,7 +33,6 @@
 # machines may also.  Since BFD is incredibly buggy with respect to
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
-CFLAGS += -I $(TOPDIR)/include/asm $(CFLAGS)
 CFLAGS += -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
 LINKFLAGS  += -G 0 -static # -N
 MODFLAGS   += -mlong-calls


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

2.4.0t12p8: Fails building drivers/net/plip.o as module

[Horst von Brand]

Correct (as per AC's md5sum) patch applied. i686, RH 7, kgcc:

kgcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE   -c -o plip.o 
plip.c
plip.c: In function `plip_init_dev':
plip.c:352: structure has no member named `next'
plip.c:357: structure has no member named `next'
plip.c:363: structure has no member named `next'
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-usb-devel] [patch] hotplug fixes

[David Brownell]

> - We have been getting deadlocks at hotplug time because
>   call_usermodehelper is synchronous: it returns control after the
>   usermode application has exited.  But in some places (esp. 
>   [un]register_netdevice) this happens with a lock held (rtnl_lock). 
>   This cause `ifconfig' to get stuck.

The /sbin/hotplug script I sent around last week avoids this by doing
its work in the background.

I see the underlying problem here as being that network hotplug hooks
are called at the wrong time ... because they are piggybacking onto
existing APIs, which weren't designed for hotplug support.  Different
aspects of that root cause were all over your list of problems (seeming
to trigger all the nastiest ones :-).

To my way of thought (I don't claim expertise in Linux networking!)
the _clean_ fix here is accept that the network driver API needs an
update for hotplugging.  Not a big one, I suspect.  Likely we can
start with a "ready to open this device!" call, which hotplug-ready
network drivers call at the end of their PCI or USB probe routines.

We've needed such changes in both PCI and USB driver APIs ... suggesting
that such changes are to be expected as new subsystems start to learn
how to autoconfigure themselves.


> - Add a check for an empty executable path string in
>   call_usermodehelper.  (This check can probably be removed from the
>   USB code now?)

Sure.

- Dave




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

Re: hotplug mopup

[David Brownell]

> - I don't think we can say that the kernel hotplug interface is
>   complete until we have real, working, tested userspace tools.  David,
>   could you please summarise the state of play here? In particular,
>   what still needs to be done?

I think there's a lot of scope for more and better userspace tools, and we
have a great starting point with the latest 2.4 kernels.  I think such tools
are pretty well _enabled_ now by the kernel.  Some drivers don't yet help to
autoconfigure their devices; that'll come with time.


There's the "reference" /sbin/hotplug (CVS at linux-usb.sourceforge.net)
that makes a lot of devices usable immediately after you plug them in to
USB or CardBus.  Real and working ... but more testing is always good.
(I got a bug report yesterday ... :-)

- Prefers to delegate to /etc/hotplug/$TYPE.agent if that's there,
  otherwise it falls back to simple algorithms (next bullets).

- When new USB or PCI/Cardbus devices get added, driver modules
  will get loaded (and maybe initialized).  For 2.4 based systems,
  drivers need a MODULE_DEVICE_TABLE for the driver to load.

- There's a convention that /etc/hotplug/$TYPE/$MODULE startup scripts
  will get run.  This hook lets you do things like running a program
  to talk to your PDA (call from /etc/hotplug/usb/visor) or printer.

- When a new network device is registered, and "/sbin/ifup" is there,
  it's invoked to try bringing up the device. 

For 2.2.18 systems, USB hotplugging works (or so I'm told :-) using an older
approach to the problem solved by MODULE_DEVICE_TABLE in 2.4.x kernels.


One thing that needs to be done: figure out how to evolve the user mode
software moving forward.  Right now that's one script, but I forsee smarter
hotplug agents complicating the picture.  Life will be simpler if all distros
can share both core functionality (/sbin/hotplug) and ways to extend it (like
/etc/hotplug conventions).  It'd happen more easily if we put "/sbin/hotplug"
into some official tool package (say, modutils) but that's not the only way.


As for system "hotplug" class functionality that's missing, "pcmcia_cs" is
a partial blueprint.  Some of this needs kernel support:

- There's no Cardbus support for stuff like "cardctl eject", which
  would call the PCI driver remove() method and let the driver shut
  down cleanly while the device is still connected.  I suspect a
  solution like new ioctls on /proc/bus/pci files could solve that.

- Similarly with USB; though there's no tool like "cardctl" that
  folk are no expecting to use.  (If PCMCIA really needs tools to
  cleanly shut down drivers, then it'd seem other hotplug busses
  must too ... but nobody's suffering for this USB feature now.)

- Unless I missed a recent patch, only Cardbus (PCI) drivers get
  hotplug notifications, not PCMCIA (ISA-ish) ones ... so there's
  currently still a need for "cardmgr" if you're using PCMCIA cards.
  (Getting rid of it isn't a 2.4.0 task; maybe not a 2.4.x task.)

- There's a feeling that IEEE 1394, SCSI, disk partitions, input,
  and other sorts of Linux driver frameworks should move towards
  autoconfiguration ("hotplug") ... surely not 2.4.0 issues!

There's some other stuff that seems less likely to need kernel changes:

- 'remove' events are ignored ... something else must unload modules,
  like the "rmmod -as" cron job some systems run, or smarter agents
  to handle the "remove" hotplug events.

- Devices that are recognized at boot before the root filesystem is
  mounted are not going to get configured by /sbin/hotplug ...
  something needs to run after root is mounted, scanning the busses
  (/proc/bus/pci; and usbdevfs in /proc/bus/usb if it's configured
  and mounted) and effectively faking hotplug events.

- For 2.4.x systems with "pcmcia_cs", the network hotplugging has
  kicked in before the "pcmcia_cs" support doing the same stuff.
  Something smart should IMHO remove that overlap, preferably by
  making this something pcmcia_cs just doesn't do any more.

- More documentation will likely be needed.

All those additional usermode-only behaviors would seem to strongly benefit
from Linux standards for the relevant sysadmin and booting procedures, but
as I understand it they don't exist yet.

- Dave




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

2.4.0-test12-pre8 -- ohci1394.c:1588 In function `alloc_dma_rcv_ctx': structure has no member named `next'

[Miles Lane]

make[2]: Entering directory `/usr/src/linux/drivers/ieee1394'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE  
-DEXPORT_SYMTAB -c ohci1394.c
ohci1394.c: In function `alloc_dma_rcv_ctx':
ohci1394.c:1588: structure has no member named `next'
{standard input}: Assembler messages:
{standard input}:20: Warning: Ignoring changed section attributes for
.modinfo
make[2]: *** [ohci1394.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394'
make[1]: *** [_modsubdir_ieee1394] Error 2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

more compile errors, test12-pre8 and reiserfs

[David Ford]

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o journal.o journal.c
journal.c: In function `reiserfs_journal_commit_thread':
journal.c:1816: invalid operands to binary !=
make[3]: *** [journal.o] Error 1

The portion of code is this:

=>while(reiserfs_commit_thread_tq) {
run_task_queue(&reiserfs_commit_thread_tq) ;
  }


This tq_struct change surely missed a whole lot of code.  Granted
reiserfs is an external patch but I've fixed several unrelated parts of
code already.

-d



begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard

[PATCH] VLSI irq router (was: PCI irq routing..)

[Martin Diehl]

On Thu, 7 Dec 2000, Linus Torvalds wrote:

> > btw, I'm thinking I could guess the routing from the VLSI config space,
> > but I don't have any doc's. Would it be worth to try to add some specific
> 
> Please do. You might leave them commented out right now, but this is

Ok. Apparently it's the "pirq is nibble index in config space" kind of
routing which makes guessing a change bios and lspci procedure.
patch vs. 2.4.0-t12p8 below. Tested as (in)complete as my bios permits.
Works fine for several days and correctly assigns IRQ's when unassigned 
due to "pnp os". So I feel confident enough to not leave it commented out.
Test example attached.

Regards
Martin

-

diff -Nur linux-2.4.0-t12p8/arch/i386/kernel/pci-irq.c 
linux-2.4.0-t12p8-md/arch/i386/kernel/pci-irq.c
--- linux-2.4.0-t12p8/arch/i386/kernel/pci-irq.cMon Dec 11 00:29:42 2000
+++ linux-2.4.0-t12p8-md/arch/i386/kernel/pci-irq.c Mon Dec 11 00:58:48 2000
@@ -298,6 +298,33 @@
return 1;
 }
 
+/*
+ * VLSI: nibble offset 0x74 - educated guess due to routing table and
+ *   config space of VLSI 82C534 PCI-bridge/router (1004:0102)
+ *   Tested on HP OmniBook 800 covering PIRQ 1, 2, 4, 8 for onboard
+ *   devices, PIRQ 3 for non-pci(!) soundchip and (untested) PIRQ 6
+ *   for the busbridge to the docking station.
+ */
+
+static int pirq_vlsi_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
+{
+   if (pirq > 8) {
+   printk("VLSI router pirq escape (%d)\n", pirq);
+   return 0;
+   }
+   return read_config_nybble(router, 0x74, pirq-1);
+}
+
+static int pirq_vlsi_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int 
+irq)
+{
+   if (pirq > 8) {
+   printk("VLSI router pirq escape (%d)\n", pirq);
+   return 0;
+   }
+   write_config_nybble(router, 0x74, pirq-1, irq);
+   return 1;
+}
+
 #ifdef CONFIG_PCI_BIOS
 
 static int pirq_bios_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int 
irq)
@@ -329,6 +356,7 @@
 
{ "NatSemi", PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5520, pirq_cyrix_get, 
pirq_cyrix_set },
{ "SIS", PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, pirq_sis_get, pirq_sis_set },
+{ "VLSI 82C534", PCI_VENDOR_ID_VLSI, PCI_DEVICE_ID_VLSI_82C534, 
+pirq_vlsi_get, pirq_vlsi_set },
{ "default", 0, 0, NULL, NULL }
 };




PCI: BIOS32 Service Directory structure at 0xc00ec060
PCI: BIOS32 Service Directory entry at 0xeefb0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xeefc2, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Scanning for ghost devices on bus 0
PCI: Scanning for ghost devices on bus 1
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f36e0
00:03 slot=00 0:00/ 1:00/ 2:00/ 3:00/
00:04 slot=00 0:01/8eb8 1:04/8eb8 2:04/ 3:04/
00:05 slot=00 0:08/8eb8 1:08/ 2:08/ 3:08/
00:06 slot=00 0:02/8eb8 1:02/ 2:02/ 3:02/
01:00 slot=00 0:08/8eb8 1:08/ 2:08/ 3:08/
01:06 slot=01 0:06/8eb8 1:06/8eb8 2:06/8eb8 3:06/8eb8
PCI: Using IRQ router VLSI 82C534 [1004/0102] at 00:01.0
PCI: IRQ fixup
00:03.0: ignoring bogus IRQ 255
00:04.0: ignoring bogus IRQ 255
00:04.1: ignoring bogus IRQ 255
IRQ for 00:03.0(0) via 00:03.0 -> not routed
IRQ for 00:04.0(0) via 00:04.0 -> PIRQ 01, mask 8eb8, excl  -> newirq=0 ... failed
IRQ for 00:04.1(1) via 00:04.1 -> PIRQ 04, mask 8eb8, excl  -> newirq=0 ... failed
PCI: Allocating resources
PCI: Resource c000-c03f (f=1208, d=0, p=0)
PCI: Resource 3100-31ff (f=101, d=0, p=0)
PCI: Resource 1f00-1fff (f=200, d=0, p=0)
PCI: Resource 3000-301f (f=101, d=0, p=0)
  got res[1000:1fff] for resource 0 of Texas Instruments PCI1131
  got res[10001000:10001fff] for resource 0 of Texas Instruments PCI1131 (#2)
PCI: Sorting device list...

Linux PCMCIA Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
PCI: Enabling device 00:04.0 ( -> 0002)
IRQ for 00:04.0(0) via 00:04.0 -> PIRQ 01, mask 8eb8, excl  -> newirq=5 -> 
assigning IRQ 5 ... OK
PCI: Assigned IRQ 5 for device 00:04.0
PCI: Enabling device 00:04.1 ( -> 0002)
IRQ for 00:04.1(1) via 00:04.1 -> PIRQ 04, mask 8eb8, excl  -> newirq=9 -> 
assigning IRQ 9 ... OK
PCI: Assigned IRQ 9 for device 00:04.1
Yenta IRQ list 0ad8, PCI irq5
Socket status: 3110
Yenta IRQ list 08d8, PCI irq9
Socket status: 3010

00:00.0 Host bridge: VLSI Technology Inc 82C535 (rev 03)
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: VLSI Technology Inc 82C534 (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 4000-7fff
Memory behind bridge: 2000-2fff
P

OOPS when using 4GB memory setting

[Rainer Mager]

Hi all,

About 1 month back I reported a problem with getting OOPs when running with
a kernel compiled with the 4GB memory setting. Since then I've finally
managed to get the ksymoops results. Where should I post them?

To review:

My machine has 1GB RAM. If I build a 2.4.0test11 (or 8, 9, or 10 I haven't
tried earlier) kernel and chose the 1GB memory setting then only 900504 K is
detected (but everything runs stably). If I chose the 4GB memory setting
then the full 1 GB is detected but I get oops. I can reliably force an oops
by mounting a samba drive and then accessing it (via ls for example).


--Rainer

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

RE: Signal 11

[Rainer Mager]

I just applied the said patch and will report my results. Note that I have
never been able to reliably, on-demand reproduce this so give me a few days
to see what happens.

--Rainer


-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 08, 2000 11:07 PM
To: David Woodhouse
Cc: Andi Kleen; Rainer Mager; [EMAIL PROTECTED]; Mark Vojkovich
Subject: Re: Signal 11


> > wrong with it.  I've only seen this under 2.3.x/2.4 SMP kernels.  I
> > would say that this is definitely a kernel problem.=20
>
> XFree86 3.9 and XFree86 4 were rock solid for a _long_ time on 2.[34]
> kernels - even on my BP6=B9. The random crashes started to happen when =
> I
> upgraded my distribution=B2 - and are only seen by people using 2.4. So=
>  I
> suspect that it's the combination of glibc and kernel which is triggeri=
> ng
> it.

Have any of the folks seeing it checked if Ben LaHaise's fixes for the page
table updating race help ?

Alan

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

Re: 2.2.18pre25, S3, AMD K6-2, and MTRR....

[Victor J. Orlikowski]

You appear to be right, sir.
The SVGA xserver was what I was using. Changing over to use the S3
server, and then adding back in MTRRs, seems to have solved the
trouble. I'll let you know if it returns, but for now, all appears
well.

Victor
-- 
Victor J. Orlikowski
==
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

Re: [PATCH] test12-pre8 task queue fix batch

[Mohammad A. Haque]

More fixes. Ignore previous.

"Mohammad A. Haque" wrote:
> 
> Lets see if this is the gist of them...

-- 

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

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

diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c 
linux-2.4.0-test12/drivers/atm/ambassador.c
--- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul  7 00:37:24 2000
+++ linux-2.4.0-test12/drivers/atm/ambassador.c Sun Dec 10 19:44:09 2000
@@ -2397,7 +2397,7 @@
   
 #ifdef FILL_RX_POOLS_IN_BH
   // initialise bottom half
-  dev->bh.next = 0;
+  INIT_LIST_HEAD(&dev->bh.list);
   dev->bh.sync = 0;
   dev->bh.routine = (void (*)(void *)) fill_rx_pools;
   dev->bh.data = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/drm/gamma_dma.c 
linux-2.4.0-test12/drivers/char/drm/gamma_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/gamma_dma.c Tue Oct  3 14:13:53 2000
+++ linux-2.4.0-test12/drivers/char/drm/gamma_dma.c Sun Dec 10 19:04:01 2000
@@ -651,7 +651,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = gamma_dma_schedule_tq_wrapper;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/drm/i810_dma.c 
linux-2.4.0-test12/drivers/char/drm/i810_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/i810_dma.c  Tue Oct  3 14:13:53 2000
+++ linux-2.4.0-test12/drivers/char/drm/i810_dma.c  Sun Dec 10 19:04:32 2000
@@ -924,7 +924,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = i810_dma_task_queue;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/drm/mga_dma.c 
linux-2.4.0-test12/drivers/char/drm/mga_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/mga_dma.c   Sun Dec 10 13:49:22 2000
+++ linux-2.4.0-test12/drivers/char/drm/mga_dma.c   Sun Dec 10 19:05:43 2000
@@ -818,7 +818,7 @@
dev->dma->next_buffer = NULL;
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = mga_dma_task_queue;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/n_r3964.c 
linux-2.4.0-test12/drivers/char/n_r3964.c
--- linux-2.4.0-test12.old/drivers/char/n_r3964.c   Fri Jul 21 22:51:56 2000
+++ linux-2.4.0-test12/drivers/char/n_r3964.c   Sun Dec 10 19:02:28 2000
@@ -1157,12 +1157,12 @@
 * Add 'on_timer' to timer task queue
 * (will be called from timer bh)
 */
-   pInfo->bh_1.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_1.list);
pInfo->bh_1.sync = 0;
pInfo->bh_1.routine = &on_timer_1;
pInfo->bh_1.data = pInfo;

-   pInfo->bh_2.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_2.list);
pInfo->bh_2.sync = 0;
pInfo->bh_2.routine = &on_timer_2;
pInfo->bh_2.data = pInfo;
diff -urw linux-2.4.0-test12.old/drivers/char/scan_keyb.c 
linux-2.4.0-test12/drivers/char/scan_keyb.c
--- linux-2.4.0-test12.old/drivers/char/scan_keyb.c Tue Oct  3 14:13:21 2000
+++ linux-2.4.0-test12/drivers/char/scan_keyb.c Sun Dec 10 19:06:20 2000
@@ -120,7 +120,7 @@
 void __init scan_kbd_init(void)
 {
 
-   task_scan_kbd.next=NULL;
+   INIT_LIST_HEAD(task_scan_kbd.list);
task_scan_kbd.sync=0;
task_scan_kbd.routine=scan_kbd;
task_scan_kbd.data=NULL;
diff -urw linux-2.4.0-test12.old/drivers/i2o/i2o_lan.c 
linux-2.4.0-test12/drivers/i2o/i2o_lan.c
--- linux-2.4.0-test12.old/drivers/i2o/i2o_lan.cSun Dec 10 19:14:36 2000
+++ linux-2.4.0-test12/drivers/i2o/i2o_lan.cSun Dec 10 17:46:07 2000
@@ -112,8 +112,10 @@
 };
 static int lan_context;
 
-static struct tq_struct i2o_post_buckets_task = {
-   0, 0, (void (*)(void *))i2o_lan_receive_post, (void *) 0
+DECLARE_TASK_QUEUE(i2o_post_buckets_task);
+struct tq_struct run_i2o_post_buckets_task = {
+   routine: (void (*)(void *)) run_task_queue,
+   data: (void *) 0
 };
 
 /* Functions to handle message failures and transaction errors:
@@ -379,8 +381,8 @@
/* If DDM has already consumed bucket_thresh buckets, post new ones */
 
if (atomic_read(&priv->buckets_out) <= priv->max_buckets_out - 
priv->bucket_thresh) {
-   i2o_post_buckets_task.data = (void *)dev;
-   queue_task(&i2o_pos

Re: INIT_LIST_HEAD marco audit

[Mohammad A. Haque]

Generating an updated batch patch right now

Frank Davis wrote:
> 
> Hello all,
> It looks like we need to perform an audit of test12-pre8 and find all the 
>changes where INIT_LIST_HEAD should now be used.  Does anyone have a complete list of 
>all the problem drivers, as well as a list of the ones that have already been fixed? 
>If so, please post it to l-k . I don't mind maintaining a list of those patches..Just 
>send them to [EMAIL PROTECTED] .

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

INIT_LIST_HEAD marco audit

[Frank Davis]

Hello all,
It looks like we need to perform an audit of test12-pre8 and find all the 
changes where INIT_LIST_HEAD should now be used.  Does anyone have a complete list of 
all the problem drivers, as well as a list of the ones that have already been fixed? 
If so, please post it to l-k . I don't mind maintaining a list of those patches..Just 
send them to [EMAIL PROTECTED] .
Regards,
-Frank


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

Re: 2.4.0-test11 EXT2 corruption: mixing up file contents

[Guest section DW]

On Sun, Dec 10, 2000 at 10:44:02PM +0100, Frank van Maarseveen wrote:

Dag Frank -

I see lots of messages from you about corruption in 2.4.0-test11
but we all know very well that 2.4.0-test11 corrupts things
and further evidence is not necessary.
Hopefully all, or at least the most significant, problems
have been solved now, so you should upgrade to the most
recent test kernel and see how things are there.

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

Re: test12-pre8 ohci1394.c compile error

[Robert M. Love]

On Sun, 10 Dec 2000, Frank Davis wrote:
> I suspect there are more. Is there a simple patch that will fix all
> affected drivers?

yah there are a lot. ive posted a couple of patches already.

the problem is because the task queue was changed (yes, this late in 2.4)
to a newer better design, and drivers have not been redone for the new
implementation. so, there is no simple patch, and we need to fix all
these.

patches like you did for i2o are what we need. basically its just changing
to the new macros/member names.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

Re: [PATCH] test12-pre8 task queue fix batch

[Ingo Oeser]

On Sun, Dec 10, 2000 at 07:20:56PM -0500, Mohammad A. Haque wrote:
> Lets see if this is the gist of them...
 
At least one more to fix:

diff -ru linux-2.4.0-test12-pre8/drivers/isdn/hisax/config.c 
linux/drivers/isdn/hisax/config.c
--- linux-2.4.0-test12-pre8/drivers/isdn/hisax/config.c Sun Dec 10 20:38:55 2000+++ 
linux/drivers/isdn/hisax/config.c  Mon Dec 11 01:04:16 2000
@@ -1180,7 +1180,7 @@
cs->tx_skb = NULL;
cs->tx_cnt = 0;
cs->event = 0;
-   cs->tqueue.next = 0;
+   INIT_LIST_HEAD(&cs->tqueue.list);
cs->tqueue.sync = 0;
cs->tqueue.data = cs;



Regards 

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] test12-pre8 task queue fix batch

[Mohammad A. Haque]

Lets see if this is the gist of them...

-- 

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

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

diff -urw linux-2.4.0-test12.old/drivers/char/drm/gamma_dma.c 
linux-2.4.0-test12/drivers/char/drm/gamma_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/gamma_dma.c Tue Oct  3 14:13:53 2000
+++ linux-2.4.0-test12/drivers/char/drm/gamma_dma.c Sun Dec 10 19:04:01 2000
@@ -651,7 +651,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = gamma_dma_schedule_tq_wrapper;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/drm/i810_dma.c 
linux-2.4.0-test12/drivers/char/drm/i810_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/i810_dma.c  Tue Oct  3 14:13:53 2000
+++ linux-2.4.0-test12/drivers/char/drm/i810_dma.c  Sun Dec 10 19:04:32 2000
@@ -924,7 +924,7 @@
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
 
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = i810_dma_task_queue;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/drm/mga_dma.c 
linux-2.4.0-test12/drivers/char/drm/mga_dma.c
--- linux-2.4.0-test12.old/drivers/char/drm/mga_dma.c   Sun Dec 10 13:49:22 2000
+++ linux-2.4.0-test12/drivers/char/drm/mga_dma.c   Sun Dec 10 19:05:43 2000
@@ -818,7 +818,7 @@
dev->dma->next_buffer = NULL;
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = mga_dma_task_queue;
dev->tq.data  = dev;
diff -urw linux-2.4.0-test12.old/drivers/char/n_r3964.c 
linux-2.4.0-test12/drivers/char/n_r3964.c
--- linux-2.4.0-test12.old/drivers/char/n_r3964.c   Fri Jul 21 22:51:56 2000
+++ linux-2.4.0-test12/drivers/char/n_r3964.c   Sun Dec 10 19:02:28 2000
@@ -1157,12 +1157,12 @@
 * Add 'on_timer' to timer task queue
 * (will be called from timer bh)
 */
-   pInfo->bh_1.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_1.list);
pInfo->bh_1.sync = 0;
pInfo->bh_1.routine = &on_timer_1;
pInfo->bh_1.data = pInfo;

-   pInfo->bh_2.next = NULL;
+   INIT_LIST_HEAD(&pInfo->bh_2.list);
pInfo->bh_2.sync = 0;
pInfo->bh_2.routine = &on_timer_2;
pInfo->bh_2.data = pInfo;
diff -urw linux-2.4.0-test12.old/drivers/char/scan_keyb.c 
linux-2.4.0-test12/drivers/char/scan_keyb.c
--- linux-2.4.0-test12.old/drivers/char/scan_keyb.c Tue Oct  3 14:13:21 2000
+++ linux-2.4.0-test12/drivers/char/scan_keyb.c Sun Dec 10 19:06:20 2000
@@ -120,7 +120,7 @@
 void __init scan_kbd_init(void)
 {
 
-   task_scan_kbd.next=NULL;
+   INIT_LIST_HEAD(task_scan_kbd.list);
task_scan_kbd.sync=0;
task_scan_kbd.routine=scan_kbd;
task_scan_kbd.data=NULL;
diff -urw linux-2.4.0-test12.old/drivers/i2o/i2o_lan.c 
linux-2.4.0-test12/drivers/i2o/i2o_lan.c
--- linux-2.4.0-test12.old/drivers/i2o/i2o_lan.cSun Dec 10 19:14:36 2000
+++ linux-2.4.0-test12/drivers/i2o/i2o_lan.cSun Dec 10 17:46:07 2000
@@ -112,8 +112,10 @@
 };
 static int lan_context;
 
-static struct tq_struct i2o_post_buckets_task = {
-   0, 0, (void (*)(void *))i2o_lan_receive_post, (void *) 0
+DECLARE_TASK_QUEUE(i2o_post_buckets_task);
+struct tq_struct run_i2o_post_buckets_task = {
+   routine: (void (*)(void *)) run_task_queue,
+   data: (void *) 0
 };
 
 /* Functions to handle message failures and transaction errors:
@@ -379,8 +381,8 @@
/* If DDM has already consumed bucket_thresh buckets, post new ones */
 
if (atomic_read(&priv->buckets_out) <= priv->max_buckets_out - 
priv->bucket_thresh) {
-   i2o_post_buckets_task.data = (void *)dev;
-   queue_task(&i2o_post_buckets_task, &tq_immediate);
+   run_i2o_post_buckets_task.data = (void *)dev;
+   queue_task(&run_i2o_post_buckets_task, &tq_immediate);
mark_bh(IMMEDIATE_BH);
}
 
@@ -1401,7 +1403,7 @@
atomic_set(&priv->tx_out, 0);
priv->tx_count = 0;
 
-   priv->i2o_batch_send_task.next= NULL;
+   INIT_LIST_HEAD(&priv->i2o_batch_send_task.list);
priv->i2o_batch_send_task.sync= 0;
priv->i2o_batch_send_task.routine = (void *)i2o_lan_batch_send;
priv->i2o_batch_send_task.data= (void *)

Re: test12-pre8 ohci1394.c compile error

[Ingo Oeser]

On Sun, Dec 10, 2000 at 07:02:05PM -0500, Frank Davis wrote:
> ohci1394.c:1588: structure has no member named 'next'
> make[2]:*** [ohci1394.o] Error 1
> make[2]: Leaving directory '/usr/src/linux/drivers/ieee1394'
> 
> Its the same case with drivers/i2o/i2o_lan.c
> 
> I suspect there are more. Is there a simple patch that will fix all affected drivers?

Working on it. I _need_ pre8, because of some critical fixes in
it.


Whoever changed this interface without fixing _all_ the offending
files, should be shot^W^Wthink about the meaning of the words

  CODE FREEZE
for at least one week.


Sorry, but this had to be said ;-)

But heh, we all make mistakes sometimes.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [2*PATCH] alpha I/O access and mb()

[Richard Henderson]

On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote:
> asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is
> defined, otherwise it uses (take writel as an example) __raw_writel that
> IMHO need to be defined in core_t2.h.

Perhaps you should _show_ an actual failure rather than just guessing.

You are wildly incorrect asserting that out of line functions are used
only with CONFIG_ALPHA_GENERIC.  You should examine

#ifndef __raw_writel
# define __raw_writel(v,a)  ___raw_writel((v),(unsigned long)(a))
#endif

and suchlike definitions.

> core_t2.h is the only core_*.h file that does not define it and this is
> why I've proposed that patch.

FOR THE NTH TIME, NO IT IS NOT!

How often do I have to point you at the other files that do not
define (all of) these macros before you will believe me?

Jesus H Christ!  Look at some preprocessor output why don't you?
Better yet, compile the kernel with CONFIG_ALPHA_T2.  Notice how
it does not fail with undefined symbol errors.  Notice how there
are non-trivial bit fiddling insns implementing the functions in
alpha/lib/io.o.  That's the quickest way to see that I'm right
and you aren't.

End of discussion.


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

Re: eepro100 driver update for 2.4

[Udo A. Steinberg]

Hi,

Anton Altaparmakov wrote:

> Just to say that the patch (including added 4) fixed the "card reports no
> resources" messages for me. - Looking at my logs the messages appeared once
> every 10-40 minutes. - Now the box is up for more than 5 hours with the
> patch and test12-pre7 and not a single no resources message logged so far.
> (Note, I upgraded the kernel at the same time as adding the patch so it is
> actually possible that test12-pre7 vanilla is fixed as well.)

The problem here only ever happens at initialisation/first packets. Once the
network interface has been initialised properly it never produces those
messages anymore. Usually it helps to shut the NIC down with ifconfig and
bringing it back up afterwards to properly initialise it.

If you are bored, try to reboot a couple dozen times and see if you still
see it. I have test12-pre7 also.

> My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557
> [Ethernet Pro 100] (rev 04) and lspci -n gives: class 0200: 10b7:9004

Mine's a rev 08.

00:0d.0 Class 0200: 8086:1229 (rev 08)

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

Re: EMU10K1 bug (all kernel ->2.4.0-test12pre7)

[J . A . Magallon]

On Sun, 10 Dec 2000 15:11:53 Gregoire Favre wrote:
> Hello,
> 
> Well maybe not on all kernel revision, but all I tested the EMU10K1 on there
> (most off the time I use ALSA, which as the same bug...).
> 
> The bug is that the card as two audio output, they both deliver good sound
> for playing wav or mp3, but only one of them deliver the sound that came from
> the line in (same for the CD in).
> 
> I am sorry if that's not a bug and if there is an easy way to hear the sound
> out of the two output (same sound out of the two output, just mirrored).
> 

I think that depends on the player, not on the driver. The usual players only
take into account the front channels (gtcd, for example). If you use
alsaplayer to play both mp3 and CDs, the sound goes to four chans even with
CDs (but because alsaplayer is written to send the same signal to front
and rear channels).

I have been looking for a way to say to the mixer to "always mirror front
output on rear", but the mixers for emu10k are a real pain. The one that
shows all the channels, fails with the names. No one show all the features
of the chip. I even don't understand why it shows four channels in the
Main volume and 2 more for the rear.

I am thinkin of writing my own SBLive mixer for alsa, but I have found no
good description of the mixer and all the features it is supposed to have.

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux werewolf 2.2.18-pre25-vm #4 SMP Fri Dec 8 01:59:48 CET 2000 i686

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

Re: Oops in test11, test11-ac4 and test12-pre4/7

[Keith Owens]

On Sun, 10 Dec 2000 17:44:06 + (GMT), 
Tim <[EMAIL PROTECTED]> wrote:
>Dec 10 17:08:24 oxygen kernel: Call Trace: [] 
>[call_spurious_interrupt+33951/35940] [sprintf+20/28] 
>[call_spurious_interrupt+33924/35940] [do_resource_list+77/132] 
>[call_spurious_interrupt+33907/35940] []

Yet another completely broken klogd oops conversion.  Always run klogd
as "klogd -x", probably started from /etc/rc.d/init.d/syslog.

>Dec 10 17:08:24 oxygen kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 
>8b 44 24 1c

Not decoded.  Get a clean oops (without klogd getting in the way) then
run the clean oops through ksymoops.  Documentation/oops-tracing.txt.

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

test12-pre8 ohci1394.c compile error

[Frank Davis]

Hello,
   I also received this error:

ohci1394.c:1588: structure has no member named 'next'
make[2]:*** [ohci1394.o] Error 1
make[2]: Leaving directory '/usr/src/linux/drivers/ieee1394'
...
Its the same case with drivers/i2o/i2o_lan.c

I suspect there are more. Is there a simple patch that will fix all affected drivers?

Regards,
Frank


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

[PATCH] serial.c, kernel 2.2.14

[Giuseppe Guerrini]

 Hi, Linux community!

 Some time ago I had to add a proprietary multiport card to my Linux box,
and found a small incompatibility with the standard Linux serial
driver. The driver confuses the NEC NS1655x-family UARTs with Startch
ST16550, and decide not to use the FIFO, although the NEC UARTs fully
support it. In addition, the identifying algorithm is able to mess up the
state of NEC16552 Dual UART. The patch in attachment solved my problem. I
generated and tested it only on my RedHat 6.2 Linux box with kernel
2.2.14. The patch adds an item in the kernel configuration menu
("CONFIG_NEC_DUART_SUPPORT"). Although it should be harmless, I suggest to
use it only if really needed.

Bye

P.S. Please answer at my personal address, because I am not subscribed to
the mailing list.

-- 


-- 


Giuseppe Guerrini <[EMAIL PROTECTED]>

L'ordine non e` che una configurazione particolare del caos.







Sun Dec 10 23:25:24 CET 2000

 The NEC-DUART patch corrects a bug in Linux-2.2.14' serial driver
(file linux/drivers/char/serial.c). The chipset probe algorithm
doesn't identify as full-compatible 16550A UART the chips of the NEC
NS1655x family: the FIFO is not enabled, although present and fully working.
In addition, with the DUAL UART NS16552A, the chip state is messed up.
 Although harmful, the patch should be applied only if really needed.
Use it only if you are sure that you are using a NEC NS1655x UART and
are experiencing loss of characters. 
 I have developed and tested my patch on Linux 2.2.14. I can't guaratee
that it works well with other kernels.
 The patch must be applied as follows:
(I assume that there is a complete kernel source tree
in /usr/src/linux-2.2.14)

su
cd /usr/src
patch -p0 < patch-NecDuart

 A new configuration item will be added in "character devices" section:

   Bugfix for NEC UARTs (NS16C55x)
 
 Enable it, save the new configuration and rebuild the kernel.

 Enjoy,

Giuseppe Guerrini <[EMAIL PROTECTED]>



diff -Naur linux-2.2.14/Documentation/Configure.help 
linux-2.2.14-NecDuart/Documentation/Configure.help
--- linux-2.2.14/Documentation/Configure.help   Tue Apr 25 16:21:15 2000
+++ linux-2.2.14-NecDuart/Documentation/Configure.help  Sun Dec 10 13:39:52 2000
@@ -1343,6 +1343,20 @@
 
   Most people can say N here.
 
+Bugfix for NEC NS16C55x UARTs
+CONFIG_NEC_DUART_SUPPORT
+  Say Y here if you have a NEC NS1655x-family UART (NS16550Ax,
+  NS16C552x), and are experiencing problems (characters loss).
+  The standard serial driver is used to confuse the NEC UARTs
+  with Startech UARTs without FIFO support (NEC UARTs have
+  full 16550A FIFO). Use the "setserial" command to know if the
+  kernel has detected the wrong chip model.
+
+  You must say Y also if you are using the SER2 or IOSPC64 cards
+  produced by CNi (www.cnisrl.it).
+
+  If unsure, say N.
+
 Extended dumb serial driver options
 CONFIG_SERIAL_EXTENDED
   If you wish to use any non-standard features of the standard "dumb"
diff -Naur linux-2.2.14/drivers/char/Config.in 
linux-2.2.14-NecDuart/drivers/char/Config.in
--- linux-2.2.14/drivers/char/Config.in Tue Apr 25 16:21:14 2000
+++ linux-2.2.14-NecDuart/drivers/char/Config.inSun Dec 10 13:35:29 2000
@@ -10,6 +10,7 @@
 fi
 tristate 'Standard/generic (dumb) serial support' CONFIG_SERIAL
 if [ "$CONFIG_SERIAL" = "y" ]; then
+   bool '   Bugfix for NEC UARTs (NS16C55x)' CONFIG_NEC_DUART_SUPPORT
bool '   Support for console on serial port' CONFIG_SERIAL_CONSOLE
 fi
 bool 'Extended dumb serial driver options' CONFIG_SERIAL_EXTENDED
diff -Naur linux-2.2.14/drivers/char/serial.c 
linux-2.2.14-NecDuart/drivers/char/serial.c
--- linux-2.2.14/drivers/char/serial.c  Tue Apr 25 16:21:13 2000
+++ linux-2.2.14-NecDuart/drivers/char/serial.c Sun Dec 10 13:43:17 2000
@@ -154,8 +154,13 @@
 #define _INLINE_ inline
 #endif

+
 static char *serial_name = "Serial driver";
-static char *serial_version = "4.27";
+static char *serial_version = "4.27"
+#ifdef CONFIG_NEC_DUART_SUPPORT
+   " - NECDUART fix 1.0"
+#endif
+   ;
 
 static DECLARE_TASK_QUEUE(tq_serial);
 
@@ -199,6 +204,18 @@
{ "ST16650V2", 32, UART_CLEAR_FIFO | UART_USE_FIFO |
  UART_STARTECH }, 
{ "TI16750", 64, UART_CLEAR_FIFO | UART_USE_FIFO},
+#ifdef CONFIG_NEC_DUART_SUPPORT
+ /* The NEC NS16C55x is actually a 16550A. If I added
+  * a specific record for this particular chipset in "uart_config",
+  * I would have to change both "serial.h" and the "setserial"
+  * utility. I don't think it's worth. Anyway, this source is
+  * ready to accept the change. */
+#ifndef PORT_NS16C550AF
+#define PORT_NS16C550AF (PORT_MAX + 1)
+#else
+   { "NS16C55x", 16, UART_CLEAR_FIFO | UART_USE_FIFO }, 
+#endif
+#endif
{ 0, 

Re: Checking for incorrect MODULE_PARM

[Keith Owens]

On Sun, 10 Dec 2000 13:38:56 -0300, 
Horst von Brand <[EMAIL PROTECTED]> wrote:
>With 2.2.18pre27 on i686 I get:
>
> /lib/modules/2.2.18/ipv4/ip_masq_user.o
>warning: symbol for parameter ports not found
>ports int array (min = 1, max = 12)
>debug int

ports is not used in ip_masq_user, dead code.  Trivial patch.

Index: 18-pre27.1/net/ipv4/ip_masq_user.c
--- 18-pre27.1/net/ipv4/ip_masq_user.c Sun, 01 Oct 2000 19:35:12 +1100 kaos 
(linux-2.2/e/11_ip_masq_us 1.2.3.1.1.2 644)
+++ 18-pre27.1(w)/net/ipv4/ip_masq_user.c Mon, 11 Dec 2000 10:55:38 +1100 kaos 
+(linux-2.2/e/11_ip_masq_us 1.2.3.1.1.2 644)
@@ -35,7 +35,6 @@
  */
 static int debug=0;
 
-MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_MASQ_APP_PORTS) "i");
 MODULE_PARM(debug, "i");
 
 /*

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

Re: No shared memory??

[J . A . Magallon]

On Sun, 10 Dec 2000 12:11:14 David D.W. Downey wrote:
> 
> OK, got a tiny little bug here.
> 
> When running top, procinfo, or free I get 0 for Shared memory. Obviously
> this is incorrect. What has changed from the 2.2.x and the 2.4.x that
> would cause these apps to misreport this information.
> 

Have you mounted /dev/shm (shared memory) filesystem ?
Take a look at kernel documentation under linux/Documentation/Changes.

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux werewolf 2.2.18-pre25-vm #4 SMP Fri Dec 8 01:59:48 CET 2000 i686

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

[PATCH]test12-pre8 i2o_lan.c

[Frank Davis]

Hello,
   I just downloaded test12-pre8 from ftp.kernel.org and received the following error, 
as I did in the old test12-pre8. The following error appears to fix the problem.
Regards,
Frank

i2o_lan.c:116: warning: initialization makes integer from pointer
   without a cast
   i2o_lan.c:1404: structure has no member named 'next'
   make[2]: *** [i2o_lan.o] Error 1
   make[2]: *** Leaving directory '/usr/src/linux/drivers/i2o

--- drivers/i2o/i2o_lan.c.old   Sun Dec 10 18:02:22 2000
+++ drivers/i2o/i2o_lan.c   Sun Dec 10 18:35:01 2000
@@ -1401,7 +1401,7 @@
atomic_set(&priv->tx_out, 0);
priv->tx_count = 0;
 
-   priv->i2o_batch_send_task.next= NULL;
+   INIT_LIST_HEAD(&priv->i2o_batch_send_task.list);
priv->i2o_batch_send_task.sync= 0;
priv->i2o_batch_send_task.routine = (void *)i2o_lan_batch_send;
priv->i2o_batch_send_task.data= (void *)dev;


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

Re: eepro100 driver update for 2.4

[Anton Altaparmakov]

At 20:57 08/12/2000, Ion Badulescu wrote:
>On Fri, 8 Dec 2000, Udo A. Steinberg wrote:
>
> > > +   /* disable advertising the flow-control capability */
> > > +   sp->advertising &= ~0x0400;
> > > +   mdio_write(ioaddr, sp->phy[0] & 0x1f, sp->advertising);
> >
> >   ^^^
> >  missing a 4 here?
>
>Yes, sorry about that.
>
> > I've tried the patch putting a 4 in the place noted above. It doesn't
> > help with the issue at all.

Just to say that the patch (including added 4) fixed the "card reports no 
resources" messages for me. - Looking at my logs the messages appeared once 
every 10-40 minutes. - Now the box is up for more than 5 hours with the 
patch and test12-pre7 and not a single no resources message logged so far. 
(Note, I upgraded the kernel at the same time as adding the patch so it is 
actually possible that test12-pre7 vanilla is fixed as well.)

My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557 
[Ethernet Pro 100] (rev 04) and lspci -n gives: class 0200: 10b7:9004

Just my 2p.

Anton


-- 
  "Education is what remains after one has forgotten everything he 
learned in school." - Albert Einstein
-- 
Anton Altaparmakov  Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom   WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Re: pdev_enable_device no longer used ?

[Jamie Lokier]

Here are a few more:

 net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
 net/gmac.c: PCI_CACHE_LINE_SIZE, 8);
 scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n",
 video/pm2fb.c: WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00);

-- Jamie

[EMAIL PROTECTED] wrote:
> > > 1. Is there reason for the drivers to be setting this themselves
> > >to hardcoded values ?
> > 
> > Definitely not unless the devices are buggy and need a work-around.
> 
> Maybe that's the case. The culprits are mostly IDE interfaces. Andre ?
> 
> drivers/ide/cmd64x.c:   (void) pci_write_config_byte(dev,PCI_CACHE_LINE_SIZE, 0x10);
> drivers/ide/cs5530.c:   pci_write_config_byte(cs5530_0,PCI_CACHE_LINE_SIZE, 0x04);
> drivers/ide/hpt366.c:   pci_write_config_byte(dev,PCI_CACHE_LINE_SIZE, 0x08);
> drivers/ide/ns87415.c:  (void) pci_write_config_byte(dev,PCI_CACHE_LINE_SIZE, 0x10);
> 
> drivers/atm/eni.c:  pci_write_config_byte(eni_dev->pci_dev,PCI_CACHE_LINE_SIZE, 
>0x10);
> drivers/media/video/planb.c:pci_write_config_byte (pdev,PCI_CACHE_LINE_SIZE, 
>0x8);

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

Re: Checking for incorrect MODULE_PARM

[Horst von Brand]

Keith Owens <[EMAIL PROTECTED]> said:
> modutils 2.3.22 does more rigorous checking of MODULE_PARM entries and
> has already found several cases where MODULE_PARM(x) is used but the
> corresponding variable 'x' is not defined.  These are module coding
> bugs that were previously hidden.  Run this script to do a quick check
> of all your modules against modutils 2.3.22.  Run as any user, does not
> have not be root.
> 
> for i in $(/sbin/modprobe -l)
> do
>   (echo -e "\n" $i ; /sbin/modinfo -p $i) > /var/tmp/modinfo
>   grep warning /var/tmp/modinfo > /dev/null && cat /var/tmp/modinfo
> done

With 2.2.18pre27 on i686 I get:

 /lib/modules/2.2.18/ipv4/ip_masq_user.o
warning: symbol for parameter ports not found
ports int array (min = 1, max = 12)
debug int

Hope this helps a bit.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Difficult to diagnose oops in 2.2.17, details at www.aeinet.com/oops

[Johnathan Corgan]

(Please cc: me directly if you so choose, I am not subscribed to l-k at the 
moment. Thanks.  Otherwise, I'll follow the thread in a l-k archive.)

All,

I'd like to enlist your help in diagnosing a series of oopsen over the last 
eight weeks. I didn't start tracking the problem in detail until a week ago, 
but you can now find the log files, ksymoops output, SysRq dumps, and other 
files at:

http://www.aeinet.com/oops

Basically, the system is a stock Debian 2.2 (potato) install on an Intel 
system, with a custom compiled kernel. The motherboard is a dual-cpu Intel 
N440BX server board with single PIII (katmai) 500 cpu, 256 MB RAM, and is 
very lightly loaded most of the time.

It had been stable for approximately nine months on 2.2.14, then began to 
exhibit a variety of strange oops and crashes about eight weeks ago. 
Generally, the oops would result in a hard system lock up, where only a reset 
would return the box to normal. Some of these oops made it into 
/var/log/messages, and ksymoops was run on that. The output is one of the 
links at the URL above. The average uptime at this point was about an hour or 
two, though sometimes it was only five minutes.

My first guess was hardware, specifically memory.  Running memcheck86 on the 
system found serious faults, so the memory was replaced with a new module 
that passed memcheck86 with flying colors. The result was that the system 
would stay up approximately one or two days at a time, but the oops and 
lockups were still occurring.

Since it was taking about 15 minutes to reboot, I installed and converted to 
reiserfs (3.5.57), and upgraded to 2.2.17 at the same time.  The kernel is 
now 2.2.17 + crypto (10) + reiserfs (3.5.57) + badram (3.3). No change in the 
symptoms happened, and I was resetting the system manually every day or so.

Fast forward to about a week ago, when I decided that I should seek community 
help. As an incentive, I'll ship one six-pack of beer anywhere in the world 
to the first person who solves this problem permanently. Brand of beer is 
negotiable--but I only have access to cheap American beer :)

See the web log for the (unsuccessful) efforts taken so far suggested by the 
helpful people at #linpeople and #kernelnewbies on irc.debian.org.

I still suspect it's hardware, though I have no idea what it might be now. 
Christmas break brings a new system to replace it, so it will be moot by 
then, but I'm still determined to get to the bottom of it anyway.

Thanks for your time.

Johnathan Corgan
Atlas Enterprises Internet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Fwd: NTFS repair tools]

[Horst von Brand]

[EMAIL PROTECTED] (John Alvord) said:

[...]

> If this was a business, and we were knowingly distributing software
> that was known to be dangerous, we would probably be risking legal
> action.

Debatable. It is marked EXPERIMENTAL and DANGEROUS, and not enabled by
default.

> Why are we distributing such severely broken software? Heck, we seem
> reluctant to include reiserfs, a pretty high quality, supported file
> system. And we continue to distribute this !@#$%... There must be some
> strange agenda going on to limit the use of Linux.

It is just that NTFS has been in the kernel for ages, and rotted. Nobody
has taken the time to remove it (would be a lot less than what has been
wasted up to now discussing the matter here...).
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Dropping chars on 16550

[Jens Axboe]

On Sun, Dec 10 2000, [EMAIL PROTECTED] wrote:
> Hi folks
> 
> What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI
> CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550-
> enhanced serial port, without handshake, with full-duplex load of 115200 bps?
> About 1 of 320 bytes is miscommunicated.
> 
> The kernel is 2.2.12.

hdparm -u1 /dev/hdX

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at buffer.c:827! and scsi modules no load at boot w/ initrd - test12pre7

[Mohammad A. Haque]

This is seems to be fixed in test12-pre8.

Linus Torvalds wrote:
> Do you have something special that triggers this? Can you test if it
> only happens with initrd, for example?

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Linking with kernel code (Makefile)

[Jean Fekry Rizk]

Hi Kernel World,
I'm new to linux-kernel developement, so I would appreciate any help.

What I want to do:
create a shared memory segment between user space and kernel space

How am I trying to do it from kernel:
use the 'newseg' function from 'ipc/shm.c', or even the array shm_segs
directly.

The problem:
I can't link with the array or the function, this also happens with
all functions that are not defined in 'ksyms'
Even though I declared 'newseg' and 'shm_segs' as 'extern' in my file

I think my problem is in the Makefile.
I'm using linux-2.2.14
Here is the Makefile from the ipc folder
O_TARGET:=ipc.o
O_OBJS  :=util.o msg.o sem.o shm.o
include  $(TOPDIR)/Rules.make
To compile my file 'mycode.c'- which uses newseg - I just added 'mycode.o'
to the O_OBJS line.
But while making bzImage, it gives the error unresolved external 'newseg'

So my question is how can I link to the kernel source code, or am I not
allowed to?

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Dropping chars on 16550

[Igmar Palsenberg]

On Sun, 10 Dec 2000 [EMAIL PROTECTED] wrote:

> Hi folks
> 
> What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI
> CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550-
> enhanced serial port, without handshake, with full-duplex load of 115200 bps?
> About 1 of 320 bytes is miscommunicated.

Use handshaking



Igmar

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

[HOWTO] Quick howto fix on the new task queue

[Robert M. Love]

the majority of the problems i am seeing with the new task queue is that,
on list init, *next is still being used. all of that was replaced by a
single list member in the new implementation.

on init, *next is typically set to NULL. for the new task queue, there is
a macro to initialize the list: INIT_LIST_HEAD, so we simply need to use
that in lieu.

thus, replace something like:
penguin->tq.next -> NULL;

with:
INIT_LIST_HEAD(&penguin->tq.list);

this is the only problem i am seeing in pre8 ... i am still looking for
some documentation on the new interface, but the source (where i got the
above, hopefully i am right) is readable.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

Re: test12-pre8

[Mohammad A. Haque]

I think you're right. Here's an update to what I submitted before. I'll
be submitting more patches as I encounter more.

On Sun, 10 Dec 2000, Urban Widmark wrote:
> or just leaving the list as it is. It will be initialized anyway by
> schedule_task (queue_task), but using the init macro seems like a nice
> thing to do.
>

-- 

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

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


--- linux/drivers/i2o/i2o_lan.c Sun Dec 10 14:17:22 2000
+++ linux-2.4.0-test12.mhaque/drivers/i2o/i2o_lan.c Sun Dec 10 14:28:27 2000
@@ -112,8 +112,10 @@
 };
 static int lan_context;
 
-static struct tq_struct i2o_post_buckets_task = {
-   0, 0, (void (*)(void *))i2o_lan_receive_post, (void *) 0
+DECLARE_TASK_QUEUE(i2o_post_buckets_task);
+struct tq_struct run_i2o_post_buckets_task = {
+   routine: (void (*)(void *)) run_task_queue,
+   data: (void *) 0
 };
 
 /* Functions to handle message failures and transaction errors:
@@ -379,8 +381,8 @@
/* If DDM has already consumed bucket_thresh buckets, post new ones */
 
if (atomic_read(&priv->buckets_out) <= priv->max_buckets_out - 
priv->bucket_thresh) {
-   i2o_post_buckets_task.data = (void *)dev;
-   queue_task(&i2o_post_buckets_task, &tq_immediate);
+   run_i2o_post_buckets_task.data = (void *)dev;
+   queue_task(&run_i2o_post_buckets_task, &tq_immediate);
mark_bh(IMMEDIATE_BH);
}
 
@@ -1401,7 +1403,7 @@
atomic_set(&priv->tx_out, 0);
priv->tx_count = 0;
 
-   priv->i2o_batch_send_task.next= NULL;
+   INIT_LIST_HEAD(&priv->i2o_batch_send_task.list);
priv->i2o_batch_send_task.sync= 0;
priv->i2o_batch_send_task.routine = (void *)i2o_lan_batch_send;
priv->i2o_batch_send_task.data= (void *)dev;
--- linux/drivers/net/aironet4500_core.cSun Dec 10 14:30:20 2000
+++ linux-2.4.0-test12.mhaque/drivers/net/aironet4500_core.cSun Dec 10 14:31:04 
+2000
@@ -2868,7 +2868,7 @@

priv->command_semaphore_on = 0;
priv->unlock_command_postponed = 0;
-   priv->immediate_bh.next = NULL;
+   INIT_LIST_HEAD(&priv->immediate_bh.list);
priv->immediate_bh.sync = 0;
priv->immediate_bh.routine  = (void *)(void *)awc_bh;
priv->immediate_bh.data = dev;
--- linux/drivers/usb/serial/keyspan_pda.c  Sun Dec 10 13:55:25 2000
+++ linux-2.4.0-test12.mhaque/drivers/usb/serial/keyspan_pda.c  Sun Dec 10 14:11:18 
+2000
@@ -742,11 +742,11 @@
if (!priv)
return (1); /* error */
init_waitqueue_head(&serial->port[0].write_wait);
-   priv->wakeup_task.next = NULL;
+   INIT_LIST_HEAD(&priv->wakeup_task.list);
priv->wakeup_task.sync = 0;
priv->wakeup_task.routine = (void *)keyspan_pda_wakeup_write;
priv->wakeup_task.data = (void *)(&serial->port[0]);
-   priv->unthrottle_task.next = NULL;
+   INIT_LIST_HEAD(&priv->unthrottle_task.list);
priv->unthrottle_task.sync = 0;
priv->unthrottle_task.routine = (void *)keyspan_pda_request_unthrottle;
priv->unthrottle_task.data = (void *)(serial);
--- linux/fs/smbfs/sock.c   Sun Dec 10 14:33:49 2000
+++ linux-2.4.0-test12.mhaque/fs/smbfs/sock.c   Sun Dec 10 14:34:28 2000
@@ -163,7 +163,7 @@
found_data(sk);
return;
}
-   job->cb.next = NULL;
+   INIT_LIST_HEAD(&job->cb.list);
job->cb.sync = 0;
job->cb.routine = smb_data_callback;
job->cb.data = job;

[PATCH] 2.4.0 task queue updates for smbfs's sock.c

[Robert M. Love]

fs/smbfs/sock.c needs updating for the new task queue as well. find the
patch below. if i find any more of these ill put together a mass patch
instead of these individual emails.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]

--- linux/fs/smbfs/sock.c~  Sun Dec 10 17:40:56 2000
+++ linux/fs/smbfs/sock.c   Sun Dec 10 17:41:43 2000
@@ -163,7 +163,7 @@
found_data(sk);
return;
}
-   job->cb.next = NULL;
+   INIT_LIST_HEAD(&job->cb.list);
job->cb.sync = 0;
job->cb.routine = smb_data_callback;
job->cb.data = job;

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

Re: test12-pre8

[Urban Widmark]

On Sun, 10 Dec 2000, Mohammad A. Haque wrote:

> Could someome who knows what they are doing check over the following
> patch please?

I wouldn't say that I do, but no one else seems to be answering this.
list_add_tail does head->prev and making the call with a NULL 'head' looks
bad to me. I would prefer:

diff -ur -X exclude linux-2.4.0-test12-pre8-orig/fs/smbfs/sock.c 
linux-2.4.0-test12-pre8-smbfs/fs/smbfs/sock.c
--- linux-2.4.0-test12-pre8-orig/fs/smbfs/sock.cSun Dec 10 21:01:16 2000
+++ linux-2.4.0-test12-pre8-smbfs/fs/smbfs/sock.c   Sun Dec 10 23:07:15 2000
@@ -163,7 +163,7 @@
found_data(sk);
return;
}
-   job->cb.next = NULL;
+   INIT_LIST_HEAD(&job->cb.list);
job->cb.sync = 0;
job->cb.routine = smb_data_callback;
job->cb.data = job;

or just leaving the list as it is. It will be initialized anyway by
schedule_task (queue_task), but using the init macro seems like a nice
thing to do.

/Urban

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

[PATCH] Matrox DRM (mga_dma.c) tq fix Was: Re: Compile Failure:mga_dma.o on 2.4.0-test12-pre8

[Robert M. Love]

i previously reported a problem with mga_dma.c not compiling due to the
new schedule task queue updates. below is a patch to use the new task
queue system.

-- 
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]

--- linux/drivers/char/drm/mga_dma.c~   Sun Dec 10 17:35:17 2000
+++ linux/drivers/char/drm/mga_dma.cSun Dec 10 17:35:37 2000
@@ -818,7 +818,7 @@
dev->dma->next_buffer = NULL;
dev->dma->next_queue  = NULL;
dev->dma->this_buffer = NULL;
-   dev->tq.next  = NULL;
+   INIT_LIST_HEAD(&dev->tq.list);
dev->tq.sync  = 0;
dev->tq.routine   = mga_dma_task_queue;
dev->tq.data  = dev;

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

2.4.0-test12-pre8 compilation errors and make oldconfig problem

[Frank van Maarseveen]

I don't know why but make oldconfig keeps asking this:
ServerWorks OSB4 chipset support (CONFIG_BLK_DEV_OSB4) [N/y/?] (NEW) 

Compilation problems:
plip.c: In function `plip_init_dev':
plip.c:352: structure has no member named `next'
plip.c:357: structure has no member named `next'
plip.c:363: structure has no member named `next'

make[2]: Entering directory `/loc/x29/linux/fs/smbfs'
gcc -D__KERNEL__ -I/loc/x29/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE -DSMBFS_PARANOIA 
 -c -o proc.o proc.c
gcc -D__KERNEL__ -I/loc/x29/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE -DSMBFS_PARANOIA 
 -c -o dir.o dir.c
gcc -D__KERNEL__ -I/loc/x29/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE -DSMBFS_PARANOIA 
 -c -o cache.o cache.c
gcc -D__KERNEL__ -I/loc/x29/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -DMODULE -DSMBFS_PARANOIA 
 -c -o sock.o sock.c
sock.c: In function `smb_data_ready':
sock.c:166: structure has no member named `next'
make[2]: *** [sock.o] Error 1
make[2]: Leaving directory `/loc/x29/linux/fs/smbfs'

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

2.4.0-test12-pre8 (plip) does not compile

[f5ibh]

Hi there,

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i586 -DMODULE   -c -o plip.o plip.c
plip.c: In function `plip_init_dev':
plip.c:352: structure has no member named `next'
plip.c:357: structure has no member named `next'
plip.c:363: structure has no member named `next'
{standard input}: Assembler messages:
{standard input}:18: Warning: Ignoring changed section attributes for .modinfo
make[2]: *** [plip.o] Erreur 1
make[2]: Quitte le répertoire
`/usr/src/kernel-sources-2.4.0-test12-pre8/drivers/net'
make[1]: *** [_modsubdir_net] Erreur 2
make[1]: Quitte le répertoire
`/usr/src/kernel-sources-2.4.0-test12-pre8/drivers'
make: *** [_mod_drivers] 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]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Tigran Aivazian]

On Sun, 10 Dec 2000, Szabolcs Szakacsits wrote:
> 
> - this comment from include/linux/fs.h should be deleted
>   #define NR_RESERVED_FILES 10 /* reserved for root */

well, not really -- it is "reserved" right now too, it is just root is
allowed to use up all the reserved entries in the beginning and then when
the normal user uses up all the "non-reserved" ones (from slab
cache) there would be nothing left for the root.

But let us not argue about the above definition of "reserved" -- that is
not productive. Let's do something productive -- namely, take your idea to
the next logical step. Since you have proven that the freelist mechanism
or concept of "reserve file structures" is not 100% satisfactory as is
then how about removing the freelist altogether? I.e. what about serving
each allocation request directly from the slab cache and imposing any
"reserved for root" policy purely by the nr_xxx_files counters?

The only argument against such idea would be "taking elements off the
freelist is probably faster than allocating from slab". But maybe not? Who
measured it? if slab allocator is so fast that the difference is
negligible then applying the same idea all over the kernel (e.g. to
superblocks etc) will remove a lot of code, which is a good thing.

Regards,
Tigran

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

Re: 2.2.18-25 DELL Laptop Video Problems

[Jeff V. Merkey]

On Sun, Dec 10, 2000 at 05:49:06PM +0100, Dominik Kubla wrote:
> Use the VESA fb driver instead of the ATI fb driver. I have been doing so
> ever since i got my DELL Inspiron 7500: the ATI driver won't recognize the
> Rage Mobility chips (well, i could convince it to do so but the 1400x1050
> LCD panel timing never worked...)
> 
> Dominik

Can you enable both at the same time?  It's an installer issue with laptops
and I need tobe able to detect whatever is running.

:-)

Jeff


> -- 
> Drug misuse is not  a disease, it is a decision, like  the decision to step
> out in  front of a  moving car. You  would call that  not a disease  but an
> error of judgment.  --Philip K. Dick. Author's Note, A SCANNER DARKLY, 1977
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Szabolcs Szakacsits]

On Sun, 10 Dec 2000, Tigran Aivazian wrote:

> If, however, you believe that the above _is_ the case but it should _not_
> happen then you are proposing a completely new policy of file structure
> allocation which you believe is superior. It is quite possible so let's
> all understand your new policy and let Linus decide whether it's better
> than the existing one. But if so, don't tell me you are fixing a bug
> because it is not a bug -- it's a redesign of file structure allocator.

If it's not a bug then

- this comment from include/linux/fs.h should be deleted
  #define NR_RESERVED_FILES 10 /* reserved for root */
- books should be updated
- people's mind also who believe kernel reserves fd's for superuser

Kernel from 2.1 plays lottery in this regards. And this would be
another sad fact that the kernel is exteremely poor *out of the box*
in regards security and relaibility ...

Szaka


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

Re: [PATCH] truncate () doesn't clear partial pages

[Miloslav Trmac]

Hi,
On Sun, Dec 10, 2000 at 03:30:41PM -0500, Alexander Viro wrote:
> On Sun, 10 Dec 2000, Miloslav Trmac wrote:
> > Hi,
> > vmtruncate () in test11 doesn't clear ends of partial pages. Patch is attached
> 
> It doesn't and it shouldn't. That's done in ->truncate(). Check ext2_truncate()
> for example.
ext2_truncate () (or block_truncate_page (), to be precise) clears end of
page-cache page. partial_clear () in mm/memory.c is IMHO supposed to clear
ends of anonymous pages (created from COW on MAP_PRIVATE mappings).
I wasn't adding any new functionality, just correcting the old
implementation (which would never trigger).

[Yes, currently it would clear the end of the page-cache
page as many times as the page is accessible trough a pte.
partial_clear () should probably clear *only* anonymous
and swap pages.]

Actually, I'm not that sure that MAP_PRIVATE partial pages should be
cleared; SuSv2 only says "the whole pages beyond the new end will be
discarded" [ftruncate ()] and "It is unspecified whether modifications
to the underlying object done after the MAP_PRIVATE mapping is established
are visible through the MAP_PRIVATE mapping." [mmap ()].
So maybe not clearing the pages is The Right Thing - especially as it avoids
the trouble with swapped-out pages. Remove partial_clear () completely, then.
Mirek Trmac
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

fatal lockup, BIOS/CMOS reset?

[Jonathan Brugge]

I was experimenting with Hunt, a program I found. This caused some heavy 
load, and my system had already quite some programs running, so I think I 
got out of memory (no programs got killed, shouldn't that be done by the 
VM?). Maybe it was for some other reason, but my system locked, I had to use 
CTRL-ALT-DELETE. This seemed to work, my HD made some sound and it rebooted. 
But then: I got a message about a bad CMOS and when I looked in my 
BIOS-settings I saw they were totally reset... No HD's, date was 1/1/2000, 
etc.
After setting everything to the correct value I tried to boot again and no 
problem this time, not even about a partition that was unmounted 
incorrectly. It seems to me that no program may EVER have a chance to change 
things in BIOS/CMOS.I'm running kernel 2.4.0test11 with libc6-2.2.5 (Debian 
woody, if it matters).

1: Is it possible that a program sets options in BIOS/CMOS?
2: If so, should it be possible?
3: Any other things that could cause this to happen?

I'm not sure it's a kernel-related problem, but it's something that should 
never happen, in my opinion (except BIOS-flashing).

Thanks,

Jonathan Brugge

P.S.: My system: Gigabyte GA-7IXE mainboard, K7-700, 128 MB, AMD 751/756 
chipset.
_
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

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

2.4.0-test11 EXT2 corruption: mixing up file contents

[Frank van Maarseveen]

After removing 128MB, leaving the original 64MB in the main board:

+ tar xzf /home/fvm/kernel/v2.4/linux-2.4.0-test10.tar.gz
+ bzcat /home/fvm/kernel/v2.4/patch-2.4.0-test11.bz2
+ patch -p0 -s
+ zcat /home/fvm/kernel/v2.4/test12-pre7.gz
+ patch -p0 -s
3 out of 3 hunks FAILED -- saving rejects to linux/arch/mips64/Makefile.rej
1 out of 1 hunk FAILED -- saving rejects to linux/arch/mips64/arc/Makefile.rej
1 out of 1 hunk FAILED -- saving rejects to linux/arch/mips64/arc/console.c.rej

-rw-r--r--   1 fvm  sec   Aug 11 20:23 linux/arch/mips64/Makefile.orig
File contains C code (!!!), starts with:
 Descr Read SM */
#define CSR_DWRITE_RUN  (1L<<11)/* Bit 11:  Rel. Descr Write SM */
#define CSR_DWRITE_RST  (1L<<10)/* Bit 10:  Reset Descr Write SM */
#define CSR_TRANS_RUN   (1L<<9) /* Bit  9:  Release Transfer SM */
#define CSR_TRANS_RST   (1L<<8) /* Bit  8:  Reset Transfer SM */
#define CSR_ENA_POL (1L<<7) /* Bit  7:  Enable Descr Polling */
#define CSR_DIS_POL (1L<<6) /* Bit  6:  Disable Descr Polling 
*/
#define CSR_STOP(1L<<5) /* Bit  5:  Stop Rx/Tx Queue */
#define CSR_START   (1L<<4) /* Bit  4:  Start Rx/Tx Queue */
#define CSR_IRQ_CL_P(1L<<3) /* Bit  3: (Rx) Clear Parity IRQ */
#define CSR_IRQ_CL_B(1L<<2) /* Bit  2:  Clear EOB IRQ */
#define CSR_IRQ_CL_F(1L<<1) /* Bit  1:  Clear EOF IRQ */
#define CSR_IRQ_CL_C(1L<<0) /* Bit  0:  Clear ERR IRQ */
Ends with (incomplete last line):
/*  RB_TST1 8 bit   RAM Buffer Test Register 1 */
/* Bit 7:   reserved */
#define RB_WP_T_ON  (1<<6)  /* Bit 6:   Write Pointer Test On */
#define RB_WP_T

-rw-r--r--   1 fvm  sec   320 May 13  2000 
linux/arch/mips64/arc/Makefile.orig
Entire file is again C (incomplete last line):
al Receive Buffer Address upper dword*/
SK_U32  RxStat ;/* Receive Frame Status Word */
SK_U32  RxTiSt ;/* Receive Timestamp provided by the XMAC */
#ifndef SK_USE_REV_DESC 
SK_U16  RxTcpSum1 ; /* TCP Checksum 1 */
SK_U16  RxTcpSum2 ; /* TCP Checksum 2 */
SK_U16  RxTcpSp1 ;  /* TCP Checksum Calculation Start Position


-rw-r--r--   1 fvm  sec   551 May 13  2000 
linux/arch/mips64/arc/console.c.orig
Entire file:
), XMA((Mac), (Reg+2)), (SK_U16)\
 (((SK_U16)(pByte[2]) & 0x00ff)|\
 (((SK_U16)(pByte[3]) << 8) & 0xff00)));\
SK_OUT16((IoC), XMA((Mac), (Reg+4)), (SK_U16)   \
 (((SK_U16)(pByte[4]) & 0x00ff)|\
 (((SK_U16)(pByte[5]) << 8) & 0xff00)));\
SK_OUT16((IoC), XMA((Mac), (Reg+6)), (SK_U16)   \
 (((SK_U16)(pByte[6]) & 0x00ff)|\
 (((SK_U16)(pByte[7]) << 8) & 0xff00)));\
}

/*
 * Different PHY Types
 */
#define SK_PHY_XMAC 0   /* integrated in Xmac II*/
#define SK_PHY_BCOM 1   /* Broadcom BCM5400 */
#define SK_PHY_LONE 2   /* Level

Rather unusual for a console driver ;-)

fsck didn't find anything.

I checked a test11 tree and it seems that only the contents of the three
files was messed up, not the mtime/length. I can't rule out a hardware
cause but this doesn't look like a typical hardware problem to me:
mixing up data of different files.

Maybe SMP related because hardware is a dual PIII-450.

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

Patch to improve PCI consistency

[Bruce Korb]

Hi,

The information about PCI devices is scattered about the kernel
and, consequently, is inconsistent.  This patch puts the PCI/IDE
bridge information into a text database along with the data from
include/linux/pci_ids.h and drivers/pci/pci.ids.  I may have mis-
typed a few things, but the 2.4.0-test11 kernel seems to compile
and work for me.

Below is the README from the patch and the patch lives here:

  ftp://autogen.linuxave.net/pub/PCIDEV.tgz


This patch will unify the PCI device information between the
PCI driver database (pci.ids), the PCI-IDE bridges (ide-pci.c)
and the header that should enumerate all pci devices (pci_ids.h).
It does this by putting all the data into a single file and
tagging the values with names.  These named values are then
inserted into the output files.  This will provide for guaranteed
consistency, which is not now the case.  In fact, there were some
unresolvable inconsistencies in the data that are marked with
``FIXME''  comments.

The patches are against linux-2.4.0-test11.

There are other PCI device tables that could be generated as well.
As it happens, though, I am only interested in PCI/IDE bridges.
The rest are left as exercises for the reader.  :-)

Hand edited files:

pci.def  --  replacement for drivers/pci/pci.ids
pci_ids.tpl  --  Template for producing generated files
:mkpcidev--  Script for constructing files (read before use!)
PATCH--  a patch for the following files:

drivers/pci/gen-devlist.c -- obsolete
arch/i386/kernel/pci-irq.c
drivers/char/serial.c
drivers/pci/names.c
drivers/pci/Makefile
drivers/ide/ide-pci.c
drivers/parport/parport_pc.c

Generated files:

drivers/pci/devlist.hreplacement for devlist.h and classlist.h
drivers/ide/ide-pci.hReplacement for hand-coded tables in ide-pci.c
include/linux/pci_ids.h  replacement


The patches mostly remove data that are now generated.
However, some were changed because it is no longer possible to
create #define-d values with mixed case (a lower case `x').

For the ide-pci.c file, however, it also renames macros that
are inconsistent with the device names already defined in
pci.ids (pci.def).

=

The tool that makes this all happen is:

  http://AutoGen.SourceForge.net/

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Tigran Aivazian]

On Sun, 10 Dec 2000, Tigran Aivazian wrote:
> Ok, let's slowly understand each other. The scenario you suggest is:
> 
> a) measure nr_free_files and let root exhaust all freelist entries. Now
> the freelist is empty and nr_free_files = 0.
> 
> b) now let the user app allocate (from the slab cache) lots of new file
> structures. He can keep doing so until nr_files hits max_files.
> 
> Now what? Now root tries to allocate some and obviously he can't because
> the freelist is empty
.
... and neither can he allocate from the slab cache since nr_files ==
max_files now.

Now, if I understand your proposal correctly -- you would like to redefine
NR_RESERVED_FILES to be _guaranteed_ for root at any time regardless of
the allocation pattern instead of their current definition as guaranteed
number of elements on the _freelist_? Right?

So you would like to deny normal users some requests from the slab cache
if otherwise root's new NR_RESERVED_FILES wouldn't be honoured?

Did I understand your idea correctly? Such policy sounds sensible but is
certainly a redesign of file allocator and should be carefully checked if
it's ok in all cases...

If you agree with the above then we never disagreed to begin with -- I
just insisted (and still insist) that it is the expected behaviour,
perhaps not 100% satisfactory.

Also, I agree with your suggestion to increase NR_RESERVED_FILES -- with
both policies (the current and your new one) the current value of 10 is
way too small.

Regards,
Tigran

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

Patch for ymfpci in test12-pre7

[Pete Zaitcev]

Hi, Linus:

The attached patch fixes the following problems with ymfpci in 2.4 tree:

1. Enumeration was wrong, this bit people with several soundcards
   (Abhijit Menon-Sen).
2. Must use semaphore to guard open/close.
3. Old ymfpci locks up if compiled with CONFIG_SMP due to
   recursive calls to spin_lock_irqsave().
4. Endianness buglet with ''rev'' (same as in ALSA).

Also, The patch removes P3 tagged messages that I do not
anticipate to use soon.

More improvements are in my queue (bugs from Pavel Roskin,
Simon Higgins, etc.), which I would like to put in later.

Thanks in advance,
--Pete

--- linux-2.4.0-pre12-test7/drivers/sound/ymfpci.h  Fri Dec  8 22:45:29 2000
+++ linux-2.4.0-test12-pre7-p3/drivers/sound/ymfpci.h   Sat Dec  9 23:36:14 2000
@@ -247,7 +247,7 @@
 };
 
 struct ymf_unit {
-   unsigned int rev;   /* PCI revision */
+   u8 rev; /* PCI revision */
void *reg_area_virt;
void *work_ptr; // +
 
@@ -275,13 +275,13 @@
u16 ac97_features;
 
struct pci_dev *pci;
-   int inst;   /* Unit number (instance) */
 
spinlock_t reg_lock;
spinlock_t voice_lock;
 
/* soundcore stuff */
int dev_audio;
+   struct semaphore open_sem;
 
struct list_head ymf_devs;
struct ymf_state *states[1];// *
@@ -331,10 +331,6 @@
 
 struct ymf_state {
struct ymf_unit *unit;  /* backpointer */
-
-   /* single open lock mechanism, only used for recording */
-   struct semaphore open_sem;
-   wait_queue_head_t open_wait;
 
/* virtual channel number */
int virt;   // * unused a.t.m.
--- linux-2.4.0-pre12-test7/drivers/sound/ymfpci.c  Fri Dec  8 22:45:29 2000
+++ linux-2.4.0-test12-pre7-p3/drivers/sound/ymfpci.c   Sun Dec 10 12:55:35 2000
@@ -32,6 +32,9 @@
  *  ? merge ymf_pcm and state
  *  ? pcm interrupt no pointer
  *  ? underused structure members
+ *  - Remove remaining P3 tags (debug messages).
+ *  - Resolve XXX tagged questions.
+ *  - Cannot play 5133Hz.
  */
 
 #include 
@@ -59,7 +62,7 @@
 int pair, ymfpci_voice_t **rvoice);
 static int ymfpci_voice_free(ymfpci_t *codec, ymfpci_voice_t *pvoice);
 static int ymf_playback_prepare(ymfpci_t *codec, struct ymf_state *state);
-static int ymf_state_alloc(ymfpci_t *unit, int nvirt, int instance);
+static int ymf_state_alloc(ymfpci_t *unit, int nvirt);
 
 static LIST_HEAD(ymf_devs);
 
@@ -602,11 +605,9 @@
char silence;
 
if ((ypcm = voice->ypcm) == NULL) {
-/* P3 */ printk("ymf_pcm_interrupt: voice %d: no ypcm\n", voice->number);
return;
}
if ((state = ypcm->state) == NULL) {
-/* P3 */ printk("ymf_pcm_interrupt: voice %d: no state\n", voice->number);
ypcm->running = 0;  // lock it
return;
}
@@ -628,7 +629,7 @@
if (pos < 0 || pos >= dmabuf->dmasize) {/* ucode bug */
printk(KERN_ERR
"ymfpci%d: %d: runaway: hwptr %d dmasize %d\n",
-   codec->inst, voice->number,
+   codec->dev_audio, voice->number,
dmabuf->hwptr, dmabuf->dmasize);
pos = 0;
}
@@ -645,7 +646,7 @@
 
if (dmabuf->count == 0) {
printk("ymfpci%d: %d: strain: hwptr %d\n",
-   codec->inst, voice->number, dmabuf->hwptr);
+   codec->dev_audio, voice->number, dmabuf->hwptr);
ymf_playback_trigger(codec, ypcm, 0);
}
 
@@ -664,7 +665,7 @@
 */
printk("ymfpci%d: %d: lost: delta %d"
" hwptr %d swptr %d distance %d count %d\n",
-   codec->inst, voice->number, delta,
+   codec->dev_audio, voice->number, delta,
dmabuf->hwptr, swptr, distance, dmabuf->count);
} else {
/*
@@ -672,7 +673,7 @@
 */
 // printk("ymfpci%d: %d: done: delta %d"
 // " hwptr %d swptr %d distance %d count %d\n",
-// codec->inst, voice->number, delta,
+// codec->dev_audio, voice->number, delta,
 // dmabuf->hwptr, swptr, distance, dmabuf->count);
}
played = dmabuf->count;
@@ -738,7 +739,6 @@
 {
 
if (ypcm->voices[0] == NULL) {
-/* P3 */ printk("ymfpci: trigger %d no voice\n", cmd);
return -EINVAL;
}
if (cmd != 0) {
@@ -911,7 +911,7 @@
if ((err = ymfp

Re: [2*PATCH] alpha I/O access and mb()

[Abramo Bagnara]

Richard Henderson wrote:
> 
> On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote:
> > ... the only missing things from core_t2.h are some defines to
> > permit to it to work when CONFIG_ALPHA_T2 is defined.
> 
> Have you tried it?  I did.  It works fine.
> 
> What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to
> define out of line functions that asm/io.h then uses.

asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is
defined, otherwise it uses (take writel as an example) __raw_writel that
IMHO need to be defined in core_t2.h.

core_t2.h is the only core_*.h file that does not define it and this is
why I've proposed that patch.

Perhaps there is a reason I don't understand and in this case I want to
apologize and I'd like to ask you to explain me what I'm missing.

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com

It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: who is writing to disk

[Pavel Machek]

Hi!

> I found a process constantly writing to disk when I run gnome as desktop 
> and while the whole system is idle.  I don't find anything in the log
> file, and I don't see anything updated in my home dir or in /tmp.  Does it
> sound like bdflush is writing?  But I don't hear the disk access when I
> am not running gnome.  
> 
> My question then is, is there a (monitoring) tool that can tell me who is
> writing to disk?  Or how I configure the kernel to know that?

Access time updates? Try mounting with noatime.
Pavel

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

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Szabolcs Szakacsits]

On Sun, 10 Dec 2000, Tigran Aivazian wrote:

> problem (e.g. you mentioned something about allocating more than NR_FILES
> on SMP -- what do you mean?) which you are not explaining clearly.

E.g. situation, only one file struct left for allocation. One CPU goes
into get_empty_filp and before kmem_cache_alloc unlocks file_list,
another CPU gets also into get_empty_filp and locks file_list at the
top and goes on the same path, the end result potentially can be both
will increase nr_files instead of only one. But I don't think it's a
big issue at *present* that could cause any problems ...

> You just say "it is broken and here is the patch" but that, imho, is not
> enough. (ok, one could overcome the laziness and actually _read_ your
> patch to see what you _think_ is broken but surely it is better if you
> explain it yourself?).

Sorry I didn't explain, I thought it's short enough and significantly
faster to understand reading the code then my poor English ;)

Szaka

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

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Tigran Aivazian]

On Sun, 10 Dec 2000, Szabolcs Szakacsits wrote:
> Or 0 shouldn't be between 0 and NR_RESERVED_FILES. Right? Wrong. I saw
> it happens, you can reproduce it if you lookup the nr_free_files
> value, allocate that much by root, don't release them and
> immediately after this start to allocate fd's by user app. 

Ok, let's slowly understand each other. The scenario you suggest is:

a) measure nr_free_files and let root exhaust all freelist entries. Now
the freelist is empty and nr_free_files = 0.

b) now let the user app allocate (from the slab cache) lots of new file
structures. He can keep doing so until nr_files hits max_files.

Now what? Now root tries to allocate some and obviously he can't because
the freelist is empty. So what? Where is the bug? This is an expected
behaviour to me -- since the freelist is empty there are no more reserved
file structures for root. Which part of this do you believe is wrong? Or
do you believe that this is not the case at all? I.e. something else
happens in the above scenario which I am still missing? If so, please
explain.

If, however, you believe that the above _is_ the case but it should _not_
happen then you are proposing a completely new policy of file structure
allocation which you believe is superior. It is quite possible so let's
all understand your new policy and let Linus decide whether it's better
than the existing one. But if so, don't tell me you are fixing a bug
because it is not a bug -- it's a redesign of file structure allocator.

Regards,
Tigran

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

[PATCH] mdacon.c cleanup

[Pavel Rabel]

Both MODULE_PARM and __init are removed by precompiler when not compiler
as module, so no need for ifdefs. 
2.4.0-test12pre8

Pavel Rabel

--- mdacon.c.oldSun Dec 10 21:00:20 2000
+++ mdacon.cSun Dec 10 21:04:32 2000
@@ -77,10 +77,8 @@
 
 static struct vc_data  *mda_display_fg = NULL;
 
-#ifdef MODULE_PARM
 MODULE_PARM(mda_first_vc, "1-255i");
 MODULE_PARM(mda_last_vc,  "1-255i");
-#endif
 
 /* MDA register values
  */
@@ -200,11 +198,7 @@
 }
 #endif
 
-#ifdef MODULE
-static int mda_detect(void)
-#else
 static int __init mda_detect(void)
-#endif
 {
int count=0;
u16 *p, p_save;
@@ -287,11 +281,7 @@
return 1;
 }
 
-#ifdef MODULE
-static void mda_initialize(void)
-#else
 static void __init mda_initialize(void)
-#endif
 {
write_mda_b(97, 0x00);  /* horizontal total */
write_mda_b(80, 0x01);  /* horizontal displayed */
@@ -316,11 +306,7 @@
outb_p(0x00, mda_gfx_port);
 }
 
-#ifdef MODULE
-static const char *mdacon_startup(void)
-#else
 static const char __init *mdacon_startup(void)
-#endif
 {
mda_num_columns = 80;
mda_num_lines   = 25;
@@ -605,11 +591,7 @@
con_invert_region:  mdacon_invert_region,
 };
 
-#ifdef MODULE
-void mda_console_init(void)
-#else
 void __init mda_console_init(void)
-#endif
 {
if (mda_first_vc > mda_last_vc)
return;

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

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

[Gerard Sharp]

Hakan Lennestal wrote:

> > Well try the latest out there...test12-pre7.
> This is with test12-pre7 and HPT-bios 1.27.

My system is test12-pre7 also; but the bios is only 1.22 - but I am
using the 'RU' bp6 bios, which I thought to be the latest. Any pointers
on how to get a newer HPT-bios?

> Regards.
> /Håkan


Good Day and Happy Hacking
Gerard Sharp
Two Penguins at 1024x768
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] aty128fb & >8bit

[Tom Rini]

Hello.  I just noticed that in 2.2.18pre27 you can only use the aty128fb
driver at 8 bit, because of some missing bits to drivers/video/Config.in.
w/o this you can't use console at > 8 bit nor X.  I would consider this to
be a good thing to squash for 2.2.18 final because 2.2.18 is the 1st release
in a while that works well on PPC, and lots of PPCs have a rage128.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


= drivers/video/Config.in 1.10 vs edited =
--- 1.10/drivers/video/Config.inFri Oct 20 22:20:29 2000
+++ edited/drivers/video/Config.in  Sun Dec 10 13:33:45 2000
@@ -188,7 +188,8 @@
 "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
  "$CONFIG_FB_IGA" = "y" -o "$CONFIG_FB_MATROX" = "y" -o \
 "$CONFIG_FB_CT65550" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
-"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" ]; then
+"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" -o \
+"$CONFIG_FB_ATY128" = "y" ]; then
   define_bool CONFIG_FBCON_CFB8 y
 else
   if [ "$CONFIG_FB_ACORN" = "m" -o "$CONFIG_FB_ATARI" = "m" -o \
@@ -202,14 +203,15 @@
   "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
"$CONFIG_FB_IGA" = "m" -o "$CONFIG_FB_MATROX" = "m" -o \
   "$CONFIG_FB_CT65550" = "m" -o "$CONFIG_FB_PM2" = "m" -o \
-  "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" ]; then
+  "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" -o \
+  "$CONFIG_FB_ATY128" = "m" ]; then
define_bool CONFIG_FBCON_CFB8 m
   fi
 fi
 if [ "$CONFIG_FB_ATARI" = "y" -o "$CONFIG_FB_ATY" = "y" -o \
 "$CONFIG_FB_MAC" = "y" -o "$CONFIG_FB_VESA" = "y" -o \
 "$CONFIG_FB_VIRTUAL" = "y" -o "$CONFIG_FB_TBOX" = "y" -o \
-"$CONFIG_FB_Q40" = "y" -o \
+"$CONFIG_FB_Q40" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \
 "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \
 "$CONFIG_FB_VIRGE" = "y" -o "$CONFIG_FB_CYBER" = "y" -o \
 "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
@@ -221,7 +223,7 @@
   if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \
   "$CONFIG_FB_MAC" = "m" -o "$CONFIG_FB_VESA" = "m" -o \
   "$CONFIG_FB_VIRTUAL" = "m" -o "$CONFIG_FB_TBOX" = "m" -o \
-"$CONFIG_FB_Q40" = "m" -o \
+  "$CONFIG_FB_Q40" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \
   "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \
   "$CONFIG_FB_VIRGE" = "m" -o "$CONFIG_FB_CYBER" = "m" -o \
   "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
@@ -233,14 +235,14 @@
 fi
 if [ "$CONFIG_FB_ATY" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \
 "$CONFIG_FB_CLGEN" = "y" -o "$CONFIG_FB_VESA" = "y" -o \
- "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
-"$CONFIG_FB_CYBER2000" = "y" ]; then
+"$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
+"$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_ATY128" = "y" ]; then
   define_bool CONFIG_FBCON_CFB24 y
 else
   if [ "$CONFIG_FB_ATY" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \
   "$CONFIG_FB_CLGEN" = "m" -o "$CONFIG_FB_VESA" = "m" -o \
   "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \
-  "$CONFIG_FB_CYBER2000" = "m" ]; then
+  "$CONFIG_FB_CYBER2000" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then
define_bool CONFIG_FBCON_CFB24 m
   fi
 fi
@@ -249,7 +251,8 @@
 "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \
 "$CONFIG_FB_TGA" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \
 "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \
-"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" ]; then
+"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \
+"$CONFIG_FB_ATY128" = "y" ]; then
   define_bool CONFIG_FBCON_CFB32 y
 else
   if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \
@@ -257,7 +260,7 @@
   "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \
   "$CONFIG_FB_TGA" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \
   "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \
-   "$CONFIG_FB_SGIVW" = "m" ]; then
+   "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then
define_bool CONFIG_FBCON_CFB32 m
   fi
 fi

Re: [2*PATCH] alpha I/O access and mb()

[Richard Henderson]

On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote:
> ... the only missing things from core_t2.h are some defines to
> permit to it to work when CONFIG_ALPHA_T2 is defined.

Have you tried it?  I did.  It works fine.

What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to
define out of line functions that asm/io.h then uses.

This same mechanism is used on cia, mcpcia, lca, and jensen.
It has been in place in just this fashion since 2.1.something.


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

Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too

[Szabolcs Szakacsits]

On Sun, 10 Dec 2000, Tigran Aivazian wrote:

> > user% ./fd-exhaustion   # e.g. while(1) open("/dev/null",...);
> > root# cat /proc/sys/fs/file-nr
> > cat: /proc/sys/fs/file-nr: Too many open files in system
> >
> > The above happens even with increased NR_RESERVED_FILES to 96 [no
> > wonder, get_empty_filp is broken].
>
> no, it is not broken. But your experiment is broken. Don't do cat file-nr
> but compile this C program

Ok, now I understand why you can't see the problem ;) You lookup the
values in user space but I did it [additionally] in kernel space [also
I think I understand what happens ;)]. I guess with the code below you
claim I shouldn't see values like this when file struct allocations
started by user apps,
1024 0 1024

Or 0 shouldn't be between 0 and NR_RESERVED_FILES. Right? Wrong. I saw
it happens, you can reproduce it if you lookup the nr_free_files
value, allocate that much by root, don't release them and
immediately after this start to allocate fd's by user app. Note, if
you already hit nr_files = max_files you won't ever be able to
reproduce the above - but this is a half solution, kernel 2.0 was
fine, get_empty_filp was broke somewhere between 2.0 and 2.1 and it's
still broken. With the patch the functionality is back and also works
the way what the authors of the book mentioned believe ;)

It's quite funny, because before I was also told this is broken but I
couldn't believe it, so I look the code and tested it, the report was
right ...

Still disagree? ;)

Szaka

> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> int fd, len;
> static char buf[2048];
>
> fd = open("/proc/sys/fs/file-nr", O_RDONLY);
> if (fd == -1) {
> perror("open");
> exit(1);
> }
> while (1) {
> len = read(fd, buf, 1024);
> printf("len=%d %s", len, buf);
> lseek(fd, 0, SEEK_SET);
> sleep(1);
> }
> return 0;
> }
>
> and leave it running while doing experiments on the other console. You
> will see that everything is fine -- there is no bug. No wonder you saw the
> bug -- you ignored my 4 emails telling you otherwise :)
>
> Regards,
> Tigran
>
>

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

Re: 2.4.0-test11 EXT2 corruption (3)

[Jens Axboe]

On Sun, Dec 10 2000, Frank van Maarseveen wrote:
> Hmm, not only I see files stuffed with random data but sometimes also with
> a block of zeroes (about 3600 consecutive zero bytes in a .depend
> file) At one time /var/log/messages said while doing rm -rf:
> 
> Dec 10 21:23:04 iapetus kernel: EXT2-fs error (device ide0(3,4)):
> ext2_readdir: bad entry in directory #152149: rec_len is smaller than
> minimal - offset=0, inode=0, rec_len=0, name_len=0 Dec 10 21:23:04
> iapetus kernel: EXT2-fs warning (device ide0(3,4)): empty_dir: bad
> directory (dir #152149) - no `.' or `..' Dec 10 21:23:05 iapetus
> kernel: EXT2-fs error (device ide0(3,4)): ext2_readdir: bad entry in
> directory #332361: rec_len is smaller than minimal - offset=0,
> inode=0, rec_len=0, name_len=0 Dec 10 21:23:05 iapetus kernel: EXT2-fs
> warning (device ide0(3,4)): empty_dir: bad directory (dir #332361) -
> no `.' or `..'
> 
> Maybe it is a hardware problem?

No, it's a test11 problem. Go to test12-pre[latest].

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12

[Steven Cole]

Aaron Tiensivu wrote:
>| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
>| 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
>
>That's your answer right there.
>GCC 2.95.3 compiles much slower than kgcc.
>
>Rerun the 2.4.0 with kgcc to be fair. :)

Actually, it is fair.  There are really two results,

1) 309 sec for 2.2.18p26 vs  318 sec for 2.4.0t12p7 where the
   task was building 2.2.18p26 using kgcc.

2) 444 sec for 2.2.18p26 vs  457.3 sec for 2.4.0t12p7 where the
   task was building 2.4.0t12p7 using gcc.

In each case, the task and the tools used are the same.  The
only difference was the kernel used. In both cases, 2.2.18 won by 3%.  Its 
comparing apples to apples and oranges to oranges. Granted 3% isn't
very much, but I would have guessed that 2.4.0 would have been the
winner.  It wasn't, at least for this single processor machine.

Now, if you're saying that 2.4.0-test12 will get the job done faster when 
compiled using kgcc, that's something else.  I'll try that out to see if it 
makes a difference.

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

Re: 2.4.0-test11 EXT2 corruption (3)

[Frank van Maarseveen]

Hmm, not only I see files stuffed with random data but sometimes also with
a block of zeroes (about 3600 consecutive zero bytes in a .depend file)
At one time /var/log/messages said while doing rm -rf:

Dec 10 21:23:04 iapetus kernel: EXT2-fs error (device ide0(3,4)): ext2_readdir: bad 
entry in directory #152149: rec_len is smaller than minimal - offset=0, inode=0, 
rec_len=0, name_len=0
Dec 10 21:23:04 iapetus kernel: EXT2-fs warning (device ide0(3,4)): empty_dir: bad 
directory (dir #152149) - no `.' or `..'
Dec 10 21:23:05 iapetus kernel: EXT2-fs error (device ide0(3,4)): ext2_readdir: bad 
entry in directory #332361: rec_len is smaller than minimal - offset=0, inode=0, 
rec_len=0, name_len=0
Dec 10 21:23:05 iapetus kernel: EXT2-fs warning (device ide0(3,4)): empty_dir: bad 
directory (dir #332361) - no `.' or `..'

Maybe it is a hardware problem?

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

Re: 2.2.18pre25, S3, AMD K6-2, and MTRR....

[Julian Anastasov]

Hello,

On Sat, 9 Dec 2000, Victor J. Orlikowski wrote:

> After doing some googling
> It would appear that, in Family 5, Model 8, Stepping 12 of the K6-2,
> AMD used a different CPU core, that was more similar to the K6-3, and
> that there is a slightly odd way of doing write-combining.

I'm now investigating the problem. It seems it is related
to XF86_SVGA (3.3.6):

S3VGEReset called from s3v_accel.c line 300

Hm, what can trigger this reset

On total lockup I can't activate ikd nor to use sysrq.
I can reproduce the temporary lockups afetr 1 minute of testing and
usually receive the above message. I have a ktrace output (not
sure if I catch the problem in this output) and this strace -r for
the XF86_SVGA program:

 0.001019 brk(0x851a000)= 0x851a000
 0.009577 gettimeofday({976474616, 24017}, NULL) = 0
 4.865610 write(2, "\tS3VGEReset called from s3v_acce"..., 45) = 45
 0.000410 nanosleep({0, 1000}, NULL) = 0
 0.012520 nanosleep({0, 1000}, NULL) = 0
 0.019712 nanosleep({0, 1000}, NULL) = 0
 0.019997 nanosleep({0, 1000}, NULL) = 0

What means 4.8 seconds between gettimeofday() and write() ?
Can this be a problem raised from gettimeofday? I have CONFIG_RTC=y
in all tests.

> Perhaps this is the problem?
> Anyone with more knowledge on the AMD cores care to comment?
>
> Victor

So, I'm not sure whether the problem is in XFree or is
hardware/kernel related. IMO, it is not related to the MTRR
support. Any ideas for testing are welcome!


Regards

--
Julian Anastasov <[EMAIL PROTECTED]>

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

Re: [PATCH] truncate () doesn't clear partial pages

[Alexander Viro]

On Sun, 10 Dec 2000, Miloslav Trmac wrote:

> Hi,
> vmtruncate () in test11 doesn't clear ends of partial pages. Patch is attached

It doesn't and it shouldn't. That's done in ->truncate(). Check ext2_truncate()
for example.

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

automount doesn't unmount

[Philipp Matthias Hahn]

Hello!

I'm using the kernel automounter to mount several cdrom's and partitions
on my smp-box. When the mount expires they aren't automatically
unmounted.
Forcing a 'kill -SIGUSR1 `pidof automount`' works for some devices, but
others stay.

$ umount /auto/install 
umount: /auto/install: device is busy

$ fuser -v /auto/install
 USERPID ACCESS COMMAND
/auto/installroot kernel mount  /auto/install

$ lsof | grep /auto/install
doesn't print anything

Is their a way to find out why the device is still busy?

$ uname -a
Linux titan 2.4.0-test11 #1 SMP Mon Nov 20 21:39:42 CET 2000 i686 unknown
$ mount --version
mount: mount-2.10q
$ /usr/sbin/automount --version
Linux automount version 3.1.7

BYtE
Philipp
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED]

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

test12-pre8 tq_struct compile failures

[Frank Davis]

Hello,
   I sent Linus a patch a few minutes ago regarding a tq_struct issue within 
drivers/i2o/i2o_lan.c . Alan just sent out a MD5sum for test12-pre8 , so I would 
double check the MD5sum against your version of test12-pre8 to see if your errors are 
from 'old' test12-pre8 or 'new' test12-pre8 . Who knows, maybe will release a 
test12-pre9 soon. :-)

Regards,
-Frank


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

[PATCH] truncate () doesn't clear partial pages

[Miloslav Trmac]

Hi,
vmtruncate () in test11 doesn't clear ends of partial pages. Patch is attached
below.
HOWEVER, it doesn't fix everything: partial_clear () contains
if (!pte_present(pte))
return;
so swapped-out pages don't get truncated (so the patch seems to break things:
truncate () behaves differently under memory pressure).
To reproduce:
--tst.c:
int
main (int argc, char *argv[])
{
  int fd;
  volatile char *base, *p;
  unsigned i, len;

  fd = open (argv[1], O_RDWR);
  len = atoi (argv[2]) * 1048576;
  base = mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
  p = base;
  base[49] = 1;
  base[50] = 2;
  for (i = len / 4096; i != 0; i--)
{ /* Touch all pages to eat memory and force swapping the 1st page out */
  *p = 1;
  p += 4096;
}
  ftruncate (fd, 50);
  printf ("%u,%u\n", base[49], base[50]);
  return 0;
}
--
$ dd bs=1M count=$MEGS tmp
$ ./tst tmp $MEGS
Plain test11 prints always 1,2 (i.e. partial page unaffected), patched
prints 1,0 if $MEGS is low enough, 1,2 if the first page was swapped out
($MEGS >= your RAM size).
The swap case should probably be handled as in ptrace.c: access_one_page()
(fault_in_page), but I don't understand the kernel well enough.
Mirek Trmac

--- mm/memory.c.origSun Dec 10 19:51:01 2000
+++ mm/memory.c Sun Dec 10 20:17:45 2000
@@ -935,7 +935,7 @@
unsigned long diff;
 
/* mapping wholly truncated? */
-   if (mpnt->vm_pgoff >= pgoff) {
+   if (mpnt->vm_pgoff > pgoff) {
flush_cache_range(mm, start, end);
zap_page_range(mm, start, len);
flush_tlb_range(mm, start, end);
@@ -951,13 +951,16 @@
/* Ok, partially affected.. */
start += diff << PAGE_SHIFT;
len = (len - diff) << PAGE_SHIFT;
-   if (start & ~PAGE_MASK) {
-   partial_clear(mpnt, start);
-   start = (start + ~PAGE_MASK) & PAGE_MASK;
+   if (partial) {
+   partial_clear(mpnt, start + partial);
+   start += PAGE_SIZE;
+   len -= PAGE_SIZE;
+   }
+   if (len) {
+   flush_cache_range(mm, start, end);
+   zap_page_range(mm, start, len);
+   flush_tlb_range(mm, start, end);
}
-   flush_cache_range(mm, start, end);
-   zap_page_range(mm, start, len);
-   flush_tlb_range(mm, start, end);
} while ((mpnt = mpnt->vm_next_share) != NULL);
 }
  
@@ -984,7 +987,7 @@
if (!mapping->i_mmap && !mapping->i_mmap_shared)
goto out_unlock;
 
-   pgoff = (offset + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
+   pgoff = offset >> PAGE_CACHE_SHIFT;
partial = (unsigned long)offset & (PAGE_CACHE_SIZE - 1);
 
if (mapping->i_mmap != NULL)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Enviromental Monitoring

[Mohammad A. Haque]

Looks like their dns server is borked. I can't even get to their site.

David Ford wrote:
> 
> "Mohammad A. Haque" wrote:
> 
> > Hit http://www.lm-sensors.nu/
> 
> does anyone have an IP address for cvs.lm-sensors.nu?
> 
> -d

-- 

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

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Dropping chars on 16550

[clock]

Hi folks

What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI
CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550-
enhanced serial port, without handshake, with full-duplex load of 115200 bps?
About 1 of 320 bytes is miscommunicated.

The kernel is 2.2.12.

Clock

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