Re: Linux-2.4.5 and Reiserfs, oops!

[Alexander Viro]

On Sat, 26 May 2001, Chris Rankin wrote:

> Well the first thing I checked was vanilla 2.4.5, and I managed to
> bring that down hard too. It has nothing at all to do with reiserfs,
> but may be related to USB instead. I have been able to reproduce the
> problem by doing the following:
> 
> a) Booting with X on vc/2
> b) Logging into vc/6 instead
> c) Mounting a filesystem on my USB Zip drive
> d) Unmounting the filesystem again
> e) Unmounting the NFS mount
> f) Executing "rmmod -a" twice to clean out the now-unused modules
> (e.g. sd_mod, scsi_mod, usb-storage)
> g) Trying to switch back to vc/2
> h) Oops!
> 
> 2.4.4 seems OK; I guess I'll have to build those -pre kernels now.

Interesting. See Pete's posting in thread about USB problems - it
may be related.

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

Re: Linux 2.4.4-ac17

[Jaswinder Singh]

Dear Mike,

"Mike Galbraith" <[EMAIL PROTECTED]> wrote :

>
> Exactly.  Nothing but ram and it's mostly unfreeable.  That makes
> life pretty tough for the vm.
>

This is not a good concept at all , why linux is wasting precious RAM
unnecassarily, if not required .

Then what will happen for Embedded system (like in my case), which do not
have any Hard disk , only things they have Flash or Ram.

> Does it hang if you are doing other things than creating/destroying
> tiny files (with unique names) as rapidly as possible?.. ie did you
> start doing that to troubleshoot because it was hanging over a long
> period of time?
>

If i create and delete files with same name , inode_cache & dentry_cache
increases only one time , there is no problem .
If i create and delete files with different name , inode_cache &
dentry_cache increases continously and will eat my whole RAM and crash
system.

And if i create and delete my file after long lapse , inode_cache &
dentry_cache are restore after some time , their is no problem .
But if i create and delete files very frequently , inode_cache &
dentry_cache get no time for restore and eat my whole RAM and crash system.

If i donot create and delete files files frequently with different name ,
their is no problem at all.

> You snipped my suggestion.. did you try it?  If not, please do.  In
> fact, go a bit further.  Make unconditional calls to kmem_cache_reap()
> and shrink_icache_memory() as well.. prior to calling page_launder().
> It's a long shot, but it might help.  If it does help, that will
> tell developers what they need to know.  It costs you five minutes.
>
> Another option is to build 2.4.5-pre6 and add the patch Rik posted.
> If my thinker is working right, that _will_ help (if not cure).
>
> Another option which virtually guarantees successful identification
> of the problem (but costs more than five minutes) is for you to grab
> a copy of IKD from your favorite kernel mirror and give memleak a try
> locally.  It can be found in /pub/linux/kernel/people/andrea/ikd. If
> you choose this option and have any trouble, drop me a note offline.
>

Thank you very much for your suggestions , i was getting this problem in my
ARM target machine and right now i am working on SH target machines , and i
am quite busy with my SH target machines now , i have to do lot of setups to
change my target machines , i am sorry right now i am not in position to
test your suggestions , but as soon as my SH target machine work is over , i
will test all your suggestions and options.

BTW, i am getting Ramdisk intialization problem in SH target machine.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.




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

Re: Linux-2.4.5 and Reiserfs, oops!

[Chris Rankin]

> That's... interesting. With that patch changes to fs/super.c should make
> no difference whatsoever.
> 
> OK, can you reproduce NFS lockup on 2.4.5-pre5 (without that patch)
> and on 2.4.5-pre3 (ditto)? 
> 
> There were NFS changes in -pre4 and -pre5 and umount ones in -pre6. The
> latter need the patch I've posted, so vanilla -pre5 and -pre3 are the
> first candidates for checking.

Well the first thing I checked was vanilla 2.4.5, and I managed to
bring that down hard too. It has nothing at all to do with reiserfs,
but may be related to USB instead. I have been able to reproduce the
problem by doing the following:

a) Booting with X on vc/2
b) Logging into vc/6 instead
c) Mounting a filesystem on my USB Zip drive
d) Unmounting the filesystem again
e) Unmounting the NFS mount
f) Executing "rmmod -a" twice to clean out the now-unused modules
(e.g. sd_mod, scsi_mod, usb-storage)
g) Trying to switch back to vc/2
h) Oops!

2.4.4 seems OK; I guess I'll have to build those -pre kernels now.

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

Re: [linux-usb-devel] USB oops on SMP, 2.4.5 kernel, and other problems

[Pete Zaitcev]

> From: Oleg Drokin <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Date: Sat, 26 May 2001 14:37:24 +0400

> >>EIP; c01a3162<=
> Trace; c01a42fc 
> Trace; c01a5f9c 
> Trace; c01a42e0 
> Trace; c019f19f 
> Trace; c0118a9e 
> Trace; c0117e62 
> Trace; c0106e0b 

This is a relatively known problem, on SMP. My old patch for that
sort of thing fixed it, and the replacement that Johannes rolled
did not fix it completely. Linus did not like my fix, because
the kindest apprisal that he used was "idiocy".

For the moment I in Red Hat ship a patch that backs out the
Johannes' fix and reinstalls my fix, because I would rather
have things working than get Linus pleased (even if such
a thing was possible...). Johannes is generally on the right
track here and will fix it compeltely in time, one way or
another (e.g. perhaps adding one more refcounting somewhere :)

If someone needs a resolution until Johannes completes it,
use my attached patch, or use Red Hat kernels.

-- Pete

--- linux-2.4.5/drivers/usb/hub.h   Tue Apr 17 17:23:06 2001
+++ linux-2.4.5-tr5/drivers/usb/hub.h   Sat May 26 07:39:34 2001
@@ -109,7 +109,7 @@
 
struct usb_hub_descriptor *descriptor;
 
-   atomic_t refcnt;
+   struct semaphore khubd_sem;
 };
 
 #endif
--- linux-2.4.5/drivers/usb/hub.c   Wed Apr 25 14:10:47 2001
+++ linux-2.4.5-tr5/drivers/usb/hub.c   Sat May 26 07:44:10 2001
@@ -289,7 +289,7 @@
 
INIT_LIST_HEAD(&hub->event_list);
hub->dev = dev;
-   atomic_set(&hub->refcnt, 1);
+   init_MUTEX(&hub->khubd_sem);
 
/* Record the new hub's existence */
spin_lock_irqsave(&hub_event_lock, flags);
@@ -318,34 +318,11 @@
return NULL;
 }
 
-static void hub_get(struct usb_hub *hub)
-{
-   atomic_inc(&hub->refcnt);
-}
-
-static void hub_put(struct usb_hub *hub)
-{
-   if (atomic_dec_and_test(&hub->refcnt)) {
-   if (hub->descriptor) {
-   kfree(hub->descriptor);
-   hub->descriptor = NULL;
-   }
-
-   kfree(hub);
-   }
-}
-
 static void hub_disconnect(struct usb_device *dev, void *ptr)
 {
struct usb_hub *hub = (struct usb_hub *)ptr;
unsigned long flags;
 
-   if (hub->urb) {
-   usb_unlink_urb(hub->urb);
-   usb_free_urb(hub->urb);
-   hub->urb = NULL;
-   }
-
spin_lock_irqsave(&hub_event_lock, flags);
 
/* Delete it and then reset it */
@@ -356,7 +333,22 @@
 
spin_unlock_irqrestore(&hub_event_lock, flags);
 
-   hub_put(hub);
+   down(&hub->khubd_sem); /* Wait for khubd to leave this hub alone. */
+   up(&hub->khubd_sem);
+
+   if (hub->urb) {
+   usb_unlink_urb(hub->urb);
+   usb_free_urb(hub->urb);
+   hub->urb = NULL;
+   }
+
+   if (hub->descriptor) {
+   kfree(hub->descriptor);
+   hub->descriptor = NULL;
+   }
+
+   /* Free the memory */
+   kfree(hub);
 }
 
 static int hub_ioctl(struct usb_device *hub, unsigned int code, void *user_data)
@@ -668,7 +660,7 @@
list_del(tmp);
INIT_LIST_HEAD(tmp);
 
-   hub_get(hub);
+   down(&hub->khubd_sem); /* never blocks, we were on list */
spin_unlock_irqrestore(&hub_event_lock, flags);
 
if (hub->error) {
@@ -676,8 +668,8 @@
 
if (usb_hub_reset(hub)) {
err("error resetting hub %d - disconnecting", 
dev->devnum);
+   up(&hub->khubd_sem);
usb_hub_disconnect(dev);
-   hub_put(hub);
continue;
}
 
@@ -753,7 +745,7 @@
usb_hub_power_on(hub);
}
}
-   hub_put(hub);
+   up(&hub->khubd_sem);
 } /* end while (1) */
 
spin_unlock_irqrestore(&hub_event_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac17

[Mike Galbraith]

On Sat, 26 May 2001, Jaswinder Singh wrote:

> > The OS resides on disk, yes.  I suppose I could plunk a minimal
> > system into ramfs, pivot_root and umount disk, but I don't see
> > any way that could matter for a memory leak.
> >
>
> It is very difficult to see memory leak , with hard disks .

It is very easy for me to see any leak which I can trigger.  I'm using
a tool which tracks each any every allocation in the kernel. (a 1/32
scale model of physical memory with 'who allocated it, and when' tags)

> As i told you , in my case i am using no harddisks , only thing i have is
> RAM , so i am using only Ramdisk and ramfs, so in my case my Ram will full
> within few minutes and My machine hangs .

Exactly.  Nothing but ram and it's mostly unfreeable.  That makes
life pretty tough for the vm.

Does it hang if you are doing other things than creating/destroying
tiny files (with unique names) as rapidly as possible?.. ie did you
start doing that to troubleshoot because it was hanging over a long
period of time?

You snipped my suggestion.. did you try it?  If not, please do.  In
fact, go a bit further.  Make unconditional calls to kmem_cache_reap()
and shrink_icache_memory() as well.. prior to calling page_launder().
It's a long shot, but it might help.  If it does help, that will
tell developers what they need to know.  It costs you five minutes.

Another option is to build 2.4.5-pre6 and add the patch Rik posted.
If my thinker is working right, that _will_ help (if not cure).

Another option which virtually guarantees successful identification
of the problem (but costs more than five minutes) is for you to grab
a copy of IKD from your favorite kernel mirror and give memleak a try
locally.  It can be found in /pub/linux/kernel/people/andrea/ikd. If
you choose this option and have any trouble, drop me a note offline.

-Mike

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

RE: Linux-2.4.5 and Reiserfs, oops!

[Alexander Viro]

On Sat, 26 May 2001, Chris Rankin wrote:

> Hi,
> 
> Thanks for the patch; I successfully unmounted my reiserfs USB Zip 250
> MB disc. However, the box then locked up hard when I unmounted an NFS
> mount and tried to switch to another virtual console.

That's... interesting. With that patch changes to fs/super.c should make
no difference whatsoever.

OK, can you reproduce NFS lockup on 2.4.5-pre5 (without that patch)
and on 2.4.5-pre3 (ditto)? 

There were NFS changes in -pre4 and -pre5 and umount ones in -pre6. The
latter need the patch I've posted, so vanilla -pre5 and -pre3 are the
first candidates for checking.

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

RE: Linux-2.4.5 and Reiserfs, oops!

[Chris Rankin]

Hi,

Thanks for the patch; I successfully unmounted my reiserfs USB Zip 250
MB disc. However, the box then locked up hard when I unmounted an NFS
mount and tried to switch to another virtual console.

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

RE: 2.4.5aa1

[Phil Oester]

Works for me.  Running cerberus on a machine w/2gb RAM - deadlocks on 2.4.5
vanilla, keeps running on 2.4.5aa1.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Andrea Arcangeli
Sent: Saturday, May 26, 2001 10:33 AM
To: [EMAIL PROTECTED]
Subject: 2.4.5aa1


I merged Rik's three liner fix to alloc_pages for GFP_BUFFER, plus my
other fix in create_buffers wait_event and a bit bigger reserved pool of
async bh. I'd suggest to test if this makes the highmem deadlock to go
away.

Detailed description of 2.4.5aa1 follows.

---
00_alpha-illegal-irq-1

Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number
is getting run.

(debugging)

00_boot-serial-console-1

Allows the serial console to work anytime during boot. It may have side
effects but certainly nothing relevant and the current situation was
annoying enough.

(nice to have)

00_create_buffers-deadlock-1

Fix tasks possibly deadlocking in wait_event because the unused_list
isn't refilled at I/O completion anymore with the 2.4
pagecache(/swapcache) design.

(recommended)

00_eepro100-64bit-1

Fixes a 64bit bug that was generating false positives and memory
corruption.

(recommended)

00_eepro100-alpha-1

Possibly fix the eepro100 transmitter hang on alpha by doing atomic PIO
updates to avoid the clear_suspend to be lost.

(recommended)

00_gfp_buffer-alloc-pages-deadlock-1

Fix from Rik that avoids GFP_BUFFER to deadlock inside alloc_pages().

This is by no means a definitive fix for the VM deadlocks during oom,
all other __GFP_IO allocations can still dealdock inside alloc_pages()
like before. But it is a first step in the right direction I think.

Please try to beat 2.4.5aa1 hard and see if you can reproduce deadlocks
with highmem.

(recommended)

00_cachelinealigned-in-smp-1

Moves the pagecache_lock and the VM pagemap_lru_lock in two
different L1 cachelines to avoid contention, mostly useful on
the alpha where the spinlocks uses load locked store
conditional loops (and we don't want to loop).

(nice to have)

00_copy-user-lat-2

Put the rechedule points into copy-user calls, with lots of
cache large read/writes could otherwise _never_ reschedule
once until they returns to userspace.

(recommended)

00_cpus_allowed-1

Fixes a bug in the cpu affinity in-kernel API, bug was fatal
for ksoftirqd.

(recommended)

00_double-buffer-pass-1

Avoids looping two times for no good reason into the lru lists
of the buffer cache (the double loop was an unreliable hack
from the prehistory that survided 'till today).

(nice to have)

00_exception-table-1

Avoids a compilation warning when compiling without modules.

(very minor thing)

00_highmem-deadlock-3

Fixes an highmem deadlock using a reserved pool for the bounce
buffers.

(recommended)

00_highmem-debug-1

Allows people with x86 machines with less than 1G of ram to
test the highmem code.

(debugging)

00_ia32-bootmem-corruption-1

Fixes the x86 boot stage to finish initializing all the
reserved memory before starting allocating memory.

(recommended)

00_ipv6-null-oops-1

Fixes null pointer oops.

(recommended)

00_jens-loop-noop-nobounce-1

Skips the bounces with the null transfer function.

(nice to have)

00_ksoftirqd-4

Avoids 1/HZ latency for the softirq if the softirq is marked
again pending when do_softirq() finished and the machine is
otherwise idle, it also fixes the case of a softirq re-marking
itself runnable by delegating to the scheduler the balance of
the softirq load like if it would be an normal task.

(nice to have)

00_kupdate-large-interval-1

Allows to set large interval for the kupdate runs, this is
useful on the laptops, instead of sigstopping ksoftirqd it's
nicer to set a large interval for example of the order of one
hour (do that at your own risk of course, doing that is not
recommended unless you know what you're doing).

(nice to have)

00_lvm-0.9.1_beta7-4

Updates to the lvmbeta7 with fixes for the lv hardsectsize
estimantion based on the max hardsectsize of the underlying
pv, plus it has some other tons of fixes and it is a must have
for the 64bit archs as the IOP silenty changed for those
platforms.

(recommended)

00_max_readahead-1

Increases the max_readahead to allow the blkdev to read with
512k scsi commands when possible.

(nice to have)

00_msync-fb0-1

   

DIESEL FUEL INJECTION-2001/5/27

[c.h]

Hi:

   We, China-Lutong mechanical company, located in south east of
China, specialized in the supply of VE distributor pump. My name is
ChenHwa, the "C.H"  is the abbreviation  At present.
The main products available for us is the hydraulic head of VE
distributor pump, which is standard spares in good quality. We can
supply them in the very competitive price. As for the VE distributor
head. If you are interested, contact me please.
   We can supply the VE distributor head with below type for the
vehicle re-assembly.
Engine model   VE PUMS code  NO UNIT PRICE(EX WORK)
(ISUZU)4JB1  NP-VE4/11F1800LNP777   146402-0920USD$ 40
(ISUZU)4JB1  NP-VE4/11L(DENSO)  096400-1600USD$ 40
(ISUZU)4JB1  NP-VE4/11R 146402-0820USD$ 45
(ISUZU)4JA1  NP-VE4/11L 146402-3820USD$ 45
(ISUZU)4JA1  NP-VE4/12L 146404-2200USD$ 45
(CUMMINS)6BT NP-VE6/12F1050R381-7   1 468 336 423  USD$ 45
(IVECO)8140  NP-VE4/11FR1900R1271 468 334 798  USD$ 45
  Regarding the quality of our products, we adapt precision forging
technology, surface treating by imported shot-blasting machine. And
the constant grinding process guarantee the plunger in identical
clearance each. If you are interested, we can supply them in
competitive price.
   Since we have been in the field of diesel fuel injection system
for quite a few years,we acquaint with many domestic manufacturers
and sales agents.(injector nozzle, plunger, delivery valve etc.parts)

Thanks again for your interests with our company.

We are waiting for your prompt response.

Best regards!

C.Hwa
Sale & purchasing department director
[EMAIL PROTECTED]
HTTP://WWW.China-LuTong.COM
<>

Re: 2.4.5 + ReiserFS + SMP + umount = oops

[Rene]

On Sun, 27 May 2001, Keith Owens wrote:

> On Sun, 27 May 2001 06:04:28 +0200 (CEST), 
> Rene <[EMAIL PROTECTED]> wrote:
> >hmm I feel quite certain that I am using /dev/tty - is there some way I
> >can check this?
> 
> /etc/inittab, lines for mingetty, getty or agetty.

1:2345:respawn:/sbin/mingetty tty1
.   
8:2345:respawn:/sbin/mingetty tty8

is what I have 
default runlevel is 4

regards
  /rene
-- 
Rene Mikkelsen, 
Tlf: +45 40501985
---
http://www.eslug.dk - the choice of a GNU generation
http://dustpuppy.dk - UF på dansk
---

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

[FIX] Re: umount segfault on shutdown

[Alexander Viro]

On Sat, 26 May 2001, Gavin wrote:

> Hi,
> Hope this is enough info :P
> 
> Unmounting file systems: journal_begin called without kernel lock held
> kernel BUG at journal.c:423!


--- fs/super.c  Fri May 25 21:51:14 2001
+++ fs/super.c.new  Sun May 27 00:21:53 2001
@@ -873,6 +873,7 @@
}
spin_unlock(&dcache_lock);
down_write(&sb->s_umount);
+   lock_kernel();
sb->s_root = NULL;
/* Need to clean after the sucker */
if (fs->fs_flags & FS_LITTER)
@@ -901,6 +902,7 @@
put_filesystem(fs);
sb->s_type = NULL;
unlock_super(sb);
+   unlock_kernel();
up_write(&sb->s_umount);
if (bdev) {
blkdev_put(bdev, BDEV_FS);

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

Re: Linux-2.4.5, reiserfs, Oops!

[Alexander Viro]

On Sat, 26 May 2001, Chris Rankin wrote:

> Linux 2.4.5, SMP, devfs, < 1 GB memory, compiled with gcc-2.95.3
 
> drive. I didn't do anything clever with parameters or anything; just
> "mkreisferfs /dev/sda1", mounted it and then unmounted it again. And
> the kernel oopsed on me.

Bloody hell. 
--- fs/super.c   Fri May 25 21:51:14 2001
+++ fs/super.c.new Sun May 27 00:21:53 2001
@@ -873,6 +873,7 @@
}
spin_unlock(&dcache_lock);
down_write(&sb->s_umount);
+   lock_kernel();
sb->s_root = NULL;
/* Need to clean after the sucker */
if (fs->fs_flags & FS_LITTER)
@@ -901,6 +902,7 @@
put_filesystem(fs);
sb->s_type = NULL;
unlock_super(sb);
+   unlock_kernel();
up_write(&sb->s_umount);
if (bdev) {
blkdev_put(bdev, BDEV_FS);


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

Linux-2.4.5, reiserfs, Oops!

[Chris Rankin]

Linux 2.4.5, SMP, devfs, < 1 GB memory, compiled with gcc-2.95.3


Hi,
I have just experimented with using reiserfs; since I didn't have a
hard disc partition free I used a 250MB Zip disc instead with my USB
drive. I didn't do anything clever with parameters or anything; just
"mkreisferfs /dev/sda1", mounted it and then unmounted it again. And
the kernel oopsed on me.

The kernel log says:
May 26 20:49:53 twopit kernel: SCSI subsystem driver Revision: 1.00
May 26 20:49:53 twopit kernel: scsi: host order: usb-storage-0:ide-scsi:ppa
May 26 20:49:53 twopit kernel: Initializing USB Mass Storage driver...
May 26 20:49:53 twopit kernel: usb.c: registered new driver usb-storage
May 26 20:49:53 twopit kernel: scsi0 : SCSI emulation for USB Mass Storage devices
May 26 20:49:53 twopit kernel:   Vendor: IOMEGAModel: ZIP 250   Rev: 31.G
May 26 20:49:53 twopit kernel:   Type:   Direct-Access  ANSI SCSI 
revision: 02
May 26 20:49:53 twopit kernel: Detected scsi removable disk sda at scsi0, channel 0, 
id 0, lun 0
May 26 20:49:55 twopit kernel: SCSI device sda: 489532 512-byte hdwr sectors (251 MB)
May 26 20:49:55 twopit kernel: sda: Write Protect is off
May 26 20:49:56 twopit kernel:  /dev/scsi/host0/bus0/target0/lun0: p1
May 26 20:49:56 twopit kernel: WARNING: USB Mass Storage data integrity not assured
May 26 20:49:56 twopit kernel: USB Mass Storage device found at 2
May 26 20:49:56 twopit kernel: USB Mass Storage support registered.
May 26 20:51:15 twopit kernel: reiserfs: checking transaction log (device 08:01) ...
May 26 20:52:48 twopit kernel: Using r5 hash to sort names
May 26 20:52:48 twopit kernel: ReiserFS version 3.6.25
May 26 20:58:45 twopit kernel: journal_begin called without kernel lock held
May 26 20:58:45 twopit kernel: kernel BUG at journal.c:423!
May 26 20:58:45 twopit kernel: invalid operand: 
May 26 20:58:45 twopit kernel: CPU:1
May 26 20:58:45 twopit kernel: EIP:0010:[]
May 26 20:58:45 twopit kernel: EFLAGS: 00010286
May 26 20:58:45 twopit kernel: eax: 001d   ebx: c8f21f2c   ecx: c155c000   edx: 
0001
May 26 20:58:45 twopit kernel: esi: cc4eea00   edi: c8f21f2c   ebp: 000a   esp: 
c8f21ec4
May 26 20:58:45 twopit kernel: ds: 0018   es: 0018   ss: 0018
May 26 20:58:45 twopit kernel: Process umount (pid: 1809, stackpage=c8f21000)
May 26 20:58:45 twopit kernel: Stack: d29a40cf d29a4264 01a7 d299c886 d29a5281 
c8f21f2c cc4eea00 d29a6100 
... etc.

The translated oops looks like this:

ksymoops 2.4.1 on i686 2.4.5.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5/ (default)
 -m /boot/System.map-2.4.5 (specified)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
May 26 20:58:45 twopit kernel: kernel BUG at journal.c:423!
May 26 20:58:45 twopit kernel: invalid operand: 
May 26 20:58:45 twopit kernel: CPU:1
May 26 20:58:45 twopit kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
May 26 20:58:45 twopit kernel: EFLAGS: 00010286
May 26 20:58:45 twopit kernel: eax: 001d   ebx: c8f21f2c   ecx: c155c000   edx: 
0001
May 26 20:58:45 twopit kernel: esi: cc4eea00   edi: c8f21f2c   ebp: 000a   esp: 
c8f21ec4
May 26 20:58:45 twopit kernel: ds: 0018   es: 0018   ss: 0018
May 26 20:58:45 twopit kernel: Process umount (pid: 1809, stackpage=c8f21000)
May 26 20:58:45 twopit kernel: Stack: d29a40cf d29a4264 01a7 d299c886 d29a5281 
c8f21f2c cc4eea00 d29a6100 
May 26 20:58:45 twopit kernel:cc4eea44 3b107b75 40119ca8  c9864464 
ca79ebe0 4001b000 d299caaa 
May 26 20:58:45 twopit kernel:c8f21f2c cc4eea00 000a  d298ed2c 
c8f21f2c cc4eea00 000a 
May 26 20:58:45 twopit kernel: Call Trace: [] [] [] 
[] [] [] [] 
May 26 20:58:45 twopit kernel:[] [kill_super+132/332] 
[kill_super+183/332] [] [__mntput+80/88] [path_release+40/48] 
[sys_umount+289/328] [sys_munmap+54/84] 
May 26 20:58:45 twopit kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 
56 53 31 db 

>>EIP; d299a3b0 <[reiserfs]reiserfs_check_lock_depth+38/40>   <=
Trace; d29a40cf <[reiserfs].rodata.start+456f/643f>
Trace; d29a4264 <[reiserfs].rodata.start+4704/643f>
Trace; d299c886 <[reiserfs]do_journal_begin_r+26/218>
Trace; d29a5281 <[reiserfs].rodata.start+5721/643f>
Trace; d29a6100 <[reiserfs]reiserfs_sops+0/38>
Trace; d299caaa <[reiserfs]journal_begin+16/1c>
Trace; d298ed2c <[reiserfs]reiserfs_put_super+1c/e4>
Trace; d29a6100 <[reiserfs]reiserfs_sops+0/38>
Code;  d299a3b0 <[reiserfs]reiserfs_check_lock_depth+38/40>
 <_EIP>:
Code;  d299a3b0 <[reiserfs]reiserfs_check_lock_depth+38/40>   <=
   0:   0f 0b ud2a  <=
Code;  d299a3b2 <[reiserfs]reiserfs_check_lock_depth+3a/40>
   2:   83 c4 0c  add$0xc,%esp
Code;  d299a3b5 <[reiserfs]reiserfs_check_lock_depth+3d/40>
   5:   c3

Re: 2.4.5 + ReiserFS + SMP + umount = oops

[Keith Owens]

On Sun, 27 May 2001 06:04:28 +0200 (CEST), 
Rene <[EMAIL PROTECTED]> wrote:
>hmm I feel quite certain that I am using /dev/tty - is there some way I
>can check this?

/etc/inittab, lines for mingetty, getty or agetty.

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

Re: 2.4.5 + ReiserFS + SMP + umount = oops

[Rene]

> On Sun, 27 May 2001 05:10:30 +0200 (CEST), 
> Rene <[EMAIL PROTECTED]> wrote:
> >Problem #2
> >Certain keystrokes like ctrl+c does not work when logged in from the
> >console
> 
> Are you using /dev/console or /dev/tty for the console session?
> /dev/console does not support control-C, use /dev/tty for a VGA
> session, /dev/ttyS for a serial line.

hmm I feel quite certain that I am using /dev/tty - is there some way I
can check this? The setup on this machine wrt login shouldn't be any
different from what I use on my other boxes, and there I have no problem
with stuff like ctrl+c 

regards
/rene

-- 
Rene Mikkelsen, 
Tlf: +45 40501985
---
http://www.eslug.dk - the choice of a GNU generation
http://dustpuppy.dk - UF på dansk
---

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

Re: 2.4.5 + ReiserFS + SMP + umount = oops

[Keith Owens]

On Sun, 27 May 2001 05:10:30 +0200 (CEST), 
Rene <[EMAIL PROTECTED]> wrote:
>Problem #2
>Certain keystrokes like ctrl+c does not work when logged in from the
>console

Are you using /dev/console or /dev/tty for the console session?
/dev/console does not support control-C, use /dev/tty for a VGA
session, /dev/ttyS for a serial line.

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

Re: [patch] severe softirq handling performance bug, fix, 2.4.5

[Albert D. Cahalan]

David S. Miller
> Ingo Molnar writes:

>> (unlike bottom halves, soft-IRQs do not preempt kernel code.)
> ...
>
> Since when do we have this rule? :-)
...
> You should check Softirqs on return from every single IRQ.
> In do_softirq() it will make sure that we won't run softirqs
> while already doing so or being already nested in a hard-IRQ.
> 
> Every port works this way, I don't know where you got this "soft-IRQs
> cannot run when returning to kernel code" rule, it simply doesn't
> exist.

After you two argue this out, please toss a note in Documentation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scsi_ioctl.c

[John Martin]

this seems to be a straight forward case of memory not being freed on an
error path.  so i just added in one line to each of the if statements that
could fail.
   -john martin


--- drivers/scsi/scsi_ioctl.c.orig  Fri Apr 27 13:59:19 2001
+++ drivers/scsi/scsi_ioctl.c   Sat May 26 20:13:03 2001
@@ -317,10 +317,16 @@

sb_len = (sb_len > OMAX_SB_LEN) ? OMAX_SB_LEN : sb_len;
if (copy_to_user(cmd_in, SRpnt->sr_sense_buffer, sb_len))
+   {
+   scsi_release_request(SRpnt);
return -EFAULT;
+   }
} else
if (copy_to_user(cmd_in, buf, outlen))
+   {
+   scsi_release_request(SRpnt);
return -EFAULT;
+   }

result = SRpnt->sr_result;


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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

Dear Greg,

"Greg Banks" <[EMAIL PROTECTED]> wrote :
>
>   Ok, I've found the description of this on handhelds.org, and
> it appears to be a derivative of xscribble, which I have tried.
> Unlike xscribble it does fullscreen mode, which is good, but
> it's still single-character and requires the user to learn
> how to write all over again.  In other words, like everything
> else available on Linux (and even MS's Jot) it's *crap* compared to
>

i even face problem in xscribble too , i think it donot likes my handwriting
;)

> http://www.paragraph.com/products/internetink/calligrapher/features.html
>
>   I would give my eye teeth for a Linux version of Calligrapher.
>

Are you having sources of Calligrapher ?

If no , i know that you can write better version then Calligrapher in Linux
:)

Happy Hacking !!

Jaswinder.
--
These are my opinions not 3Di.


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

2.4.5 + ReiserFS + SMP + umount = oops

[Rene]

Hi list :)

I just upgraded an SMP-machine from 2.4.4 to 2.4.5.
It's a 
2xPII@300MHz 
Asus P2B-D motherboard 
128mb RAM.
unknown PCI gfx-card
Promise ATA-100 IDE-controller

Problem #1
I have 2 disk on the ATA-controller (30 and 45GB - both IBM) running a
Reiser-partition each.
I can do reiserfsck and debugreiserfs just fine and get an 'ok' back from
both ('ok' from fsck and 'VALID' from debug..). I can mount the
reiser-partitions, but - when I umount the first partition I get:
# umount /stuff (/dev/hde1)
journal_begin called without kernel lock held
kernel BUG at journal.c:423!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 001d   ebx: c1ea5f28   ecx: 0001   edx: 0001
esi: c6104e00   edi: 3b105b44   ebp: 000a   esp: c1ea5ec0
ds: 0018   es: 0018   ss: 0018
Process umount (pid: 9217, stackpage=c1ea5000)
Stack: c022210c c0a4 01a7 c018395f c02232c1 c1ea5f28 c6104e00
c0250220
   c6104e34 3b105b44  c5eada60 c1ea4000 c6104e00 c1ea4000
c0183b6a
   c1ea5f28 c6104e00 000a  c0174728 c1ea5f28 c6104e00
000a
Call Trace: [] [] [] []
[] [] []
   [] [] [] []

Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 56 be 00 f3


I took a look at fs/reiserfs/journal.c and compared (diff) it to the same
file from 2.4.4 and found the line where the message is generated (line
423). The problem is that a diff on those two journal.c's revealed no
difference whatsoever which leads me to the conclusion that this bug might
not have so much to do with ReiserFS afterall.

These things worked fine in 2.4.4 btw.
back in 2.4.2 I followed the Changes and did an upgrade to binutils,
e2fsprogs and util-linux, and these upgrades should still be ok.


Problem #2
Certain keystrokes like ctrl+c does not work when logged in from the
console - only when logged in throuhg ssh. This is really not that
important as the machine only acts as a monitor-less fileserver.



If You need additional information - please let me know.

regards
  /Rene 



-- 
Rene Mikkelsen, 
Tlf: +45 40501985
---
http://www.eslug.dk - the choice of a GNU generation
http://dustpuppy.dk - UF på dansk
---

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

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

Alan Cox wrote:
> 
> > Visual Studio, or the feature where you can have a decent handwriting
> > recognition system, or the feature where you can run Pocket {Internet
> > Explorer,Word} then the answer is none of them.
> 
> Handwriting recognition with fscrib works very well indeed.

  Ok, I've found the description of this on handhelds.org, and
it appears to be a derivative of xscribble, which I have tried.
Unlike xscribble it does fullscreen mode, which is good, but
it's still single-character and requires the user to learn
how to write all over again.  In other words, like everything
else available on Linux (and even MS's Jot) it's *crap* compared to

http://www.paragraph.com/products/internetink/calligrapher/features.html

  I would give my eye teeth for a Linux version of Calligrapher.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.  - jd, slashdot, 11Feb2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please help me fill in the blanks.

[Jeff Garzik]

Jonathan Morton wrote:
> 
> >> * Live Upgrade
> >
> >LOBOS will let one Linux kernel boot another, but that requires a boot
> >step, so it is not a live upgrade.  so, no, afaik
> 
> If you build nearly everything (except, obviously what you need to boot) as
> modules, you can unload modules, build new versions, and reload them.  So,
> you could say that partial support for "live upgrades" is included.

I stand corrected, though I clearly know better:
Modules are unloaded/reloaded all the time during my driver development
:)

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please help me fill in the blanks.

[Jonathan Morton]

>> * Live Upgrade
>
>LOBOS will let one Linux kernel boot another, but that requires a boot
>step, so it is not a live upgrade.  so, no, afaik

If you build nearly everything (except, obviously what you need to boot) as
modules, you can unload modules, build new versions, and reload them.  So,
you could say that partial support for "live upgrades" is included.

It works, too - I unloaded my OV511 driver a few weeks ago, copied the
source for the new one in, built it, and re-inserted it.  Same goes for the
DRM module a couple of weeks before that.  Now, the machine in question
gets rebooted fairly often in any case, but those were things I *didn't*
have to reboot for.

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

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

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

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


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

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 09:02:21PM -0400, Jeff Garzik wrote:
> Andrea Arcangeli wrote:
> > diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
> > --- alpha/arch/alpha/kernel/sys_dp264.c Sun Apr  1 01:17:07 2001
> > +++ alpha-1/arch/alpha/kernel/sys_dp264.c   Wed May 23 02:43:49 2001
> > @@ -16,15 +16,18 @@
> >  #include 
> >  #include 
> > 
> > +#define __EXTERN_INLINE inline
> > +#include 
> > +#include 
> > +#undef  __EXTERN_INLINE
> > +
> 
> Why is "__EXTERN_INLINE" defined as "inline" not "extern inline"?

because it must be implemented somewhere for the alpha_mv pointer to
functions and for some reason they are not implemented by
core_tsunami.c in my tree (but they are in mainline and that's right).

> I simply added "extern" and things started working (as noted in my
> previous message in this thread)..

defining it as `extern inline' is completly equivalent to backing out
the patch I posted, see core_tsunami.h:

#ifndef __EXTERN_INLINE
#define __EXTERN_INLINE extern inline
#define __IO_EXTERN_INLINE
#endif

Of course your patch works like a charm too. A cleaner fix is to backout my
patch because core_tsunami.h will define it to `extern inline'
atuomatically.

Tomorrow I'll go through the log generated by the script that did the
binary search for me while I was out to find out what patch in my tree
caused me to write the posted patch to get all compilations right.

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

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

Jaswinder Singh wrote:
> 
> "Greg Banks" <[EMAIL PROTECTED]> wrote:
> >
> >   I have some code which could become the basis for such a thing.
> > It's a touch panel driver for the DMIDA but it also has a device-
> > independent layer which does supersampling, scaling, provides
> > raw and cooked Linux Input interfaces, and a /proc interface to
> > allow the calibration app to control the scaling.
> >
> >   Unfortunately I can't release it yet for (ahem) legal reasons.
> >
> 
> nice job , from where you get the related specs ?

  From the manufacturer.  We had the fullest possible co-operation
including all technical specs, several sample machines, source to
the WinCE drivers for the hardware, and engineers (including the lead
hardware designer, a *very* cluey gentleman) on standby to answer
questions.

  It makes an amazing difference to have all the nasty little
hardware quirks and known workarounds for them laid bare before you.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.  - jd, slashdot, 11Feb2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new aic7xxx oopses with AHA2940

[Jeff Garzik]

Marc Schiffbauer wrote:
> >>EIP; e0a7b3a7 <[aic7xxx]ahc_match_scb+17/c0>   <=
> Trace; e0a7b79d <[aic7xxx]ahc_search_qinfifo+14d/6b0>
> Trace; e0a7c226 <[aic7xxx]ahc_abort_scbs+66/300>
> Trace; c0234ce3 <__delay+13/30>
> Trace; e0a7c81d <[aic7xxx]ahc_reset_channel+25d/370>
> Trace; e0a70990 <[aic7xxx]ahc_linux_isr+0/270>
> Trace; e0a812a9 <[aic7xxx].rodata.start+c89/157c>
> Trace; e0a7dca7 <[aic7xxx]ahc_pci_config+497/4b0>
> Trace; c023 
> Trace; e0a6f93e <[aic7xxx]ahc_linux_initialize_scsi_bus+3e/1d0>
> Trace; e0a78855 <[aic7xxx]ahc_set_name+15/30>

I'm curious what happens with the attached patch?

It adds some debugging checks which will halt your kernel with "BUG! at
:line"...

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |

Index: linux_2_4/drivers/scsi/aic7xxx/aic7xxx.c
diff -u linux_2_4/drivers/scsi/aic7xxx/aic7xxx.c:1.1.1.26 
linux_2_4/drivers/scsi/aic7xxx/aic7xxx.c:1.1.1.26.36.1
--- linux_2_4/drivers/scsi/aic7xxx/aic7xxx.c:1.1.1.26   Tue May  8 21:50:17 2001
+++ linux_2_4/drivers/scsi/aic7xxx/aic7xxx.cSat May 26 19:35:04 2001
@@ -4837,6 +4837,10 @@
 #if AHC_TARGET_MODE
int group;
 
+   if (!scb->io_ctx)
+   BUG();
+   if (!scb->hscb)
+   BUG();
group = XPT_FC_GROUP(scb->io_ctx->ccb_h.func_code);
if (role == ROLE_INITIATOR) {
match = (group != XPT_FC_GROUP_TMODE)
@@ -4848,6 +4852,8 @@
   || (tag == SCB_LIST_NULL));
}
 #else /* !AHC_TARGET_MODE */
+   if (!scb->hscb)
+   BUG();
match = ((tag == scb->hscb->tag) || (tag == SCB_LIST_NULL));
 #endif /* AHC_TARGET_MODE */
}

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

[EMAIL PROTECTED] wrote:
> 
> Greg Banks <[EMAIL PROTECTED]>:
> >   Having said that, I agree that the help text entries for the SH
> > port are in general of less than stellar quality, for various
> > (mostly good) reasons.  I'm hoping ESR will give us some editorial
> > feedback which will provide a good excuse to fix them.
> 
> Since you asked...
> 
> # Choice: superhsys
> Generic
> CONFIG_SH_GENERIC
>   Select Generic if configuring for a generic SuperH system.

  The "generic" option compiles in *all* the possible hardware
support and relies on the sh_mv= kernel commandline option to choose
at runtime which routines to use.  "MV" stands for "machine vector";
each of the machines below is described by a machine vector and
the "generic" option chooses to compile them all in.

>   Select SolutionEngine if configuring for a Hitachi SH7709
>   or SH7750 evalutation board.
> 
>   Select Overdrive if configuring for a ST407750 Overdrive board.
>   More information at
>   
> 
>   Select HP620 if configuring for a HP Jornada HP620.
>   More information at
>   .
> 
>   Select HP680 if configuring for a HP Jornada HP680.
>   More information at
>   .
> 
>   Select HP690 if configuring for a HP Jornada HP690.
>   More information at .

  You won't get any information about Linux on Jornadas at HP.

> 
>   Select CqREEK if configuring for a CqREEK SH7708 or SH7750.
>   More information at
>   .
> 
>   Select DMIDA if configuring for a DataMyte 4000 Industrial
>   Digital Assistant. More information at .
> 
>   Select EC3104 if configuring for a system with an Eclipse
>   International EC3104 chip, e.g. the Harris AD2000.
> 
>   Select Dreamcast if configuring for a SEGA Dreamcast.
>   More information at
>   .

  The Dreamcast project is at 
They usually have slightly newer DC support than
linuxsh.sourceforge.net,
to which they sync regularly.

> 
>   Select BareCPU if you know what this means, and it applies
>   to your system.
> 
> Can you be any more explicit about the BareCPU option?

  "Bare CPU" aka "unknown" means an SH-based system which is not
one of the specific ones mentioned above, which means you need to
enter all sorts of stuff like CONFIG_MEMORY_START because the config
system doesn't already know what it is.  You get a machine vector
without any platform-specific code in it, so things like the RTC may
not work.

  This option is for the early stages of porting to a new machine.

  Basically the machine choices are laid out like this:

  generic = all of the known machines
  machine foo
  machine bar
  unknown = none of the known machines

> Physical memory start address
> CONFIG_MEMORY_START
>   The physical memory start address will be automatically
>   set to 0800, unless you selected one of the following
>   processor types: SolutionEngine, Overdrive, HP620, HP680, HP690,
>   in which case the start address will be set to 0c00.
> 
>   Do not change this address unless you know what you are doing.
> 
> Why might someone want to change this address?

  Only when porting to a new machine which is not already
known by the config system.  Changing it from the known correct
value on any of the known systems will only lead to disaster.

> Early printk support
> CONFIG_SH_EARLY_PRINTK
>   Say Y here to redirect kernel printks from the boot console to an
>   SCI serial console as soon as one is available.
> 
> This was my guess.  Is it correct?

  Nearly.

-  the serial console can be either SCI or SCIF (the latter has a FIFO)

-  the redirect happens *before* the serial console is available, and
   stops when the serial console is initialised

-  printks go to a BIOS conforming to the LinuxSH standard (i.e.
   the SH-IPL bootloader)

  Try:

Say Y here to redirect kernel messages to the serial port
used by the SH-IPL bootloader, starting very early in the boot
process and ending when the kernel's serial console is initialised.
This option is only useful porting the kernel to a new machine,
when the kernel may crash or hang before the serial console is
initialised.

> SuperH SCI (serial) support
> CONFIG_SH_SCI
>   Selecting this option will allow the Linux kernel to transfer
>   data over SCI (Serial Communication Interface) and/or SCIF
>   which are built into the Hitachi SuperH processor.
> 
>   If in doubt, press "y".
> 
> What data?  Is this just an on-board RS232C controller?

  Sorry, the description is unclear.  It's an on-CPU RS232 controller,
usually used as the console.  The option provides 1 to 3 (depending
on the CPU model) standard Linux tty devices, /dev/ttySC[012].

> 
> Use LinuxSH standard BIOS
> CONFIG_SH_STANDARD_BIOS Say Y here if your target has the gdb-sh-stub
>   pac

Re: Please help me fill in the blanks.

[Jeff Garzik]

Cesar Da Silva wrote:
> The features that I'm wondering about are:
> * Dynamic Processor Resilience

is this fault tolerance?  I think if a CPU croaks, you are dead.

There are patches for hot swap cpu support, but I haven't seen any CPU
fault tolerance patches that can handle a dead processor

> * Dynamic Memory Resilience

RAM fault tolerance?  There was a patch a long time ago which detected
bad ram, and would mark those memory clusters as unuseable at boot. 
However that is clearly not dynamic.

If your memory croaks, your kernel will experience random corruptions

> * Dynamic Page Sizing

no

> * Live Upgrade

LOBOS will let one Linux kernel boot another, but that requires a boot
step, so it is not a live upgrade.  so, no, afaik

> * Alternative I/O Pathing

be less vague

> * HSM

patches exist, I believe

> * TCP selective acknowledgement (SACK)

yes

> * Service Location Protocol (SLP)

don't know

> * ATM IP switching

yes, I believe

> * SOCKS 5 support

yes, via userspace apps/libs

> * Multilink PPP

yes

> * TCP/IP Gratuitous ARP (RFC 2002)

not sure

> * Path MTU Discovery (RFC 1191)

yes

> * Path MTU Discovery over UDP

not sure, but I think so

> * IP Multipath Routing

yes

> The questions I have about the features above are:
> * Are any of the above features implemented in the
> kernel? If yes, where can I read (url-link  to the
> article, paper... please) about it?

http://google.com/

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] zr36120.c

[John Martin]

I found this error using xgcc with metal as an error checker.  It seems to
be a simple case of not freeing allocatd memory on an error path.
-john martin


--- drivers/media/video/zr36120.c.orig  Fri Mar  2 11:12:10 2001
+++ drivers/media/video/zr36120.c   Sat May 19 15:31:03 2001
@@ -1195,7 +1195,10 @@
if (vcp==NULL)
return -ENOMEM;
if (vw.clipcount && copy_from_user(vcp,vw.clips,sizeof(struct 
video_clip)*vw.clipcount))
+   {
+   vfree(vcp);
return -EFAULT;
+   }

on = ztv->running;
if (on)

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

Re: new aic7xxx oopses with AHA2940

[Marc Schiffbauer]

* Keith Owens schrieb am 27.05.01 um 03:07 Uhr:
> Because you are using a broken version of klogd that stuffs up oops
> traces.  Change klogd to run as klogd -x (probably in
> /etc/rc.d/init.d/syslog) so it keeps its broken fingers off the oops.
> 

done

> Since you are failing during modprobe, creating /var/log/ksymoops is a
> good idea, man insmod, see KSYMOOPS ASSISTANCE.  Reproduce the
> problem to get a clean oops trace then run it through ksymoops, using
> the saved module data in /var/log/ksymoops.
> 

OK. Now I cut out the Oops out of my /var/log/messages, then did

cat aic7xxx.oops | ksymoops -k /var/log/ksymoops/20010527040453.ksyms -l
/var/log/ksymoops/20010527040453.modules > trace1

and another run with default options:

cat aic7xxx.oops | ksymoops > trace2

trace1:
###

ksymoops 0.7c on i686 2.4.5.  Options used
 -V (default)
 -k 20010527040453.ksyms (specified)
 -l 20010527040453.modules (specified)
 -o /lib/modules/2.4.5/ (default)
 -m /usr/src/linux/System.map (default)

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
May 27 04:06:08 homer kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 
May 27 04:06:08 homer kernel: e0a7b3a7
May 27 04:06:08 homer kernel: *pde = 
May 27 04:06:08 homer kernel: Oops: 
May 27 04:06:08 homer kernel: CPU:0
May 27 04:06:08 homer kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
May 27 04:06:08 homer kernel: EFLAGS: 00010096
May 27 04:06:08 homer kernel: eax: 0041   ebx:    ecx: dd5bdc00   edx: 

May 27 04:06:08 homer kernel: esi:    edi: 00ff   ebp: dd5bdc00   esp: 
dd065cbc
May 27 04:06:08 homer kernel: ds: 0018   es: 0018   ss: 0018
May 27 04:06:08 homer kernel: Process modprobe (pid: 480, stackpage=dd065000)
May 27 04:06:08 homer kernel: Stack:   00ff dd5bdc00 41000357 
e0a7b79d dd5bdc00  
May 27 04:06:08 homer kernel: 0041  00ff  
0041  dd5bdc00 
May 27 04:06:08 homer kernel:dd5bdc00 0001 0001 0001 0001 
0001  0001 
May 27 04:06:08 homer kernel: Call Trace: [] [] [] 
[] [] [] [] 
May 27 04:06:08 homer kernel:[] [] [] 
[] [] [] [] [] 
May 27 04:06:08 homer kernel:[] [] [] 
[] [] [] [] [] 
May 27 04:06:08 homer kernel:[] [] [] 
[] [] [] [] [] 
May 27 04:06:08 homer kernel:[] [] [] 
[] [] [] [] 
May 27 04:06:08 homer kernel: Code: 8b 02 8b 7c 24 20 8b 6c 24 28 0f b6 40 19 f6 81 f0 
00 00 00 

>>EIP; e0a7b3a7<=
Trace; e0a7b79d 
Trace; e0a7c226 
Trace; c0234ce3 <__delay+13/30>
Trace; e0a7c81d 
Trace; e0a70990 <__module_parm_multicast_filter_limit+4ab4/>
Trace; e0a812a9 
Trace; e0a7dca7 
Trace; c023 
Trace; e0a6f93e <__module_parm_multicast_filter_limit+3a62/>
Trace; e0a78855 
Trace; e0a6f891 <__module_parm_multicast_filter_limit+39b5/>
Trace; e0a6f8b0 <__module_parm_multicast_filter_limit+39d4/>
Trace; e0a85280 
Trace; c01d6fdc 
Trace; e0a85300 
Trace; e0a85360 
Trace; c01d7054 
Trace; e0a85360 
Trace; e0a85280 
Trace; e0a7287a <__module_parm_multicast_filter_limit+699e/>
Trace; e0a6f74e <__module_parm_multicast_filter_limit+3872/>
Trace; e0a85280 
Trace; e0a6f068 <__module_parm_multicast_filter_limit+318c/>
Trace; c01bf7d9 
Trace; e0a85280 
Trace; e0a85280 
Trace; e0a6f068 <__module_parm_multicast_filter_limit+318c/>
Trace; e0a6f000 <__module_parm_multicast_filter_limit+3124/>
Trace; e0a6f068 <__module_parm_multicast_filter_limit+318c/>
Trace; c01c003d 
Trace; e0a85280 
Trace; e0a6f000 <__module_parm_multicast_filter_limit+3124/>
Trace; e0a726d6 <__module_parm_multicast_filter_limit+67fa/>
Trace; e0a85280 
Trace; c011541d 
Trace; e0a68000 <[emu10k1].data.end+23f9/2459>
Trace; e0a6f060 <__module_parm_multicast_filter_limit+3184/>
Trace; c0106b9b 
Code;  e0a7b3a7 
 <_EIP>:
Code;  e0a7b3a7<=
   0:   8b 02 mov(%edx),%eax   <=
Code;  e0a7b3a9 
   2:   8b 7c 24 20   mov0x20(%esp,1),%edi
Code;  e0a7b3ad 
   6:   8b 6c 24 28   mov0x28(%esp,1),%ebp
Code;  e0a7b3b1 
   a:   0f b6 40 19   movzbl 0x19(%eax),%eax
Code;  e0a7b3b5 
   e:   f6 81 f0 00 00 00 00  testb  $0x0,0xf0(%ecx)


1 warning issued.  Results may not be reliable.

#

trace2:
#

ksymoops 0.7c on i686 2.4.5.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol reso

Please help me fill in the blanks.

[Cesar Da Silva]

Hi again.
I am doing a thesis about comparing the Linux kernel
against HP-UX, AIX, Tru64 UNIX, and Solaris (as you
probably alredy know).
I'm stuck now (and the thesis has to bee ready until
tomorow) with some few features that the other
operating system have, and I can't find any
information about it, if those features are
implemented in Linux or not.

The features that I'm wondering about are:
* Dynamic Processor Resilience
* Dynamic Memory Resilience
* Dynamic Page Sizing
* Live Upgrade
* Alternative I/O Pathing
* HSM
* TCP selective acknowledgement (SACK)
* Service Location Protocol (SLP)
* ATM IP switching
* SOCKS 5 support
* Multilink PPP
* TCP/IP Gratuitous ARP (RFC 2002)
* Path MTU Discovery (RFC 1191)
* Path MTU Discovery over UDP
* IP Multipath Routing

The questions I have about the features above are:
* Are any of the above features implemented in the
kernel? If yes, where can I read (url-link  to the
article, paper... please) about it?
* Is any of the features implemented through a program
/daemon? If yes, which program (link to program)?

Here is the link to my thesis if anyone hasn't got my
previous message:

http://www.student.hig.se/~na98csa/{
,Linux.tex,xjobb.ps}

Thanks in advance,
Cesar da Silva

_
Do You Yahoo!?
[EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

"Greg Banks" <[EMAIL PROTECTED]> wrote:
> 
>   I have some code which could become the basis for such a thing.
> It's a touch panel driver for the DMIDA but it also has a device-
> independent layer which does supersampling, scaling, provides
> raw and cooked Linux Input interfaces, and a /proc interface to
> allow the calibration app to control the scaling.
> 
>   Unfortunately I can't release it yet for (ahem) legal reasons.
> 

nice job , from where you get the related specs ?

Best Regards,

Jaswinder.
-- 
These are my opinions not 3Di.


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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

"Greg Banks" <[EMAIL PROTECTED]> wrote:
> > 
> > Can we use "HP Jornada 600 series" inspite of "WindowsCE machine" ?
> 
>   Sorry, I'm not sure what you mean here.
>

forget about it ;)
 
> 
>   But Compaq is playing nice in a way HP (or at least the division
> that makes Jornadas) isn't.  Furthermore the ARM port is older.
> 

Thats why Compaq's iPAQ are in much demand :)

Best Regards,

Jaswinder.
-- 
These are my opinions not 3Di.


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

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

Jaswinder Singh wrote:
> 
> "Alan Cox" <[EMAIL PROTECTED]> wrote :
> 
> >
> > Handwriting recognition with fscrib works very well indeed.
> >
> 
> But not in Linux SH , there is so Touch Panel Interface in Linux SH yet :(

  I have some code which could become the basis for such a thing.
It's a touch panel driver for the DMIDA but it also has a device-
independent layer which does supersampling, scaling, provides
raw and cooked Linux Input interfaces, and a /proc interface to
allow the calibration app to control the scaling.

  Unfortunately I can't release it yet for (ahem) legal reasons.

  Anyway the limitation with handwriting recognition is not getting
the data out of the hardware but recognising the sample stream as
characters.  This is *difficult*.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.  - jd, slashdot, 11Feb2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

[EMAIL PROTECTED] wrote :

>   Select HP620 if configuring for a HP Jornada HP620.
>   More information at
>   .
> 
>   Select HP680 if configuring for a HP Jornada HP680.
>   More information at
>   .
> 
>   Select HP690 if configuring for a HP Jornada HP690.
>   More information at .
> 

Have you asked from HP , are they ready to support Linux ?

Thank you ,

Best Regards,

Jaswinder.
-- 
These are my opinions not 3Di.


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

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

Alan Cox wrote:
> 
> > [...] or the feature where you can have a decent handwriting
> > recognition system,[...]
> 
> Handwriting recognition with fscrib works very well indeed.

  I haven't tried that one.  Does it do cursive writing,
with dictionary assistance, on the X root window?

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.  - jd, slashdot, 11Feb2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5aa1

[David S. Miller]

Andrea Arcangeli writes:
 > 00_eepro100-64bit-1
 > 
 >  Fixes a 64bit bug that was generating false positives and memory
 >  corruption.
 > 
 >  (recommended)

Good spotting, I've put this into my tree ;-)

 > 00_eepro100-alpha-1
 > 
 >  Possibly fix the eepro100 transmitter hang on alpha by doing atomic PIO
 >  updates to avoid the clear_suspend to be lost.
 >  
 >  (recommended)

The correct fix is to create {set,clear,change}_bit{8,16,32}()
routines architectures may implement.  The comment there in eepro100.c
indicates the those defines are simply wrong for anything other than
x86, not just Alpha.

 > 00_ipv6-null-oops-1
 > 
 >  Fixes null pointer oops.
 > 
 >  (recommended)

Please delete this, a proper fix is in 2.4.5, and in fact your
added NULL test will never pass now :-)

 > 10_no-virtual-1
 > 
 >  Avoids wasting tons of memory if highmem is not selected (like
 >  in all the 64bit ports).
 > 
 >  (nice to have)

I experimented with computing the address every time on sparc64 and
the performance actually went down slightly, it turned out it's
quicker to load from an in-cache page struct member than compute the
offset each time.

It's probably not an issue on ix86, but who knows.

I have no strong opinions about the other patches ;-)

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

Re: IDE Performance lack !

[Marc Schiffbauer]

* Guido Stepken schrieb am 26.05.01 um 22:19 Uhr:
> Hi !
> 
> RedHat 7.1 - IDE IBM 41.1 GIG
> Update to 2.4.5 -> noticed, that hdparm -t /dev/hda went down from 10 
> MByte/sec to 1.9 MByte/sec
> Any special Options, beside ide-scsi driver activated ..
> 
> Anybody noticed the same problem ? Any clues ?
> 
> tnx in advance ...

Hi Guido,

This is a 20.1 GB Seagate Barracuda (with hdparm -d1)


homer:~ # hdparm -t /dev/hda
 
/dev/hda:
 Timing buffered disk reads:  64 MB in  2.74 seconds = 23.36 MB/sec
homer:~ #


Did you turn on dma-mode?

-Marc

-- 
+-O . . . o . . . O . . . o . . . O . . .  ___  . . . O . . . o .-+
| Ein neuer Service von Links2Linux.de:   /  o\   RPMs for SuSE   |
| --> PackMan! <-- naeheres unter|   __|   and  others|
| http://packman.links2linux.de/ . . . O  \__\  . . . O . . . O . |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

Dear Greg,

>
>   Modems are tricky, because they're frequently WinModems which
> have a whole lot of well-known issues.  Other features depend on
> the speed at which they can be reverse engineered, as most
> WinCE manufacturers don't co-operate.  I'd be surprised if any
> WindowsCE machine's hardware was fully supported by LinuxSH yet,
> but I don't have a full list anywhere (sorry).  I'd guess the HP
> Jornada 600 series are probably best supported.
>

yes , this is what i am looking for :)

Can we use "HP Jornada 600 series" inspite of "WindowsCE machine" ?

BTW, in Jornada 600 series only Keyboard and LCD is working and some CPU
related stuff  which we can found in Hitachi Manuals , thats it .

But linux-arm is supporting full iPAQ hardware .

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

"Alan Cox" <[EMAIL PROTECTED]> wrote :


> 
> Handwriting recognition with fscrib works very well indeed.
> 

But not in Linux SH , there is so Touch Panel Interface in Linux SH yet :(

Thank you,

Best Regards,

Jaswinder.
-- 
These are my opinions not 3Di.


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

PROBLEM: "kernel BUG at inode.c:486!"

[josn]

Indexing as suggested in 'REPORTING-BUGS'.

[1.] One line summary
I get "kernel BUG at inode.c:486" when using NFS.

[2.] Full description
I can reproducibly generate a problem when I try to build a kernel,
located on a NFS drive. The kernel build failes when compiling the first
source; the kernel logs 'kernel BUG at inode.c:486!'. The message is
apparently generated because inode->i_data.nrpages is unexpectedly
non-zero in linux/fs/inode.c The problem has occurred on kernel 2.4.5,
and also on kernel 2.4.5-pre4. I didnt get it on kernel 2.4.5-pre3.
Almost any other things on the same NFS drive seem to work fine.

[3.] keywords
kernel bug, inode, nfs

[4.] Kernel versions
system getting the kernel problem:
"Linux version 2.4.5 (josn@voyager) (gcc version 2.95.2 19991024 (release)) #1 Sun May 
27 00:50:28 CEST 2001"
system used as fileserver:
"Linux version 2.4.5-pre3 (josn@voyager) (gcc version 2.95.2 19991024 (release))
#6 Thu May 17 00:42:13 CEST 2001"

[5.] Kernel logging involved
May 27 01:34:43 voyager kernel: kernel BUG at inode.c:486!
May 27 01:34:43 voyager kernel: invalid operand: 
May 27 01:34:43 voyager kernel: CPU:0
May 27 01:34:43 voyager kernel: EIP:0010:[clear_inode+51/280]
May 27 01:34:43 voyager kernel: EFLAGS: 00010286
May 27 01:34:43 voyager kernel: eax: 001b   ebx: c4badc00   ecx: c6a96000   
edx: c7f70ea0
May 27 01:34:43 voyager kernel: esi: c90bb1e0   edi: c4be7160   ebp: c6a97fa4   
esp: c6a97eec
May 27 01:34:43 voyager kernel: ds: 0018   es: 0018   ss: 0018
May 27 01:34:43 voyager kernel: Process make (pid: 2198, stackpage=c6a97000)
May 27 01:34:43 voyager kernel: Stack: c01e0955 c01e09b4 01e6 c4badc00 
c013f677 c4badc00 c4bac340 c4badc00
May 27 01:34:43 voyager kernel:c90afb1a c4badc00 c013d256 c4bac340 
c4badc00 c4bac340  c0135d0c
May 27 01:34:43 voyager kernel:c4bac340 c6a97f68 c013642a c4be7160 
c6a97f68  c7b29000 
May 27 01:34:43 voyager kernel: Call Trace: [iput+311/332] 
[usbcore:usb_devfs_handle_Re9c5f87f+610906/44386086] [dput+214/324] 
[cached_lookup+72/84] [path_walk+1334/1932] [getname+90/152] [__user_walk+60/88]
May 27 01:34:43 voyager kernel:[sys_stat64+22/120] [sys_close+67/84] 
[system_call+51/56]
May 27 01:34:43 voyager kernel:
May 27 01:34:43 voyager kernel: Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 19 68 
e8 01 00 00 68
Since I dont think the kernel messages after the 'kernel BUG' message is
really is really interesting anymore, I did nothing to decode them. On
request, I will.

[6.] example of what I did

# logged in as non-root
# fstab contains: 'ds9:/ /router nfs defaults,noauto,user,exec'
mount /router
cd /router/usr/src
mkdir linux-2.4.5
cd linux-2.4.5
tar xIf /archive/linux/kernel/linux-2.4.5.tar.bz2
cd linux; cp -al . ../voyager
cd ../voyager
cp ../../linux-2.4.5-pre4/voyager/.config .
rm /usr/src/linux
ln -s /router/usr/src/linux-2.4.5/voyager /usr/src/linux
make dep
make bzImage # 'kernel BUG' IS LOGGED; gcc gets sig11 on first compile

[7.1]

Output of ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux voyager 2.4.5 #1 Sun May 27 00:50:28 CEST 2001 i686 unknown

Gnu C  2.95.2
Gnu make   3.79.1
binutils   2.10.0.33
util-linux 2.10q
mount  2.10q
modutils   2.4.2
e2fsprogs  1.19
pcmcia-cs  3.1.26
PPP2.3.11
Linux C Libraryx1 root root  1382179 Jan 19 07:14 
/lib/libc.so.6
Dynamic linker (ldd)   2.2
Procps 2.0.7
Net-tools  1.57
Kbd1.02
Sh-utils   2.0
Modules Loaded audio soundcore nfs lockd sunrpc af_packet xirc2ps_cs 
ds i82365 pcmcia_core ipv6 mousedev hid input usb-uhci apm nls_iso8859-15 nls_cp850 
vfat fat usbcore unix

[7.2] Output of /proc/cpuinfo

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

[7.3] Module info

audio  35584   0 (autoclean) (unused)
soundcore   3856   0 (au

Re: [kbuild-devel] Configure.help entries wanted

[Alan Cox]

> Visual Studio, or the feature where you can have a decent handwriting
> recognition system, or the feature where you can run Pocket {Internet
> Explorer,Word} then the answer is none of them.

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

Re: FWD: [RHSA-2000:108-02] Updated modutils fixing local root

[Keith Owens]

On Sat, 27 May 2001 21:11:25, 
[EMAIL PROTECTED] (Joseph S Price) wrote:
>   Red Hat, Inc. Security Advisory
>Synopsis:  Updated modutils fixing local root security bug available
>Advisory ID:   RHSA-2000:108-02
>Issue date:2000-11-16
>Updated on:2000-11-16
>Product:   Red Hat Linux
>Keywords:  modutils root exploit security

What is the point of sending a 6 month old security report to
linux-kernel?  That exploit was fixed a couple of days after it was
reported.

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

Re: [kbuild-devel] Configure.help entries wanted

[Greg Banks]

Jaswinder Singh wrote:
> 
> "Greg Banks" <[EMAIL PROTECTED]> wrote:

  (I'm posting from a different address because kernel.org had
some difficulties with pocketpenguins.com)

> > Jaswinder Singh wrote:
> > >
> > > >
> > > BTW, how many WindowsCE machines are fully (means all the features as
> > > provided by Windows CE) supported by LinuxSH and how many machines are
> > > partially(only few features) supported by LinuxSH ?
> >
> >   I don't understand, what features do you mean?
> >
> 
> By features , i mean , that we can use all the hardware of WindowsCE machine
> , like Touch panel , modem , IrDA, Sound , etc , etc .

  Modems are tricky, because they're frequently WinModems which
have a whole lot of well-known issues.  Other features depend on
the speed at which they can be reverse engineered, as most
WinCE manufacturers don't co-operate.  I'd be surprised if any
WindowsCE machine's hardware was fully supported by LinuxSH yet,
but I don't have a full list anywhere (sorry).  I'd guess the HP
Jornada 600 series are probably best supported.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.  - jd, slashdot, 11Feb2000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

FWD: [RHSA-2000:108-02] Updated modutils fixing local root

[Joseph S Price]

Warning
Could not process message with given Content-Type: 
multipart/mixed;boundary="=_0121112227==_"

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

"Greg Banks" <[EMAIL PROTECTED]> wrote:

> Jaswinder Singh wrote:
> >
> > >
> > BTW, how many WindowsCE machines are fully (means all the features as
> > provided by Windows CE) supported by LinuxSH and how many machines are
> > partially(only few features) supported by LinuxSH ?
>
>   I don't understand, what features do you mean?
>

By features , i mean , that we can use all the hardware of WindowsCE machine
, like Touch panel , modem , IrDA, Sound , etc , etc .

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: new aic7xxx oopses with AHA2940

[Keith Owens]

On Sat, 26 May 2001 18:05:29 +0200, 
Marc Schiffbauer <[EMAIL PROTECTED]> wrote:
>I have problems with the new aic7xxx-Driver. These problems exist
>with vanilla (2.4.4, 2.5.5, other d.k.) and -ac
>May 26 17:52:33 homer kernel: EIP:
>0010:[usbcore:usb_devfs_handle_Re9c5f87f+161255/198895517]
>May 26 17:52:33 homer kernel: Call Trace: 
>[usbcore:usb_devfs_handle_Re9c5f87f+162269/198894503] 
>[usbcore:usb_devfs_handle_Re9c5f87f+164966/198891806] [__delay+19/48] 
>[usbcore:usb_devfs_handle_Re9c5f87f+166493/198890279] 
>[usbcore:usb_devfs_handle_Re9c5f87f+117712/198939060] 
>[usbcore:usb_devfs_handle_Re9c5f87f+185577/198871195] 
>[usbcore:usb_devfs_handle_Re9c5f87f+171751/198885021] 
>
>Does it crash with the USB-Driver?? But USB works fine... even after
>the Oops

Because you are using a broken version of klogd that stuffs up oops
traces.  Change klogd to run as klogd -x (probably in
/etc/rc.d/init.d/syslog) so it keeps its broken fingers off the oops.

Since you are failing during modprobe, creating /var/log/ksymoops is a
good idea, man insmod, see KSYMOOPS ASSISTANCE.  Reproduce the
problem to get a clean oops trace then run it through ksymoops, using
the saved module data in /var/log/ksymoops.

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

Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

Andrea Arcangeli wrote:
> diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
> --- alpha/arch/alpha/kernel/sys_dp264.c Sun Apr  1 01:17:07 2001
> +++ alpha-1/arch/alpha/kernel/sys_dp264.c   Wed May 23 02:43:49 2001
> @@ -16,15 +16,18 @@
>  #include 
>  #include 
> 
> +#define __EXTERN_INLINE inline
> +#include 
> +#include 
> +#undef  __EXTERN_INLINE
> +

Why is "__EXTERN_INLINE" defined as "inline" not "extern inline"?

I simply added "extern" and things started working (as noted in my
previous message in this thread)..

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: vm in 2.4.5

[Andrzej Krzysztofowicz]

> On Sat, 26 May 2001, J . A . Magallon wrote:
> > It does not begin to use swap in a growing fashion, it just appears
> > full in a moment.
> 
> It gets _allocated_ in a moment, but things don't actually get
> swapped out. This isn't a problem.
> 
> The real problem is that we don't actively reclaim swap space
> when it gets full. We just assign swap to parts of processes,
> but we never reclaim it when we need swap space for something
> else; at least, not until the process exit()s or exec()s.

As I understand the original message, before the compilation and after the
system is in a "similar" state ("the same" processes should be running; even
less of them if some were killed by OOM).

:  total   used   free sharedbuffers cached
: -/+ buffers/cache:  49908 205780
: Swap:   152576  0 152576

~49 MB in use befere the test,

: -/+ buffers/cache:  14844 240844
: Swap:   152576 152576  0

~149 MB allocated swap. By processes of total size of 49 MB ? Strange...

Either the test shows some leak in running userspace processes (they
allocate a lot of memory) as an effect of memory shortage (strange) or there
is some leak in the kernel. Or the test is bad (something else is running
when it finishes).

Am I right ?

Andrzej

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

Re: IDE Performance lack !

[Jaswinder Singh]

>
> RedHat 7.1 - IDE IBM 41.1 GIG
> Update to 2.4.5 -> noticed, that hdparm -t /dev/hda went down from 10
> MByte/sec to 1.9 MByte/sec
> Any special Options, beside ide-scsi driver activated ..
>
> Anybody noticed the same problem ? Any clues ?
>

yes , i am also not happy with IDE performance of Linux . That why i dont
use Hard disk in my Target machines ;)

When ever i copy big data (around 400 to 700 MB ) from one partion to
another my machine do not response at all (i can not work on another shell)
during data transfer.

Thank you ,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.



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

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Pavel Machek]

Hi!

> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> > still a pain to work with.
> 
> If you really want to have fun, remove all swap...

My handheld has 12MB ram, no swap ;-), and that's pretty big machine
for handheld.
Pavel
PS: Swapping on flash disk is bad idea, right?
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[James Sutherland]

On Fri, 25 May 2001, Adam J. Richter wrote:
> Larry McVoy wrote:
> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:

> >It's also about the concept of boundaries - if you think that that
> >concept is not a legal one then why aren't all programs which are run
> >on top of a GPLed kernel then GPLed?
>
>   Apparently Linus felt that that was a sufficiently
> plausible gray area that he addressed it explicitly in
> /usr/src/linux/COPYING:
>
> |   NOTE! This copyright does *not* cover user programs that use kernel
> | services by normal system calls - this is merely considered normal use
> | of the kernel, and does *not* fall under the heading of "derived work".
> | Also note that the GPL below is copyrighted by the Free Software
> | Foundation, but the instance of code that it refers to (the Linux
> | kernel) is copyrighted by me and others who actually wrote it.

Note the "derived work"; there is no way on this earth (or any other) that
you could regard the device's firmware as being a "derived work" of the
driver! AFAICS, the firmware is just a file served up to the device as
needed - no more a derivative work from the kernel than my homepage is a
derivative work of Apache.


James.

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Pavel Machek]

Hi!

> > explicit about defining source code:
> > The source code for a work means the preferred form of the work for
> > making modifications to it.
> 
> Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
> of constants of unknown origin. If you want to modify the implementation
> you most certainly want more than numeric values.
> 
> Same goes for any tables that contain anything besides well-known constants.

Imagine the hell opening when you generate table of random numbers
with hardware generator :-). How do you write source of hardware
random generator?
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

umount segfault on shutdown

[Gavin]

Hi,
Hope this is enough info :P

Unmounting file systems: journal_begin called without kernel lock held
kernel BUG at journal.c:423!
423: invalid operand: 
CPU: 0
EIP: 0010: []
EFLAGS: 00010286
eax: 001d ebx: c42edf38 ecx: 0001 edx:0001
esi: c12dc800 edi: c42edf38 ebp: 000a esp: c42eded0

that's all I wrote down. There was more, please reply to reply-to if
you need more info and anything else I can do to provide more
information. Running Via apollo pro-a on smp MSI694D pro/2x366
reiserfs on /dev/hde8 (/usr)  which seems
to be the cause of the segfault. I can reproduce this everytime with
2.4.5, doesn't happen with earlier versions.

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

Re: PS/2 Esdi patch #8

[Paul Gortmaker]

Jens Axboe wrote:
> 
> On Thu, May 24 2001, Paul Gortmaker wrote:
>
> > Probably makes sense for driver to set it regardless, seeing
> > as default (MAX_SECTORS) has changed several times over last
> > few months.  At least then it will be under driver control
> > and not at the mercy of some global value.
> 
> You might want to assign that max_sect array too, otherwise it's just
> going to waste space :-)

Heh, yes. :) 

> Take a look at how ps2esdi handles requests -- always processing just
> the first segment. Alas, it doesn't matter how big the request is.

Well here is the missing line, for completeness, in case somebody
someday gets bored and changes the above behaviour (it won't be me!)

Paul.

--- drivers/block/ps2esdi.c~Thu May 24 16:33:46 2001
+++ drivers/block/ps2esdi.c Sat May 26 04:47:45 2001
@@ -424,6 +424,7 @@
request_dma(dma_arb_level, "ed");
request_region(io_base, 4, "ed");
blksize_size[MAJOR_NR] = ps2esdi_blocksizes;
+   max_sectors[MAJOR_NR] = ps2esdi_maxsect;
 
for (i = 0; i < ps2esdi_drives; i++) {
register_disk(&ps2esdi_gendisk,MKDEV(MAJOR_NR,i<<6),1<<6,




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

Re: [patch] severe softirq handling performance bug, fix, 2.4.5

[David S. Miller]

Ingo Molnar writes:
 > (unlike bottom halves, soft-IRQs do not preempt kernel code.)
 ...

Since when do we have this rule? :-)

 > the two error cases are:
 > 
 >  #1 hard-IRQ interrupts user-space code, activates softirq, and returns to
 > user-space code
 > 
 >  #2 hard-IRQ interrupts the idle task, activates softirq and returns to
 > the idle task.
 > 
 > category #1 is easy to fix, in entry.S we have to check active softirqs
 > not only the exception and ret-from-syscall cases, but also in the
 > IRQ-ret-to-userspace case.
 > 
 > category #2 is subtle, because the idle process is kernel code, so
 > returning to it we do not execute active softirqs. The main two types of
 > idle handlers both had a window do 'miss' softirq execution:

Ingo, I don't think this is the fix.

You should check Softirqs on return from every single IRQ.
In do_softirq() it will make sure that we won't run softirqs
while already doing so or being already nested in a hard-IRQ.

Every port works this way, I don't know where you got this "soft-IRQs
cannot run when returning to kernel code" rule, it simply doesn't
exist.

And looking at the x86 code, I don't even understand how your fixes
can make a difference, what about the do_softirq() call in
arch/i386/kernel/irq.c:do_IRQ()???  That should be taking care of all
these "error cases" right?

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

Re: 2.4.4-ac[356]: network (8139too) related crashes

[Alan Cox]

> Tried 2.4.5 and got the same problem again. Parhaps I'll sty with 2.4.3-ac3 
> for now. At least it doesn't freeze ...

Can you try 2.4.5 with the 8139too.c file from the 2.4.3-ac3 that works for
you and report on that
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to open an initial console (on SMP machine)

[Doru Petrescu]

:(

ok, so after diging few hours into the kernel it seems that the vgacon.c
fails to detect/initialize the VGA card. also it seems that it is not
listed in the /proc/pci ... so I guess there is a bit of a hardware
problem ... probably the card moved in its slot and now it is not working
properly.

I will investigate and let you guys know if this is a 'hardware' problem ...
and is just a concidence that it started when I upgraded to 2.4.5-preX

anyway, I think that the VGA console driver should emit an WARNING that 
"No VGA card detected => VGA console disabled"

'cause if I select VGA text console in the kernel config, I am
probably expecting to have one. and the rest that use mathines with no
video card, can just unselect the VGA console option if they don't like
seeing the warning.


unfortnatly the machine is in a remote location, and i can't go and fix
the video card at this hour (01:00 am) ... :(



Best regards,
Doru Petrescu

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

Re: Linux-2.4.5

[Andrea Arcangeli]

On Sat, May 26, 2001 at 11:36:22AM -0300, Rik van Riel wrote:
> On Sat, 26 May 2001, Andrea Arcangeli wrote:
> > > No Comment(tm)   *grin*
> > 
> > I'm having lots of fun, thanks.
> 
> Now _this_ is tweaking magic limits ;)

Others agreed that the real source of the create_buffers could be just
too few reserved pages in the unused_list, the unused_list is the only
"deadlock avoidance logic" designed to avoid create_buffers to deadlock,
so I really don't see why you don't listen to me and you just assume my
idea is obviously wrong while it obviously isn't. The only thing I can
do is to laugh while reading your illogical "No Comment(tm)   *grin*",
if I would take such comment serously I would just ignore the VM and
stay in other subsystem where those funny things never happens as far I
can tell, which I'm not going to do just because of your new funny "No
Comment(tm) *grin*". If for any reason you notice I somehow invite those
things to happen please let me know and I will certainly try to get
better from my part.

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

Re: 2.4.5: 'mount /cdrom' doesn't work

[Harald Dunkel]

Jens Axboe wrote:
> 
> On Sat, May 26 2001, Harald Dunkel wrote:
> > Hi folks,
> >
> > With 2.4.5 my CD and DVD drives have become unaccessable.
> >
> > Can you reproduce this problem?
> 
> Any kernel messages? And please show what happens.
> 

Currently I am back to 2.4.4, but AFAIR I got a message 'no medium found' 
or something like that on the command line.

I have found this in kern.log:

May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0
May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0
May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr2 at scsi2, channel 0, id 0, lun 0
May 26 15:31:17 bilbo kernel: sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray
May 26 15:31:17 bilbo kernel: Uniform CD-ROM driver Revision: 3.12
May 26 15:31:17 bilbo kernel: sr1: scsi3-mmc drive: 32x/32x cd/rw xa/form2 cdda tray
May 26 15:31:17 bilbo kernel: sr2: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda 
tray
May 26 15:31:17 bilbo kernel: VFS: Disk change detected on device sr(11,1)
May 26 15:31:17 bilbo last message repeated 3 times
May 26 15:31:17 bilbo kernel: Device 0b:01 not ready.
May 26 15:31:17 bilbo kernel:  I/O error: dev 0b:01, sector 1024

Using 2.4.4 the same CD works in the same drive. 


Regards

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

Re: QOS &fair queuing modules- can't load

[Jaswinder Singh]

>Let me put across my situation. I need to load the
> modules for QOS & Fair Queuing . I have compiled my
> kernel with modular support for these modules. When I
> try to load these modules a series of error messages
> all indicating unresolved symbols are coming. The
> unresolved symbols  are all defined in
> /usr/src/linux/include/net/pkt_sched.h.
> I have checked out /proc/ksyms file and these symbols
> are listed there,

Are you fulfilling all the requirements for modules , means are you include
proper files and defines module's term while compling your modules , just a
guess.

Better do one thing , define something in kernel , export it in
arch/i386/i386_ksyms.c file and check are you able to get that symbols or
not ?

Jaswinder.
--
These are my opinions not 3Di.


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

Linux 2.4.5-ac1

[Alan Cox]

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

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

In terms of going through the code audit almost all the sound drivers still 
need fixing to lock against format changes during a read/write. Poll creating 
and starting a buffer as write does and also mmap during write, write during
an mmap.

This is the merge with Linus 2.4.5 tree. Its probably primarily of interest
to folks who want to review the merge - in paticular on the VM side of
things.

2.4.5-ac1
o   Merge Linus 2.4.5 tree

Summary of changes for Linux 2.4.5-ac versus Linus 2.4.5

o   Fix memory leak in wanrouter
o   Fix memory leak in wanmain
o   Use non atomic memory for linearising NFS buffers as they are 
done in task context
o   Fix dereference of freed memory in NetROM drivers
o   Fix writing to freed memory in ax25_ip
o   Support debugging of slab pools
o   NinjaSCSI pcmcia scsi driver
o   Raw HID device for USB peripheral buttons/controllers
o   Updated NTFS
o   RAMfs with resource limits
o   NMI watchdog available on uniprocessor x86
o   Update CMPCI drivers (not yet SMP safe)
o   Configurable max_map_count
o   Dynamic sysctl key registration
o   SE401 USB camera driver
o   Updated Zoran ZR3606x driver (replaces buz)
o   w9966 parallel port camera driver (partially merged with Linus)
o   Include headers in etags
o   Don't delete empty directories on make distclean
o   Fix halt/reboot handling on Alcor Alpha
o   IDE driver support for Etrax E100
o   IDE infrastructure support for IDE using non standard data transfers
o   Run ~/bin/installkernel if present
o   Support for out of order stores on x86 with this mode (IDT Winchip)
- worth 20% performance on them
o   Configure level debugging menu
o   Make BUG() default to an oops only - saves 70K
o   Power management help for UP-APIC
o   Work around 440BX APIC hang (eg the ne2000 SMP hang)
o   Run time configurable APM behaviour (interrupts, psr etc)
o   Smarter DMI parser - handles multiple use of names
o   DMI layer has blacklist tables fixing Dell Inspiron 5000e crashes,
PowerEdge reboot problems , and IBM laptop APM problems
o   PNPBios support
o   Fix atomicity of IRQ error count
o   Handle PCI/ISA boxes that don't list edge levels but have an ELCR
o   Don't erroneously mangle settings on all VIA bridges - cures the 
horrible performance problem in 2.4.5 vanilla with VIA
o   Fix bootmem corruption on x86 boot
o   Scan and retrieve multipliers for processors (not yet used to handle
the SMP cases where we need to disable tsc use)
o   Support machine check on Athlon and Pentium
o   Fix SUS violation with signal stacks
o   Handle boxes where firmware resets the timer to 18Hz (this should
now not show false positives)
o   Better OOPS formatting on x86
o   Fix nasty problems with interrupts being disabled for long periods
in frame buffer drivers
o   PAE mode alignment assumption fixes
o   32bit UID clean quota
o   Fix quota deadlocks
o   Fix TLB shootdown races
o   Experimental merge of usermode Linux
o   Fix memory leaks and othe rproblems with the iphase driver
o   IBM AS/400 iSeries virtual drivers
o   DAC960 null pointer checks
o   CCISS driver leak fixes
o   MPT fusion drivers for scsi and networking
o   Handle out of memory allocating request queue entries and avoid oops
o   Free the initial ramdisk correctly
o   Small CD-ROM layer updates
o   AGP power management hooks
o   First basic applicom driver fixes
o   Fix copy_from_user with interrupts off in cyclades driver
o   Fix out of memory handling in DRM
o   Clean up dsp56K driver
o   Update generic serial driver with break support
o   Clean up h8 driver namespace
o   Fix keymap changing problems in console drivers
o   Fix locking in machzwd
o   Updated rio serial driver
o   A2232 driver
o   Fix serial driver mangling of some clone uarts
o   Handle xircom serial port setup delay bug
o   Updated sx driver for newer generic_serial
o   W83877F watchdog driver
o   ITE8172 IDE driver support
o   Q40/Q60 IDE support
o   Fix nodma handling bug in alim15x3
o   hpt366 DMA blacklist
o   IDE-CD updates
o   Updated IDE DMA blacklist
o   OOPS catch for sg reuse in IDE driver
o   Support formatting of IDE floppies
o   Support PIIX4U4 (851EM)
o   Enable second port on promise pseudo raid
o   Support nodma on pmac
o   Support more PCI irq sharing on IDE
o   IDE tape updates - DI-50 support, 
o   Much updated VIA IDE support
o   video1394 updated to newer module API
o   Support write on the input event driver
o   Quieten mouse and keyboard

Re: Linux 2.4.4-ac17

[Jaswinder Singh]

>
> The OS resides on disk, yes.  I suppose I could plunk a minimal
> system into ramfs, pivot_root and umount disk, but I don't see
> any way that could matter for a memory leak.
>

It is very difficult to see memory leak , with hard disks .

As i told you , in my case i am using no harddisks , only thing i have is
RAM , so i am using only Ramdisk and ramfs, so in my case my Ram will full
within few minutes and My machine hangs .

Thanks ,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: Reg- segmentation fault

[Jaswinder Singh]

Dear Satish,

What you means by "segmentation fault on my linux m/c" ?

Segmentation fault is coming from your applications or from Linux Packages
or from Linux kernel ?

BTW, segmentation fault indicates an improper memory access , A common cause
for a segmentation fault is an attempt to access an array out of bounds.

Jaswinder.

- Original Message -
From: "sathish jayapalan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 26, 2001 6:12 AM
Subject: Reg- segmentation fault


> Hi all,
> Sorry to disturb you. I got a segmentation fault on my linux m/c. What
could be the reason for it? Please help me in knowing this.
>
> Thanks in advance,
> Regards,
> sathish.j
>
>
>
>
>
>
>
> Get 250 color business cards for FREE!
> http://businesscards.lycos.com/vp/fastpath/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

IDE Performance lack !

[Guido Stepken]

Hi !

RedHat 7.1 - IDE IBM 41.1 GIG
Update to 2.4.5 -> noticed, that hdparm -t /dev/hda went down from 10 
MByte/sec to 1.9 MByte/sec
Any special Options, beside ide-scsi driver activated ..

Anybody noticed the same problem ? Any clues ?

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

Re: Linux-2.4.5

[Andrea Arcangeli]

On Sat, May 26, 2001 at 12:51:38PM -0300, Rik van Riel wrote:
> On Sat, 26 May 2001, Andrea Arcangeli wrote:
> 
> > > > -   /* 
> > > > -* Set our state for sleeping, then check again for buffer heads.
> > > > -* This ensures we won't miss a wake_up from an interrupt.
> > > > -*/
> > > > -   wait_event(buffer_wait, nr_unused_buffer_heads >= MAX_BUF_PER_PAGE);
> > > > +   current->policy |= SCHED_YIELD;
> > > > +   __set_current_state(TASK_RUNNING);
> > > > +   schedule();
> > > > goto try_again;
> > > >  }
> 
> I'm still curious ... is it _really_ needed to busy-spin here?

As said we cannot wait_event, because those reserved bh will be released
only by the VM if there is memory pressure. If we sleep in wait_event
while I/O is in progress on the reserved bh and a big chunk of memory is
released under us, then those reserved bh may never get released and we
will hang in wait_event until there's memory pressure again, so unless
we implement another logic we need to somehow poll there and to try to
allocate again later. We should enter that path very seldom so I'm not
very concerned about the performance during the polling loop.

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

Re: Linux-2.4.5

[Andrea Arcangeli]

On Sat, May 26, 2001 at 09:42:37PM +0200, Ingo Molnar wrote:
> Andrea, can you rather start running the Cerberus testsuite instead? All

I run cerberus all the time but I don't have locally x86 machines with
>1G of ram so it will take some time for me to try on a real highmem, I
am pretty sure I just tested cerberus with highmem emulation and it
didn't deadlocked for me, I can try again with an higher highmem/normal
ratio later. The ratio I am using right now is half of the ram in
highmem (that is almost the same ratio of a 2G machine):

diff -urN 2.4.3aa/arch/i386/config.in 2.4.3aa-highmemdebug/arch/i386/config.in
--- 2.4.3aa/arch/i386/config.in Sun Apr  1 11:59:37 2001
+++ 2.4.3aa-highmemdebug/arch/i386/config.inSun Apr  1 13:00:01 2001
@@ -369,4 +369,7 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+if [ "$CONFIG_HIGHMEM" = "y" ]; then
+   bool 'Debug HIGHMEM on lowmem machines' CONFIG_HIGHMEM_DEBUG
+fi
 endmenu
diff -urN 2.4.3aa/arch/i386/kernel/setup.c 
2.4.3aa-highmemdebug/arch/i386/kernel/setup.c
--- 2.4.3aa/arch/i386/kernel/setup.cSat Mar 31 15:17:07 2001
+++ 2.4.3aa-highmemdebug/arch/i386/kernel/setup.c   Sun Apr  1 13:00:01 2001
@@ -649,7 +649,19 @@
  */
 #define VMALLOC_RESERVE(unsigned long)(128 << 20)
 #define MAXMEM (unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE)
+#ifdef CONFIG_HIGHMEM_DEBUG
+#define MAXMEM_PFN \
+({ \
+   int __max_pfn;  \
+   if (max_pfn > PFN_DOWN(MAXMEM)) \
+__max_pfn = PFN_DOWN(MAXMEM);  \
+   else\
+__max_pfn = max_pfn / 2;   \
+   __max_pfn;  \
+})
+#else
 #define MAXMEM_PFN PFN_DOWN(MAXMEM)
+#endif
 #define MAX_NONPAE_PFN (1 << 20)
 
/*


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

Re: 2.4.5: Duplicate PCI devices (new pciutils fixed it)

[Dave Gilbert]

On Sat, 26 May 2001, David S. Miller wrote:

> 
> Dave Gilbert writes:
>  > /proc/pci seems to be only listing it once.
> 
> lspci uses /prov/bus/pci/${BUS}/${DEVICE}
> so likely it is showing up twice there.

Hmm nope - /proc/bus/pci has two entries '00' and devices
Devices has 5 lines in it; corresponding to the real 5 devices.
The 00 directory has 5 files in it.

Hmm - ah - cancel the report - I've just got pciutils 2.1.8 down and it is
now happy.  Should there be a version ref for pciutils in
Documentation/Changes?

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
 \ _|_ http://www.treblig.org   |___/

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

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 07:36:49PM +0200, Andrea Arcangeli wrote:
> I got exactly the above when compiling for dp264 so I sent to Linus a
> patch to fix those compile problems, now I suspect my fix broke the
> generic compile :(, I will check that.

2.4.5aa1 compiles fine, but 2.4.5 doesn't, don't know why yet. Please
backout this patch from 2.4.5 for now, this should be the right thing to
do in the long run:

diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
--- alpha/arch/alpha/kernel/sys_dp264.c Sun Apr  1 01:17:07 2001
+++ alpha-1/arch/alpha/kernel/sys_dp264.c   Wed May 23 02:43:49 2001
@@ -16,15 +16,18 @@
 #include 
 #include 
 
+#define __EXTERN_INLINE inline
+#include 
+#include 
+#undef  __EXTERN_INLINE
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 
 #include "proto.h"


Now I will start a robot that will tell me in some hour of computations
which of the patches in my tree actually makes me to need the above
patch to compile both generic and dp264 correctly. After I localized the
offender patch it should be very easy to found why I need the above and
2.4.5 doesn't.

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

Re: Linux-2.4.5

[Linus Torvalds]

On Sat, 26 May 2001, Rik van Riel wrote:
> 
> > Testing is good. But I want to understand how we get into the
> > situation in the first place, and whether there are ways to alleviate
> > those problems too.
> 
> As I said  create_buffers() -> get_unused_buffer_head()
> -> __alloc_pages() -> loop infinitely.

No no no.

Get outside the small world of where it's looping.

Think more on the problem of "how did we get into such a state that we're
so low on memory for swapouts in the FIRST PLACE?"

That's the problem I want to fix. And I suspect part of the equation is
exactly the fact that we use SLAB_BUFFER for the buffer heads. 

Example schenario:
 - we're low on memory, but not disastrously so. We have lots of highmem
   pages, but not that much NORMAL. But we're not uncomfortable yet.
 - somebody starts writing out to a file. He nicely allocates HIGHMEM
   pages for the actual data (no memory pressure on HIGHMEM, so no
   "try_to_free_pages()" called at all)
 - the writer _also_ needs the buffer heads for those written pages (ie
   "generic_block_prepare_write()"), and here he allocates them with
   SLAB_BUFFER. The NORMAL zone starts getting low, and we start calling
   "try_to_free_pages()".
 - we deplete "try_to_free_pages()" and start swapping. Except everybody
   is calling "try_to_free_pages()" with GFP_BUFFER, so nobody can
   actually do any IO, and if we're unlucky there's not much to be free'd
   in the NORMAL zone.

Now do you start to see a pattern here? 

You're trying to fix the symptoms, by attacking the final end. And what
I've been trying to say is that this problem likely has a higher-level
_cause_, and I want that _cause_ fixed. Not the symptoms.

Now, I suspect that part of the cause for this is the fact that we're
using GFP_BUFFER where we shouldn't, which is why we cannot free stuff up
properly in the NORMAL zone.

Now, there could be other things going on too. I'm not saying that it is
necessarily _just_ the experimental silly test-patch I sent out
yesterday. But I _am_ saying that we should try to fix the root cause
first, and then apply the page_alloc.c thing as a last-ditch effort (but
I'd like that "last effort" to be something that nobody can trigger under
any reasonable load).

Do you NOW see my argument? The argument of "we shouldn't have gotten us
into this situation in the first place". See?

Linus

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

Re: Linux-2.4.5

[Linus Torvalds]

On Sat, 26 May 2001, Andrea Arcangeli wrote:
> 
> getblk still needs to use SLAB_BUFFER, not sure how many callers will be
> allowed to use SLAB_KERNEL, but certainly the "async" name was not very
> appropriate to indicate if the bh allocation can fail or not.

Note that these days, on reasonable filesystems, getblk() and friends are
only used by meta-data. So on a normal setup that uses the page cache for
data (pretty much everything), you'd probably go from "100% SLAB_BUFFER"
to "less than 10% SLAB_BUFFER".

Which should cut down on the "this can happen under real load" stuff. 

Assuming, of course, that there aren't any other causes. I can imagine
schenarios where the buffer heads are the major cause of problems, and the
fact that Rik special-cased GFP_BUFFER makes me suspect that that is _his_
schenario, but there may be other, less obvious, ways to get into similar
trouble.

MM is hard. No question about it.

Linus

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

Re: ov511 driver doesn't compile

[Erik Mouw]

On Sat, May 26, 2001 at 12:52:48PM +0200, David G?mez  wrote:
> On kernel 2.4.5, the ov511 usb driver shows a failure at compile
> time. const version is not defined.

I send a patch to Linus for linux-2.4.5-pre5, but apparently he didn't
include it. Here it is again.

BTW, this is already fixed in 2.4.4-ac17, so I suppose Alan will pass
it to Linus.


Erik

--- drivers/usb/ov511.c.origThu May 24 15:21:58 2001
+++ drivers/usb/ov511.c Thu May 24 15:24:20 2001
@@ -337,7 +337,7 @@
/* IMPORTANT: This output MUST be kept under PAGE_SIZE
 *or we need to get more sophisticated. */
 
-   out += sprintf (out, "driver_version  : %s\n", version);
+   out += sprintf (out, "driver_version  : %s\n", DRIVER_VERSION);
out += sprintf (out, "custom_id   : %d\n", ov511->customid);
out += sprintf (out, "model   : %s\n", ov511->desc ?
clist[ov511->desc].description : "unknown");


-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.4-ac18

[Alan Cox]

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

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

In terms of going through the code audit almost all the sound drivers still 
need fixing to lock against format changes during a read/write. Poll creating 
and starting a buffer as write does and also mmap during write, write during
an mmap.

This patch adds Current pending patches and fixups from the queue, as well
as the next batch of LVM changes. Also included is Rik's latest VM patch
which I'm sure he would appreciate reports on

2.4.4-ac18
o   Fix __init used on data in matroxfb (Rasmus Andersen)
o   Small tlb shootdown fix (Ben LaHaise)
o   Fix warning in the FPU code (Rich Baum)
o   Update se401 driver (Jeroen Vreeken)
o   Update NTFS file system (Anton Altaparmakov)
o   VM updates  (Rik van Riel)
o   Yamaha PCI audio updates(Pete Zaitcev,
 Paul Stewart)
o   Fix reboot v halt on Alcorn Alpha   (Tom Vier)
o   Fix null pointer check in ide-cd(Rasmus Andersen)
o   Fix null pointer check in matroxfb  (Petr Vandrovec)
o   Merge IBM AS/400 drivers(Dave Boutcher,  Jeff Haumont,
 Ryan Arnold, Kyle Lucke)
o   Mark winchip_mcheck_init as __init  (Andrey Panin)
o   Fix syncppp misbehaviour(Bob Dunlop)
o   Update mc232 changelog  (Greg Kroah-Hartmann)
o   Fix ibmtr rebuild each make modules (Eric Mouw)
o   Fix FREEVXFS name in Configure.help (Steven Cole)
o   Fix scsi_proc memory leak   (Mike Brown)
o   Fix config dependancies and xconfig of JFFS2   (Andrzej Krzysztofowicz)
o   Update lp486e to use new style request_region   (Andrey Panin)
| also add __inits
o   Final version of Alpha pyxis iommu fixes(Ivan Kokshaysky,
 Richard Henderson)
o   Move lvm-snap to lvm-internal.h
o   Delay devfs VG creation until end of vg check
o   Rewrite and clean lvm devfs/proc code   (Andreas Dilger,
 Joe Thornber)

2.4.4-ac17
o   Fix double free in new cciss(me)
o   Fix i2o_pci double free on error(me)
o   Fix use after free in iphase (two of)   (me)
o   Fix use after free in cs4281(me)
o   Fix use after free in lapbether (me)
o   Fix use after free in bpqether  (me)
o   Fix use after free in edgeport  (me)
o   Fix memory leak in cciss(me)
o   Fix memory leak in failed vxfs mounts   (me)
o   Fix memory leak in failed cmsfs mounts  (me)
o   Fix memory leak on error in ixj (me)
o   Fix memory leak in lmc  (me)
o   Fix memory leak in isdnppp  (me)
o   Fix memory leak in wanrouter(me)
o   Fix memory leak on error in jffs(me)
o   Fix reference to invalid memory in rio  (me)
o   Fix leaks in xircom driver (and update) (Arjan van de Ven)
| All of the above found by the stanford checking team
| who [or whose tools] effectively did the work for us
o   Fix maestro bug from merge  (Marcus Meissner)

2.4.4-ac16
o   Fix FAT crashes with 2K media   (OGAWA Hirofumi)
o   Fix scsi trace messages (Khalid Aziz)
o   Fix hga module laod problem (Juan Quintela)
o   Fix leak in wanproc (Akash Jain)
o   ESS solo clean ups  (Marcus Meissner)
o   Update address for Jonathan Woithe  (Jonathan Woithe)
o   Fix the mess I made of the stradis driver   (Francois Romieu)
o   Port maestro to 2.4 PCI API (Marcus Meissner)
o   Report shmem pages in /proc (Christoph Rohland)
| Im not sure this is the right approach - opinions ?
o   Port toshoboe driver to 2.4 PCI api (Marcus Meissner)
o   Update 3ware ide raid driver(Adam Radford)
o   Update ncr/symbios drivers  (Gerhard Roudier)
o   Fix fealnx build on some non x86 platforms  (Jeff Garzik)

2.4.4-ac15
o   Merge Linus 2.4.5pre5
| Also fixes a dumb bug in my mmx fixups I 
| managed to forget to test and spot
o   Dump the ACPI chang

[2.4.5] buz.c won't compile

[Jan Sembera]

Hi,

i've got a problem compiling drivers/media/video/buz.c as module. When 
i'm trying to compile, i get couple of errors:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe 
-mpreferred-stack-boundary=2 -march=athlon  -DMODULE -DMODVERSIONS 
-include /usr/src/linux/include/linux/modversions.h   -c -o buz.o buz.c
buz.c: In function `v4l_fbuffer_alloc':
buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:188: (Each undeclared identifier is reported only once
buz.c:188: for each function it appears in.)
buz.c: In function `jpg_fbuffer_alloc':
buz.c:262: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:256: warning: `alloc_contig' might be used uninitialized in this 
function
buz.c: In function `jpg_fbuffer_free':
buz.c:322: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c:316: warning: `alloc_contig' might be used uninitialized in this 
function
buz.c: In function `zoran_ioctl':
buz.c:2837: `KMALLOC_MAXSIZE' undeclared (first use in this function)
buz.c: In function `zr36057_init':
buz.c:3215: too few arguments to function `video_register_device_Recfe1c4b'
make[3]: *** [buz.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/media/video'
make[2]: *** [_modsubdir_video] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/media'
make[1]: *** [_modsubdir_media] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_mod_drivers] Error 2

Jan Sembera

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

Re: 2.4.4-ac[356]: network (8139too) related crashes

[Andris Pavenis]

On Wednesday 09 May 2001 22:25, Danny ter Haar wrote:
> Andris Pavenis  <[EMAIL PROTECTED]> wrote:
> >With kernels 2.4.4-ac[356] I'm getting system freezing on FTP transfer
> > after some time. I'm trying to upload about 6.5Mb file using MC (transfer
> > speed about 300-1000Kb/s). With these kernel versions I'm getting random
> > total freezing system (no any kernel error messages, no reaction to
> > keyboard, no response to ping from other machine). The same seems to
> > happen also when transfer speed is slower (I left wget downloading many
> > files 2 nights and both times system was hanged in morning)
>
> I have similar problems on my sony vaio laptop (pcmcia ethernet
> card that works with the 8139too driver)
> I send detailed info to Jeff & Alan weeks ago.
>
> >Kernel 2.4.3-ac3 seems to be Ok.
>
> Problems started with the change in 2.4.3-ac7.
> So up to 2.4.3-ac6 it's fine.
>

Tried 2.4.5 and got the same problem again. Parhaps I'll sty with 2.4.3-ac3 
for now. At least it doesn't freeze ...

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

[PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

"Ingo T. Storm" wrote:
> I just tried to compile 2.4.5 on a Ruffian. With CPU selection "generic" it
> fails when linking the kernel (see below). With CPU=Ruffian, it compiles and
> links fine. Haven't tried booting yet, 'cause the machine is some 20 miles
> away from here.

> ld  -r -o kernel.o entry.o traps.o process.o osf_sys.o irq.o irq_alpha.o
> signal.
> o setup.o ptrace.o time.o semaphore.o alpha_ksyms.o irq_i8259.o irq_srm.o
> es1888
> .o smc37c669.o smc37c93x.o ns87312.o pci.o pci_iommu.o core_apecs.o
> core_cia.o c
> ore_irongate.o core_lca.o core_mcpcia.o core_polaris.o core_t2.o
> core_tsunami.o
> core_titan.o sys_alcor.o sys_cabriolet.o sys_dp264.o sys_eb64p.o sys_eiger.o
> sys
> _jensen.o sys_miata.o sys_mikasa.o sys_nautilus.o sys_titan.o sys_noritake.o
> sys
> _rawhide.o sys_ruffian.o sys_rx164.o sys_sable.o sys_sio.o sys_sx164.o
> sys_takar
> a.o sys_wildfire.o core_wildfire.o irq_pyxis.o
> sys_dp264.o: In function `tsunami_inb':
> sys_dp264.c(.text+0x440): multiple definition of `tsunami_inb'
> core_tsunami.o(.text+0x500):core_tsunami.c: first defined here

I used the attached patch to fix the problem.

(note the tty.h changes are unrelated...  they are preparing for when
sched.h no longer includes tty.h, fixing a nasty include loop)

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |

Index: arch/alpha/kernel/process.c
===
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/process.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 process.c
--- arch/alpha/kernel/process.c 2001/05/25 01:09:03 1.1.1.14
+++ arch/alpha/kernel/process.c 2001/05/26 22:00:59
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
Index: arch/alpha/kernel/sys_dp264.c
===
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/sys_dp264.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 sys_dp264.c
--- arch/alpha/kernel/sys_dp264.c   2001/05/26 04:03:59 1.1.1.10
+++ arch/alpha/kernel/sys_dp264.c   2001/05/26 22:01:00
@@ -16,7 +16,7 @@
 #include 
 #include 
 
-#define __EXTERN_INLINE inline
+#define __EXTERN_INLINE extern inline
 #include 
 #include 
 #undef  __EXTERN_INLINE
Index: arch/alpha/kernel/sys_sio.c
===
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/sys_sio.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 sys_sio.c
--- arch/alpha/kernel/sys_sio.c 2000/10/30 19:47:55 1.1.1.2
+++ arch/alpha/kernel/sys_sio.c 2001/05/26 22:01:00
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 

Re: Unable to open an initial console (on SMP machine)

[Doru Petrescu]

ok, here are some more details:

NO, i do not use devfs.
thre is no problem at boot time. /dev directory is where it was supposed
to be. /sbin/ /etc and everything else is OK.
nothing is wrong with /dev directory. everything else WORKS.

just that /dev/console /dev/ttyX and /dev/ttyXX and /dev/vcs* stop
working:

this is what i geT:
root@k:~# cat /dev/console
cat: /dev/console: No such device
root@k:~# cat /dev/tty1
cat: /dev/tty1: No such device
root@k:~# cat /dev/vcs1
cat: /dev/vcs1: No such device or address

what amuse me is that i get different responses ... :-)

also, as far as i can see the major/minor IS ok ... (see below)

-
/proc/devices
/proc/tty/drivers

/proc/devices is missing one line, the last one: 
"unknown  /dev/vc/%d  41-63 console"




root@k:~# cat /proc/devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 ttyS
  5 cua
  7 vcs
 10 misc
 36 netlink
 89 i2c
128 ptm
136 pts
162 raw

Block devices:
  1 ramdisk
  2 fd
  3 ide0
  7 loop
 22 ide1

root@k:/proc/tty# cat drivers
 /dev/cua5  64-127 serial:callout
 /dev/ttyS   4  64-127 serial
pty_slave/dev/pts  136   0-255 pty:slave
pty_master   /dev/ptm  128   0-255 pty:master
pty_slave/dev/ttyp   3   0-255 pty:slave
pty_master   /dev/pty2   0-255 pty:master
/dev/vc/0/dev/vc/0   4   0 system:vtmaster
/dev/ptmx/dev/ptmx   5   2 system
/dev/console /dev/console5   1 system:console
/dev/tty /dev/tty5   0 system:/dev/tty

root@k:/proc/tty# cat ldiscs
n_tty   0


root@k:/proc# cd /dev
root@k:/dev# l console
   0 crw---   1 root tty5,   1 Apr 21  1999 console
root@k:/dev# l tty1
   0 crw--w--w-   1 root root   4,   1 May  4 12:47 tty1
root@k:/dev# l vcs1
   0 crw--w--w-   1 root tty7,   1 May  6  1996 vcs1



Best regards,
Doru Petrescu



On Sat, 26 May 2001, Doru Petrescu wrote:

> 
> starting with kernels 2.4.5-preX I get this at startup:
> 
>   Warning: unable to open an initial console.
> 
> then none of the /dev/vcs* /dev/tty* doesn't work.
> 
> 
> 
> then i get this in syslog:
>   May 26 16:10:19 www modprobe: modprobe: Can't open dependencies file 
>/lib/modules/2.4.5/modules.dep (No such file or directory)
>   May 26 16:10:19 www /sbin/agetty[383]: /dev/tty5: cannot open as standard 
>input: No such device
> 
> lucky me that this machine is a network server and most (all) of the
> administrative tasks are done via SSH ...
> 
> I attache the .config file and the dmesg results and the /proc/pci file  ...
> 
> i don't understand what is WORNG ... it worked BEFORE ...
> i have " Virtual terminal " and "Support for console on virtual
> terminal "  enabled ...
> 
> anybody has any idea ?
> 
> also i see an "WARNING: unexpected IO-APIC, please mail" ... can this be
> the problem ?!? 
> 
> 
> Best regards,
> --
> Doru Petrescu
> KappaNet - Senior Software Engineer
> E-mail: [EMAIL PROTECTED] LINUX - the choice of the GNU generation
> 
> 
> 
> 

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

Re: 2.4.5: 'mount /cdrom' doesn't work

[Harald Dunkel]

Jens Axboe wrote:
> 
> 
> The only changes that could matter would be SCSI driver changes. You
> wouldn't happen to use the new aic7xxx driver?
> 
I had the same problem with the IDE CD writer (using SCSI emulation).


Regards

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

new aic7xxx oopses with AHA2940

[Marc Schiffbauer]

Hi *,

I have problems with the new aic7xxx-Driver. These problems exist
with vanilla (2.4.4, 2.5.5, other d.k.) and -ac

When I built it into the Kernel, it will panic on boot when it tries
to access the adapter.

Built as modules it segfaults when i try to insmod (modprobe) it, 
following this Oops in messages:


May 26 17:52:33 homer kernel: PCI: Found IRQ 9 for device 00:0d.0
May 26 17:52:33 homer kernel: PCI: The same IRQ used for device 00:04.2
May 26 17:52:33 homer kernel: PCI: The same IRQ used for device 00:04.3
May 26 17:52:33 homer kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 
May 26 17:52:33 homer kernel:  printing eip:
May 26 17:52:33 homer kernel: e0a7b3a7
May 26 17:52:33 homer kernel: *pde = 
May 26 17:52:33 homer kernel: Oops: 
May 26 17:52:33 homer kernel: CPU:0
May 26 17:52:33 homer kernel: EIP:
0010:[usbcore:usb_devfs_handle_Re9c5f87f+161255/198895517]
May 26 17:52:33 homer kernel: EFLAGS: 00010096
May 26 17:52:33 homer kernel: eax: 0041   ebx:    ecx: dd5d6e00   edx: 

May 26 17:52:33 homer kernel: esi:    edi: 00ff   ebp: dd5d6e00   esp: 
dd165cbc
May 26 17:52:33 homer kernel: ds: 0018   es: 0018   ss: 0018
May 26 17:52:33 homer kernel: Process modprobe (pid: 766, stackpage=dd165000)
May 26 17:52:33 homer kernel: Stack:   00ff dd5d6e00 41000357 
e0a7b79d dd5d6e00  
May 26 17:52:33 homer kernel: 0041  00ff  
0041  dd5d6e00 
May 26 17:52:33 homer kernel:dd5d6e00 0001 0001 0001 0001 
0001  0001 
May 26 17:52:33 homer kernel: Call Trace: 
[usbcore:usb_devfs_handle_Re9c5f87f+162269/198894503] 
[usbcore:usb_devfs_handle_Re9c5f87f+164966/198891806] [__delay+19/48] 
[usbcore:usb_devfs_handle_Re9c5f87f+166493/198890279] 
[usbcore:usb_devfs_handle_Re9c5f87f+117712/198939060] 
[usbcore:usb_devfs_handle_Re9c5f87f+185577/198871195] 
[usbcore:usb_devfs_handle_Re9c5f87f+171751/198885021] 
May 26 17:52:33 homer kernel:[rpc_new_task+240/368] 
[usbcore:usb_devfs_handle_Re9c5f87f+113534/198943238] 
[usbcore:usb_devfs_handle_Re9c5f87f+150165/198906607] 
[usbcore:usb_devfs_handle_Re9c5f87f+113361/198943411] 
[usbcore:usb_devfs_handle_Re9c5f87f+113392/198943380] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] [pci_announce_device+28/80] 
[usbcore:usb_devfs_handle_Re9c5f87f+202048/198854724] 
May 26 17:52:33 homer kernel:
[usbcore:usb_devfs_handle_Re9c5f87f+202144/198854628] [pci_register_driver+68/96] 
[usbcore:usb_devfs_handle_Re9c5f87f+202144/198854628] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] 
[usbcore:usb_devfs_handle_Re9c5f87f+125626/198931146] 
[usbcore:usb_devfs_handle_Re9c5f87f+113038/198943734] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] 
[usbcore:usb_devfs_handle_Re9c5f87f+111272/198945500] 
May 26 17:52:33 homer kernel:[scsi_register_host+73/720] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] 
[usbcore:usb_devfs_handle_Re9c5f87f+111272/198945500] 
[usbcore:usb_devfs_handle_Re9c5f87f+68/198945604] 
[usbcore:usb_devfs_handle_Re9c5f87f+111272/198945500] [scsi_register_module+45/96] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] 
May 26 17:52:33 homer kernel:
[usbcore:usb_devfs_handle_Re9c5f87f+68/198945604] 
[usbcore:usb_devfs_handle_Re9c5f87f+125206/198931566] 
[usbcore:usb_devfs_handle_Re9c5f87f+201920/198854852] [sys_init_module+1277/1440] 
[eepro100:__insmod_eepro100_O/lib/modules/2.4.5/kernel/drivers/net/ee+0/96] 
[usbcore:usb_devfs_handle_Re9c5f87f+111264/198945508] [system_call+51/56] 
May 26 17:52:33 homer kernel: 
May 26 17:52:33 homer kernel: Code: 8b 02 8b 7c 24 20 8b 6c 24 28 0f b6 40 19 f6 81 f0 
00 00 00 

Does it crash with the USB-Driver?? But USB works fine... even after
the Oops

BTW: The old aic7xxx-Driver works fine for me

Devices connected to the adapter:
 - teac CDR
 - old plextor cdrom
 - ibm 4G HD

System is an AMD Thunderbird 800, 512MB, ASUS A7V

Do you need any further information?

Cheers
-Marc
-- 
|  |
|  |
| http://www.links2linux.de <-- Von Linux-Usern fuer Linux-User|

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

2.4.4 and VC display lost

[Roeland Th. Jansen]

I have mentioned this weird behaviour under 2.4.3 as well.

if I use X for some time, I alwasy switch and forth between the (IMHO)
idel CLI and sometimes switch back to the clumsy GUI.

now, what happens is that sometimes, after I switch from X back to a VC,
the display gets black and stays that way.

the system works fine. I can still input everything I like etc but won't
see anything.

it's on all non graphic consoles and I can't recover without rebooting.

anyone an idea ? 

I am using X 4.02 (XFREE) on a riva TNT (viper 550); no special driver
used, only the one that's supplied with X itself.


-- 
Grobbebol's Home   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel   | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ext3 message if FS is not ext3

[Steve Dodd]

On Wed, May 23, 2001 at 01:06:16PM +0100, Stephen C. Tweedie wrote:
> On Wed, May 23, 2001 at 02:00:13PM +0200, Florian Lohoff wrote:

> > i think this message should be removed ;)
[..]
> > VFS: Can't find an ext3 filesystem on dev fd(2,0).

> mount(8) tried to get the kernel to mount /dev/fd0 as an ext3
> filesystem.  The kernel is entitled to emit an error in that case.
> ext2 will complain too.

Shouldn't it be doing the mount 'silently' when mount(8) is guessing the
filesystem type? I'm seeing this too (2.2.19 + ext3 0.0.6b):

lilith:tmp$ cat /etc/filesystems
ext3
vfat
lilith:tmp$ grep floppy /etc/fstab
/dev/fd0 /floppy auto noauto,nodev,nosuid,user 0 0
lilith:tmp$ # with a VFAT filesystem on /dev/fd0:
lilith:tmp$ mount /floppy
VFS: Can't find an ext3 filesystem on dev fd(2,0).

Looking at the kernel source, read_super (and hence ext3_read_super) are only
called with silent=1 when mounting the root filesystem. I believe mount(8)
checks for magic numbers at the start of the filesystem, and so avoids
attempting a mount for ext2 or various others.

As the kernel (2.2 or 2.4) doesn't seem to provide a way for userspace to
request a silent mount, I don't know whose (if anyone's) bug this is.

-- 
PGP signed or encrypted mail preferred, key ID 0x68383A73.
Please *do* Cc: me on mailing list replies.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-2.4.5

[Linus Torvalds]

On Sat, 26 May 2001, Rik van Riel wrote:
> 
> O, that part is fixed by the patch that Linus threw away
> yesterday ;)

Rik, I threw away the parts of the patch that were bad and obvious
band-aids, and it was hard to tell whether any of your patch was a
"real" fix as opposed to just making more reservations.

And you have not replied to any of the real arguments for fixing the
_real_ bugs. You jst repeat "my patch, my patch, my patch", without even
acknowledging that others are finding the real _underlying_ problems.

Please take a moment to realize that you're not exactly being helpful.

Linus

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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

>
>   The class of machines for which this option does not apply is
> "machines with an existing operating system in mask rom and no
> flash", which AFAICT is equivalent to "WindowsCE machines
> ".  The

AFAIK WindowsCE machines are also broad term.

BTW, how many WindowsCE machines are fully (means all the features as
provided by Windows CE) supported by LinuxSH and how many machines are
partially(only few features) supported by LinuxSH ?

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.




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

Re: Linux 2.4.4-ac17

[Jaswinder Singh]

>
> The OS resides on disk, yes.  I suppose I could plunk a minimal
> system into ramfs, pivot_root and umount disk, but I don't see
> any way that could matter for a memory leak.
>

It is very difficult to see memory leak , with hard disks .

As i told you , in my case i am using no harddisks , only thing i have is
RAM , so i am using only Ramdisk and ramfs, so in my case my Ram will full
within few minutes and My machine hangs .

Thanks ,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: kernel BUG at inode.c:654!

[Alexander Viro]

On Sat, 26 May 2001, Santiago Garcia Mantinan wrote:

> Hi!
> 
> That's what my server, wich is running 2.4.5, was shouting when I pluged in
> my laptop at the console (ttyS0), all I could do was copy the output I was
> seeing on minicom to a file, after rebooting I saw that the kernel had left
> some of the logging on kern.log, so I'm attaching a file with both the stuff
> on the console and the ones on the log.
> 
> The machine is an intel pentium 166 with 48 megs of mem, it has an stock
> 2.4.5 kernel with netfilter patches for the irc NAT, even though this
> patches were working ok on 2.4.4 and don't seem to have anything to do with
> this problem, I'm recompiling an stock 2.4.5 now, just to be sure.
> 
> Well, I don't know what else to say, if I'm missing something you want to
> know, don't hesitate to ask.

Lovely... It's one of the long lists and these asserts (lines 650 and 654)
are exactly what would happen if it was corrupted at some place. OTOH, it
may be for real - i.e. real inodes in wrong state getting on the list, rather
than corrupted pointer.

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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

>
>   The class of machines for which this option does not apply is
> "machines with an existing operating system in mask rom and no
> flash", which AFAICT is equivalent to "WindowsCE machines
> ".  The

AFAIK WindowsCE machines are also broad term.

BTW, how many WindowsCE machines are fully (means all the features as
provided by Windows CE) supported by LinuxSH and how many machines are
partially(only few features) supported by LinuxSH ?

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

[patch] severe softirq handling performance bug, fix, 2.4.5

[Ingo Molnar]

i've been seeing really bad average TCP latencies on certain gigabit cards
(~300-400 microseconds instead of the expected 100-200 microseconds), ever
since softnet went into the main kernel, and never found a real
explanation for it, until today.

the problem always went away when i tried to use tcpdump or strace, so the
bug remained hidden and was hard to prove that it actually existed. (apart
from the bad lat_tcp numbers.) We found many related bugs, but this
problem remained. tcpdumps done on the network did not show any fault of
the TCP stack. The lat_tcp latencies fluctuated alot, but for certain
cards the latencies were stable, so i suspected some sort of hw problem.
The loopback networking device never showed these problems, which added to
the mystery.

the problem turned out to be a severe softirq handling bug in the x86
code.

background: soft interrupts were introduced as a generic kernel framework
around January 2000, as part of the softnet networking-rewrite, that
predated the final scalability rewrite of the Linux TCP/IP networking
code. Soft interrupts have unique semantics, they can be best described as
'IRQ-triggered atomic system calls'. (unlike bottom halves, soft-IRQs do
not preempt kernel code.)

soft-IRQs, like their name suggest, are used from device interrupts ('hard
interrupts') to trigger 'background' work related to interrupts. Soft-IRQs
are triggered per-CPU, and they are supposed to execute whenever nothing
else is done by the kernel on that particular CPU. Softirqs are executed
with interrupts enabled, so hard interrupts can re-enable them while they
are executing. do_softirq() is a kernel function that returns with IRQs
disabled and at this point it's guaranteed that there are no more pending
softirqs for this CPU.

this mechanizm was the intention, but not the reality. In two important
and frequently used code paths it was possible for an active soft-IRQ to
"go unnoticed": i measured as long as 140 milliseconds (!!!) latency
between softirq activation and softirq execution in certain cases. This is
obviously bad behavior.

the two error cases are:

 #1 hard-IRQ interrupts user-space code, activates softirq, and returns to
user-space code

 #2 hard-IRQ interrupts the idle task, activates softirq and returns to
the idle task.

category #1 is easy to fix, in entry.S we have to check active softirqs
not only the exception and ret-from-syscall cases, but also in the
IRQ-ret-to-userspace case.

category #2 is subtle, because the idle process is kernel code, so
returning to it we do not execute active softirqs. The main two types of
idle handlers both had a window do 'miss' softirq execution:

- the HLT-based default handler could be called after schedule()'s check
  for softirqs, but after enabling IRQs. In this case an interrupt handler
  has a window to activate a softirq and neither the IRQ return code, nor
  the idle loop would execute it immediately. The fix is to do a softirq
  check right before the safe_halt call.

- the idle-poll handler does not check for softirqs either, it now does
  this in every iteration.

with the attached softirq-2.4.5-A0 patch applied to vanilla 2.4.5, i see
picture-perfect lat_tcp latencies of 109 microseconds over real gigabit
network. I see very stable (and very good) TUX latencies as well. TCP
bandwidth got better as well, probably due to the caching-locality bonus
when executing softirqs right after hardirqs.

[I'd like to ask everyone who had TCP latency problems (or other
networking performance problems) to test 2.4.5 with this patch applied -
thanks!]

impact of the bug: all softirq-using code is affected, mostly networking.
The loopback net driver was not affected because it's not interrupt-based.
The bug went away due to strace or tcpdump because those two utilities
pumped system-calls into the system which 'fixed' the softirq handling
bug.

(other softirq-based code is the tasklet code, and the keyboard code is
using tasklets, so the keyboard code might be affected as well.)

Ingo


--- linux/arch/i386/kernel/entry.S.orig Sat May 26 19:20:48 2001
+++ linux/arch/i386/kernel/entry.S  Sat May 26 19:21:52 2001
@@ -214,7 +214,6 @@
 #endif
jne   handle_softirq

-ret_with_reschedule:
cmpl $0,need_resched(%ebx)
jne reschedule
cmpl $0,sigpending(%ebx)
@@ -275,7 +274,7 @@
movl EFLAGS(%esp),%eax  # mix EFLAGS and CS
movb CS(%esp),%al
testl $(VM_MASK | 3),%eax   # return to VM86 mode or non-supervisor?
-   jne ret_with_reschedule
+   jne ret_from_sys_call
jmp restore_all
 
ALIGN
--- linux/arch/i386/kernel/process.c.orig   Sat May 26 19:21:56 2001
+++ linux/arch/i386/kernel/process.cSat May 26 19:28:06 2001
@@ -79,8 +79,12 @@
  */
 static void default_idle(void)
 {
+   int this_cpu = smp_processor_id();
+
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();

Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

It should note, though, that -not- using CONFIG_ALPHA_GENERIC seems to
have a detrimental effect on my machines, in 2.4.5 vanilla.

When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails. 
It probes the drives ok, on boot, but a logic hang occurs where no more
boot progress can be made.  All I get are "hda: lost interrupt"
messages.  I am booting w/ aboot 0.7a from SRM, -without- the
srm-as-bootloader kernel config option.  These problems go away when
using the generic MDK alpha kernel, which is based on Alan's '2.4.4-ac'
patchkit, and uses CONFIG_ALPHA_GENERIC.

A very similar problem occurs on my new test alpha, a miata.  With
CONFIG_ALPHA_MIATA, IDE fails with "hda: lost interrupt" as above, but
additionally, the keyboard is no longer recognized.  Again, with MDK(ac)
kernel, things work fine.

After wondering for a while what magic was in the 'ac' patchkit, I
realized that my build needed CONFIG_ALPHA_GENERIC to work.  Tested that
theory... sure enough, I can boot 2.4.5-vanilla no problems now.

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

[Daniel Phillips]

On Saturday 26 May 2001 05:07, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > Oops, oh wait, there's already another open point: your breakage
> > examples both rely on opening ".".  You're right, "." should always
> > be a directory and I believe that's enforced by the VFS.  So we
> > don't have an example of breakage yet.
>
> That's just because I did a simple "ls".  But it doesn't make a
> difference.  The magicdevs _are_ directories and
>
>   chdir("magicdev");
>   open(".", O_RDONLY);
>
> shouldn't open the device.

It won't, the open for "." is handled in the VFS, not the filesystem - 
it will open the directory.  (Without needing to be told it's a 
directory via O_DIRECTORY.)  If you do open("magicdev") you'll get the 
device, because that's handled by magicdevfs.

I'm not claiming there isn't breakage somewhere, just that we didn't 
find it on this attempt.

--
Daniel

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

[PATCH] comx-hw-mixcom.c interrupt flag cleanup (244-ac18)

[Rasmus Andersen]

(Forgot l-k when sending this off to [EMAIL PROTECTED] :/)

Hi.

The following patch tries to eliminate the interrupt flag bugs
identified by the stanford team a while back in drivers/net/wan/
comx-hw-mixcom.c. It moves request_region and request_irq outside
the cli()/restore_flags() pair as they can sleep and cleans up
some error paths wrt. resource deallocation. It applies against
244-ac18.

Comments would be nice as this is not my day job :)



--- linux-244-ac18-clean/drivers/net/wan/comx-hw-mixcom.c   Mon Dec 11 22:38:29 
2000
+++ linux-244-ac18/drivers/net/wan/comx-hw-mixcom.c Sat May 26 22:45:44 2001
@@ -487,15 +487,18 @@
struct mixcom_privdata *hw = ch->HW_privdata;
struct proc_dir_entry *procfile = ch->procdir->subdir;
unsigned long flags; 
+   int ret = -ENODEV;
 
-   if (!dev->base_addr || !dev->irq) return -ENODEV;
+   if (!dev->base_addr || !dev->irq)
+   goto err_ret;
 
 
if(hw->channel==1) {
if(!TWIN(dev) || !(COMX_CHANNEL(TWIN(dev))->init_status & 
IRQ_ALLOCATED)) {
printk(KERN_ERR "%s: channel 0 not yet 
initialized\n",dev->name);
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto err_ret;
}
}
 
@@ -503,28 +506,29 @@
/* Is our hw present at all ? Not checking for channel 0 if it is already 
   open */
if(hw->channel!=0 || !(ch->init_status & IRQ_ALLOCATED)) {
-   if (check_region(dev->base_addr, MIXCOM_IO_EXTENT)) {
-   return -EAGAIN;
+   if (!request_region(dev->base_addr, MIXCOM_IO_EXTENT, dev->name)) {
+   ret = -EAGAIN;
+   goto err_ret;
}
if (mixcom_probe(dev)) {
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_release_region;
}
}
 
-   save_flags(flags); cli();
-
-   if(hw->channel==1) {
-   request_region(dev->base_addr, MIXCOM_IO_EXTENT, dev->name);
-   } 
-
if(hw->channel==0 && !(ch->init_status & IRQ_ALLOCATED)) {
if (request_irq(dev->irq, MIXCOM_interrupt, 0, 
dev->name, (void *)dev)) {
printk(KERN_ERR "MIXCOM: unable to obtain irq %d\n", dev->irq);
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto err_restore_flags;
}
+   }
+
+   save_flags(flags); cli();
+
+   if(hw->channel==0 && !(ch->init_status & IRQ_ALLOCATED)) {
ch->init_status|=IRQ_ALLOCATED;
-   request_region(dev->base_addr, MIXCOM_IO_EXTENT, dev->name);
mixcom_board_on(dev);
}
 
@@ -560,6 +564,13 @@
}
 
return 0;
+   
+err_restore_flags:
+   restore_flags(flags);
+err_release_region:
+   release_region(dev->base_addr, MIXCOM_IO_EXTENT);
+err_ret:
+   return ret;
 }
 
 static int MIXCOM_close(struct net_device *dev)

-- 
Rasmus([EMAIL PROTECTED])

"I'm not going to have some reporters pawing through our papers. We are
the president."  -Hillary Clinton commenting on the release of subpoenaed
documents.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-2.4.5

[Ingo Molnar]

On Sat, 26 May 2001, Andrea Arcangeli wrote:

> On Sat, May 26, 2001 at 02:11:15PM -0400, Ben LaHaise wrote:
> > No.  It does not fix the deadlock.  Neither does the patch you posted.
>
> can you give a try if you can deadlock 2.4.5aa1 just in case, and post a
> SYSRQ+T + system.map if it still deadlocks?

Andrea, can you rather start running the Cerberus testsuite instead? All
these deadlocks happen pretty early during the test, and we've been fixing
tons of these deadlocks, and no, it's not easy.

Ingo

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

[PATCH] fix interrupt flag bugs in irport.c (2.4.4-ac18)

[Rasmus Andersen]

Hi.

The following patch tries to correct the interrupt bugs found
by the stanford team a long time ago in drivers/net/irda/irport.c.
Applies against 2.4.4-ac18.


--- linux-244-ac18-clean/drivers/net/irda/irport.c  Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irport.cSat May 26 21:35:59 2001
@@ -951,13 +951,17 @@
switch (cmd) {
case SIOCSBANDWIDTH: /* Set bandwidth */
if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
-   irda_task_execute(self, __irport_change_speed, NULL, NULL, 
- (void *) irq->ifr_baudrate);
+   ret = -EPERM;
+else
+   irda_task_execute(self, __irport_change_speed, NULL, 
+ NULL, (void *) irq->ifr_baudrate);
break;
case SIOCSDONGLE: /* Set dongle */
-   if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
+   if (!capable(CAP_NET_ADMIN)) {
+   ret = -EPERM;
+   break;
+   }
+
/* Initialize dongle */
dongle = irda_device_dongle_init(dev, irq->ifr_dongle);
if (!dongle)
@@ -978,16 +982,22 @@
  NULL);
break;
case SIOCSMEDIABUSY: /* Set media busy */
-   if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
+   if (!capable(CAP_NET_ADMIN)) {
+   ret = -EPERM;
+   break;
+   }
+
irda_device_set_media_busy(self->netdev, TRUE);
break;
case SIOCGRECEIVING: /* Check if we are receiving right now */
irq->ifr_receiving = irport_is_receiving(self);
break;
case SIOCSDTRRTS:
-   if (!capable(CAP_NET_ADMIN))
-   return -EPERM;
+   if (!capable(CAP_NET_ADMIN)) {
+   ret = -EPERM;
+   break;
+   }
+
irport_set_dtr_rts(dev, irq->ifr_dtr, irq->ifr_rts);
break;
default:

-- 
Regards,
Rasmus([EMAIL PROTECTED])

A great many people think they are thinking when they are merely 
rearranging their prejudices. -- William James 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] softirq-2.4.5-A1

[Ingo Molnar]

i've attached the next round of softirq-handling fixes.

correctness fixes:

 - check for softirqs in the signal return path(s)

 - make sure all the entry.S return paths check for softirqs with
   interrupts disabled, otherwise we can end up getting another softirq
   right after the test. (and this causes a missed softirq.)

 - add softirq handling to the ACPI and APM code (untested)

performance tweaks:

 - remove __cli() from idle-poll, it's not needed.

 - separate exception handling and irq-ret path to avoid double-checking
   for softirqs

with this -A1 patch applied, softirqs should be executed by the kernel at
the first possible place, and there should be no unlimited softirq
latencies anymore.

patch is against vanilla 2.4.5 (patch includes the previous fixes as
well). The patch compiles, boots and works just fine on x86 SMP.

Ingo


--- linux/drivers/acpi/cpu.c.orig   Sat May 26 21:12:01 2001
+++ linux/drivers/acpi/cpu.cSat May 26 21:14:39 2001
@@ -231,10 +231,14 @@
sleep_level = 1;
acpi_sleep_on_busmaster();
for (;;) {
+   int this_cpu = smp_processor_id();
unsigned long time;
unsigned long diff;
 
__cli();
+   if (softirq_active(this_cpu) & softirq_mask(this_cpu))
+   do_softirq();
+
if (current->need_resched)
goto out;
time = acpi_read_pm_timer();
--- linux/arch/i386/kernel/entry.S.orig Thu Nov  9 02:09:50 2000
+++ linux/arch/i386/kernel/entry.S  Sat May 26 21:21:39 2001
@@ -133,6 +133,17 @@
movl $-8192, reg; \
andl %esp, reg
 
+#ifdef CONFIG_SMP
+# define CHECK_SOFTIRQ \
+   movl processor(%ebx),%eax; \
+   shll $CONFIG_X86_L1_CACHE_SHIFT,%eax; \
+   movl SYMBOL_NAME(irq_stat)(,%eax),%ecx; \
+   testl SYMBOL_NAME(irq_stat)+4(,%eax),%ecx
+#else
+# define CHECK_SOFTIRQ \
+   movl SYMBOL_NAME(irq_stat),%ecx; \
+   testl SYMBOL_NAME(irq_stat)+4,%ecx
+#endif
 ENTRY(lcall7)
pushfl  # We get a different stack layout with call gates,
pushl %eax  # which has to be cleaned up later..
@@ -203,18 +214,10 @@
call *SYMBOL_NAME(sys_call_table)(,%eax,4)
movl %eax,EAX(%esp) # save the return value
 ENTRY(ret_from_sys_call)
-#ifdef CONFIG_SMP
-   movl processor(%ebx),%eax
-   shll $CONFIG_X86_L1_CACHE_SHIFT,%eax
-   movl SYMBOL_NAME(irq_stat)(,%eax),%ecx  # softirq_active
-   testl SYMBOL_NAME(irq_stat)+4(,%eax),%ecx   # softirq_mask
-#else
-   movl SYMBOL_NAME(irq_stat),%ecx # softirq_active
-   testl SYMBOL_NAME(irq_stat)+4,%ecx  # softirq_mask
-#endif
-   jne   handle_softirq
+   cli
+   CHECK_SOFTIRQ
+   jne handle_softirq

-ret_with_reschedule:
cmpl $0,need_resched(%ebx)
jne reschedule
cmpl $0,sigpending(%ebx)
@@ -230,6 +233,13 @@
jne v86_signal_return
xorl %edx,%edx
call SYMBOL_NAME(do_signal)
+#ifdef CONFIG_SMP
+   GET_CURRENT(%ebx)
+#endif
+   cli
+   CHECK_SOFTIRQ
+   je restore_all
+   call SYMBOL_NAME(do_softirq)
jmp restore_all
 
ALIGN
@@ -238,6 +248,13 @@
movl %eax,%esp
xorl %edx,%edx
call SYMBOL_NAME(do_signal)
+#ifdef CONFIG_SMP
+   GET_CURRENT(%ebx)
+#endif
+   cli
+   CHECK_SOFTIRQ
+   je restore_all
+   call SYMBOL_NAME(do_softirq)
jmp restore_all
 
ALIGN
@@ -260,22 +277,22 @@
 ret_from_exception:
 #ifdef CONFIG_SMP
GET_CURRENT(%ebx)
-   movl processor(%ebx),%eax
-   shll $CONFIG_X86_L1_CACHE_SHIFT,%eax
-   movl SYMBOL_NAME(irq_stat)(,%eax),%ecx  # softirq_active
-   testl SYMBOL_NAME(irq_stat)+4(,%eax),%ecx   # softirq_mask
-#else
-   movl SYMBOL_NAME(irq_stat),%ecx # softirq_active
-   testl SYMBOL_NAME(irq_stat)+4,%ecx  # softirq_mask
 #endif
+   cli
+   CHECK_SOFTIRQ
jne   handle_softirq
+   cmpl $0,need_resched(%ebx)
+   jne reschedule
+   cmpl $0,sigpending(%ebx)
+   jne signal_return
+   jmp restore_all
 
 ENTRY(ret_from_intr)
GET_CURRENT(%ebx)
movl EFLAGS(%esp),%eax  # mix EFLAGS and CS
movb CS(%esp),%al
testl $(VM_MASK | 3),%eax   # return to VM86 mode or non-supervisor?
-   jne ret_with_reschedule
+   jne ret_from_sys_call
jmp restore_all
 
ALIGN
--- linux/arch/i386/kernel/process.c.orig   Sat May 26 20:54:30 2001
+++ linux/arch/i386/kernel/process.cSat May 26 21:17:05 2001
@@ -79,8 +79,12 @@
  */
 static void default_idle(void)
 {
+   int this_cpu = smp_processor_id();
+
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
+   if 

Re: Linux-2.4.5

[Rik van Riel]

On Sat, 26 May 2001, Andrea Arcangeli wrote:

> > > - /* 
> > > -  * Set our state for sleeping, then check again for buffer heads.
> > > -  * This ensures we won't miss a wake_up from an interrupt.
> > > -  */
> > > - wait_event(buffer_wait, nr_unused_buffer_heads >= MAX_BUF_PER_PAGE);
> > > + current->policy |= SCHED_YIELD;
> > > + __set_current_state(TASK_RUNNING);
> > > + schedule();
> > >   goto try_again;
> > >  }

I'm still curious ... is it _really_ needed to busy-spin here?

I've seen some big problems with processes eating CPU time
while not getting any work done and am slowly trying to
eliminate those places in the VM by waiting on things.

Is it really needed to introduce a new busy-wait place in the
kernel?

regards,

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

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

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

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

Re: Linux-2.4.5

[Andrea Arcangeli]

On Sat, May 26, 2001 at 02:11:15PM -0400, Ben LaHaise wrote:
> No.  It does not fix the deadlock.  Neither does the patch you posted.

can you give a try if you can deadlock 2.4.5aa1 just in case, and post a
SYSRQ+T + system.map if it still deadlocks?

> But, if you're going to add a reserve pool for buffer heads and bounce
> pages, please do it with generic, not yet another special case hack.

The reserved pool for buffer heads is there since the first time I used
linux I think. I won't certainly object to convert  all reserved pool to
an unified interface, as I'd like if all hashtables would be also sized
with an unified interface, but that's just a stylistic issue, at least
for 2.4 that's a very secondary object compared to people who can get
dealdocks during production.

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

cb_enabler.o / 2.4.5 kernel

[Peter DiCostanzo Jr]

I have a xircom cardbus card, that is not working unless i put it in
promisc mode.. i got a patch to fix it but it seems its already in
there... i did notice however, that using the same kernelconfig as my
2.4.4 kernel that cb_enabler.o is not being installed.  A BROKEN symlink
exists in /lib/modules/2.4.5/pcmcia/cb_enabler.o ->
../kernel/drivers/pcmcia/cb_enabler.o  Anyone know why its not being
installed?  (Its under a RH 7.1 box.. the 2.4.4 kernel was fine.)

thanks!
-pete

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

kernel BUG at inode.c:654!

[Santiago Garcia Mantinan]

Hi!

That's what my server, wich is running 2.4.5, was shouting when I pluged in
my laptop at the console (ttyS0), all I could do was copy the output I was
seeing on minicom to a file, after rebooting I saw that the kernel had left
some of the logging on kern.log, so I'm attaching a file with both the stuff
on the console and the ones on the log.

The machine is an intel pentium 166 with 48 megs of mem, it has an stock
2.4.5 kernel with netfilter patches for the irc NAT, even though this
patches were working ok on 2.4.4 and don't seem to have anything to do with
this problem, I'm recompiling an stock 2.4.5 now, just to be sure.

Well, I don't know what else to say, if I'm missing something you want to
know, don't hesitate to ask.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

 log.bz2

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 05:20:29PM +0200, Ingo T. Storm wrote:
> sys_dp264.o: In function `tsunami_inb':
> sys_dp264.c(.text+0x440): multiple definition of `tsunami_inb'
> core_tsunami.o(.text+0x500):core_tsunami.c: first defined here
> sys_dp264.o: In function `clipper_map_irq':
> sys_dp264.c(.text+0x480): multiple definition of `tsunami_inw'
> core_tsunami.o(.text+0x540):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_inl':
> sys_dp264.c(.text+0x4c0): multiple definition of `tsunami_inl'
> core_tsunami.o(.text+0x580):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_outb':
> sys_dp264.c(.text+0x460): multiple definition of `tsunami_outb'
> core_tsunami.o(.text+0x520):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_outw':
> sys_dp264.c(.text+0x4a0): multiple definition of `tsunami_outw'
> core_tsunami.o(.text+0x560):core_tsunami.c: first defined here
> sys_dp264.o: In function `dp264_init_pci':
> sys_dp264.c(.text+0x4e0): multiple definition of `tsunami_outl'
> core_tsunami.o(.text+0x5a0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readb':
> sys_dp264.c(.text+0x540): multiple definition of `tsunami_readb'
> core_tsunami.o(.text+0x600):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readw':
> sys_dp264.c(.text+0x560): multiple definition of `tsunami_readw'
> core_tsunami.o(.text+0x620):core_tsunami.c: first defined here
> sys_dp264.o: In function `webbrick_init_arch':
> sys_dp264.c(.text+0x580): multiple definition of `tsunami_readl'
> core_tsunami.o(.text+0x640):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readq':
> sys_dp264.c(.text+0x5a0): multiple definition of `tsunami_readq'
> core_tsunami.o(.text+0x660):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writeb':
> sys_dp264.c(.text+0x5c0): multiple definition of `tsunami_writeb'
> core_tsunami.o(.text+0x680):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writew':
> sys_dp264.c(.text+0x5e0): multiple definition of `tsunami_writew'
> core_tsunami.o(.text+0x6a0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writel':
> sys_dp264.c(.text+0x600): multiple definition of `tsunami_writel'
> core_tsunami.o(.text+0x6c0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writeq':
> sys_dp264.c(.text+0x620): multiple definition of `tsunami_writeq'
> core_tsunami.o(.text+0x6e0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_ioremap':
> sys_dp264.c(.text+0x500): multiple definition of `tsunami_ioremap'
> core_tsunami.o(.text+0x5c0):core_tsunami.c: first defined here
> sys_dp264.o: In function `monet_init_pci':
> sys_dp264.c(.text+0x520): multiple definition of `tsunami_is_ioaddr'
> core_tsunami.o(.text+0x5e0):core_tsunami.c: first defined here
> make[1]: *** [kernel.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/alpha/kernel'
> make: *** [_dir_arch/alpha/kernel] Error 2

I got exactly the above when compiling for dp264 so I sent to Linus a
patch to fix those compile problems, now I suspect my fix broke the
generic compile :(, I will check that.

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

2.4.5aa1

[Andrea Arcangeli]

I merged Rik's three liner fix to alloc_pages for GFP_BUFFER, plus my
other fix in create_buffers wait_event and a bit bigger reserved pool of
async bh. I'd suggest to test if this makes the highmem deadlock to go
away.

Detailed description of 2.4.5aa1 follows.

---
00_alpha-illegal-irq-1

Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number
is getting run.

(debugging)

00_boot-serial-console-1

Allows the serial console to work anytime during boot. It may have side
effects but certainly nothing relevant and the current situation was
annoying enough.

(nice to have)

00_create_buffers-deadlock-1

Fix tasks possibly deadlocking in wait_event because the unused_list
isn't refilled at I/O completion anymore with the 2.4
pagecache(/swapcache) design.

(recommended)

00_eepro100-64bit-1

Fixes a 64bit bug that was generating false positives and memory
corruption.

(recommended)

00_eepro100-alpha-1

Possibly fix the eepro100 transmitter hang on alpha by doing atomic PIO
updates to avoid the clear_suspend to be lost.

(recommended)

00_gfp_buffer-alloc-pages-deadlock-1

Fix from Rik that avoids GFP_BUFFER to deadlock inside alloc_pages().

This is by no means a definitive fix for the VM deadlocks during oom,
all other __GFP_IO allocations can still dealdock inside alloc_pages()
like before. But it is a first step in the right direction I think.

Please try to beat 2.4.5aa1 hard and see if you can reproduce deadlocks
with highmem.

(recommended)

00_cachelinealigned-in-smp-1

Moves the pagecache_lock and the VM pagemap_lru_lock in two
different L1 cachelines to avoid contention, mostly useful on
the alpha where the spinlocks uses load locked store
conditional loops (and we don't want to loop).

(nice to have)

00_copy-user-lat-2

Put the rechedule points into copy-user calls, with lots of
cache large read/writes could otherwise _never_ reschedule
once until they returns to userspace.

(recommended)

00_cpus_allowed-1

Fixes a bug in the cpu affinity in-kernel API, bug was fatal
for ksoftirqd.

(recommended)

00_double-buffer-pass-1

Avoids looping two times for no good reason into the lru lists
of the buffer cache (the double loop was an unreliable hack
from the prehistory that survided 'till today).

(nice to have)

00_exception-table-1

Avoids a compilation warning when compiling without modules.

(very minor thing)

00_highmem-deadlock-3

Fixes an highmem deadlock using a reserved pool for the bounce
buffers.

(recommended)

00_highmem-debug-1

Allows people with x86 machines with less than 1G of ram to
test the highmem code.

(debugging)

00_ia32-bootmem-corruption-1

Fixes the x86 boot stage to finish initializing all the
reserved memory before starting allocating memory.

(recommended)

00_ipv6-null-oops-1

Fixes null pointer oops.

(recommended)

00_jens-loop-noop-nobounce-1

Skips the bounces with the null transfer function.

(nice to have)

00_ksoftirqd-4

Avoids 1/HZ latency for the softirq if the softirq is marked
again pending when do_softirq() finished and the machine is
otherwise idle, it also fixes the case of a softirq re-marking
itself runnable by delegating to the scheduler the balance of
the softirq load like if it would be an normal task.

(nice to have)

00_kupdate-large-interval-1

Allows to set large interval for the kupdate runs, this is
useful on the laptops, instead of sigstopping ksoftirqd it's
nicer to set a large interval for example of the order of one
hour (do that at your own risk of course, doing that is not
recommended unless you know what you're doing).

(nice to have)

00_lvm-0.9.1_beta7-4

Updates to the lvmbeta7 with fixes for the lv hardsectsize
estimantion based on the max hardsectsize of the underlying
pv, plus it has some other tons of fixes and it is a must have
for the 64bit archs as the IOP silenty changed for those
platforms.

(recommended)

00_max_readahead-1

Increases the max_readahead to allow the blkdev to read with
512k scsi commands when possible.

(nice to have)

00_msync-fb0-1

Fixes oopses while running msync on a region of virtual memory
that maps to reserved memory.

(recommended)

00_nfs-corruption-3

Production fix for the nfs map_shared fs data
corruption. Other design solutions are discussed and the long
term fix migh

Re: Linux-2.4.5

[Rik van Riel]

On Sat, 26 May 2001, Linus Torvalds wrote:
> On Sat, 26 May 2001, Rik van Riel wrote:
> > 
> > O, that part is fixed by the patch that Linus threw away
> > yesterday ;)
> 
> Rik, I threw away the parts of the patch that were bad and obvious
> band-aids, and it was hard to tell whether any of your patch was a
> "real" fix as opposed to just making more reservations.

1) Remove GFP_BUFFER and HIGHMEM related deadlocks, by letting
   these allocations fail instead of looping forever in
   __alloc_pages() when they cannot make any progress there.

It's the changes to __alloc_pages(), where we don't loop forever
but fail the allocation.

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

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

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


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